OT: Windows and file share speeds

[Bill Vermillion]

Putting quill to paper and scribbling furiously on Fri, Aug 13 04:13  
Fairlight missed achieving immortality when he said: 

> Okay, blatantly OT, but I know at least one other person (JE,
> I believe) confirmed that he's experienced this, and I'm
> wondering if anyone else has seen it and knows -why- it is so.

> I have three computers. I can get a good 295KB/sec in and out
> of the 10b2 system, and 430-490KB/sec in and out of the two
> 10bT systems to and from each other using ftp. ...

> However, when using an SMB mounted share with samba (one is
> linux, one is win2k), or when sharing between win95 and win2k,
> the transfer rate is chopped down to about 150KB/sec maximum.
> ....

> I'm curious what about SMB actually causes this, since it
> happens between Windows systems and not just with samba. The
> timings all calculate out to about the same--roughly 155KB/sec,
> even though the slowest machine can do nearly twice that.

So I went looking when you asked this - and there is a LOT of
information.

SMB [Server Message Block] now renamed CIFS [Common Internet File
System] was developed by IBM and came into play in 1987. This was
before IMB and MS went their separate ways, and it was first
available on Window For Workgroups 3.zxx

Reading on the CIFS in notes on a Microsoft link it says
that "The CFIS protocol has been optimized to run well over slow
speed dialup lines"

I also see that in the smb.conf default there are the comments
on setting   SO_RCVBUF-8192   and SO_SNDFUF=8192 

I was pointed to this when I saw a reference to making transfers
in Unix/NT environments compe closer to the performance of
NT/NT connections.  

It also notes that the default Unix send buffer sizes are large -
and notes the FreeBSD is 16304.  However I see by querhing sysctl
on this system that my default smb buggers are 65535.

Other reference are to dropped packets.  The author of the doc I'm
looking at has not determined the packet drop cause, but notes that
when this happens it requests a resend and then it >appears< that
many acks are sent to be able to show how many bytes have been
successfully transmitted.

If many packets are dropped Samba it goes into a mode that delays
before blocks are sent and performance may drop to 1/20th in
a Unix <-> NT environment compared to Nt <-> NT environment.

[An aside - about 90% of the time I use ftp between my *n*x systems
except when I need to bring up pdf file on XP that are stored on
the FreeBSD.]

I've seen one discussion on the NIC drivers, and it noted that
since there is no source he used Windump [the MS equivalent of
tcpdump] the NIC card HE had show there is a delay of .1 second
switching between send/receive if there is traffic both ways.
He also noted it works fast with NT server but slowly with
a Samba server.

> I'd love to hear theories or be shown references. I'm at the
> point where I'm ready to stick apache on the win2k server and
> turn it back on the win95 server and just use http across all
> platforms, since it's easier than getting a decent ftpd for
> Windows.

As above - those aren't theories.  If you want reference perform a
google search.  Since I've done the searches under Lynx on another
sessions it's too hard to type in the the URLs I've looked at.

I normally use ftp >from< the NT platform.  Speed are about
wire-speed and I get very close to 10MB/sec on the 100Mbit
connection when transfering iso images [about 700MB] or
processed DVD images of 4GB.

And ftpd daemon is one of the few things not included with
SFU [Services for Unix].  But if you have Windows 2000 with the
approrpiate service packs, or XP or Server 2003,  SFU gives
you all the things you got used to in Unix.

Perl, awk, sed, grep, ksh, tcsh, sendmail, and on and on.
I just checked and there are 206 of the tools you are used to
in \SFU\bin.

I don't find the lack of an ftp daemon to be that bad since the
push via ftp TO the *n*x systems works so well.

And of course YMMV.

> If I want convenience, I just use SMB...I'll cp from linux to
> windows or the other way around off the mounted share. But
> considering I was moving 10gigs of data, I decided 7hrs was a
> bit more friendly than 20hrs or so. So I opened up the windows
> ftp client and had at it.

I find that running ftp from the command line is easier than
the windows client.

> But there shouldn't -be- a discrepancy unless SMB has a
> -really- bloated overhead. This wouldn't surprise me, but you'd
> have to really work hard to take a 60% speed hit.

See above.   And 60% hit isn't as bad as the worst.  Set
your send and receive buffers in your smb configuraiton file
and see if that helps.  The smb problems can be laid squarely in
the laps of IBM and MS - while the Unix sides seem to follow
all the accepted protocols MS often violates them at will.

> So I don't think it's bloated, but it's "off" in some
> odd way I can't seem to figure out.

Search google on   smb perfomance .  You'll even find articles
from Microsoft on how to patch the registry for the slow
performance with an XP client connecting to 2000 domain
controllers.

Slow SMB appears to be a common problem.

> It's just a puzzle that's driving me slowly mad. :) If anyone
> knows the answer, I wouldn't mind hearing it. If anyone knows
> a -solution- I'd be even more interested in hearing how to get
> ftp-like performance speeds out of SMB.

I'll only ask why you didn't search google instead of asking
the smaller amount of readers on this list.   And I don't think
you'll ever get ftp-like performance out of SMB.  

Bill
-- 
Bill Vermillion - bv @ wjv . com