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

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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/13/2012 03:34 PM, Brian Utterback wrote:
> On 12/13/12 09:14, Jonatan Walck wrote:
>> 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.
> 
> So you have an interesting case of the kernel clock being mostly 
> undisciplined and just using the controller clock. That might work,
> but it would be exceedingly odd. Also, as I read the specs, I think
> that there is a maximum of three packets that can be queued for
> launchtime, you might need to take that into account.
> 
> Brian.

Since one wants the timestamps as close to the wire as possible, I
don't find doing it in the network controller when it has a good
enough clock that odd.:)

The three packet limit is only for 82580 iirc, I350 and I210 widens
the whole rx queue and can save timestamps for each and every incoming
packet.

// jwalck
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQyen0AAoJEFwg9i9GDX+n+u8QAIzTEwbzHFX1KKfmhtJb/qMD
rlTJOUcNCEp09HeY7XjDxoJiVrVqhVg+3817H7oU/Zmr+8WMMPETC6eCNQzhyczi
NNwhc2L9IOUM+P1mkp34zQEAZKDXGDEas3xE+ViKGJWQeeSMotRx8JuwuGKqCHhA
zNovxcp8A7ajo2EcBs10mzn46/Hr0N4JSKSny6LO/VAX+TdhjmN2I3SfjLad3DUL
spdre9U8fQ3VGHwCuiwTr3GYxrZwsrdBfXqYgQQC+OqvLNKWwJNr8njSUU7DtiC+
qcL6o3gbwhdbzGrzm1z1D18uLMoDZ52HGYe0xdi5dF0eYj9kkz9rgDJvY11tW23m
G3QUtZ/4SCc4tTteydg63CCX7uqNVn/JiggESGawZs9sgnTBcJfa5eroCGJWiAmD
vZDC8BxP86EJ37ch+5HKlZf+NW15G/x0gnltVfZjTCxt7TP++txXaQje+nh/o+H0
80bJx6kwtN+csFBwFDWNSHckUNRYQl8sLubXPNqGNgnydEYK7i8v2GsGmwGBbPEF
S8YU+Kevk/+86xaH6X79caNF35o8AAdCdnxw83bW5PCIQdk6pOGcQIOqC+wOLlPU
yzSXNRerrbMYgyBXJUW+ZOWACGHggzJTQORXlOwgc2ECG5PWGlCzvYH7s4cIiV6q
3bPG4KR+4AexlXd+xZKE
=wO+t
-----END PGP SIGNATURE-----


More information about the questions mailing list