<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: James Knott <james.knott,AT,rogers,DOT,com>
Subject: Re: Checklist (sub-thread of: "Slow file sharing performance:lostpidgeons")
From: Les Mikesell <les,AT,futuresource,DOT,com>
Date: 09 Sep 2003 08:00:21 -0500
Cc: CIPE <cipe-l,AT,inka,DOT,de>
In-reply-to: <3F5DC241.90200@rogers.com>
References: <002f01c376aa$bb23a860$d620a8c0@pcw_hans.hnsasd.priv> <3F5DC241.90200@rogers.com>

On Tue, 2003-09-09 at 07:06, James Knott wrote:

> I am aware the UDP is best effort and that the services using it are 
> supposed to provide flow control if necessary.  Given that FTP, which 
> uses TCP works fine and Samba and NFS, which use UDP have problems, what 
> observations would you make?

A) The 'flow control' mechanism when going between a fast medium to
a much slower one is to buffer some, then discard packets when the
buffer is filled. TCP has a window size mechanism that will
limit the unacked packets sent on a single connection. CIPE
doesn't change this by using UDP - it just wraps the packets
already being sent with another header during delivery.  Things that
use UDP natively for reliable transfers (NFS, etc.) normally
have their own windowing and error correction mechanism that
can differ in size and backoff strategy from TCP's.

B) Samba uses TCP for file transfer, so any conclusions
you made about UDP by observing samba are incorrect.

C) If you want to diagnose where the problem is you will have
to use tcpdump or some other protocol analyzer to see where the
packets are being discarded. If you watch a tcp stream like
samba going into the cipe interface you will see the tcp sequence
numbers repeat as tcp's error recovery fixes things.  On the
other end you will only see one instance come out.  Then you
have to figure out which hardware interface dropped the cipe
packet between them.

D) Wild guess here - I haven't checked but it is possible that
samba sets the DF (don't fragment) bit where ftp doesn't (Microsoft
likes to do that for no particular reason...).  That means if
the medium can't accept the whole packet it has to discard it
instead of fragmenting so it will be rebuilt at the other end.

  Les Mikesell

<< | Thread Index | >> ]    [ << | Date Index | >> ]