Re: [PATCH 2/25]: Avoid accumulation of large send credit

[Gerrit Renker <gerrit@erg.abdn.ac.uk>]

|  Thus the RTT measurement is EXPLICITLY fed in to the throughput 
|  equation.  In TCP the RTT measurement mostly just feeds in to the RTO, which 
|  is why the protocol's behavior is less sensitive to the measurement.
|  
|  DCCP *MIGHT* work just fine with the inflated RTT measurements (i.e. the RTT 
|  including IP processing) but there is yet another gerrit missive to work 
|  through to see how real that complaint is.
|  
|  A less aggressive version of "turn off RTT for LANs" would be simply to 
|  subtract an estimate of the IP<->card path's cost from the measured coarse 
|  RTT.  This would fix the problem.  If you used a stable minimum estimate, the 
|  RTT would naturally "inflate" when the host was busy, which as Ian points out 
|  is what we actually want.  How to obtain an estimate?  Probably anything would 
|  do, including something derived at boot time from BogoMIPS.
Such an estimate is difficult to obtain - I get completely different results on
different computers; depending on the card (ee100 with NAPI is fine, my cheapo RTL 8139
on the other hand makes a lot of noise). Some practical figures are:

 * when the timestamps get taken at arrive time, the RTT values are very close to what ping
   reports (e.g. 100 ... 1,100 usec on a LAN);

 * when the timestamps get taken in the CCID3 module, the RTT values are roughly up to 10
   times larger (5 milliseconds on a link with a 500usec link RTT was frequently the case)