On 2008-10-15, Mohit Aron <[EMAIL PROTECTED]> wrote: > ATTRIBUTION MISSING said: > >> 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.
Here's a possible explanation for your report of 'ntpd -gq' taking 3 minutes to sync: When older versions of ntpd start up the Undisciplined Local Clock (LocalCLK) will not be accepted as a "time source" until 4 polls have elapsed. The first poll occurs at start up and the subsequent polls occur at 64 second intervals using the default settings. So, using the dafults, the quickest that ntpd can "sync" to the LocalCLK is a bit over 3 * 64 seconds (192 sceonds or 3.2 minutes). When ntpd is started with '-gq' and only has the LocalCLK as a time source it _will_ block for a bit over 3 minutes. This "sync" time may be reduced a bit (to about 50 seconds) by setting minpoll for the LocalCLK to 4 (i.e. 'server 127.127.1.0 minpoll 4). Along the same vein, if the server is using the Undisciplined Local Clock (LocalCLK) as it's time source _none_ of the client systems will be able to sync to it for _at_ _least_ 3 minutes after it boots. So using sntp at client start up may not be the panacea it appears to be. Even though it appears that sntp, or ntpdate, are "done" because they return almost immediately the initial clock setting may have silently failed because ntpd on the server is not available (whether it is because the server is down or the server's ntpd is not synced is not important). The client systems may be "free wheeling" for some time before their ntpds are are able to poll the server and step their clocks or initate the first slew. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
