[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


-----BEGIN PGP SIGNED MESSAGE-----
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
discussion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQyeK4AAoJEFwg9i9GDX+nUdsQALjDtOO/HBZFlTHBVc9fyIJi
5ljsoGcz3mQI7sQGpO1GN4VWz0k+rpjFVrwOUiKcDnalpO361+HvvpHVllMtT9wp
pysMode7lCVyQtLxxU1tsJuCkCC5LQ6KkECX1Hb3SZlCXKXfUlO74qXC35nPTpJ4
KLoBJ8OFpr8+obdgdR7jCrUZnwAudSImsfdPFRTsKnSNa+2OA7Ja5+L52DE5hSK/
loHyCiq19OMaSAUmQBvyV6rBJJB/flrOqF8Apo9bjdUN1Wym83HbadQcBYgtsCkY
Ak81akJymFIP/WMVg8JSM9uVWLHxfvmVB4JXHx6CMi6qnZSwW2FuH+cbCOxvHDCw
HhS9USDI8l2JbsYyM94kOzO2mLHiGH4GmEKDBgkZbawu77tCg+FEXJ04ghg6DWZ7
fKW+8iyirapJl4JrRDMiUzf6ZaDTmf0jlbXfZ88aa5crw3hMW9MjMdU54BnqnnxV
MbMfuo1RaVomNxT1RtMMg9tEI70+TmpZd+00l7NGWHliZ7h9QA2w0oVuAsRfaqCW
dn2DVtVquaOcaDtzzEPrfVzXEz3DtV1KnwkmyxIUk/pRZ4cH8cvO8vsrbqej2XOd
vUyUI1q2MdFEwjR6jVjufc5dWqz+S3B/eib3/4KfCMgsRoViBvIfj4yTA06moUoJ
fo02sjPJkzsJGRY4R7qs
=HMi4
-----END PGP SIGNATURE-----


More information about the questions mailing list