Slow write performance with Win 98 and Samba (fwd)

Kenichi Okuyama okuyamak at
Thu Jun 21 02:28:59 GMT 2001

Dear Jeremy,

>>>>> "JA" == Jeremy Allison <jeremy at> 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

as root.

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.
Kenichi Okuyama

More information about the samba-technical mailing list