[ntp:questions] A proposal to use NIC launch time support to improve NTP
ulf at invalid.com
Thu Dec 20 11:25:25 UTC 2012
On 2012-12-19 17:05, Brian Utterback wrote:
> 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,
The Network controller will timestamp the message in H/W as it arrives
and will add a CMESG with the timestamp, and this is supported in
ntpd since some time.
You add a small delay to the receive timestamp to make your launchtime.
systime does not get involved at any stage, and can be way off.
(Note that I am only interested in Stratum 1 server functionality)
> 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.
More information about the questions