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

Jonatan Walck jwalck at netnod.se
Thu Dec 13 14:14:17 UTC 2012

Hash: SHA1

On 12/13/2012 02:23 PM, Brian Utterback wrote:
> On 12/13/2012 5:00 AM, Jonatan Walck wrote:
>>> This is going to be very hard to get it to be useful. Looking
>>> at
>>>> the specs for the card, the timestamp you give is relative to
>>>> a clock that is internal to the controller, and is only
>>>> accurate to the nearest second. That is, it is like the PPS
>>>> in that it is assumed that the clock is in sync to within .5
>>>> seconds to avoid aliasing the timestamp.
>>>> Brian.
>> The internal clock of the network controller is the PHC for
>> IEEE1588, it has a 1 ns resolution, and can be steered with a 32
>> bit fractional of 1 ns. see SYSTIML and TIMINCA in the I210
>> datasheet.
>> // jwalck
> I know that. The problem is that there is going to be jitter
> introduced when you set the clock from the kernel. That is
> generally the problem with IEEE 1588, getting the time from the
> controller to the kernel and vice versa. If you have to go across a
> PCI bus for instance that will introduce jitter.
> Brian

I'm pondering two different use cases and senarios to make this work,
and work well;

In a generic case: If a client or server (same principle) runs NTP and
lets propose run a PPL locking the PHC clock to the local/kernel clock
(I admit this creates new challenges), you wouldn't have to "move
time" over the bus at every single query. One could fetch a recieve
timestamp from the network controller (actually it'll come along with
the packet already, so you don't have to fetch anything) and use that
as if it was set from the clock in the kernel.

When sending, one would base the wanted time sometime in the future
based on the local clock, make it a timed transmit and just let the
network controller decide when it is time to put the packet on the wire.

In a very specific case, like the one I'm currently working with:
Right by the NTP server is UTC, with a PPS*. Connect 1-PPS to the NICs
SDP, it can sample it's internal clock without interrupts at the
rising edge of the PPS. Use those samples for a PLL to steer the
network controllers clock to UTC, using TIMINCA and associates.

Now forget about the clocks from the kernel. Just let NTP use the
receive timestamps, and set timed transmits whenever in the future
that's far enough ahead for the computer to have time to do whatever
it is busy doing and putting the packet in the tx queue, and let
LaunchTime (as Intel calls it) do the job.

I'm interested in both of these cases, but as I mentioned above
focusing on the latter.

// jwalck

* How this is done, time transmission methods from the national time
standard and local atomic frequency standards is out of scope for this
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/


More information about the questions mailing list