From: Rick Jones <rick.jones2@hp.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Daniel Baluta <daniel.baluta@gmail.com>,
davem@davemloft.net, kuznet@ms2.inr.ac.ru, jmorris@namei.org,
yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@vger.kernel.org
Subject: Re: [RFC] tcp: Export TCP Delayed ACK parameters to user
Date: Fri, 28 Oct 2011 09:38:52 -0700 [thread overview]
Message-ID: <4EAADA9C.30306@hp.com> (raw)
In-Reply-To: <1319791441.23112.80.camel@edumazet-laptop>
>> On Solaris there is a global option tcp_deferred_acks_max [2],
>> which is similar with our tcp_delack_segs.
>>
>
> and also has tcp_deferred_ack_interval
And those have similar settings in HP-UX 11.X.
For the sake of completeness, the ACK avoidance heuristic in HP-UX, and
I presume Solaris (as they share a common "Mentat" heritage) includes a
mechanism to reduce the per-connection effective number of segments per
ACKnowledgement. I believe this is done to handle cases where the
sender may have reduced her cwnd. That would have deployment going back
to 1997 in the case of HP-UX 11.0, and presumably a few years before
that in the case of Solaris. That mechanism in their ACK avoidance
heuristics may be the reason neither have gone so far as to make the
settings per-route or per-connection (though I could be wrong). I
believe that Solaris does though have two deferred ACK limits - one for
perceived to be local connections and one (lower) for perceived to be
remote connections.
There can be "fun" interactions with senders which increase cwnd per ACK
rather than per bytes ACKed.
Still, I myself am somewhat fond of ACK avoidance heuristics.
rick jones
PS - when discussing the performance benefits of an ACK avoidance
heuristic, feel free to use netperf and service demand numbers :)
next prev parent reply other threads:[~2011-10-28 16:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-27 23:07 [RFC] tcp: Export TCP Delayed ACK parameters to user Daniel Baluta
2011-10-28 0:01 ` Eric Dumazet
2011-10-28 8:01 ` Daniel Baluta
2011-10-28 8:44 ` Eric Dumazet
2011-10-28 16:38 ` Rick Jones [this message]
2011-10-28 21:14 ` [RFC v2] " Daniel Baluta
2011-10-28 21:19 ` David Miller
2011-10-28 21:35 ` Daniel Baluta
2011-10-28 22:31 ` David Miller
2011-10-28 22:40 ` Rick Jones
2011-10-29 2:24 ` David Miller
2011-10-29 12:32 ` Daniel Baluta
2011-10-30 4:13 ` David Miller
2011-10-31 18:10 ` Rick Jones
2011-10-31 20:02 ` Daniel Baluta
2011-10-31 21:29 ` Rick Jones
2011-10-28 21:53 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EAADA9C.30306@hp.com \
--to=rick.jones2@hp.com \
--cc=daniel.baluta@gmail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).