On Thursday 15 December 2005 4:32 am, Per Jessen wrote:

"During operation ntpd measures and corrects for incidental clock frequency error and writes the current value to a file called by default /etc/ntp.drift"

My reading of the online description of ntp seems to indicate that the drift file is updated hourly, but when I did an ls on it I found that it hadn't been modified for over a day. And the only place I could find a file named ntp.drift was in /var/lib/ntp/drift/ntp.drift rather than the expected /etc/drift/ntp.drift Maybe I'm misunderstanding the udel description of ntpd, but I thought from that description that the external servers are contacted hourly, and that on each such occasion (a) the hardware clock is set to the time gotten from the external servers, and (b) the drift file is updated. Though come to think of it, if that's what happens then the drift file is useless. So after attempting to understand the ntpd description, I still have several questions: 1. How often are the external servers consulted? 2. What happens when they are consulted? 3. How often is the drift file updated? 4. When and how is the data in the drift file used? Anyone know?

what does "ntptrace" say? It sounds more like your clock isn't in fact being synchronised.

It says: suillus:~ # ntptrace /usr/sbin/ntpq: read: Connection refused Paul

On Friday 16 December 2005 2:39 am, Per Jessen wrote:

...

suillus:~ # ntptrace /usr/sbin/ntpq: read: Connection refused

Is your xntpd actually running? It doesn't look like it.

That may be the problem, since ps -A | grep ntp doesn't reveal it. Here are the last several entries in the ntp log: 30 Oct 10:22:30 ntpd[5269]: synchronized to 67.128.71.75, stratum 2 30 Oct 10:22:30 ntpd[5269]: kernel time sync disabled 0041 30 Oct 10:22:34 ntpd[5269]: synchronized to 209.51.161.238, stratum 1 30 Oct 10:22:34 ntpd[5269]: kernel time sync enabled 0001 30 Oct 10:23:34 ntpd[5269]: synchronized to 67.128.71.75, stratum 2 30 Oct 10:31:07 ntpd[5269]: synchronized to 209.51.161.238, stratum 1 30 Oct 11:40:26 ntpd[5269]: ntpd exiting on signal 15 14 Dec 21:10:50 ntpd[14778]: synchronized to 67.128.71.75, stratum 2 14 Dec 21:10:50 ntpd[14778]: kernel time sync disabled 0041 14 Dec 21:13:01 ntpd[14778]: synchronized to 209.51.161.238, stratum 1 14 Dec 21:16:16 ntpd[14778]: kernel time sync enabled 0001 14 Dec 21:35:49 ntpd[14778]: ntpd exiting on signal 15 14 Dec 21:39:04 ntpd[16264]: synchronized to 67.128.71.75, stratum 2 14 Dec 21:39:08 ntpd[16264]: synchronized to 209.51.161.238, stratum 1 14 Dec 21:43:26 ntpd[16264]: kernel time sync disabled 0041 14 Dec 21:52:06 ntpd[16264]: kernel time sync enabled 0001 14 Dec 23:37:37 ntpd[16264]: ntpd exiting on signal 15 15 Dec 22:53:08 ntpd[13217]: synchronized to 67.128.71.75, stratum 2 15 Dec 22:53:08 ntpd[13217]: kernel time sync disabled 0041 15 Dec 22:56:25 ntpd[13217]: synchronized to 209.51.161.238, stratum 1 15 Dec 22:56:26 ntpd[13217]: kernel time sync enabled 0001 15 Dec 23:32:05 ntpd[13217]: ntpd exiting on signal 15 What seems to be happening is that something is killing ntpd. Some of the entries are probably accounted for by my occasionally doing (as root) /etc/init.d/ntp restart or by actual restarts. There's also the mysterious gap between 30 Oct and 14 Dec. I also have: pwa@suillus:~> ls -l /var/lib/ntp/drift/ntp.drift -rw-r--r-- 1 ntp root 8 2005-12-14 23:35 /var/lib/ntp/drift/ntp.drift And here are the relevant (I think) values from Yast: NTPD_INITIAL_UPDATE AUTO NTPD_OPTIONS -u ntp NTPD_RUN_CHROOTED yes NTPD_CHROOT_FILES (empty) (These all seem to be the defaults.) There's probably a connection between the fact that ntp.drift isn't getting modified and that ntpd isn't running. Any ideas? Thanks. Paul

On Friday 16 December 2005 3:10 am, Carl Hartung wrote:

4. When the above process is completed, the client is effectively synced to the server. This makes two things possible: a) the hardware clock drift can be accurately measured and, b) that drift can be compensated for in software until the hardware clock is due for it's next adjustment (cron job? reboot?)

It's the ongoing compensation process that I'm wondering about, not the initial calculations. Presumably not only does the hardware clock drift, but the amount of drift itself drifts. Moreover, the tiniest inaccuracy in the drift value will accumulate over time. The natural way to handle this, I'd think, would be to check the external servers hourly, say (that shouldn't impose too great a load on them) and then modify the drift value accordingly. In between, use the drift data to nudge the hardware clock to the correct value. But I can't tell from the ntp docs I've looked at if this is what's supposed to happen -- or if not, what really does happen. My drift file hasn't been modified for the last two days, according to "ls -l". Paul

On Fri, December 16, 2005 9:23, Jeff Dierking said:

I set a cron job to run as root, the command is:

rcntp restart > /dev/null 2>&1 every night at 00:00

Make that... rcntp restart > /dev/null 2>&1 It is sceduled daily at 00:00 -- Jeff Dierking jeff@lordjester.com

On Fri, December 16, 2005 9:34, Patrick Shanahan said:

* Jeff Dierking [12-16-05 12:29]:

...

rcntp restart > /dev/null 2>&1

Why don't you test to see if ntpd is running before arbitrarily restarting it? --

Because the restart forces a time sync. There is no harm, IMO, of restarting the service. -- Jeff Dierking jeff@lordjester.com

On Fri, 2005-12-16 at 10:05 -0800, Jeff Dierking wrote:

On Fri, December 16, 2005 9:34, Patrick Shanahan said:

...

* Jeff Dierking [12-16-05 12:29]:

...

rcntp restart > /dev/null 2>&1

Why don't you test to see if ntpd is running before arbitrarily restarting it? --

Because the restart forces a time sync.

There is no harm, IMO, of restarting the service.

There should be -no- reason to force a time sync unless you have something else buggered up. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

On Friday 16 December 2005 4:06 pm, Jeff Dierking wrote:

On Fri, December 16, 2005 11:31, Ken Schneider said:

...

There should be -no- reason to force a time sync unless you have something else buggered up.

My clock drifts. I haven't anylyzed my drift file since I put that in the last time a few weeks ago, but as all my machines get thier time from this box and the only other time it syncs is at boot, which happens rarely, I opted for a more pro-acive approach.

So I'm not the only one with a drifting clock! What does ps -A | grep ntp show you? In my case it showed me that no ntp-related daemon was running. I don't know where such daemons are supposed to be started, though, so I don't have a fix other than ad-hocery such as you adopted. Paul

On Friday 16 December 2005 6:10 pm, Carl Hartung wrote:

On Friday 16 December 2005 16:06, Jeff Dierking wrote:

...

My clock drifts. I haven't anylyzed my drift file since I put that in the last time a few weeks ago, but as all my machines get thier time from this box and the only other time it syncs is at boot, which happens rarely, I opted for a more pro-acive approach.

My experience has always been along the same lines as Jerry's and Ken's on this one... set and forget... I usually use YaST and don't experience any problems.

How much drift are you seeing, over what time frame and how did you first become aware of it?

I just discovered, thanks to an article by Carlos Robinson, that ntpd was not being started at boot time but that I could fix it by going into the runlevel editor within Yast. I don't understand why the default is to not run ntpd. In any event, I've turned it on now, so I'll see if my clock keeps better time. But that still leaves the following question. If ntpd relies only on the drift file to keep the system clock accurate, sooner or later the system clock will wander. Supposedly if ntpd is running, the drift value is updated on halt. But what if the machine is never turned off? Is there some way to get ntpd to consult its collection of timeservers periodically and/or update the drift value? Paul

On Friday 16 December 2005 06:40 pm, Patrick Shanahan wrote:

You can answer all your questions and get a better understanding of the function of the ntp daemon if you would spend a few minutes reading the beginning of the voluminous documentation available for ntp.  Also there are *many* faq's in existance.  Carlos Robinson has written a good one.  *You* need to do this because your questions show that you know *very* little of the function of ntp. --

My thoughts exactly.... and the reason that SuSE doesn't turn it on by default is because it *does* put a load on all of the time servers (especially by people who don't know how to operate NTPD) and you are *supposed* to ask permission or at least notify the owner of a time server that you are going to access it. Do your homework, please.....

On Friday 16 December 2005 07:48 pm, Carlos E. R. wrote:

I think the primary reason is that SuSE doesn't know if the system will have a permanent network access (I don't, for instance). Then, of course, we, as users, have to choose which servers to take the time from.

As well as whether the install of SuSE would be on one of many machines at a particular site... in which case they might all sync on one of the machines instead of having them all access a time server on the net.

On Friday 16 December 2005 7:30 pm, Bruce Marshall wrote:

The reason that SuSE doesn't turn [ntpd] on by default is because it *does* put a load on all of the time servers (especially by people who don't know how to operate NTPD) and you are *supposed* to ask permission or at least notify the owner of a time server that you are going to access it.

Your comment got me more curious about this subject and I did some investigation. The primary source of information about available timeservers is at http://www.cis.udel.edu/~mills/ntp/servers.html. (You probably know that already, but my comment is for the benefit of other readers.) Here's what's said there, a couple of web pages in: <begin quote> pool.ntp.org uses DNS round robin to make a random selection from a pool of time servers who have volunteered to be in the pool. This is often good enough for end-users. The minimal ntpd configuration file (e.g. /etc/ntpd.conf) for using pool.ntp.org is: driftfile /var/lib/ntp/ntp.drift server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server pool.ntp.org If you use only one pool server, we recommend you use the "bare" zone without a number, but if you use several, then use the numbered ones first. To make it possible to select a timeserver which is geographically close, we have sub-zones of pool.ntp.org. The "continent" ones are: Area: HostName: Worldwide pool.ntp.org Asia asia.pool.ntp.org Europe europe.pool.ntp.org North America north-america.pool.ntp.org Oceania oceania.pool.ntp.org South America south-america.pool.ntp.org There are also sub-zones for many countries. Click on your continent to see which country-zones are available there. <end quote> The upshot of all this is that the typical end-user should use one of the pool timeservers (they explicitly say that's okay, and no notification is needed or indeed possible) and put the references into /etc/ntp.conf. And given that, the typical end-user can also turn on ntp in the runlevel section of Yast without guilt. (And if you don't, your clock will drift.) Paul

A few minor corrections to account for some implicit but not necessarily universal assumptions: 1. There's no point in activating ntp in Yast if the machine has no network access, since there's nothing to verify the local time against. 2. If network access is available only intermittently, "ntpd -q" (equivalent to ntpdate, but better) should be called from a cron job or when access is available to update the drift file on a one-time basis. 3. After running for several hours and waiting for the drift values to stabilize, ntpd shuts down and revives itself periodically as necessary in order to make further corrections. Kernel support, which Linux provides, is necessary for ntpd to be able to do this. Without such support, it runs continuously. Paul

Another correction: The polling of the listed time servers actually happens more often than hourly, though I don't know how the data is used (it isn't used right away to modify ntp.drift). The polling intervals for the time servers are revealed by the command "ntp -qn" and appear in the "poll" column; the "when" column indicates elapsed seconds since the last poll. ntpd avoids polling all the servers at the same moment. Also, the pool time servers should be referred to by their domain names, not their IP addresses, since the time servers in the pool are changed periodically to equalize the load among them. My description does in fact use the domain names. Paul

Bruce Marshall wrote:

On Friday 16 December 2005 06:40 pm, Patrick Shanahan wrote:

...

You can answer all your questions and get a better understanding of the function of the ntp daemon if you would spend a few minutes reading the beginning of the voluminous documentation available for ntp. Also there are *many* faq's in existance. Carlos Robinson has written a good one. *You* need to do this because your questions show that you know *very* little of the function of ntp. --

My thoughts exactly.... and the reason that SuSE doesn't turn it on by default is because it *does* put a load on all of the time servers (especially by people who don't know how to operate NTPD) and you are *supposed* to ask permission or at least notify the owner of a time server that you are going to access it.

Whether or not you ask permission, depends on what the server wants. Some expect you to ask, some don't. Check the list and see what the policy is. http://ntp.isc.org/bin/view/Servers/WebHome

On Friday 16 December 2005 18:26, Paul W. Abrahams wrote: <snip>

I just discovered ... that ntpd was not being started at boot time

When I configure it in YaST, all I do is enter my preferred time server and test the connection (after dropping the firewall). When I click 'Finish' or 'OK' or whatever that label is, the process is done and ntpd starts at boot. Did you configure it manually, by editing files, or did you set it up in YaST?

I don't understand why the default is to not run ntpd. In any event, I've turned it on now, so I'll see if my clock keeps better time.

Per the above, it would/should have been starting at boot if you configured it in YaST

But that still leaves the following question. If ntpd relies only on the drift file to keep the system clock accurate, sooner or later the system clock will wander. Supposedly if ntpd is running, the drift value is updated on halt. But what if the machine is never turned off? Is there some way to get ntpd to consult its collection of timeservers periodically and/or update the drift value?

This hypothetical style of questioning is hard to respond to without rolling up one's sleeves, digging into the documentation and doing a lot of research -- unless you're a Linux guru, of course. I prefer to just give the creators of the ntp system credit for understanding how to keep time accurate on a system that runs 24x7. I could be wrong... I've been wrong before... but mine just works here. Your's should, too. regards, - Carl

* Paul W. Abrahams [12-16-05 19:34]:

But I'm still curious about certain aspects of how it works.

http://www.ntp.org -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2

On Fri, 16 Dec 2005 19:32:30 -0500, Paul W. Abrahams wrote:

But I'm still curious about certain aspects of how it works.

As has been told to you numerous times in this thread: read the ntp documentation! Some of it can even be read offline if you install the xntp-doc package and then point the browser of your choice to file:///usr/share/doc/packages/xntp-doc/html/index.html . For the rest visit http://www.ntp.org Participants of this mailing list are required to make themselves knowledgable *before* asking the list. Show that you've actually read the available documentation and *then* come back witch questions if you didn't understand some part or if you have questions the documentation doesn't cover. Philipp

On Fri, 16 Dec 2005 21:43:11 -0500, Paul W. Abrahams wrote:

But nowhere in what I read did I find an explicit statement that ntpd queries the time servers once an hour to update the drift file,

Quoting from http://www.eecis.udel.edu/~mills/ntp/html/notes.html : One of the things the NTP daemon does when it is first started is to compute the error in the intrinsic frequency of the clock on the computer it is running on. It usually takes about a day or so after the daemon is started to compute a good estimate of this (and it needs a good estimate to synchronize closely to its server). Once the initial value is computed, it will change only by relatively small amounts during the course of continued operation. Nowhere in the documentation will you find an exact time like "one hour" because there is no fixed frequency in which ntpd will update the drift file. Philipp

Paul W. Abrahams wrote:

I don't understand why the default is to not run ntpd.

First, many people probably don't have a need for a highly accurate clock. It often comes in very handy e.g. when you've got multiple database-servers with timestamps and such, but Joe Bloggs doesn't really have a need for it. Second, because it needs to be specifically configured for your environment, i.e. you need to tell it which time-server to use.

But that still leaves the following question. If ntpd relies only on the drift file to keep the system clock accurate, sooner or later the system clock will wander.

But ntpd does not only rely on the drift-file for keeping your clock accurate. Really, it's time to RTM. I know it's long and complex, but ...

Is there some way to get ntpd to consult its collection of timeservers periodically and/or update the drift value?

Yes, and it does so by default. /Per Jessen, Zürich -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2005-12-16 at 10:05 -0800, Jeff Dierking wrote:

...

...

rcntp restart > /dev/null 2>&1

Why don't you test to see if ntpd is running before arbitrarily restarting it?

Because the restart forces a time sync.

There is no harm, IMO, of restarting the service.

Actually, there is. The ntp daemon is designed to run continuously and discipline the system clock; if you restart it, you force it to redo its calculations, which no longer will have a long time to compare drifts. If you are running ntp daemon and it doesn't keep your clock in sync, then you have some problem you have got to find out and solve - but not by restarting the daemon. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDo0n1tTMYHG2NR9URAka9AKCTpO0wStT4Nqh064HSZryzEZuXMACfdjsV q8sxdxHp6PPO+YVjh5KqF3U= =uylP -----END PGP SIGNATURE-----

On Thursday 15 December 2005 01:32 am, Per Jessen wrote:

Paul W. Abrahams wrote:

...

As I understand it, the system clock is set upon boot from network time sources by the command   /etc/init.d/ntp start and can subsequently be set by   /etc/init.d/ntp restart

Yes. I wrote a little thing on it here, too... http://www.perfectreign.com/modules/articles/article.php?id=4 HTH! -- kai www.perfectreign.com linux - genuine windows replacement part

On Saturday 17 December 2005 00:12, Paul W. Abrahams wrote: <snip>

The one improvement I'd suggest there is the choice of time server. Configuring more directly via Yast is a good idea, and I didn't realize you can do it. But using 4 pool servers is better than using 1 specific server, especially if your method becomes very popular and that server becomes overloaded.

Hi Paul, This list (archives or active e-mails) aren't meant to replace documentation. I don't know what you think you're accomplishing, but IMHO it is ridiculous at this point to keep stretching this thread out with an ongoing stream of details and corrections. The only time this might be reasonable is when a real person with an ongoing problem is continuing to ask questions. Moreover, I hate drilling down through twenty or thirty posts in an archived thread, searching for an answer, only to find it full of contradicting information in the form of corrections and 'corrected corrections' (which may or may not be accurate.) Near the start of this thread, some people wisely suggested that you study the docs... they even provided paths and links. This thread really could and should have ended then, so can you please stop appending to it now? Thanks & regards, - Carl