On Sun, 30 Dec 2007, Gavin McCullagh wrote:

Hi,

On Fri, 21 Dec 2007, Ilpo Järvinen wrote:

quoted

quoted

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.