| 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) - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
