why does skb->tstamp use getnstimeofday?

why does skb->tstamp use getnstimeofday?

[Anatoly Sivov]

Hello everyone.

struct sk_buff has a field tstamp, which is used for high resolution rtt  
calculation.
All operations with this field are done directly or indirectly via ktime_*  
interface,
which uses getnstimeofday function.
My question is why does skb->tstamp use getnstimeofday?
Isn't it better to use getrawmonotonic, where we are not inetrfered with  
ntp,  for rtt calculation?

Thank you.

Re: why does skb->tstamp use getnstimeofday?

[Eric Dumazet]

Le dimanche 15 janvier 2012 à 19:11 +0400, Anatoly Sivov a écrit :
> Hello everyone.
> 
> struct sk_buff has a field tstamp, which is used for high resolution rtt  
> calculation.
> All operations with this field are done directly or indirectly via ktime_*  
> interface,
> which uses getnstimeofday function.
> My question is why does skb->tstamp use getnstimeofday?
> Isn't it better to use getrawmonotonic, where we are not inetrfered with  
> ntp,  for rtt calculation?
> 

It's using this since day 0, so cannot be changed or break applications,
which expect timeofday, not monotonic.

monotonic time services were added later.

Re: why does skb->tstamp use getnstimeofday?

[Anatoly Sivov]

Hello Eric,

thanks for your answer.

> monotonic time services were added later.

Yep, I understand.

> It's using this since day 0, so cannot be changed or break applications,
> which expect timeofday, not monotonic.

I missed that field tstamp is used for things other than RTT and can be  
even user-spaced with SO_TIMESTAMP.
However, timekeeper speed up/slow down (due to ntp) can seriously affect  
some congestion avoidance algorithm quality, I guess.
Am I wrong?

Re: why does skb->tstamp use getnstimeofday?

[Anatoly Sivov]

> some congestion avoidance algorithm quality, I guess.

I mean efficiency, not quality.

Re: why does skb->tstamp use getnstimeofday?

[Eric Dumazet]

Le dimanche 15 janvier 2012 à 21:55 +0400, Anatoly Sivov a écrit :

> I missed that field tstamp is used for things other than RTT and can be  
> even user-spaced with SO_TIMESTAMP.
> However, timekeeper speed up/slow down (due to ntp) can seriously affect  
> some congestion avoidance algorithm quality, I guess.
> Am I wrong?

For what kind of application or protocol do you feel there could be a
problem ?

TCP stack doesnt use skb->tstamp/jtime_t, for example, but jiffies.

ntp adjustements are normally very small and nobody notice.

Re: why does skb->tstamp use getnstimeofday?

[Anatoly Sivov]

> TCP stack doesnt use skb->tstamp/jtime_t, for example, but jiffies.
Some CA engines asks for RTT calculation with skb->tstamp.
They state about it by setting TCP_CONG_RTT_STAMP flag in their struct  
tcp_congestion_ops instances.

> For what kind of application or protocol do you feel there could be a
> problem ?
I don't insist on problems are here, just want to mark that there could be  
a problem with these CA engines
in the case of "big ntp adjustment".

Re: why does skb->tstamp use getnstimeofday?

[Rick Jones]

On 01/15/2012 09:55 AM, Anatoly Sivov wrote:
> I missed that field tstamp is used for things other than RTT and can be
> even user-spaced with SO_TIMESTAMP.
> However, timekeeper speed up/slow down (due to ntp) can seriously affect
> some congestion avoidance algorithm quality, I guess.
> Am I wrong?

Good question - not sure if we will see anything, but the upcoming 
leap-second might be interesting to watch - though I think contemporary 
NTP addresses that by a big slew rather than a step adjust.  Of course 
it can step-adjust the time on the system, but 99 times out of 10 (*) 
that will be just at system start-up, when there probably will not be 
all that many congestion controlled connections active.  Of course, who 
knows what that 100th out of 10 times will do.

rick jones
* 99 times out of 10 is an expression which if I recall correctly was 
coined or at least repeated by a high-school sports coach to mean 
"virtually all of the time"