Subject: Re: tcp delayed ack - TCP_NODELAY
To: Douglas Egan <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
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?