[ntp:hackers] timespec vs timeval

Greg Dowd GDowd at symmetricom.com
Wed Jul 18 16:46:36 UTC 2007


That actually works quite well.  The way so_timestamp works in the linux
kernel is that the kernel checks to see if the driver filled in the
timestamp field.  If it is already loaded, the kernel just passes it
along.  If it's empty, it calls gettimeofday and loads the timestamp.
So, the structure is all there to support pushing timestamping of the rx
packets further and further down the chain.  The hardware timestampers
with layer 1 or layer 2 taps are beginning to define in band mechanisms
for pushing timestamps up with the pkt, independent of the protocol.
This is coming from the ptp application space but bodes well for ntp as
well.  



 


Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc. 
www.symmetricom.com
"The current implementation is non-obvious and may need to be improved."




-----Original Message-----
From: hackers-bounces+gdowd=symmetricom.com at lists.ntp.org
[mailto:hackers-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf
Of David L. Mills
Sent: Wednesday, July 18, 2007 9:21 AM
To: hackers at ntp.org
Subject: Re: [ntp:hackers] timespec vs timeval

Frank,

My apologies; I see there is no gettimeofday(), just that the kernel did
that and you get what results.

Reason for my twitch is that the IEEE 1588 guys are stirring the pot
claimin NTP is good only to several milliseconds. My experience
documented in the book is that NTP can perform much better than that. 
We've gone to much pain to split the microsecond only to be limited by
the resolution of the kernel timestamp.

Here is what I have proposed to NASA. Have the driver capture a
timestamp on the interrupt following packe transmission. Leave that in
the buffer for the protocol module to see and append to a subsquent
packet in an extension field. How does that grab you?

Dave

Frank Kardel wrote:

>> Frank,
>>
>> Slow down.
>
> Well, maybe I was not clear enough.
>
>> If the program does in fact the equivalent of get_systime(),
>
>
> Note quite - it does not read the clock itself, but the time stamp 
> that was taken by the kernel when the UDP packet was delivered to the 
> queue of the socket. This timestamp is taken pretty early in udp input

> - a long time before the ntpd will be:
> - signaled with SIGIO
> - and wake up (according to scheduling decisions)
> - and enter the signal handler
> - and fetch a timestamp via get_systime
> - and dig out the paket...
>
>> it should call that routine, if only to insure portability.
>
> To be precise - the timestamp fetch_timestamp gets was taken in the 
> kernel and is delivered together with the paket data. All 
> fetch_timestamp does is to extract the kernel time stamp that came 
> along with the paket data.
>
>> As for the
>> kernel interface, it should do a timespec.
>
> Yes, but SO_TIMESTAMP is currently a struct timeval. We can lobby to 
> get a better resolution - no problem for the free OS around here - 
> just a SMOP (simple matter of programming).
>
>> The bottom line is that it
>> takes half a microsecond to read the kernel clock in Solaris 10 with 
>> a Blade 1500. It's hard to see the interrupt latency is comparable or

>> longer than that.
>
> We are not talking about interrupt latency here but *roughly* the
path:
> interrupt (Pouls remarks about chip interrupt dely would go in here)
> -> eth_input
> -> netisr/softinter (leave device interrupt) ip_input (at soft 
> -> interupt) udp_input (take SO_TIMESTAMP time stamp around here) 
> -> socket delivery post SIGIO (leave softintr) scheduling ntpd (most 
> -> likely context switch) ntpd SIGIO handler get_systime (goes into 
> -> the kernel again and takes about
> 0.5 usec for that roundtrip or even stays at user level depending on 
> implementation, definitely does not need to context switch)
>
> The above path is certainly longer than get_systime.
>
> SO_TIMESTAMP grabs the usec (sigh) timestamp at socket delivery. long 
> before get_systime can even be called.
>
>> On the other hand, the beauty of using FreeBSD and the like is that 
>> the kernel can be changed.
>
> Yes. I am all for that. Maybe another socket option SO_TMSTAMP option 
> that selects the format (timeval, timestamp, bintime).
>
> I hope I have be clearer now. fetch_timestamp only extracts the kernel

> time stamp delivered with the packet data. Portability is via the 
> existence of SO_TIMESTAMP and the definition that SO_TIMESTAMP returns

> struct timeval.
>
> For ultimate time stamping we should go for interfaces with HW 
> timestamping at MII Level along with a time stamp feedback mechanism 
> for sent pakets (needs some new functionality at the socket interface 
> level). I would like to see that.
>
> Frank
>
>> Dave
>>
>> Frank Kardel wrote:
>>
>>> Hi Dave !
>>>
>>>> This might go to Frank, Danny and Harlan. Others might be
interested.
>>>>
>>>> I was looking in ntp_io.c for something or other and tripped over 
>>>> the
>>>> fetch_timestamp() routine. It uses a timeval structure where I 
>>>> would think a timespec structure more appropriate. Is there a 
>>>> reason why the
>>>> get_systimer() is not used?
>>>
>>>
>>> fetch_timestamp() extracts the time stamp taken by the *kernel* upon

>>> receipt of a UDP paket for sockets that have the SO_TIMESTAMP
option.
>>> If no kernel time stamp is provided the time stamp from paket 
>>> reception will be used (read via get_systimer()).
>>> SO_TIMESTAMP is enabled for systems that provide that interface.
>>>
>>> Unfortunately SO_TIMESTAMP only provides usec resolution an I 
>>> currently don't know of any widespread SO_TIMESTAMP like 
>>> implementation with a better resolution.
>>>
>>> Anyhow, measurements have shown (DEBUG_TIMING IIR) that the kernel 
>>> taken time stamps preceedes user level time stamps by several usecs 
>>> (range
>>> 10-700)
>>> on an AMD Athlon X2 4400+ running NetBSD 4/-current.
>>> I'd rather take a usec time stamp on soft intr level than a sub usec

>>> time stamp delayed by several microseconds.
>>>
>>> Maybe we should propose another SO_TIMESTAMP option to make use of 
>>> struct timespec to the OS communities.
>>>
>>>> I checked elsewhere for timvals and found a few, mostly in some 
>>>> refclocks. The input buffer timestamp is the most important, as the

>>>> time to read the clock is now in the order of half a microsecond.
>>>
>>>
>>> Yes, but get_systime() is too late - it's running at user level and 
>>> fetch_timestamp fetches the kernel time stamp.
>>> To improve the resolution of SO_TIMESTAMP beyond struct timeval that

>>> we need to change the kernel interface.
>>>
>>> Frank
>>>
>> _______________________________________________
>> hackers mailing list
>> hackers at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/hackers
>>
>>
>
>

_______________________________________________
hackers mailing list
hackers at lists.ntp.org
https://lists.ntp.org/mailman/listinfo/hackers


More information about the hackers mailing list