[ntp:questions] Re: Post processing of NTP data...

Danny Mayer mayer at gis.net
Thu Sep 29 03:14:35 UTC 2005


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




More information about the questions mailing list