My pre-2.1.90-2 patch fix this probelm well (hoping that this could
help you to find the bug).
The change in ack'ing policy necessary to get the behavior you desire
is highly questionable. We did it in 2.0.x, the change was that if we
saw the PSH flag set in an incoming data packet, we ACK'd immediately.
FreeBSD even added a hack to do this too, and recently removed it.
It helps your case, but it deteriorates performance in other bulk
transfer cases.
A sample transfer snapshot demonstrating why the "PSH bit ACK hack" is
wrong:
Bulk data transfer, FreeBSD ftp server to 2.1.90+my_local_changes
Linux client:
20:24:43.423411 165.113.121.81.ftp-data > dm.cobaltmicro.com.1225: . 211417:212877(1460) ack 1 win 17520 [tos 0x8]
20:24:43.431383 165.113.121.81.ftp-data > dm.cobaltmicro.com.1225: . 212877:214337(1460) ack 1 win 17520 [tos 0x8]
20:24:43.431452 dm.cobaltmicro.com.1225 > 165.113.121.81.ftp-data: . ack 214337 win 30660 (DF) [tos 0x8]
20:24:43.439361 165.113.121.81.ftp-data > dm.cobaltmicro.com.1225: . 214337:215797(1460) ack 1 win 17520 [tos 0x8]
20:24:43.447333 165.113.121.81.ftp-data > dm.cobaltmicro.com.1225: . 215797:217257(1460) ack 1 win 17520 [tos 0x8]
20:24:43.447400 dm.cobaltmicro.com.1225 > 165.113.121.81.ftp-data: . ack 217257 win 30660 (DF) [tos 0x8]
20:24:43.455313 165.113.121.81.ftp-data > dm.cobaltmicro.com.1225: P 217257:218717(1460) ack 1 win 17520 [tos 0x8]
20:24:43.463288 165.113.121.81.ftp-data > dm.cobaltmicro.com.1225: . 218717:220177(1460) ack 1 win 17520 [tos 0x8]
20:24:43.463357 dm.cobaltmicro.com.1225 > 165.113.121.81.ftp-data: . ack 220177 win 30660 (DF) [tos 0x8]
Things are clocking just right, we get 2 full sized frames within the
delayed ACK interval, and we thus ACK every other packet. The end of
one of the FTP servers write system calls fell at the point where the
PSH flag is set in the 3rd to last packet. With the "PSH bit ACK
hack" we would have acked that frame and not the next one, destroying
to advantage of the delayed ack rules. This tends to upset the
natural clocking of TCP during bulk data transfer.
Your suggested change makes delayed ACK's not happen at all, causing
us to ACK every single data packet all the time, so it is not correct
either.
I welcome someone to come up with a heuristic which preserves the
current behavior for bulk data transfer, yet ACK's a bit more quickly
for interactive sessions. ;-) Delayed ACK'ing strategies are an
interesting problem to solve completely.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu