Sorry, I misread the email. Please see below. | 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. CCID3 uses the sampled RTT value as input into an equation so any inaccuracies will multiply. I observed a difference of about 10. Currently the performance of CCID3 severely sucks and I tried every bit to make it better. Obviously this is not the right way. Your comments are helpful, thank you. I will revert all RX/TX timestamps and I think there is no need to take the timestamp in the dccp receive input function. By taking the timestamp in the CCID3 handler, it will include all processing overhead, slowing the sending rate further down in proportion to that difference. - 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
