Page MenuHomeFreeBSD

Reduce Delayed ACK timeout to 40ms
ClosedPublic

Authored by rscheff on Jan 20 2020, 6:34 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 23 2024, 9:50 AM
Unknown Object (File)
Feb 23 2024, 9:50 AM
Unknown Object (File)
Feb 23 2024, 9:50 AM
Unknown Object (File)
Feb 23 2024, 9:50 AM
Unknown Object (File)
Feb 23 2024, 9:50 AM
Unknown Object (File)
Feb 23 2024, 9:37 AM
Unknown Object (File)
Feb 12 2024, 12:55 AM
Unknown Object (File)
Jan 27 2024, 4:22 AM
Subscribers

Details

Summary

As D4294 appears to be abandoned, reviving the particular aspect
of delayed Acknowledgments here, as a single change.

It seems that a few other stacks have been moving to shorter delayed
ack timeout intervals of around 40 to 50ms. Given that precedent,
it appears prudent to reduce arificial delay introduced to some
request-response workload, by following their example.

One of the problems addressed with rtt_slope in my expirience is
the unpredictability, if the remote host is using delayed acks, and
when, what the timeout is. To err on the save side, i tended to
keep rto_slop to 2* delack...

The RTOBASE change contained in D4294 was already update with D18941

Making the actual minimum allowed RTO 3 ticks requires different
changes than those proposed in D4294 (only the default minimum is
touched that way, not made sure that minRTO is at least 3 ticks.)

Test Plan

elicit delayed acks by sending an uneven number of MSS
sized segments, and verify the delay to be 40ms instead of 100ms

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Jan 21 2020, 7:29 AM

Would it make sense to make the default value for the delay ACK timer sysctl'able?

Probably more than adjusting it completely dynamically. OTOH, traditionally the delayed ACK timeout is typically hardcoded in other stacks also.

For now, I would suggest to retain a hardcoded value - and the merits/drawbacks of more dynamic adjustments of that value should be discussed separately...

Yup I think there is room for additional improvement and discussion in later work but this part doesn't seem controversial to me. Linux has a more dynamic approach called quick ack which can drop down to 4ms, and the standard delack function can vary from 40ms up to 200ms.

Would it make sense to make the default value for the delay ACK timer sysctl'able?

The used value is already (not VNETted) sysctl under

net.inet.tcp.delacktime: 100

so there is a way to tune the used ack timeout back to the old default, if the new default does not work as expected.

As a conservatively reduced timeout from 100ms down to 40ms should not have widespread detrimental effect.
Instead, this new default should result in improved responsiveness in many cases. Every deployment already making use of customized delayed timeout via /etc/sysctl.conf, would continue to work unchanged. One discussion may be to also VNET this (and possibly other) timer variables of TCP, to allow separate settings per VNET (e.g. public internet facing VNET can be tuned differently than an internal backend network VNET)..

So you are only changing the default of ta sysctl variable. That is fine with me.

  • refer to changed default delack timeout in tuning(7)
This revision now requires review to proceed.Apr 9 2020, 3:15 PM
reduce default TCP delayed ACK timeout to 40ms

Reviewed by:	kbowling, tuexen (mentor)
Approved by:	tuexen (mentor)
MFC after:	2 weeks
Sponsored by:	NetApp, Inc.
Differential Revision:	https://reviews.freebsd.org/D23281
  • bump man page timestamp
bcr added a subscriber: bcr.

OK for the man page change. Thanks!

This revision is now accepted and ready to land.Apr 13 2020, 3:21 PM
This revision was automatically updated to reflect the committed changes.