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

Brian Utterback brian.utterback at oracle.com
Thu Dec 13 14:34:08 UTC 2012


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.


-- 
blu

Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
-----------------------------------------------------------------------|
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterback at oracle.com



More information about the questions mailing list