Re: [PATCH 07/29] Use skb timestamp for receiver side

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

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.