[ntp:questions] A proposal to use NIC launch time support to improve NTP

Brian Utterback brian.utterback at oracle.com
Wed Dec 19 16:05:57 UTC 2012

On 12/19/12 10:12, Ulf Samuelsson wrote:
>> Now, if you have a PPS signal available and can provide it to both the
>> network controller and the kernel, then you don't have this problem
>> since the PPS signal will sync the time to an accuracy better than the
>> jitter that was introduced.
>> Even without the PPS signal to the kernel, your system might be usable,
>> since the only timestamp used in the kernel will be for the
>> originate/transmit timestamp, and this timestamp will be in sync with
>> the the network controller timestamp by virtue of the use of launchtime.
>> But you will have to be sure that the kernel clock is always a little
>> ahead of the network controller clock, enough so that the actual delay
>> in the stack doesn't cause the packet to reach the controller after the
>> designated launchtime, but not so far ahead that the timestamp wraps
>> (i.e. .5 second). Also, not so far ahead that you get too large a back
>> log in the controller of packets waiting to be sent
> The desired launchtime is compared to the network controller timestamp 
> counter in H/W, so again there is no need to synchronize with the 
> system time.

Yes there is. The ntpd program has to set a timestamp in the outgoing 
packet and then specify the launchtime when it writes the packet. The 
goal here is to have the timestamp written in the packet exactly match 
the time the packet actually hits the wire. So, the timestamp in the 
packet must be a little in the future when it is written so that by the 
time the controller gets it the packet can be delayed until the right 
time. Since ntpd cannot access the clock in the controller, this 
requires that the kernel time be relatively close to the controller 
time. If you can guarantee that they agree to within some upper bound 
and then add that maximum error to the timestamp written to packet, plus 
the maximum delay in the stack, then your scheme should work anyway. The 
key is, what is that maximum error and delay? If they get too close to 
.25 seconds then it will fail because of the timestamp wrap restrictions 
of the launchtime register.

So you are dependent on how accurately you can synchronize the kernel 
and network controller's clocks. But I think that the required tolerance 
should easily be obtainable, so you should be good to go. But remember 
that the greater that additive term is, the more packets you might need 
to queue. I couldn't find the spec I saw originally that made me think 
that there was a three packet limit, but even if that isn't the limit, 
there is very likely to be some limit.


Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterback at oracle.com

More information about the questions mailing list