netdev - Re: RFC: Nagle latency tuning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ljy2tfgi.fsf@basil.nowhere.org>
Date:	Tue, 09 Sep 2008 00:55:57 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Christopher Snook <csnook@...hat.com>
Cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: RFC: Nagle latency tuning

Christopher Snook <csnook@...hat.com> writes:
>
> I'm afraid I don't know the TCP stack intimately enough to understand
> what side effects this might have.  Can someone more familiar with the
> nagle implementations please enlighten me on how this could be done,
> or why it shouldn't be?

The nagle delay you're seeing is really the delayed ack delay which
is variable on Linux (unlike a lot of other stacks). Unfortunately
due to the way delayed ack works on other stacks (especially traditional
BSD with its fixed 200ms delay) there are nasty interactions with that. 
Making it too short could lead to a lot more packets even in non nagle 
situations.

Ok in theory you could split the two, but that would likely have
other issues and also make nagle be a lot less useful.

-Andi

-- 
ak@...ux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html