Hi there,
As many of you know, our test rules require disabling delayed ACKs
on Polygraph clients and servers. This TCP option is disabled using a
FreeBSD sysctl command.
Disabling delayed ACKs usually _increases_ the number of packets on the
network while _decreasing_ average response time of an isolated HTTP
transaction. It is hard to predict the effect of delayed ACKs on
throughput. A product may be able to achieve a higher throughput with
delayed ACKs enabled.
Since we've got most of the registrations for the second bake-off, we would
like to re-visit this issue. We have asked FreeBSD networking folks for
some advice, and the consensus was that delayed ACKs are evil and should be
disabled. Note that the default FreeBSD setting is currently to enable
delayed ACKs so those people were essentially pummeling themselves for
introducing that option in the first place.
John Nagle (the author of the Nagle algorithm) also does not like delayed
ACKs. His opinion and related discussion can be found at
http://x32.deja.com/=dnc/getdoc.xp?AN=477899304
However, our ultimate goal is to simulate realistic traffic rather than
"doing the right thing" for the network. Unfortunately, in this particular
case we probably do not have a flexibility of having "a little bit of
delayed ACKs". Changing the delay introduced by the option from 200msec is
probably far from trivial, involves potentially serious kernel
modifications, and we simply do not have time for that investigation before
the bake-off. Hence, it is an everything or nothing kind of a deal.
We would like to hear your opinion about the problem. By default, the
delayed ACKs will continue to be disabled in Polygraph workloads.
Thanks,
Alex.
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:09 MDT