Slow write performance with Win 98 and Samba (fwd)
okuyamak at dd.iij4u.or.jp
Thu Jun 21 02:28:59 GMT 2001
>>>>> "JA" == Jeremy Allison <jeremy at valinux.com> writes:
>> I have seen this problem with Linux, but not with FreeBSD. And
>> biggest difference between my Linux Machine and FreeBSD machine is
>> that I stop delayed-ack when it connect with Windows machine, while
>> on Linux, we have no way to do this for kernel 2.4.2.
JA> How does *BSD achieve this. Is there a setsockopt()
JA> call ?
Before I start connecting windows machine, I run
# sysctl -w net.inet.tcp.delayed_ack=0
and when finish, I do
# sysctl -w net.inet.tcp.delayed_ack=1
This option is not controllable with setsockopt(), because this is
not managable per socket on FreeBSD.
BTW, I don't know about other *BSDs, whether they can handle this,
or not. Also, I don't know if this is trully blocking the problem,
or simply ( magically ) I havn't meet with the problem.
I do this, to speed up Win->unix tcp/ip transfer.
First, take a look at
You read it? Ok.
The story continues.
When sending large data Win->unix directional, Windows will first
send 2 packet, then wait for ack. Windows will not send third packet
until ack arrives, or timeout occur.
Unix side do not send ack immediately. This is called "delayed-ack".
It waits for a while, looking for piggy-bag-able packet ( usually
10-100msec wait ).
As result, Win->unix tcp/ip transfer can only send 2 packets per
10msec, if delayed-ack fully waited. Because this delay is usually
controlled by jiffie, we usually have better chance, around 2
packets per 5msec.
By stopping "delayed-ack", you can have better performance.
More information about the samba-technical