[ntp:questions] frequency adjusting only
mayer at ntp.isc.org
Wed Apr 23 11:42:00 UTC 2008
maxime louvel wrote:
> I am actually using 4 public NTP server, which whom my node-1
> synchronises to.
> Then node-1 broadcasts the time to all the other nodes in the subnet.
If you are using broadcast mode then you have two additional issues that
you need to deal with:
1) authentication is required by default
2) you are not measuring the delay for every packet
With autokey, the delay gets measured during the autokey dance which
happens in client/server mode and then it switches to broadcast when it
completes. You cannot measure the delay in broadcast mode since the
server sends out the packets and the client just receives them.
Broadcast can only apply the delay estimates that it got when in the
autokey dance and cannot account for changes until the next autokey dance.
If accuracy is critical in this environment, don't use broadcast. At
least in client/server mode you get to measure the delay with each packet.
> My goal is to achieve a synchronisation between the nodes (not with the
> public NTP server) within 50 usec.
> I don't care if the synchronisation to the public NTP is accurate around
> half a second.
> I think it's possible, because the nodes are close to each other and
> every communication is using gigabit ethernet (cards + switch).
> I achieve to get a small offset when nothing else than linux and ntpd is
> running on the nodes
> (offset arount 10 usec).
> I have a program which sends data from one node to another.
> The sending/reception are timestamped and the delay is then computed.
> I would like the measured delay to be constrained in a 50usec wide range.
> Do you think it should be possible ?
> I have tried to run the test for 24h and didn't get the expected results.
> The range of the measured delay is 2 milliseconds (between -1ms and
> +1ms) with some spikes (ten or so for a milion measurments). The mean
> delay is -0.066087 (ms) and the std dev is 0.22849
> Do you think the spikes can influence ntp ?
> thanks very much
More information about the questions