On Fri, 2 Sep 2005, John Heffner wrote:
If it is window clamping, then you should be asymptotically approaching a ratio between receive buffer and window that corresponds (with a fudge factor) to the ratio between TCP segment data size and allocated packet size. If you make the receive buffer large enough, then the clamped window should still end up big enough.
For what it's worth, running with a 512k receive buffer still caused the clamping to occur, though it took longer than with the normal buffer size. The window went down from a maximum of 12291 (times 2^4 due to window scaling) to 3190 currently. That's still enough for our purposes, but I'll keep monitoring it to see if it shrinks any further. It could be a viable work-around for the time being.
Is this a bug, though, or a feature? :)
Also, since you have "real time" data, a larger receive buffer should probably be adequate to eliminate this problem, since it only occurs when the receiving application falls behind for a while, and a bigger receive buffer allows it to fall behind more without triggering the window clamping.
Correct. I noticed too while experimenting that the clamping never occurs if the application is fast enough to keep the socket buffer empty. It's when data is allowed to accumulate in the buffer that the window shrinks, and then it never grows back, as if a portion of the buffer got lost permanently.
-Ion - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
