Slow write performance with Win 98 and Samba (fwd)

Kenichi Okuyama okuyamak at dd.iij4u.or.jp
Thu Jun 21 02:28:59 GMT 2001


Dear Jeremy,

>>>>> "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

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.


BTW-2:
I do this, to speed up Win->unix tcp/ip transfer.

First, take a look at
URL: http://www.dd.iij4u.or.jp/~okuyamak/Documents/tuning.english.html

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