Hi Dave. > This could be avoided by forcefully setting the clock at initial > startup
That's exactly what we do. You have to know that Robert an I are working on the same project. Robert is a systems engineer of the platform we use to build our device. The requirements of max. 100ms external offset, max. 10ms internal offset an 5 minutes until service availability are coming from our requirement specification. ;-) And we are always talking about a reboot scenario. So we don't need to compensate large offsets. What we do now during reboot is a) Measure the drift with my script for 2 seconds b) Set the time with ntpdate -b c) start ntpd with "iburst burst minpoll 4 maxpoll 6" for the controller blades requiring <100ms offfset and with "iburst burst minpoll 4 maxpoll 4" for those blades requiring <10ms among themselves So ntpd can start its operation with (almost) no initial offset and a drift that is +-2ppm away from the long-term value. This gives us a max. offset of <<1 ms right from the start. And that's what we were looking for. :-) Bye Juergen _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
