Re: Post processing of NTP data...

vschmidt@xxxxxxxxxxxx (Val Schmidt) · Thu, 29 Sep 2005 13:36:39 GMT

Thanks Danny.
So let me see if I can summarize what I think everyone has said in  
these past few posts and you all can grade how well I was paying  
attention.
1) When one talks about system clock accuracy one should define how  
it is to be measured. One might measure the offset between the local  
system clock and UTC as the difference between the results of the  
gettimeofday(() function executed on the local system and a 1 PPS  
signal standard (whose accuracy is in the 10's of nano-second range  
to UTC).
2) The offset measurement itself between an ntp system trained clock  
and the reference standard is a sum of (at least) the actual time  
error between the two clocks, the precision in which time is reported  
to the system OS by the hardware. the latency involved in executing  
the gettimeofday() function, and the latency involved in  
communicating and timestamping the reference signal. The latter three  
are OS and hardware dependent and depend, in part, on the processor  
speed (how frequently interrupts are processed), the OS (how reliably  
interrupts are processed) and the coarseness of the tick rate of the  
system clock which might be anywhere from ~60 to 1000Hz. (translating  
to ~17ms to 1ms delays).
3) The tick rate can generally be thought of as the system's  
metronome and limits the accuracy at which the system can report  
time. However I think OSes provide higher resolution time stamps, and  
I can only assume they interpolate between ticks with software. At  
any rate, at least some hardware has the ability to interpolate  
between ticks to provide a higher resolution time stamp. But  
ultimately the resolution of the time stamp is limited by the tick rate.
4) While a fast tick rate increases the theoretical resolution of the  
system clock, the increased interrupt rate to the system can cause  
OSes to skip interrupts, which prevents algorithms like ntp from  
accurately training the local clock and ultimately results in larger  
offsets. Catching every tick is better than getting them more rapidly  
but missing some.
5) To date, Sun and FreeBSD have proved very good at catching time  
interrupts reliably, while LInux and Windows often skip interrupts  
when under system load. It is not clear to me if Intel hardware is  
part of the problem.
6) All of this said, ntp is designed to train the local oscillator to  
a reference time standard measured either from a 1) an ntp driver to  
a local standard, or 2) over the network from a higher stratum  
server. Local oscillators drift for whatever reason, temperature, and  
ntp attempts to adjust their frequency to minimize the clock offset  
and drift rate in a smooth fashion. Changing system conditions  
(ambient temp, system load, etc.) and the ntp daemon's ability to  
reliably predict the transmission delay of the reference signal (from  
whatever source) contribute to changes in the local oscillator  
frequency and the reported offset between the local system clock and  
the standard.
7) The consensus seems to be that one should not attempt to increase  
the accuracy of a system's time stamp by measuring the instantaneous  
offset between the local time and the reference time and applying  
that difference. The reason is that the error of any instantaneous  
measurement is potentially very large and any fairing through of the  
measurements done by the ntp algorithm to reduce the errors would  
effectively be negated. That is, one would be introducing errors into  
the time stamps that ntp had worked hard to remove.
Follow up Question:
1)  From the discussion above, it is not at all clear how one  
measures offsets less than about 10ms. How are measurements taken  
between a GPS reference with 1PPS signal and the local system clock  
when people report accuracies in the micro-seconds or even nano- 
seconds? Do I understand correctly that the local system time  
typically can't be reliably determined to better than 10's of  
milliseconds?
-Val

On Sep 28, 2005, at 11:14 PM, Danny Mayer wrote:
Richard B. Gilbert wrote:
Val Schmidt wrote:
At 5:08 PM -0400 2005-09-26, Val Schmidt wrote:

 I want to log several things with time stamps on the order of  
~ . 1ms -

 maybe less.

    Most modern OSes don't allow you to directly achieve better   
than 10-20ms accuracy at the level of an individual event.   
Some  real-time operating systems (RTOSes) may allow you to  
achieve finer  resolution at that level, but I don't know if any  
of them are going  to let you get down to the level you want.

Can you help me understand why?
Many operating systems update the clock at ten millisecond  
intervals; e.g. the clock "ticks" at 100 Hz.  When queried as to  
the time using O/S services, these systems respond with the  
current value of the clock register.  The maximum error is thus  
9.99999... milliseconds and the typical error is 5 milliseconds.    
Some very new hardware designs allow ntpd to interpolate between  
"ticks" and yield a much more precise time, if and only if, you  
use NTP supplied functions to get the time.

Well what's really happening is that ntpd is keeping the clock really

accurate of a long time period. However, when you ask for time from  
the

O/S it can only return to you a value accurate to the resolution  
allowed

by the function, usually gettimeofday(). There are a number of  
areas of

error in the accuracy that need to be considered.
1. The resolution of the function call. For example if you use
gettimeofday(), it is capable of returning results to the microsecond.
It does not, however, mean that the value returned is that accurate.
2. The resolution of the clock. Every clock is different so it's  
hard to

know what its resolution is unless you look at the specs. You'd  
need to

go to the manufacturer's site to find this out, if you're lucky enough

to know who the manufacturer is. Even then, you don't know if your  
clock

is from a bad batch, a good batch or an indifferent batch.
3. The ability of the O/S and hardware to store a value accurately.  
Even

if you are able to obtain a value accurate to the microsecond, being

able to adjust the clock to accept that value is limited by both the

Operating System and the Hardware. You'd have a very hard time  
figuring

out that error estimate.
4. You are limited by the ability to get an accurate value from an

external source, whether it be a Cesium clock, GPS or the Internet.  
This

error can be hard to estimate, but NTP tries it's best.
5. You can ask ntpd on the local machine for the most accurate time  
that

it thinks it has, but like everything else it takes time to  
retrieve the

number, but which time (no pun intended) the value will no longer be

valid. Think Heisenberg's uncertainty principle: The act of taking a

measurement causes an error in the result.
  I seem
to recall that Windows uses some really odd interval like 17  
milliseconds between "ticks".

Using clockres from Sysinternals on Windows XP Pro on an Intel CPU  
on a

Laptop running on battery:
The system clock interval is 10.014400 ms
  Linux can optionally update the clock
every millisecond (1 KHz tick rate) but this doesn't work very  
well as the system tends to lose clock interrupts when it gets busy.

Most applications simply do not require precise and accurate time  
and general purpose computers are generally not designed for  
precise and accurate timing.

If you do need that kind of accuracy you have to spend money on
hardware, the cost of doing so increasing with the required accuracy.
Even then you are limited by the sources of errors listed above.
Danny
_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxxxxxx
https://lists.ntp.isc.org/mailman/listinfo/questions

------------------------------------------------------
Val Schmidt
CCOM/JHC
University of New Hampshire
Chase Ocean Engineering Lab
24 Colovos Road
Durham, NH 03824
e: vschmidt [AT] ccom.unh.edu
m: 614.286.3726

_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxxxxxx
https://lists.ntp.isc.org/mailman/listinfo/questions
.

Re: Post processing of NTP data...

Relevant Pages