[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=aMjjz0dFqQg0ZKjEVjSbbvq49Yp7RBRV0SDri@mail.gmail.com>
Date: Mon, 23 Aug 2010 18:04:19 -0400
From: Chris Snook <chris.snook@...il.com>
To: Hagen Paul Pfeifer <hagen@...u.net>
Cc: David Miller <davem@...emloft.net>, shemminger@...tta.com,
netdev@...r.kernel.org, eric.dumazet@...il.com,
ilpo.jarvinen@...sinki.fi, therbert@...gle.com
Subject: Re: [PATCH] tcp: make TCP quick ACK behavior modifiable
On Mon, Aug 23, 2010 at 5:51 PM, Hagen Paul Pfeifer <hagen@...u.net> wrote:
> * David Miller | 2010-08-23 14:21:14 [-0700]:
>
>>> At least google inc is too busy to disable tcp quick ack's. And I
>>> think they will save a lot of packets! Who make a bet? ;)
>>
>>I think assuming that turning off quick ACKs will be a net
>>positive for google's traffic is a bit presumptuous, don't
>>you?
>
> bet? ;) The patch provides a switch to disable quick acks. If google or
> someone else is using this switch or not is up to the audience! ;)
>
> I don't know how many packets the current average HTTP session includes, but
> assuming ~20 packets the saving of one packet is a benefit.
The user experience with HTTP is very sensitive to latency. Since the
payload packets in HTTP are large, HTTP workloads generally aren't
generating enough packets that packet count is something that needs to
be optimized. I'm sure there are exceptions, like web servers
delivering small AJAX or JSON objects, but they're the exception, not
the norm.
That said, I still like the idea of this feature, but I think it
should be a per-route tunable, for consistency with the delayed ack
patch.
-- Chris
--
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
Powered by blists - more mailing lists