maxime louvel 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. > > - Danny, you're talking about the delay I got with ntpq -p ? >
I haven't seen what your delays are but if that's for the server providing the broadcast packets that's a different delay. You need to be doing queries of each of the clients to which you are distributing time packets. > - I have chosen a broadcast configuration for two reasons : > - easier to install > - I am doing the tests on only 2 nodes, thus with broadcast I assumed > that more nodes won't change the accuracy > > I though it was possible to achieve the same precision with broadcast > than with C/S, that's erroneous ? > No because you are not continuously monitoring the delay. If you are not using authentication (and you haven't said one way or the other) then the client doesn't even get an initial estimate of the delay. At that point if you are only receiving packets you don't even have an idea of the delay. If you are interested in correcting for the delay you have to have a way of measuring it. NTP can do that but only if you are using standard server configuration or with broadcast using authentication. The only other way to account for the delay is to estimate it for each node and add it into the configuration file with, I believe, the fudge command, but you'd have to look that up. The most accurate way keep all your nodes closely synchronized without using refclocks is to use client/server mode since that will be continuously monitoring the delay. Danny > maxime _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
