[Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)

[Linda Walsh]

Stan Hoeppner wrote:
> For raw bandwidth maximization, what port and protocol are used won't
> make much difference, if any.  In fact it shouldn't make _any_
> difference in raw b/w.  Communications between the Samba server and
> Win2K client appear to be exclusively over TCP 139 at this point
> according to netstat, instead I'm misreading or looking in the wrong
> place.

--- I haven't read the rest of the thread yet, so forgive me if I am
   covering things that have already been covered.

   139 AFAIK, uses UDP, that means one packet up, it gets ACKED, (packet
send back to sender) then another packet goes up.

   445 uses TCP, which can have multiple packets sent without waiting for
an ACK.  Suppose round trip for an 'empty packet is 2 ms.  For round
numbers use 1000B/packet. So you send 1000B on a 1MB/s line (yeah, it's
an odd flaver of ethernet).  But for each 1000 bytes sent, it takes
1000/10^6(B/s)  = 1ms.  So it would take 2 seconds to send.  Now the
other side could wait for the response to come back and that would take
another 1ms for an empty packet (which can include an 'ACK'.  So round
trip time for 1000 bytes would be 3m.  Now your 1MB line has dropped to
1000B / 3ms.

Instead of nearly 1000 packets/second, you only see a throughput of 
300k on our 1MB line : 33%.  Yuck!

Now tcp doesn't require nearly the overhead for single packets.  Opening
the TCP connection takes extra long -- maybe in our example it would take
5ms.  But then further packets can be sent with .05ms overhead instead of
1ms. (these figures are illustrative, not accurate!) But now you send 30
packets at 1ms+.5 each, and they all travel and are received in 30.30 ms.
The ack back takes another .5 (as it's within the TCP stream, where you
only need send packet# and ack -- no addressing or port or security info.
That 'intro stuff' is only done once at the begining of each stream open
(which in Samba is only once/ session -- not once/connection).
Additonally, the Ack back takes place AS the next packet is being sent.
Most implementations will allow the next one-to-several packets to be
sent WITHOUT having heard back.  That's important. 

So the total wait time -- is 1.5*30 or 45ms+ + the last ack has to waited
for -- so 45.5 ms. to send your 30,000 bytes.  Now we're talking 659k on
our 1MB line.  Not perfect, but maybe as perfect as less than ideal
hardware allows due to overhead (or maybe OS overhead/packet...whatever).
But in this *bogus*, (but representative in a relative sense) example TCP
bought over 100% more throughput.  In real life, might add 10-30%.
Depends on hardward and OS implementation.

Do you see why TCP=better? (for large packet sizes).  For small, sparse
amounts of data, UDP might be better.

The penalty of per-packet overhead RTT times goes *up* with the faster
networking equipment you use.  At 1GB, 1ms is a loss of a million bits!

That make sense?

So a UDP connection is much more inefficient and may show as busy but
some of that is spent constructing/sending headers while other parts are
waiting on ACKS.

-linda