[Samba] ridiculous slow gigabit transfer, faster with VNC

[Mark Baily]

Hi,
I have a problem with file transfers between a windows systems and unix systems.
I have one win32 desktop (intel e6400 2Gb Ram), one win32 laptop (p-m 2Ghz).
Also one linux laptop (p-m 1.4GHz) and one opensolaris desktop (intel
e4400 1GB Ram).

The two laptops have built-in 100Mbit ethernet and desktops have 1Gbit
ethernet on the motherboard. Both desktops use a Marvell Yukon.

The file transfer rate between two systems using FTP between the two
desktops (win32 to opensolaris) is consistently 50Mb/sec which is as
expected.

Using scp I only get 5Mb/sec between from any win32 system to any unix
system, much slower than expected.

Using scp from the linux lapotp to solaris desktop is 10Mb/sec as
expected (laptop has 100mbit only).

Using samba to copy a 1GB file I get about 7 minutes from win32 to
opensolaris. From opensolaris to win32 the windows dialog says
estiamted time 142 mins. Using plain FTP it takes 25sec. This is very
consistent.

A twist is that if a VNC client is open from the win32 desktop to the
opensolaris box the estimated transfer time via samba from opensolaris
to win32 drops right down to about 4 min. Much better, but still
nowhere near the FTP.

I have also tried swapping between a D-Link DGS-1008D switch and a
Netgear GS105 switch with no difference.

Since the FTP is very consistently acheiving 50megabytes/sec, I don't
think it can be blamed on a hardware fault.

However the problem doesn't appear to be just samba either, as the
slowness also occurs with scp, albiet scp is much more consistent at
5mb/sec than samba varying at 1GB/142min to 1GB/3min with VNC open.

Is this problem something to do with TCP stacks playing up? What else
might it be?

Thanks

[Mike]

Mark,
I have noted the same behavior many times.
I have an old server box that has not been upgraded since ver. 2.2.8.
Whenever I connect from a linux box using sftp in a terminal, I get
top speed 10/100 ethernet transfer rates over the LAN -- 10 Megs/sec.
- 12 Megs/sec.
When I use WinSCP (from a win client box), I get no more than 2
Megs/sec. transfer rate.

I wish I could articulate the why, but I cannot.
But it doesn't appear to be a Samba issue, it seems to me that the
software applications we are using handle TCP data transfer very
differently and are optimized to do things very differently.

I can add some anecdotal evidence regarding VNC ---
I use RealVNC between my work winbox and a Win Server 2003 and
sometimes transfer 1 Gig. .iso files between them. I never measured
exactly, but from memory I know it always takes at least 5 minutes
over my 10/100 LAN. Optimally, it should require no more than 2
minutes to complete such a transfer. I don't mean to compare apples
vs. oranges (win/linux transfers vs. win/win transfers) but I think it
helps to show it's the transfer software and probably not win, or
linux, or samba.

I hope someone else on the list with more empirical knowledge can
confirm and provide the "why".

HTH,

Mike

Post by Mark Baily
Hi,
I have a problem with file transfers between a windows systems and unix systems.
I have one win32 desktop (intel e6400 2Gb Ram), one win32 laptop (p-m 2Ghz).
Also one linux laptop (p-m 1.4GHz) and one opensolaris desktop (intel
e4400 1GB Ram).
The two laptops have built-in 100Mbit ethernet and desktops have 1Gbit
ethernet on the motherboard. Both desktops use a Marvell Yukon.
The file transfer rate between two systems using FTP between the two
desktops (win32 to opensolaris) is consistently 50Mb/sec which is as
expected.
Using scp I only get 5Mb/sec between from any win32 system to any unix
system, much slower than expected.
Using scp from the linux lapotp to solaris desktop is 10Mb/sec as
expected (laptop has 100mbit only).
Using samba to copy a 1GB file I get about 7 minutes from win32 to
opensolaris. From opensolaris to win32 the windows dialog says
estiamted time 142 mins. Using plain FTP it takes 25sec. This is very
consistent.
A twist is that if a VNC client is open from the win32 desktop to the
opensolaris box the estimated transfer time via samba from opensolaris
to win32 drops right down to about 4 min. Much better, but still
nowhere near the FTP.
I have also tried swapping between a D-Link DGS-1008D switch and a
Netgear GS105 switch with no difference.
Since the FTP is very consistently acheiving 50megabytes/sec, I don't
think it can be blamed on a hardware fault.
However the problem doesn't appear to be just samba either, as the
slowness also occurs with scp, albiet scp is much more consistent at
5mb/sec than samba varying at 1GB/142min to 1GB/3min with VNC open.
Is this problem something to do with TCP stacks playing up? What else
might it be?
Thanks
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

[samba at jdmc.org ()]

Post by Mike
Mark,
I have noted the same behavior many times.
I have an old server box that has not been upgraded since ver. 2.2.8.
Whenever I connect from a linux box using sftp in a terminal, I get
top speed 10/100 ethernet transfer rates over the LAN -- 10 Megs/sec.
- 12 Megs/sec.
When I use WinSCP (from a win client box), I get no more than 2
Megs/sec. transfer rate.

I ran into this when trying to rsync backups on a brand new gig-eth
card on a 2.6.x kernel machine. Funny thing was, not only was the
slow down machine specific, it was service specific as well. The
following MAY work for you ...

#!/bin/sh

/sbin/sysctl -w net.core.rmem_max=107374182
/sbin/sysctl -w net.core.wmem_max=107374182
/sbin/sysctl -w net.core.rmem_default=107374182
/sbin/sysctl -w net.core.wmem_default=107374182
/sbin/sysctl -w net.core.optmem_max=107374182
/sbin/sysctl -w net.ipv4.tcp_rmem="107374182 107374182 107374182"
/sbin/sysctl -w net.ipv4.tcp_wmem="107374182 107374182 107374182"
/sbin/sysctl -w net.ipv4.tcp_mem="107374182 107374182 107374182"
/sbin/sysctl -w net.core.netdev_max_backlog=1000
/sbin/ifconfig eth0 txqueuelen 1000
/sbin/sysctl -w net.ipv4.route.flush=1
/sbin/sysctl -w net.ipv4.tcp_no_metrics_save=1
/usr/sbin/ethtool -K eth0 tso off
# For Intel e1000 NIC Users: Add "options e1000 RxDescriptors=4096" into
/etc/modules.conf



This message is confidential, intended only for the named recipient(s) and
may contain information that is privileged or exempt from disclosure under
applicable law. If you are not the intended recipient(s), you are
notified that the dissemination, distribution or copying of this message
is strictly prohibited. If you receive this message in error, or are not
the named recipient(s), please notify the sender at the e-mail address
above and delete this e-mail from your computer. Thank you.

[Mike]

Post by samba at jdmc.org ()
I ran into this when trying to rsync backups on a brand new gig-eth
card on a 2.6.x kernel machine. Funny thing was, not only was the
slow down machine specific, it was service specific as well. The
following MAY work for you ...
#!/bin/sh
/sbin/sysctl -w net.core.rmem_max=107374182
/sbin/sysctl -w net.core.wmem_max=107374182
/sbin/sysctl -w net.core.rmem_default=107374182
/sbin/sysctl -w net.core.wmem_default=107374182
/sbin/sysctl -w net.core.optmem_max=107374182
/sbin/sysctl -w net.ipv4.tcp_rmem="107374182 107374182 107374182"
/sbin/sysctl -w net.ipv4.tcp_wmem="107374182 107374182 107374182"
/sbin/sysctl -w net.ipv4.tcp_mem="107374182 107374182 107374182"
/sbin/sysctl -w net.core.netdev_max_backlog=1000
/sbin/ifconfig eth0 txqueuelen 1000
/sbin/sysctl -w net.ipv4.route.flush=1
/sbin/sysctl -w net.ipv4.tcp_no_metrics_save=1
/usr/sbin/ethtool -K eth0 tso off
# For Intel e1000 NIC Users: Add "options e1000 RxDescriptors=4096" into
/etc/modules.conf

hmm, i've never played with anything like this before.
Thanks!
I'll do some reading on sysctl and give a try.

[Mark Baily]

Correction, the win32 Desktop has a Marvell Yukon 88E8056 PCI-E
Gigabit Ethernet Controller (PCI 11ab 4364)

The opensolaris desktop has a Realtek RTL8168/8111 PCI-E Gigabit
Ethernet NIC. (PCI 8168 1458).

Post by Mark Baily
Hi,
I have a problem with file transfers between a windows systems and unix systems.
I have one win32 desktop (intel e6400 2Gb Ram), one win32 laptop (p-m 2Ghz).
Also one linux laptop (p-m 1.4GHz) and one opensolaris desktop (intel
e4400 1GB Ram).
The two laptops have built-in 100Mbit ethernet and desktops have 1Gbit
ethernet on the motherboard. Both desktops use a Marvell Yukon.
The file transfer rate between two systems using FTP between the two
desktops (win32 to opensolaris) is consistently 50Mb/sec which is as
expected.
Using scp I only get 5Mb/sec between from any win32 system to any unix
system, much slower than expected.
Using scp from the linux lapotp to solaris desktop is 10Mb/sec as
expected (laptop has 100mbit only).
Using samba to copy a 1GB file I get about 7 minutes from win32 to
opensolaris. From opensolaris to win32 the windows dialog says
estiamted time 142 mins. Using plain FTP it takes 25sec. This is very
consistent.
A twist is that if a VNC client is open from the win32 desktop to the
opensolaris box the estimated transfer time via samba from opensolaris
to win32 drops right down to about 4 min. Much better, but still
nowhere near the FTP.
I have also tried swapping between a D-Link DGS-1008D switch and a
Netgear GS105 switch with no difference.
Since the FTP is very consistently acheiving 50megabytes/sec, I don't
think it can be blamed on a hardware fault.
However the problem doesn't appear to be just samba either, as the
slowness also occurs with scp, albiet scp is much more consistent at
5mb/sec than samba varying at 1GB/142min to 1GB/3min with VNC open.
Is this problem something to do with TCP stacks playing up? What else
might it be?
Thanks

[Andrew Morgan]

Post by Mark Baily
Hi,
I have a problem with file transfers between a windows systems and unix systems.
I have one win32 desktop (intel e6400 2Gb Ram), one win32 laptop (p-m 2Ghz).
Also one linux laptop (p-m 1.4GHz) and one opensolaris desktop (intel
e4400 1GB Ram).
The two laptops have built-in 100Mbit ethernet and desktops have 1Gbit
ethernet on the motherboard. Both desktops use a Marvell Yukon.
The file transfer rate between two systems using FTP between the two
desktops (win32 to opensolaris) is consistently 50Mb/sec which is as
expected.
Using scp I only get 5Mb/sec between from any win32 system to any unix
system, much slower than expected.
Using scp from the linux lapotp to solaris desktop is 10Mb/sec as
expected (laptop has 100mbit only).
Using samba to copy a 1GB file I get about 7 minutes from win32 to
opensolaris. From opensolaris to win32 the windows dialog says
estiamted time 142 mins. Using plain FTP it takes 25sec. This is very
consistent.
A twist is that if a VNC client is open from the win32 desktop to the
opensolaris box the estimated transfer time via samba from opensolaris
to win32 drops right down to about 4 min. Much better, but still
nowhere near the FTP.
I have also tried swapping between a D-Link DGS-1008D switch and a
Netgear GS105 switch with no difference.
Since the FTP is very consistently acheiving 50megabytes/sec, I don't
think it can be blamed on a hardware fault.
However the problem doesn't appear to be just samba either, as the
slowness also occurs with scp, albiet scp is much more consistent at
5mb/sec than samba varying at 1GB/142min to 1GB/3min with VNC open.
Is this problem something to do with TCP stacks playing up? What else
might it be?

Have you confirmed that you do not have a duplex mismatch? I don't know
if D-Link or Netgear (consumer grade?) switches can be queried for the
duplex setting or forced to full duplex. Usually this stuff "just works",
but the behavior you describe sounds very much like the switch is half
duplex and the server is full duplex.

Andy

[Mark Baily]

I have checked the duplex setting in opensolaris and it has
autonegotiated with the switch at 1000Mbps (gigabit) and also
full-duplex. The switch itself has no means to query, it is an
unmanaged consumer switch.

Post by Andrew Morgan

Post by Mark Baily
Hi,
I have a problem with file transfers between a windows systems and unix systems.
I have one win32 desktop (intel e6400 2Gb Ram), one win32 laptop (p-m 2Ghz).
Also one linux laptop (p-m 1.4GHz) and one opensolaris desktop (intel
e4400 1GB Ram).
The two laptops have built-in 100Mbit ethernet and desktops have 1Gbit
ethernet on the motherboard. Both desktops use a Marvell Yukon.
The file transfer rate between two systems using FTP between the two
desktops (win32 to opensolaris) is consistently 50Mb/sec which is as
expected.
Using scp I only get 5Mb/sec between from any win32 system to any unix
system, much slower than expected.
Using scp from the linux lapotp to solaris desktop is 10Mb/sec as
expected (laptop has 100mbit only).
Using samba to copy a 1GB file I get about 7 minutes from win32 to
opensolaris. From opensolaris to win32 the windows dialog says
estiamted time 142 mins. Using plain FTP it takes 25sec. This is very
consistent.
A twist is that if a VNC client is open from the win32 desktop to the
opensolaris box the estimated transfer time via samba from opensolaris
to win32 drops right down to about 4 min. Much better, but still
nowhere near the FTP.
I have also tried swapping between a D-Link DGS-1008D switch and a
Netgear GS105 switch with no difference.
Since the FTP is very consistently acheiving 50megabytes/sec, I don't
think it can be blamed on a hardware fault.
However the problem doesn't appear to be just samba either, as the
slowness also occurs with scp, albiet scp is much more consistent at
5mb/sec than samba varying at 1GB/142min to 1GB/3min with VNC open.
Is this problem something to do with TCP stacks playing up? What else
might it be?

Have you confirmed that you do not have a duplex mismatch? I don't know
if D-Link or Netgear (consumer grade?) switches can be queried for the
duplex setting or forced to full duplex. Usually this stuff "just works",
but the behavior you describe sounds very much like the switch is half
duplex and the server is full duplex.
Andy

[Mark Baily]

Problem partially solved..
Using a D-LINK DGE-530T with the syskonnect skge 64-bit driver,
instead of using the inbuilt realtek NIC in the opensolaris box and
now samba works great, 25 sec to copy a 1GB file.

I've heard some other posts where realtek network chips were causing
probs, think I'll stay away from them in the future.

Re ping exchanges, this does indeed show up the differences. Pinging
from the opensolaris to the linux laptop works perfectly with ping
data sizes up to the IPV4 limit (65507). This works with both the
realtek NIC and the dlink NIC.

Pinging from the opensolaris to the win32 desktop the maximum ping
size I can get to work is 1472. As greater size results in 100% packet
loss. This is also with both NIC's.

Anyway I at least have the samba functionality I need. Would be nice
to sort out why the unix machines are fine with each other but
unix<->win32 seems to have much more problems at a basic networking
level. It could indeed be bad drivers etc.

Mark

Mark,
It might be worth checking that you can do large ping exchanges between the
affected systems ... eg in solaris try
/usr/sbin/ping -s clientpcname 64000
This sends several ethernet frames almost "back to back" and can show up
duplex problems as well as driver/buffering problems (common in PCs).
Steve

[Mark Baily]

I've now put a D-LINK DGE-530T in both the win32 desktop and the
opensolaris desktop. Both large pings and samba are working.

With the DGE-530T in the win32 and the realtek in the opensolaris,
large pings worked but samba was still 63mins estimated to transfer a
1G file. With the inbuilt Marvel Yukon in the win32 and the DGE-530T
in opensolaris large pings did not work but samba did work (25 sec).

With the DGE-530T in both, both large pings and samba work fine.

My lesson in this is to avoid any NIC built-in to the motherboard and
use a seperate high-quality NIC card.

Post by Mark Baily
Problem partially solved..
Using a D-LINK DGE-530T with the syskonnect skge 64-bit driver,
instead of using the inbuilt realtek NIC in the opensolaris box and
now samba works great, 25 sec to copy a 1GB file.
I've heard some other posts where realtek network chips were causing
probs, think I'll stay away from them in the future.
Re ping exchanges, this does indeed show up the differences. Pinging
from the opensolaris to the linux laptop works perfectly with ping
data sizes up to the IPV4 limit (65507). This works with both the
realtek NIC and the dlink NIC.
Pinging from the opensolaris to the win32 desktop the maximum ping
size I can get to work is 1472. As greater size results in 100% packet
loss. This is also with both NIC's.
Anyway I at least have the samba functionality I need. Would be nice
to sort out why the unix machines are fine with each other but
unix<->win32 seems to have much more problems at a basic networking
level. It could indeed be bad drivers etc.
Mark

Mark,
It might be worth checking that you can do large ping exchanges between the
affected systems ... eg in solaris try
/usr/sbin/ping -s clientpcname 64000
This sends several ethernet frames almost "back to back" and can show up
duplex problems as well as driver/buffering problems (common in PCs).
Steve

[Charles Marcus]

Post by Mark Baily
With the inbuilt Marvel Yukon in the win32 and the DGE-530T
in opensolaris large pings did not work but samba did work (25 sec).

I had lots of problems with the Marvel drivers that came through Windows
Update... did you at least try uninstalling the driver and reinstalling
the latest version downloaded directly from your MB driver site?

The MArvels work great - again, as long as you don't let Windows Update
update the driver.