[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

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

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


More information about the questions mailing list