"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >Unruh wrote: >> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >> >>> maxime louvel wrote: >>>> On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <[EMAIL PROTECTED]> wrote: >>>> >>>>> On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> 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. >>
>A lot may depend on your LAN. A large 10/100 UTP net (300 nodes) in >which traffic might pass through two or three switches to reach its >destination is not necessarily well behaved for timing purposes. Even >after dividing the mess into several VLANs the performance left much to >be desired. It worked but I don't think we ever did much better than >millisecond accuracy. Well, I am in a physics dept. Some of my machines are across the building from others-- into the hall switch cabinette down to the basement over to the uplink to the other cabinette, through those switches to the other computer. Typical fluctuation in timing is less than 20us, much less. http://www.theory.physics.ubc.ca/chrony/chrony.html inflaton, orbit, dilaton are across the building from string, the GPS controlled ntp time source. The rest are in the same room.(but the switch is across the hall.) _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
