James Knott <james.knott,AT,rogers,DOT,com>|
Re: Checklist (sub-thread of: "Slow file sharingperformance: lostpidgeons")|
Les Mikesell <les,AT,futuresource,DOT,com>|
09 Sep 2003 11:20:26 -0500|
<002f01c376aa$bb23a860$d620a8c0@pcw_hans.hnsasd.priv> <3F5DC241.firstname.lastname@example.org> <email@example.com> <3F5DD367.firstname.lastname@example.org>|
On Tue, 2003-09-09 at 08:19, James Knott wrote:
> > 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.
> I suspect this may be the cause of the problem.
Since it doesn't happen if you don't go out the cable modem the
packets have to be dropped somewhere beyond your server's ethernet.
> > B) Samba uses TCP for file transfer, so any conclusions
> > you made about UDP by observing samba are incorrect.
> I don't know enough about SMB, but that's what I also thought. However,
> there are some UDP packets as well.
Netbios uses UDP for name lookups but the connection for file transfer
> I posted some tcpdump files to the list yesterday. I had sent them to
> Allan earlier.
I can't find them in the list archives. Since you really can't control
beyond your own ethernet you need to figure out why flow control
isn't working going into the cipe interface. You mentioned setting
mtu down. Does the packet size entering the cipe interface reflect
the size you set?
> > 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.
> Shouldn't I be seeing some ICMP messages about that? Also, I tried
> using some small MTU values and it didn't help. Also, I looked at some
> of the packets captured with Ethereal. They don't show the DF flag set.
Are you looking at the cipe interface? A quick tcpdump of port 139
on both windows or samba servers shows that it does set DF on every
packet. You should see an ICMP message if a single packet exceeds
max allowed by the medium for the next hop assuming the router involved
follows the standards and it isn't blocked by a firewall. However I
don't think you'll get that if you just overrun a buffer from the window
of packets transmitted. If you are passing several independent tcp
streams there may not be any way to control it but any single connection
should control its send window based on the remote acks.