> On its own no. With the help of ntpdate, yes. I
> wouldn't actually expect to reach this level very often, but
> I'd certainly expect several milliseconds. You will
> get these large steps because you are using individual
> measurements, which are very vulnerable to scheduling delays
> and network propagation delays, which ntpd, itself, will
> average out (it will effectively low pass filter the jitter
> out of the measurements).
Hehe ;^) That was cool, with the help of ntpdate ;^)
Okay, I'll buy the scheduling delays argument, but latency? On my control
plane? No way ;^) That lan is soooo lightly loaded that any packet can get
sent anywhere it wants at any time on Gigabit ethernet. So lag, shmag, latency
jitter does not scare me ;^) I could see having a interrupt (perhaps for the
nic on my lightning fast control network ;^) get thrown in the middle of a
measurement. This is a reasonable argument. I am convinced.
>
> If you seriously need very tight synchronisation, you
> should use ntpd or possibly chrony, with a pulse per second
> source parallel wired to all the machines. In extreme
> cases, you may need to make sure the transmission lines from
> the PPS source are or equal length.
That might be a little extreme, we don't have a PPS source, or roof access for
a GPS receiver. Actually this whole discussion is becoming academic because of
the "it's already good enough factor". Fortunately, I am an academic so I
enjoy the discussion ;^)
If we can get down to a millisecond then we are golden. Wireless packets
simply do not move that fast. So I will do this. I will switch my systems to
ntpd, and I will also urge the emane community to switch. Perhaps they will
have other reasons for not wishing to use ntpd ;^)
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
