[lkml]   [2003]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4 delayed acks don't work, fixed
   From: Andi Kleen <>
Date: Wed, 19 Mar 2003 02:55:17 +0100

> This streamer application should buffer at the sending side, in order
> to keep the window full. Introducing artificial delays on the sending
> side of a unidirectional TCP transfer is really bad for performance
> and I can assure you that more than just "weird delayed ACK" behavior
> will result.

The broken tail append patch I did some time ago was supposed to address
that (better merging of writes on the sender side even for non SG
NICs). Perhaps it should be rechecked.

It may fix this.

I think we're talking about independant problems.

This streamer application buffers, but once the buffer is fully pushed
to the other end and the "receiver catches up", we get periodic sends
created at the rate of device data creation. This cannot fill the
pipe between sender and receiver, thus TCP behaves suboptimally.

TCP needs at least a full window of data on the send side to clock
things properly. This streamer application doesn't give TCP that
after it's initial send buffering is been shrunk.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:34    [W:0.053 / U:6.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site