[ntp:questions] Accuracy of NTP - Advice Needed

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Fri Dec 23 17:02:51 UTC 2011


Paul Sobey wrote:
>> Gbit and low jitter is not quite compatible: 100 Mbit switches were
>> using cut-through, while (afaik) all Gbit and up switches use store &
>> forward, leading to higher latency and jitter.
>
> There are several varieties of cut-through gig/10GB switch available now
> - but noting that store and forward adds latency is a good point.
> Presumably layer 3 switching (routing) is always store and forward since
> we're effectively writing a new packet. It's all done in hardware though
> - negligible jitter.

Negligible only in a statistical way, when running on a lightly loaded 
network (close to zero collisions/arbitration for access to the same port)

>> You can use ntpd's internal numbers to verify the maximum possible
>> offset (half the round trip time), you should be able to use
>> statistics to show that the jitter is quite low as well.
>
> At the risk of pushing my luck, can you expand on this?

NTPD statistics will easily give you an order of magnitude better 
accuracy than that defined by half the RTT, so if you have ping times 
well below 1 ms, you should get actual offsets in the dual-digit us range.

>> The best (and probably only possible) solution that does give you
>> single-digit us is to route a PPS signal to each and every server,
>> then use the network for approximate (~100 us) timing, with the PPS
>> doing the last two orders of magnitude.
>
> Our problem will be that running coax around many sites to lots of
> machines, many of which don't have serial ports (think blades), is both
> highly time consuming and maintenance intensive. If we have to do it
> then we will but I'd like a clear idea as to the whys before I start
> down that particular path.
>
> In particular at this stage I'm trying to understand more about the
> theoretical accuracies obtainable under ideal conditions, and most
> important, how to independently verify the results of any tweaks we
> might apply. Say I have coalesence turned on a nic and I disable it -

That is just one of the things you _have_ to do in order to get rid of 
jitter.

If you have ethernet cards that support hw time sync (I don't remember 
the spec number), then you can indeed get low us over network links, but 
that isn't ntp any longer, and you'll still have to replace the blade 
infrastructure.

> I'd like to be able to determine the effect, if any of that change. Is
> it possible for ntpd (or ptpd) to accurately determine its own accuracy,
> if that makes sense? If not what techniques might I use to independently
> measure?
>
> On a related note, I'm aware that there are various methods for querying
> the system time, some of which involve a context switch, and some of
> which can be done cheaply in userspace. I'm not sure whether the same is

A fast system time query will load the time as of the last hw clock 
tick, along with the corresponding RDTSC (or similar, constant-rate 
highres clock source), load the current RDTSC value, then re-read the OS 
tick.

If the OS tick has been updated in the meantime, restart the process.

Finally, scale the RDTSC delta by the (OS-provided) frequency and add to 
the tick time: The result is the current system time in ~100 clock 
cycles, with sub-us precision.

> true for setting the time. Is anyone aware of how much ntpd operation
> involves context switches, which obviously would place quite a high
> ceiling on accuracy since we're at the mercy of the OS scheduler?

NTP does not set the time, it just tells the OS how much the tick rate 
should be tuned by, i.e. effectively how short/long each tick really is.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list