On Sun, 30 Dec 2007, Gavin McCullagh wrote: > Hi, > > On Fri, 21 Dec 2007, Ilpo Järvinen wrote: > > > > I need to re-read properly, but I think the same problem affects the > > > microsecond values where TCP_CONG_RTT_STAMP is set (used by vegas, veno, > > > yeah, illinois). I might follow up with another patch which changes the > > > behaviour where TCP_CONG_RTT_STAMP when I'm more sure of that. > > > > Please do, you might have to remove fully_acked checks to do that right > > though so it won't be as straight-forward change as this one and requires > > some amount of thinking to result in a right thing. > > The TCP_CONG_RTT_STAMP code does need to be fixed similarly. A combined > patch will follow this mail. As I understand it, the fully_acked checks > kick in where the ACK is a portion of a TSO chunk and doesn't completely > ACK that chunk. Leaving the checks in place means you get one rtt for each > TSO chunk, based on the ACK for the last byte of the chunk. This rtt > therefore is the maximum available and includes the time-lag between the > first and last chunk being acked. Removing the tests gives you an RTT > value for each ACK in a tso chunk, including the minimum and maximum. It > seems the minimum rtt is the best indicator of congestion. On the other > hand having all available RTTs gives the congestion avoidance greater > knowledge of how the RTT is evolving (albeit somewhat coloured by TSO > delays which don't seem too severe in my tests).
I guess the non-minimum TSO delays are only significant in case there was something unexpectional happening and in such case we definately want to have some measurements taken. -- i.
