On Fri, 18 Jul 2008, Thomas Jarosch wrote: > On Friday, 18. July 2008 15:55:22 Ilpo Järvinen wrote: > > Btw, on which kernel you ran these things (I hope it wasn't 2.6.24.7, > > which has FRTO related bugs anyway that the patches I've sent now won't > > fix)? > > It's the git "master" tree from two days ago, so it should be 2.6.27-pre. > Like I wrote before, there's another box doing NAT in front of it running > 2.6.24.7. FRTO is disabled on that box. Hope that helps a bit. Hmm, those were spurious RTOs indeed or a sign of perverted TCP "proxy" (or whatever they call them), longest delay spike I've found so far is this: 11:27:28.454827 172.16.1.131.56060 > 80.152.31.131.25: . 3989187:3990587(1400) ... 11:28:00.188835 80.152.31.131.25 > 172.16.1.131.56060: . ack 3990587 win 65535 That's 32 seconds? :-D What should TCP do with that :-) ...disregard that measurement because some other TCP variant would not be able to use the same measurement due to ambiguity problem(?), I don't think so... It seems that non-FRTO TCP just misses those signs and acts _too_ aggressively ;-), which is well known to happen when spurious RTO occurs. ...Also, those duplicate ACKs I pointed out earlier are a sign of unnecessary retransmissions (they occur both with and without FRTO). I actually doubt you have any real losses there, I'll probably next calculate RTTs based on that assumption in the non-FRTO dump too... -- i.
