[ntp:questions] A proposal to use NIC launch time support to improve NTP
ulf at invalid.com
Wed Dec 19 00:05:49 UTC 2012
Brian Utterback <brian.utterback at oracle.com> 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.
>> 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.
No, you capture the time for the 1 PPS pulse in the network controller.
Then you tweak the count rate of the timestamp counter up or down.
Eventually you will have synchronized the timestamp counter with the 1 PPS
If you run the network contoller from a clocksource derived from the Cesium
You should get within a few ns from the pulse,
It is an inconvenient approach since you can easily synch your timestamp
with a 1 PPS pulse
using a few counters if you understand the issue.
Unfortunately, those counters are not available in the Intel chips, so we
have to use it they way they
want us to use it.
Since launch time will be the arrival time of the client request (through
+ a constant delay, any delays in the PCIe bus will not affect the
You just have to make sure that the constant delay added, is longer than
the processing time inside the server.
Best Regards, Ulf Samuelsson
More information about the questions