> > If you run ntp -g, it WILL roughly synchronize it in exactly the same way > as ntpd -g -q does. The -q does nothing to affect the behaviour of ntp, > except once it first sets the clock, it exits. >
Yes, I realize that. However, it does mean that the time will be synchronized after a long time - the machine needs to do lots of startup stuff when it starts and its essential that the time be approximately correct when this happens. For example, it needs to log messages about various things - the timestamps on these log messages cannot be out of whack. That's why its important to update the time quickly in a single shot, and then run something like 'ntpd -g' which can keep the time in sync in the background. > > > Are you running on Linux or windows? If on Linux, you might want to look at > chrony, which is much faster in converging to the right time, and > furthermore is better at disciplining the clocks once it is running. > If you are on Windows, chrony does not work. > I'm running on Linux. One of the links posted in this thread helped me find a good alternative to ntpdate - which is 'sntp -r <server>'. I'll check out chrony too, but it seems sntp will probably serve my purpose. > The usual way of starting up machines is to use the machine's own rtc to > start up the clock. Using a recent hwclock, this use can be quite accurate > ( better than a second after a day's downtime). Not sure what your > requirements are. > The issue is that when new machines are added to the cluster, their times might be completely out of whack. So hwclock can in general not be relied upon. Also, we use VMware based virtual machines for internal testing - such machines can't keep their hwclock ticking while they are powered down. - Mohit _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
