On Monday 02 October 2006 14:37, Per Jessen wrote:

Daniel Bauer wrote:

...

Output of xntpdc is:

ntpdc> peer remote local st poll reach delay offset disp

=======================================================================

...

=LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03087 *swisstime.ee.et 192.168.2.2 2 1024 377 0.02505 0.009517 0.11856 ntpdc>

(I must confess that I have not the slightest idea what these messages want to tell me, and I havn't found out in xntp_doc...)

The LOCAL(0) line says that your localhost is a time-source at stratum 10. This is created by the "fudge" line in ntp.conf. The next line says that you are synced to swisstime.ee...

You can also try to do an "ntptrace" and study the output.

/Per Jessen, Zürich

Hm... when I typed ntptrace (as root) I got: localhost: stratum 3, offset 0.002145, synch distance 0.974084 swisstime.ee.ethz.ch: stratum 2, offset 0.000051, synch distance 0.015953 129.132.2.22: timed out, nothing received ***Request timed out So I thought, swisstime is too slow in answering, went to Yast, choosed another timeserver, but then ntptrace gave only: localhost: stratum 16, offset 0.000000, synch distance 0.000615 So I switched back to swisstime (in Yast) and now I still get only this single line. Or is this already the "good" line??? However, clicking "test" in Yast after choosing a timeserver says it's reached and answered. But var/log/messages still says Oct 2 15:12:17 venus ntpdate[20412]: adjust time server 129.132.2.21 offset -0.001462 sec Oct 2 15:12:17 venus ntpd[20417]: ntpd 4.2.0a@1.1191-r Fri Sep 9 17:17:17 UTC 2005 (1) Oct 2 15:12:17 venus ntpd[20417]: precision = 1.000 usec Oct 2 15:12:17 venus ntpd[20417]: Listening on interface wildcard, 0.0.0.0#123 Oct 2 15:12:17 venus ntpd[20417]: Listening on interface wildcard, ::#123 Oct 2 15:12:17 venus ntpd[20417]: Listening on interface lo, 127.0.0.1#123 Oct 2 15:12:17 venus ntpd[20417]: Listening on interface eth0, 192.168.2.2#123 Oct 2 15:12:17 venus ntpd[20417]: kernel time sync status 0040 Oct 2 15:12:17 venus ntpd[20417]: frequency initialized -18.184 PPM from /var/lib/ntp/drift/ntp.drift while my search in google lead me to a page telling me that this is a "firewall error", in the doc I found that "kernel time sync status 0040" is "for information only. See the codes in the timex.h file." However doing a time update manually from the command line says that my local time is almost exact. So maybe it just works fine and the message means just nothing??? Anyway I still would like to find out, if, when and how many times this deamon will check my time, but all those messages are really cryptic to me. I even don't know what "stratum" means. When I was younger, there was a disco here called "stratos" :-) Any more hints that even I can understand? Daniel -- Daniel Bauer photographer Basel Switzerland professional photography: http://www.daniel-bauer.com Madagascar special: http://www.sanic.ch

On Monday 02 October 2006 15:54, Peter Van Lone wrote:

On 10/2/06, Daniel Bauer wrote:

<snip>

what command do you run to manually update time from the ntp server?

ntpdate -u time.uni-freiburg.de ; hwclock --systohc -- Daniel Bauer photographer Basel Switzerland professional photography: http://www.daniel-bauer.com Madagascar special: http://www.sanic.ch

Carlos E. R. wrote:

You should have more than one server to read the time from. A dozen or two would be apropiate. Enter several server lines like this:

I'm not sure why you'd have that many - maybe in your pool-example, but Daniel is pulling time from a very reliable stratum 1 server.

...

Anyway I still would like to find out, if, when and how many times this deamon will check my time,

It syncs your clock as and when it thinks it's necessary. Think of it as continually keeping your clock in sync.

...

I even don't know what "stratum" means. When I was younger, there was a disco here called "stratos" :-)

I like to think of an NTP "stratum" as "layer" or "ring". The further away you are from an absolute source (DCF77 receiver, a caesium clock etc.), the higher your stratum.

We, as users, should not request the time form them, but use level 2 or 3 instead (however, if they are in the pool, that's their fault).

I would generally agree with that, but some stratum 1 servers are for public consumption and allow you to subscribe if you ask. /Per Jessen, Zürich

On Monday 02 October 2006 09:43, Per Jessen wrote:

Carlos E. R. wrote:

...

You should have more than one server to read the time from. A dozen or two would be apropiate. Enter several server lines like this:

I'm not sure why you'd have that many - maybe in your pool-example, but Daniel is pulling time from a very reliable stratum 1 server.

/Per Jessen, Zürich

Please pull from lower level time servers though. That is why Carlos' suggestions to use the <country code>.pool.ntp.org is a very great suggestion. Most of us are home/small business users and we have no need to touch the main stratum 1 ntp servers. That way we keep the traffic off those servers and distribute it to lower levels. One of our machines talking to a stratum 1 time server is not a huge deal but its the traffic generated by the hundreds of thousands of us that is the issue. http://en.wikipedia.org/wiki/NTP_vandalism has a few examples. Thanks for your consideration, Stan

On Monday 02 October 2006 20:18, Stan Glasoe wrote:

On Monday 02 October 2006 09:43, Per Jessen wrote:

...

Carlos E. R. wrote:

...

You should have more than one server to read the time from. A dozen or two would be apropiate. Enter several server lines like this:

I'm not sure why you'd have that many - maybe in your pool-example, but Daniel is pulling time from a very reliable stratum 1 server.

/Per Jessen, Zürich

Please pull from lower level time servers though. That is why Carlos' suggestions to use the <country code>.pool.ntp.org is a very great suggestion. Most of us are home/small business users and we have no need to touch the main stratum 1 ntp servers. That way we keep the traffic off those servers and distribute it to lower levels.

One of our machines talking to a stratum 1 time server is not a huge deal but its the traffic generated by the hundreds of thousands of us that is the issue.

http://en.wikipedia.org/wiki/NTP_vandalism has a few examples.

Thanks for your consideration, Stan

Many interesting answers here - I couldn't imagine that just "getting the time" implies so many things to think about. After reading here and the wikipedia-link, and also reading http://ntp.isc.org/bin/view/Servers/RulesOfEngagement where it says "As the load on the hosts supporting NTP primary (stratum 1) time service is heavy and always increasing, clients should avoid using the primary servers whenever possible" I now decided to remove the "stratum 1" server from my list and just entered three different NTP Pool Servers, as I don't care too much, if my PC's time is soooo very accurate (before I adjusted the time once every week or so). As a simple "just user" I wonder, why the servers you can choose in Yast are not explained a bit closer (for example that it isn't necessary for user like me to choose a st1 etc.). As I am in Switzerland I've just chosen a public server from Switzerland, and there is only one in Yast - and that's a stratum 1 server... On the said page there are lists of servers to choose from. Thanks again to all of you for your help and engagement! Daniel -- Daniel Bauer photographer Basel Switzerland professional photography: http://www.daniel-bauer.com Madagascar special: http://www.sanic.ch

Most of us are home/small business users and we have no need to touch the main stratum 1 ntp servers. That way we keep the traffic off those servers and distribute it to lower levels. Yes. In fact, there is no need to use a time "server" at all. In the first

On Monday 02 October 2006 13:18, Stan Glasoe wrote: place opening a port for NTP to the network opens a vulnerability--however remote--that is not necessary. Secondly, radio down link from GPS is cheap, fast, reliable, and secure. Basically, you tie an inexpensive GPS receiver to your local network. One machine on the local network becomes the NTP server for the entire network behind your local firewall, and that server gets the time from GPS. (In this scenario we are only interested in the time, not the positioning, so expensive receivers and fancy software are not necessary) I have been investigating two possibilities for my home network: 1) The GPS receiver from DeLORME 2) The GPS receiver from Megellan (plugs into my Visor Palm. The difficulty as always is the problem of drivers (or writing open code). What would be really cool is if some vendor like LinkSys would build a GPS timebase receiver into their wireless routers/modems. -- Kind regards, M Harris <><

Carlos E. R. wrote:

...

It may be reliable, but even so, it might not be, or his network path I would generally agree with that, but some stratum 1 servers are for public consumption and allow you to subscribe if you ask.

Maybe so, but I can not justify needing such a precise time keeping. It is more polite to use other servers.

I guess it's a matter of opinion - when a stratum 1 operator clearly invites you/the public to use their services, as long as you tell them, I don't see anything impolite in using it.

The article "http://en.wikipedia.org/wiki/NTP_vandalism" that Stan Glasoe mentioned is very interesting.

Yep, that was worth reading. I'd already read about Poul-Henning Kamps troubles in the Danish papers a while ago. Interesting story. /Per Jessen, Zürich

Carlos E. R. wrote:

I have a list of stratum 1 servers somewhere, but the list doesn't say what the policy is for them.

Usually there will be a website or similar that described the policy, for instance: http://ntp.isc.org/bin/view/Servers/SwisstimeEthzCh http://ntp.isc.org/bin/view/Servers/NtpMetasCh

...

...

The article "http://en.wikipedia.org/wiki/NTP_vandalism" that Stan Glasoe mentioned is very interesting.

Yep, that was worth reading. I'd already read about Poul-Henning Kamps troubles in the Danish papers a while ago. Interesting story.

My access router has none configured by default; I wrote the the name of the pool. They must be learning.

I don't have any D-Link equipment, but the couple of Zyxels routers I've had didn't have anything configured by default. /Per Jessen, Zürich

On Monday 02 October 2006 06:44, Carl Hartung wrote:

My understanding is you really only want to sync to *one* known reliable server (or pool) because the syncing process is just that: a process which takes time to complete.

Not exactly Carl. NTP is smart enough to pick the best server from a bunch. 3 or 4 is usually enough. You provide more than one because the client is smart enough to fall back to another when one becomes un-reachable. Any ntp server beyond strata 2 is likely to be up and down occasionally because they are not usually a priority service. Hence the need for more than one. Most ISPs supply an ntp server. Just ping ntp.yourisp.net/com to find out. Most EDU domains also have one. -- _____________________________________ John Andersen

On 10/3/06, Carl Hartung wrote:

On Tuesday 03 October 2006 00:07, John Andersen wrote:

...

On Monday 02 October 2006 06:44, Carl Hartung wrote:

...

My understanding is you really only want to sync to *one* known reliable server (or pool) because the syncing process is just that: a process which takes time to complete.

Not exactly Carl.

Well, sort of...

...

NTP is smart enough to pick the best server from a bunch.

Yes, if you have such a critical time sensitive application, otherwise you should conserve the traffic. And the point that I was actually focusing on was this: syncing is a process, not a one time event. You don't a) set it up b) expect the time to correct itself immediately and c) when it doesn't, start 'server shopping'. Is that clearer? ;-)

I have followed this thread with interest, because it has not seemed to me, that configuring the ntp client just has not really worked to keep either a SLES or my current suse 10.0 desktop synced. So, following the advice in the cool solutions article to add the burst and iburst paraemeters in advanced settings. However, this is what still seems to be happening: Before going into yast, but after reboot (if I had made changes to the ntp client earlier), when I issue the command xntpdc -p I get: p02-dcs13:~ # xntpdc -p remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03078 This, despite the fact that I have specified a time server in the config, and that the server tested properly (ie no issue with needing to drop the firewall). If I then go back into YAST to look at the settings (just checking, you know!) but don't change the server that is listed, then, when I issue the xntpdc -p command (and it is the same if I do xntpdc and then type peers at the ntp prompt), I get: p02-dcs13:~ # xntpdc -p xntpdc: read: Connection refused Then, if I go back into YAST and change the time server ... when I issue the xntpdc -p command, I get: p02-dcs13:~ # xntpdc -p remote local st poll reach delay offset disp ======================================================================= =LOCAL(0) 127.0.0.1 10 64 1 0.00000 0.000000 2.81735 =taylor.cs.wisc. 192.168.2.100 2 64 1 0.04097 -0.002045 1.98431 p02-dcs13:~ # However, after a reboot, I am back to square 1, with only the local server showing. So, what the ??? It seems like this should be pretty damn simple ... Peter

On Wednesday 04 October 2006 01:24, Peter Van Lone wrote:

I have followed this thread with interest, because it has not seemed to me, that configuring the ntp client just has not really worked to keep either a SLES or my current suse 10.0 desktop synced.

cat /etc/ntp.conf | grep server (your ntp server should show up as uncommented in one of these lines) cat /var/lib/ntp/drift/ntp.drift (this should show if ntp is successfully calculating the system's drift) cat /var/log/ntp | grep "time reset" (obvious... what adjustments have been made) Carl

On Tuesday 03 October 2006 21:24, Peter Van Lone wrote:

p02-dcs13:~ # xntpdc -p remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03078

This, despite the fact that I have specified a time server in the config, and that the server tested properly (ie no issue with needing to drop the firewall).

If I then go back into YAST to look at the settings (just checking, you know!) but don't change the server that is listed, then, when I issue the xntpdc -p command (and it is the same if I do xntpdc and then type peers at the ntp prompt), I get:

p02-dcs13:~ # xntpdc -p xntpdc: read: Connection refused

Then, if I go back into YAST and change the time server ... when I issue the xntpdc -p command, I get:

p02-dcs13:~ # xntpdc -p remote local st poll reach delay offset disp ======================================================================= =LOCAL(0) 127.0.0.1 10 64 1 0.00000 0.000000 2.81735 =taylor.cs.wisc. 192.168.2.100 2 64 1 0.04097 -0.002045 1.98431 p02-dcs13:~ #

You should have a look at the log in /var/log/ntp Chances are there will be some indication in there as to why it rolled over and died, (if it did indeed die). Note that ntpd will refuse to try to sync if your machine clock is hopelessly out of sync with the reference clock, by (I forget the exact limit) some fairly large number of minutes. Also (obviously) ntp needs the network to be up before it can sync, so you have to make sure the init scripts are run in the right order, but unless you've been messing with them, SuSE usually gets those right. Still bears checking that in run level 3 and 5 that the xx in Sxxntp is higher than Sxxnetwork, and that you actually have a working network at the time ntp starts. Then take a look at your /etc/ntp.conf with your favorite editor. As Carl mentioned its a simple file, and more easily managed at the command line than thru yast. Oh, and whats this reboot stuff... don't do that. All you need is: rcntp restart Just to be pedantic I've pasted my /etc/ntp.conf in below for comparison. BTW: The time zone of the reference clock does not matter. For years before there were local references in alaska I synced with NIST in Colorado and a clock in Japan. But now that the University of Alaska is on internet 2 their clock is "closer" than any others. So, what I'm getting at here is that you could SAVE A BACKUP of your /etc/ntp.conf and swap in mine to see how it works. ---begin paste ################################################################################ ## /etc/ntp.conf ## ## Sample NTP configuration file. ## See package 'ntp-doc' for documentation, Mini-HOWTO and FAQ. ## Copyright (c) 1998 S.u.S.E. GmbH Fuerth, Germany. ## ## Author: Michael Andres, ## ################################################################################ ## ## Radio and modem clocks by convention have addresses in the ## form 127.127.t.u, where t is the clock type and u is a unit ## number in the range 0-3. ## ## Most of these clocks require support in the form of a ## serial port or special bus peripheral. The particular ## device is normally specified by adding a soft link ## /dev/device-u to the particular hardware device involved, ## where u correspond to the unit number above. ## ## Generic DCF77 clock on serial port (Conrad DCF77) ## Address: 127.127.8.u ## Serial Port: /dev/refclock-u ## ## (create soft link /dev/refclock-0 to the particular ttyS?) ## # server 127.127.8.0 mode 5 prefer ## ## Undisciplined Local Clock. This is a fake driver intended for backup ## and when no outside source of synchronized time is available. ## server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized ## ## Outside source of synchronized time ## ## server xx.xx.xx.xx # IP address of server ## ## Miscellaneous stuff ## driftfile /var/lib/ntp/drift/ntp.drift # path for drift file logfile /var/log/ntp # alternate log file server bigben.cac.washington.edu server ntp.alaska.edu # logconfig =syncstatus + sysevents # logconfig =all # statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable # filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable # # Authentication stuff # # keys /etc/ntp.keys # path for keys file # trustedkey 1 2 3 4 5 6 14 15 # define trusted keys # requestkey 15 # key (7) for accessing server variables # controlkey 15 # key (6) for accessing server variables -- _____________________________________ John Andersen

* Peter Van Lone [10-04-06 09:20]:

So, the command to execute from a script on my laptot is rcntp restart .. is there anyway to associate that with the wireless network coming up, so that I don't have to do this extra little step each time?

start a script via /etc/init.d/boot.local containing a loop that checks for an internet connection every (?) minute and starts 'rcntpd start' when successful. -- 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 10/4/06, Carlos E. R. wrote:

Or in this case, start a cron job running ntpdate periodically - I mean every fifteen minutes or so. If at that moment there is a network, it will sync. There is little or no point in running ntp if there is no _permanent_ network connection.

a cron job sounds like another good way to go. I heartily disagree with your judgement in the last line ... it seems to me patently ridiculous that my laptop has to have inaccurate time just because it is not permantly network connected -- my computer is my watch basically. It seems like a simple, normal, regular request. It seems like it should not be so hard to do. Now, I have a couple different methods for doing it, so once I figure out how to do either one, I'm set. Thanks again, all ... for the help. Peter

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-10-04 at 09:54 -0500, Peter Van Lone wrote:

On 10/4/06, Carlos E. R. wrote:

...

Or in this case, start a cron job running ntpdate periodically - I mean every fifteen minutes or so. If at that moment there is a network, it will sync. There is little or no point in running ntp if there is no _permanent_ network connection.

a cron job sounds like another good way to go. I heartily disagree with your judgement in the last line ... it seems to me patently ridiculous that my laptop has to have inaccurate time just because it is not permantly network connected -- my computer is my watch basically.

It seems like a simple, normal, regular request. It seems like it should not be so hard to do. Now, I have a couple different methods for doing it, so once I figure out how to do either one, I'm set.

Er... you misinterpreted me. First, you can keep accurate time by using ntpdate only once a day: I did it that way for years, and the error was a second or two at the end of day: the same as a hand watch. Programming a query interval of fifteen minutes is just for the purpose of ensuring that at least some of the queries fall inside a connected window. Second, I said: «there is little or no point in running ntpd if there is no _permanent_ network connection». This is simply a technical requirement of the ntp daemon, not a judgment. It has to query the time at unknown moments (unknown for us), and having no network when it needs it means it will not work. Notice that it keeps the clock accurate up to about 0.01 S. In other words, ntpd is designed for machines with permanent network connections. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFJAVXtTMYHG2NR9URAtrVAKCNihIX53UEpXFDEV6/k6uV0LSYuwCfQdmM 3lIQi+T4U1yJTREiFIlIRI4= =RjYW -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-10-04 at 21:04 +0100, William Gallafent wrote:

On Wednesday 04 October 2006 20:02, Carlos E. R. wrote:

...

In other words, ntpd is designed for machines with permanent network connections.

At the risk of turning this thread circular, ...

Even though that's true, what is the reason _not_ to start ntpd (rcntp start) just after a network connection is started, and stop it again just before the network connection is shut down?

It is possible, of course, but ntpd may not have time to complete its job.

(Forgive my ignorance, but) does 'rcntp start' effectively perform an 'ntpdate' command, then start ntpd?

That's what it does, in fact. You can also call "rcntp ntptimeset", it does the same as "ntpdate" but reading the config file ntpd uses. Let me try to clarify things. The ntp daemon does quite more than checking the time periodically and adjust the system time; if it did, your approach would be correct. More or less, it checks the time, adjust the clock speed so that it slowly gets in sync with the real time out there, and then adjust the speed back again so that it maintains in sync from then on, but doing continuous adjustments as soon as it detects a difference. Lets us make an educated guess, and think out what will happen if the network connectivity is intermittent (I haven't studied the code). Suppose the system clock is slow. There is network, so ntpd adjusts it to go faster instead, till it catches; then the network goes off, and... what? The daemon can't know when it catches the real time and thus when to slow it a bit. If the daemon has been running for sufficient time (days) it will know what is the exact adjustment the clock needs and leave it there hopping for the best, till it can read outside time again. If it doesn't know the needed factor, it will probably leave the original value and exit after trying for a while. As I said, this is an educated guess, but I bet you my stipulated amount for sure things (two cents) that the above scenario is correct :-)

KNetworkManager allows commands to be run at "Link Up" and "Link Down", so why not do it there? What are the security implications of making the rcntp script suid root? Hmm, .....

Scripts can not be made suid, I understand. Or if they can they don't work. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFJD/xtTMYHG2NR9URAiQoAJwPI5XbTEdRpXB/bcy2TF2ok1n6bACfdOTP 5pDJwIFA26IVkNnC+VrRlC4= =5ql4 -----END PGP SIGNATURE-----

On Wed, October 4, 2006 7:51 am, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Wednesday 2006-10-04 at 08:19 -0500, Peter Van Lone wrote:

...

...

Then take a look at your /etc/ntp.conf with your favorite editor. As Carl mentioned its a simple file, and more easily managed at the command line than thru yast.

I don't understand why you would not want/expect YAST to work. Seems to me that if the distro provides a management tool, then it should do it's job.

If it works, good. If it doesn't, find another way, or report the problem in bugzilla and wait till its solved. Months? Dunno, I've never used that yast module but once, to see what it could do.

Never use anything but yast for my ntp settings. I couln't even tell you there was a .conf file. Works perfectly on every machine I setup. (On the laptop I don't have ntpd running typically, however. I will start it once a month or so, when I think about it, just to make sure the clock is more-or-less correct.) -- Kai Ponte www.perfectreign.com || www.4thedadz.com remember - a turn signal is a statement, not a request

Would one of you please post the text of your /etc/ntpd.conf and /etc/ntp.conf file so I can see what I erased? I lost my localhost entry. Thanks, Fred "Oops" Fumblefingers

From /var/log/ntp: ntpd exiting on signal 15 If I read it right, that is a SIGTERM, but does that mean the process terminated early or did it complete then was terminated?

On Monday 02 October 2006 11:37, Daniel Bauer wrote: <snip>

The page http://www.novell.com/coolsolutions/feature/15345.html lists a "healthy /var/log/ntp" and that shows this message, too...

Great minds must think alike, Daniel. ;-) I was just about to refer the OP to the same page! Have you straightened out your configuration? Carl

Stevens wrote:

Would one of you please post the text of your /etc/ntpd.conf and /etc/ntp.conf file so I can see what I erased? I lost my localhost entry.

Thanks, Fred "Oops" Fumblefingers

Interesting thread. Although I think Daniel was worrying about something that was never a problem, it sure made for an educational / informative thread. :-) Fred, here's my ntp.conf as example for you. Hope that helps. restrict default noquery notrust nomodify restrict 127.0.0.1 restrict 192.168.1.0 mask 255.255.255.0 server 127.127.1.0 fudge 127.127.1.0 stratum 3 driftfile /var/lib/ntp/drift/ntp.drift logfile /var/log/ntp broadcastclient north-america.pool.ntp.org