Same comment. Please do read the documentation accompanying the patch. Quoting David Miller: | From: "Ian McDonald" <ian.mcdonald@xxxxxxxxxxx> | Date: Fri, 13 Apr 2007 09:50:30 +1200 | | > I didn't know this time stamping was expensive but I knew the way we | > were trying to optimise LAN is wrong. I say LAN because a few | > microseconds or even milliseconds difference on a WAN link makes | > bugger all difference in throughput. DCCP takes into account operating | > system granularity etc and if we are running lossless (i.e. receiver | > can cope with receiving link at full speed) then we can transmit at | > line speed. I've tested this myself. | | You want the scheduling delays and other issues that can | delay DCCP input packet processing to get factored into | the RTT, so that the sender will pace properly. | | Trying to get perfect timestamping and RTT measurements, | and ignoring scheduling delays, is quite foolhardy and shows | a lack of understanding of how queueing really works. | | - 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
