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

Brian Utterback brian.utterback at sun.removeme.com
Tue Sep 27 16:13:12 UTC 2005


Val Schmidt wrote:
>>>
>> If you configure, as you should, a minimum of four network servers,  
>> which of the four different offsets would you use?
> 
> 
> It's a good question. Doesn't ntp actually use only one of them at  any 
> given time, switching between them as network latency or other  
> parameters warrant. I suppose one would want to correct to the one  
> being used at the moment.
> 
>>
>> If you want highly accurate time, using a GPS timing receiver as a  
>> hardware reference clock can give you offsets less than ten  
>> microseconds.  This assumes that your hardware and O/S are good  
>> enough to follow the reference clock that closely
>>
>> I have an old Sun Ultra 10 workstation with a 330 MHz processor  
>> running Solaris 8, NTP-4.2.0 and a Motorola Oncore M12 Timing  
>> receiver that synchronizes with offsets of less than 10  
>> microseconds.  (My total cash outlay was $300 for the Ultra 10,  $100 
>> for a Solaris 8 Media kit, and $200 for the GPS receiver.
> 
> 
> How much of this is system-load dependent? Does your Sun do anything  
> but serve time? Do you see significant excursions with other  processes 
> active or moderate to heavy network traffic to or from the  box?
> 
>>
>> Free BSD is another O/S that seems to be highly regarded for its  
>> timekeeping abilities although I have no personal experience with it.
>>
>> Poul Henning Kamp has used Soekris single board computers, Free  BSD, 
>> and Motorola Oncore M12 receivers to achieve sub microsecond  accuracies.
> 
> 
> Impressive.
> 
>>
>> Windows (any version) and Linux on the Intel platform do not  perform 
>> very well in this application.
> 
> 
> Is this because interrupts are dropped from time to time or other  reasons?
> 

To restate your plan, you want to increase the accuracy of timestamps 
taken from a system's clock by recording the offsets over time between
that system clock and a stratum 1 server, and then correcting the 
timestamps by the then current offset in post-processing. This is 
somewhat analogous to differential GPS, where the GPS unit applies
error corrections obtained from an outside source.

This won't work. Or rather, it would work, sort of, if you were not
running NTP. If the clock on your system was free-running and not
disciplined by any outside agency, then taking a series of offsets
over time could improve the accuracy of timestamps produced by that
clock.

Now consider. NTP is already taking offsets and adjusting the clock,
in real time. So, what you get directly from the system clock is the
result of applying just the same process that you are proposing. In
addition, with multiple servers in use over a long period of time,
the accuracy that NTP can achieve disciplining the system clock is
much higher than you can ever get by applying a single timestamp.
Furthermore, the limits of that accuracy are governed by exactly
the same errors that you get from taking the single offset, so
that correction will certainly decrease the accuracy of the
resulting timestamp, and not increase it as you hoped.

To answer your later question, remember that there are two sources of 
error in taking a timestamp. One is the latency and scheduling as you 
noted, but those same issues can effect the system clock itself. NTP
tries to correct for those sources of error in the clock itself, but
depending on the architecture, it may not be possible.

-- 
blu

Remember when SOX compliant meant they were both the same color?
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom




More information about the questions mailing list