Packet collision on Samba traffic

[okuyamak at dd.iij4u.or.jp]

Dear Andrew,

>>>>> "AT" == Andrew Tridgell <tridge at samba.org> writes:
>> http://www.dd.iij4u.or.jp/~okuyamak/Documents/tuning.english.html
AT> that looks really useful! Can you give us some figures for the
AT> improvement you see and with what NICs and client version?

Which NIC .... I'm sorry. I've sold NIC that this change works
effectively. And I forgot to check which NIC chip was on that card.
What I know is that some IBM Aptiva's built in NIC card have this
problem. But I never checked what chip was being used.

Since only NIC with recieve buffer less than 9kbyte (1500*6)is the one
causing problem, now I always check this parameter before I buy new
NIC.  So, currently, I don't have NIC that cause this problem.

I've checked that following client OS will cause this problem,

	WindowsNT4SP6, Windows98, Windows98SE

Meanwhile, I've found that following client OS will NOT cause this problem,

	Windows2000

I don't know about WindowsMe, but I think WindowsMe will not cause
this problem too.


AT> If this really does make a big difference then I wonder if we could
AT> automate it? Perhaps a libsmb based client testing against a share on
AT> the windows box could give a graph of speed versus SNDBUF?

Ah ... to be more specific, SNDBUF is not the only parameter.

There's really two cases.

1) Samba->Win is slow.

  If you're using NT or 98 of some kind, and if you think Samba->Win
  direction of file copy is slower, then there's high possibility of
  Winsock2 dropping IP packet. We can fix this by optimizing 
  SO_SNDBUF parameter, or go and get richer NIC(^^;)

  If you're facing this problem even with PPP connection ( which 
  we really do ), then it might be better to fix Windows side's
  default parameters. Make RCVBUF size to MSS*2 on windows side,
  will tune your windows communication speed without loosing much.

# have you never experenced PPP connection sending/recieving nothing
# when you are downloading large files ( like IE ) ? Well, that's
# when you're facing this problem.


2) Win->Samba is slow.

  This, I did not describe on the paper. We can have same kind of
  problem due to same mechanism Winsock2 is having, but for this case,
  it's quite hard to fix.

  Winsock2 tries to send two data packet, then waits for Ack arrival.
  Meanwhile, unix tries to delay ack for .. about 100msec, so that
  there might be a chance of having piggy bag. This delay ack mechanism
  of unix TCP implementation, usually works fine. But not for RPC.
  RPC uses TCP layer as Half Duplex.. i.e. if one side is speaking,
  other side is ALWAYS listening, therefore have no packet that can
  be used for piggy bag.

  So, Windows will wait for Ack arrival, but unix will not send it
  for 100msec. After ether Windows side timeout, or will wait for
  100msec and recieve ack, Windows will send next two data packet.
  As you see, this is large loss.

  To fix this case, we have no way that we can use for socket
  options. In some OS, there's really no way we can fix it.

  On FreeBSD, for example, try command:

% sysctl net.inet.tcp.delayed_ack

  you will probably get result of

net.inet.tcp.delayed_ack: 1

  This means current FreeBSD uses delayed ack mechanism. By:

% sysctl -w net.inet.tcp.delayed_ack=0

  you will be able to disable delayed ack mechanism.


  There's two problem about this tuning.

  First is that in case of unix-unix communication turning delayed_ack
  to off means we're sending too much Acks. This will cause performance
  loss.

  Second is that in case of Linux ( for example ), I found no way to
  fix this. There was no way to control delayed ack mechanism.
  And when I read the code ... I found some sort of mess there...


Since I've got stucked to case 2, I still havn't think about
mechanism of tuning the system automatically. So I have no idea how
we should do it. Maybe it's better simply to check Windows OS and
if it was NT or 98, simply run program that changes RCVBUF size of
windows at client side.


By the way, I got report from 'monyo at home.monyo.com' that there's
related report on:

http://www.microsoft.com/technet/winnt/winntas/technote/implemntintegra/ntopt6.asp

If you read this carefully, you'll find that Microsoft must have
done something wrong on old winsock2.

# 'switching directions' they say ... at sattelite communication,
# which means up-stream and down-stream is different media ....
# Hah, nice way to explain.


Did they became your help?

best regards,
---- 
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.