On 2008-04-23, maxime louvel <[EMAIL PROTECTED]> wrote: > The decision of buying a GPS is not mine ... So let's say for now > that's still not possible, if no other solution is found I'll conclude > that a GPS has to be bought.
I find it curious to hear people say that time stability is critical to the functioning of their application/business/whatever and then, in the next breath, say that they can't afford the requisite sub-$1000 solution. > - I have chosen a broadcast configuration for two reasons : > - easier to install The configuration for a leaf-node which polls a local time server is arguably simpler than any *cast configuration. > - I am doing the tests on only 2 nodes, thus with broadcast I assumed that > more nodes won't change the accuracy A broadcast client calculates the delay correction from the server during the intial unicast (i.e. client/server) phase of the association. This delay correction is based on the network conditions at the time the association is started. Broadcast packets sent during periods of lighter, or heavier, network congestion/loading will receive a less than correct broadcast delay correction. One big advantage to unicast assciations is that each poll automatically compenstates for the current network conditions. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
