Subject: Re: tcp delayed ack - TCP_NODELAY
To: Douglas Egan <degan@calcon.net>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-net
Date: 06/21/2001 15:54:25
In message <3B32780E.D7109211@calcon.net>Douglas Egan writes
>I am not really sure.  The samba help talks about 2 options:
>
>TCP_NODELAY  This effects the transmit side right, sending before the
>             buffer is filled
This turns off the Nagle algorithm, which is as you describe.

>IPTOS_LOWDELAY   (is this the same as delay ack)

This sets IP type-of-service bits, which is more-or-less deprecated in
favour of other uses of the ToS bits.

Delayed-ACK affects how the TCP receiver sends ACKS: whether an ACK is
sent for every received segment, or whether an ACK is delayed slightly,
until either the next segment arrives or the delay-timeout expires.

Under normal operation, delayed acking should have no perceptible
effect on a LAN with a low RTT.


>Anyway I want to try to see what gives with my poor performance between
>win2k and my samba server running on netbsd.

Completely off-the-wall here, but what counds as "poor"?  Samba runs
as a userspace process and incurs extra context-swiches and copying,
compared to a "native" Win2k implementation.
This is true for all Samba servers.  

Does samba on NetBSD perform worse for you than Samba on some other
OS? Or is it just that the user-space Samba process gives lower
perceived performance than the "in-kernel" win2k implementation?