samba - Jul 2007 - ridiculous slow gigabit transfer, faster with VNC

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

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




On 7/19/07, Mark Baily <mark16829@gmail.com>
wrote:
> 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
>

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).


On 7/19/07, Mark Baily <mark16829@gmail.com>
wrote:
> 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
>

On Thu, 19 Jul 2007, Mark Baily wrote:
> 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,
> 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.

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

On 7/20/07, Steve Platt <steve.platt@mrc-bsu.cam.ac.uk>
wrote:
>
> 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
>
>