[ntp:questions] A proposal to use NIC launch time support to improve NTP
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