[ntp:questions] frequency adjusting only

Unruh unruh-spam at physics.ubc.ca
Tue Apr 22 16:07:23 UTC 2008

"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>maxime louvel wrote:
>> On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <kostecke at ntp.org> wrote:
>>> On 2008-04-22, maxime louvel <m.louvel at gmail.com> wrote:
>>>> My goal is to achieve a synchronisation between the nodes (not
>>>> with the public NTP server) within 50 usec.
>>> You may want to explore other synchronization options such as IRIG,
>>> distributed PPS, or a distributed 10MHz clock.
>> Thanks I'm gonna look at some other synchronisation solution.
>>>> I don't care if the synchronisation to the public NTP is accurate
>>>> around half a second.
>>> You're displaying a common misconception about NTP.
>>> The goal of NTP is not explictly to synchronize clocks to "the one
>>> true time". Rather, NTP synchronizes clocks to a common time base. A
>>> "better" time base, and a "better" distribution method, allows tighter
>>> synchronization between nodes.
>>> It so happens that UTC (via GPS or HF Radio or UDP) is a ubiquitous,
>>> stable, and relatively inexpensive time base. A side effect of using UTC
>>> as your time base is that your clocks are synchronized to the correct
>>> time.
>> Sorry I haven't express myself correctly. What I meant is that I want an
>> accuracy of 50 usec within my subnet and I want my whole subnet to be
>> synchronised to UTC with an accuracy of 1 second or less if possible.

>That's going to be very difficult to do!  Getting the whole herd to the 
>point where the difference between any two nodes is less than 50 usec is 
>damned near impossible using NTP on a LAN.  You might want to consider 
>using a Pulse Per Second (PPS) signal delivered to each node, with NTP 
>used only to timestamp the rising edge.  If you compensate for cable 
>delays you can probably get to within 50-100 usec.

Nuts. I regularly get 10us on a lan connecting my machines all over the
physics building here. 
The biggest problem is the rate changes due to heating while the computers
are being used. The delay in the software adjusting to that is the key
noise problem. 

More information about the questions mailing list