Bug 24645
| Summary: | sometimes delayed ACKs timeout | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Paul Herman <pherman> | ||||
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 4.2-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Just a quick follow-up,
On Thu, 25 Jan 2001, Paul Herman wrote:
> + if (tcp_delack_enabled) { \
> + if (callout_pending(tp->tt_delack)) { \
> + callout_stop(tp->tt_delack); \
Jonathan, as you suggested, I tried it without callout_stop() and
works just fine. You can omit the calls.
-Paul.
State Changed From-To: open->closed Fixed in rev 1.124 of tcp_input.c, and MFC'd to stable. |
When receiving large windows worth of data, a delayed ack sometimes won't properly fire off, and the TCP will halt for 100ms (or net.inet.tcp.delacktime) multiple times in one connection. In a default installation, this can result in a transfer being up to 10x slower. This was hashed out on freebsd-net. See the mail archives with the Subject: "I have delayed ACK problems". Fix: The following patch to tcp_input.c will patch cleanly against -STABLE and -CURRENT. How-To-Repeat: tar cf localhost:/tmp/foo /boot/kernel