I am exploring changing the way our remote openSUSE systems (not connected to the internet) maintain proper time. We have GPS devices in these system, but have thus far only used the time for our own devious purposes. We have never tried to maintain the system time. The popular wisdom on the gpsd list (all things related to GPS access on Linux) is that one should use chrony (http://chrony.tuxfamily.org) rather then NTP for this purpose. The reason given is that NTP does not deal well with a time source that is perhaps seldom available. See http://chrony.tuxfamily.org/FAQ.html#question_2.1 In order to use chrony, hwclock must be disabled on system shutdown. This is because chrony would like to be the one that sets the clock when the system comes up - perhaps without a GPS time source - but keeping the time as close to correct as possible. If, on openSUSE systems, I disable hwclock on shutdown only, what madness might ensue? I don't mean 'Will the time be wrong?' I assume that chrony will take care of that. But perhaps there are some other system activities that are dependent on hwclock running at shutdown? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
I am exploring changing the way our remote openSUSE systems (not connected to the internet) maintain proper time. We have GPS devices in these system, but have thus far only used the time for our own devious purposes. We have never tried to maintain the system time. The popular wisdom on the gpsd list (all things related to GPS access on Linux) is that one should use chrony (http://chrony.tuxfamily.org) rather then NTP for this purpose. The reason given is that NTP does not deal well with a time source that is perhaps seldom available. See http://chrony.tuxfamily.org/FAQ.html#question_2.1
I guess it will depend quite a bit on on how you define "seldom" - as long as access to a time source is regular, e.g. daily, I think the local system will be able to keep the clock stable in between accesses. -- Per Jessen, Zürich (19.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 12:44 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
I am exploring changing the way our remote openSUSE systems (not connected to the internet) maintain proper time. We have GPS devices in these system, but have thus far only used the time for our own devious purposes. We have never tried to maintain the system time. The popular wisdom on the gpsd list (all things related to GPS access on Linux) is that one should use chrony (http://chrony.tuxfamily.org) rather then NTP for this purpose. The reason given is that NTP does not deal well with a time source that is perhaps seldom available. See http://chrony.tuxfamily.org/FAQ.html#question_2.1
I guess it will depend quite a bit on on how you define "seldom" - as long as access to a time source is regular, e.g. daily, I think the local system will be able to keep the clock stable in between accesses.
That seems to be the point of chrony. Access to the time source need not be regular. Obviously the longer it is not connected the more time will suffer. I guess it assumes that the error in the real time clock is basically linear. To the extent this is true, it could perhaps do a good job. I worry that the error in the rtc may not be linear, especially if (1) the system is disconnected from the power mains and runs on the PC battery, or (2) temperature changes drastically (hot in summer and cold in winter). I define 'seldom' as being when the GPS is on and has a fix. For example, if our vehicle is turned on in a garage, the GPS may not provide PPS signals and a GPS-based time. It too is providing an internal time maintained between satellite access. So, chrony may not get usable info at these times. But, chrony claims it will still set the clock rather accurately as it records the drift of the clock as part of what it keeps when the system goes down. When it comes up, it can set the time using only this information. NTP does not do this. I can confirm this. On my openSUSE machine, I use NTP and a wireless network enabled by Network Manager (not the traditional if up method). So, when NTP starts at boot, there is no network, and so it never gets the time correct - it stays with whatever the BIOS has. I have to restart NTP by hand after I log in and Network Manager gets me a connection. Seems chrony deals with this better. Or so I plan on finding out. I am now trying to see how complete the 'new' PPS driver support is in openSUSE 11.2 (kernel 2.6.31). I see it is present. Which is a good first sign. Next is to see that it works. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 12:44 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
I am exploring changing the way our remote openSUSE systems (not connected to the internet) maintain proper time. We have GPS devices in these system, but have thus far only used the time for our own devious purposes. We have never tried to maintain the system time. The popular wisdom on the gpsd list (all things related to GPS access on Linux) is that one should use chrony (http://chrony.tuxfamily.org) rather then NTP for this purpose. The reason given is that NTP does not deal well with a time source that is perhaps seldom available. See http://chrony.tuxfamily.org/FAQ.html#question_2.1
I guess it will depend quite a bit on on how you define "seldom" - as long as access to a time source is regular, e.g. daily, I think the local system will be able to keep the clock stable in between accesses.
That seems to be the point of chrony. Access to the time source need not be regular. Obviously the longer it is not connected the more time will suffer.
Probably, but not necessarily. The local clock _could_ be quite accurate by itself. I use ntp with a dcf77 receiver because it's easy and accurate, but I don't actually need the accuracy to more than 1 second, and only between my own machines.
I guess it assumes that the error in the real time clock is basically linear.
Or at least predictable.
I define 'seldom' as being when the GPS is on and has a fix. For example, if our vehicle is turned on in a garage, the GPS may not provide PPS signals and a GPS-based time. It too is providing an internal time maintained between satellite access.
So now "seldom" is directly related to how often the vehicle is active? Are we talking a moon buggy or a city tram? :-)
On my openSUSE machine, I use NTP and a wireless network enabled by Network Manager (not the traditional if up method). So, when NTP starts at boot, there is no network, and so it never gets the time correct - it stays with whatever the BIOS has. I have to restart NTP by hand after I log in and Network Manager gets me a connection. Seems chrony deals with this better.
I don't know chrony at all, I can't comment. What you're describing about ntp sounds like a bug though. ntp has, in my experience, no problem switching between servers depending on accuracy and availability. In my local setup, I have one DCF77 receiver which is not always able to receive a good time signal. When that happens my primary ntp server will fall back to stratum 2 and sync with one of two external servers. If those are also unavailable, it defaults to stratum 10 (localhost). For leased external servers I use one external time source. If that becomes unavailable, the servers sync with each other thus making sure they at least agree on which time it is. -- Per Jessen, Zürich (19.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 13:41 +0200, Per Jessen wrote:
Probably, but not necessarily. The local clock _could_ be quite accurate by itself. I use ntp with a dcf77 receiver because it's easy and accurate, but I don't actually need the accuracy to more than 1 second, and only between my own machines.
One second accuracy for me would be a disaster. We need to locate things within a decimeter. At 90 km/h, that is 1/250 of a second. So we would like time to be at least 1/500 of a second accurate. By 'accurate' I mean between the systems (the GPS receiver being one of them), not absolute.
I guess it assumes that the error in the real time clock is basically linear.
Or at least predictable.
As long as chrony discovers the method of prediction. The folk on the gpsd list have only good things to say about it.
I define 'seldom' as being when the GPS is on and has a fix. For example, if our vehicle is turned on in a garage, the GPS may not provide PPS signals and a GPS-based time. It too is providing an internal time maintained between satellite access.
So now "seldom" is directly related to how often the vehicle is active? Are we talking a moon buggy or a city tram? :-)
Depending on the season. a bit of both.
On my openSUSE machine, I use NTP and a wireless network enabled by Network Manager (not the traditional if up method). So, when NTP starts at boot, there is no network, and so it never gets the time correct - it stays with whatever the BIOS has. I have to restart NTP by hand after I log in and Network Manager gets me a connection. Seems chrony deals with this better.
I don't know chrony at all, I can't comment. What you're describing about ntp sounds like a bug though. ntp has, in my experience, no problem switching between servers depending on accuracy and availability.
In my local setup, I have one DCF77 receiver which is not always able to receive a good time signal. When that happens my primary ntp server will fall back to stratum 2 and sync with one of two external servers. If those are also unavailable, it defaults to stratum 10 (localhost).
In my laptop case with Network Manager, it moves to localhost at boot because there is no other source available. There is one configured - but it is not available at that time. The problem is that it seems not to re-evaluate the decision. So, when the NTP server is eventually available, it does not care as it is using localhost. So, I run 'rcntp restart' and all is well again. This is not an acceptable solution in our vehicles. Thus chrony. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 13:41 +0200, Per Jessen wrote:
Probably, but not necessarily. The local clock _could_ be quite accurate by itself. I use ntp with a dcf77 receiver because it's easy and accurate, but I don't actually need the accuracy to more than 1 second, and only between my own machines.
One second accuracy for me would be a disaster. We need to locate things within a decimeter. At 90 km/h, that is 1/250 of a second. So we would like time to be at least 1/500 of a second accurate. By 'accurate' I mean between the systems (the GPS receiver being one of them), not absolute.
2ms accuracy - with ntp that's not a problem, but it seems to be asking a lot when you do not have a stable time source?
I define 'seldom' as being when the GPS is on and has a fix. For example, if our vehicle is turned on in a garage, the GPS may not provide PPS signals and a GPS-based time. It too is providing an internal time maintained between satellite access.
So now "seldom" is directly related to how often the vehicle is active? Are we talking a moon buggy or a city tram? :-)
Depending on the season. a bit of both.
I shouldn't have asked. :-)
In my laptop case with Network Manager, it moves to localhost at boot because there is no other source available. There is one configured - but it is not available at that time. The problem is that it seems not to re-evaluate the decision. So, when the NTP server is eventually available, it does not care as it is using localhost. So, I run 'rcntp restart' and all is well again.
Here is an excerp of my ntp-log, you'll see it changing servers/stratum several times per day: http://files.jessen.ch/ntp-sync LOCAL is localhost, GENERIC is DCF77, the two ip-addresses are a stratum 0 and a stratum 1 server respectively. -- Per Jessen, Zürich (20.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 14:40 +0200, Per Jessen wrote:
Here is an excerp of my ntp-log, you'll see it changing servers/stratum several times per day:
http://files.jessen.ch/ntp-sync
LOCAL is localhost, GENERIC is DCF77, the two ip-addresses are a stratum 0 and a stratum 1 server respectively.
Perhaps it gets a chance to change when the system is on all the time. A laptop or otherwise non-stationary system tends to be on and off all the time. Perhaps ntp never gets a chance to re-check for a better server. I will try leaving my laptop on over night to see if it gets the time correct. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 14:40 +0200, Per Jessen wrote:
Here is an excerp of my ntp-log, you'll see it changing servers/stratum several times per day:
http://files.jessen.ch/ntp-sync
LOCAL is localhost, GENERIC is DCF77, the two ip-addresses are a stratum 0 and a stratum 1 server respectively.
Perhaps it gets a chance to change when the system is on all the time. A laptop or otherwise non-stationary system tends to be on and off all the time. Perhaps ntp never gets a chance to re-check for a better server.
Hmm, yes, that is possible - said in another way, it never has a connection for long enough to establish a solid connection to the time source. I can't help thinking your 2ms accuracy is asking a lot in such a situation, but that's just my gut feeling. /Per -- Per Jessen, Zürich (20.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer said the following on 07/15/2011 07:17 AM:
That seems to be the point of chrony. Access to the time source need not be regular. Obviously the longer it is not connected the more time will suffer.
Isn't this what NTP does? Only with 'layers' (?'stratum'?) of authority for fall-back.
I guess it assumes that the error in the real time clock is basically linear.
That's how I read the way NTP deals with 'drift'.
To the extent this is true, it could perhaps do a good job. I worry that the error in the rtc may not be linear, especially if (1) the system is disconnected from the power mains and runs on the PC battery,
There are published studies on this that I've seen but not studied/bookmarked, that seem to indicate a) drift is very low on modern devices b) it is linear to the first order. I'd go google If I were you.
or (2) temperature changes drastically (hot in summer and cold in winter).
That depends on the environment, obviously. Outside the rated temperature for semiconductors ... who knows. Here in the GWN I once had a project where we worked in Port-a-Cabins that were sub-zero (Celsius) overnight. We had to turn on the heaters and go get "breakfast" for an hour each morning while they warmed up. But that's commercial grade stuff. I've also worked with MIL-SPEC and AUTO-SPEC. Outside of military, an automobile is about the worse environment for electronics you will encounter. Its bad enough to be the electronics in, say a traffic light controller cabinet, exposed to heat fluctuations. But auto electronics has to deal with that and more. Vibration, salt, dirt .... Yes, I've worked with aviation electronics too, which is more extreme, but just about everyone encounters automobiles whereas few of us have to deal with the conditions at 60,000 feet. The point I am trying to make is that the chip and board makers *DO* know about these conditions and *DO* make components that are stable under them. If you choose to use chips & boards intended for a home theatre under these conditions, then yes there will be fluctuations. If you choose the suitable - and probably more expensive - components that are designed for that environment then the problems you describe will not be apparent. Unless you are using inappropriate hardware, the advantages you claim for chrony exist in NTP. Are there some advantages of chrony that NTP doesn't have which you have not mentioned? -- Faith may be defined briefly as an illogical belief in the occurrence of the improbable...A man full of faith is simply one who has lost (or never had) the capacity for clear and realistic thought. He is not a mere ass: he is actually ill. -- H. L. Mencken -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 09:14 -0400, Anton Aylward wrote:
Roger Oberholtzer said the following on 07/15/2011 07:17 AM:
That seems to be the point of chrony. Access to the time source need not be regular. Obviously the longer it is not connected the more time will suffer.
Isn't this what NTP does? Only with 'layers' (?'stratum'?) of authority for fall-back.
Surely that is the idea. But when all you have is a GPS, things do not reliably work to plan. If NTP does not find an external server, it eventually falls back to localhost. localhost uses whatever the BIOS has for time. If your time looks correct in the absence of a ntp server, it is probably because of some mechanism other than ntp. Like the hwclock stuff openSUSE does at boot and shutdown. I think that is what maintains time between boots. It requires that the time be correct when the system is shutdown. To whatever extent it is incorrect when it is shut down, it will be incorrect when it boots. Given that ntp seems to only periodically re-check available servers, if the GPS is not on-line when it checks, it may be missed. You have to hope that the GPS is working when ntp checks. Otherwise ntp will choose another. In a vehicle that is not attached to anything else, that will be localhost. Which really has little useful information to help improve things. This becomes a real problem when the system is turned on. ntp may not see the GPS when it first starts. It then goes to localhost. Eventually the GPS comes alive. Until ntp checks again, the GPS won't be used. So the system may have incorrect time for a long time. Systems that are on all the time or for very long periods of time do not see the deficiency in ntp. It has become apparent in systems that are off and on with some frequency. It is a recurring topic on the gpsd mailing list. Having claimed all this, I realize that I may have a few points wrong. I can only say that I see on my laptop (on and off a lot - external time source only available after boot is long completed) the unexpected ntp behavior described by others. I have no investment in using chrony or ntp. I am only exploring options at this time. And my real question about any possible side effects of not running hwclock at system shutdown remains unanswered.
Outside of military, an automobile is about the worse environment for electronics you will encounter. Its bad enough to be the electronics in, say a traffic light controller cabinet, exposed to heat fluctuations. But auto electronics has to deal with that and more. Vibration, salt, dirt ....
As we well know. Our systems are used anywhere from Northern Finland to Saudi Arabia. Being on the road, they are exposed to many nasty things. Given that we measure road quality, they find themselves on some nasty bouncing surfaces. Environmental factors determine a large part of our design. It is one thing that drives up the cost of such systems. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer said the following on 07/15/2011 09:55 AM:
Systems that are on all the time or for very long periods of time do not see the deficiency in ntp. It has become apparent in systems that are off and on with some frequency. It is a recurring topic on the gpsd mailing list.
You seem to have ommitted a number of things. Many of us live on laptops that are "off and on with some frequency" and don't always have internet connections or in circumstances where the proxy doesn't allow NTP. What NTP does do that you have ommited in this thread is also significant. It keeps track of drift of the system clock. In fact when a reference is available it keeps track of the drift continuously, so that when it starts up and isn't in contact with a reference it can make a damn good estimate of what the time really is. The issue is "how good", and that can only be determined in any instance by experimentation. The other point is the _QUALITY_ of your internal clock. I _KNOW_ my wall clocks drift, about a minute month. I expect better of my TAG Heuer Aquagraph. I you (or your company) is unwilling to invest in the quality of baseline hardware to meet your business needs then arguing about NTP vs chrony is moot. -- Farming looks mighty easy when your plow is a pencil, and you're a thousand miles from the corn field. Dwight D. Eisenhower, September 11, 1956 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Jul 15, 2011 at 10:19 AM, Anton Aylward
Roger Oberholtzer said the following on 07/15/2011 09:55 AM:
Systems that are on all the time or for very long periods of time do not see the deficiency in ntp. It has become apparent in systems that are off and on with some frequency. It is a recurring topic on the gpsd mailing list.
You seem to have ommitted a number of things.
Many of us live on laptops that are "off and on with some frequency" and don't always have internet connections or in circumstances where the proxy doesn't allow NTP.
What NTP does do that you have ommited in this thread is also significant. It keeps track of drift of the system clock. In fact when a reference is available it keeps track of the drift continuously, so that when it starts up and isn't in contact with a reference it can make a damn good estimate of what the time really is.
I believe that is the theory, but I setup a dedicated laptop to act as a weather station a couple years ago. openSUSE based. And I can say openSUSE on bootup does NOT behave that way. I suspect ntpd is way too slow to kick off and get things straightened out. I have not updated the distro since it is a dedicated purpose machine and the is nothing of value on it, so I'd guess it is 10.3 or 11 based. I can say with certainty that openSUSE on that laptop gets the time horribly wrong on reboot. (ie. its off by months.) NTP comes along and fixes it in short order, but I always have a few weather readings from the wrong month in the mix. Fortunately the bios date is months behind, so the data just impacts old data I don't care about. Roger, I suspect you need to decide if debugging the openSUSE bootup / time control is what you should be doing vs.moving to Chrony. I personally suspect Chrony won't help. Instead, I suspect the problem is in the order of how the init scrips are called. That is the bios clock is clearly used in the early boot phases and if you start depending on the time prior to NTP / Chrony coming to life, you get bogus data. In my case, NTP uses the Internet sites for time but it seems to be invoked before the network is up, so it takes quite a while to fix the machines time. And when it does that, it must not be updating the bios clock, or it wouldn't be so horribly far off. Again, debugging the NTP setup / package is where I would focus effort, not in switching to Chrony. Either way, you will likely have to do your own package level debugging to get things the way you want them. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Greg Freemyer wrote:
What NTP does do that you have ommited in this thread is also significant. It keeps track of drift of the system clock. In fact when a reference is available it keeps track of the drift continuously, so that when it starts up and isn't in contact with a reference it can make a damn good estimate of what the time really is.
I believe that is the theory, but I setup a dedicated laptop to act as a weather station a couple years ago. openSUSE based.
And I can say openSUSE on bootup does NOT behave that way. I suspect ntpd is way too slow to kick off and get things straightened out.
I have not updated the distro since it is a dedicated purpose machine and the is nothing of value on it, so I'd guess it is 10.3 or 11 based.
I can say with certainty that openSUSE on that laptop gets the time horribly wrong on reboot. (ie. its off by months.)
RTC battery bad? (surely they still have a battery?)
In my case, NTP uses the Internet sites for time but it seems to be invoked before the network is up, so it takes quite a while to fix the machines time. And when it does that, it must not be updating the bios clock, or it wouldn't be so horribly far off.
/var/log/ntp ought to tell you what's going on. -- Per Jessen, Zürich (20.9°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Greg Freemyer said the following on 07/15/2011 10:36 AM:
I believe that is the theory, but I setup a dedicated laptop to act as a weather station a couple years ago. openSUSE based.
And I can say openSUSE on bootup does NOT behave that way. I suspect ntpd is way too slow to kick off and get things straightened out.
NTP has a lot that can be configured. Running it 'out of the box' means that you are using the distribution settings, not ones suited to your specific context.
I can say with certainty that openSUSE on that laptop gets the time horribly wrong on reboot. (ie. its off by months.)
What you are saying is that the hardware clock is out. That is a hardware problem. As long as you shut down properly the hwclock program will write the system time to the hardware clock. Try running 'hwclock -r' to read it. It may be you hardware is faulty.. just as an experiment, try setting it, wait a bit, then red back # hwclock -w wait a few hours or days # hwclock -r Then go and read about the "--adjust" option on 'hwclock' On my laptop, even my father's old 2002 laptop, the hardware clock keeps reasonable (within a second or two) time. Even when shut down for weeks on end.
NTP comes along and fixes it in short order, but I always have a few weather readings from the wrong month in the mix. Fortunately the bios date is months behind, so the data just impacts old data I don't care about.
It sounds like you have some hardware issues.
Roger, I suspect you need to decide if debugging the openSUSE bootup / time control is what you should be doing vs.moving to Chrony.
I agree.
I personally suspect Chrony won't help.
I agree.
Instead, I suspect the problem is in the order of how the init scrips are called.
Almost certainly!
That is the bios clock is clearly used in the early boot phases and if you start depending on the time prior to NTP / Chrony coming to life, you get bogus data.
In my case, NTP uses the Internet sites for time but it seems to be invoked before the network is up,
Ah! Perhaps 'systemd' will be able to cure that :-)
so it takes quite a while to fix the machines time. And when it does that, it must not be updating the bios clock, or it wouldn't be so horribly far off.
That is possible, but your description makes me wonder if your hardware is suspect.
Again, debugging the NTP setup / package is where I would focus effort, not in switching to Chrony.
I agree.
Either way, you will likely have to do your own package level debugging to get things the way you want them.
And the experimentation/profiling I mentioned earlier. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011-07-15 18:45, Anton Aylward wrote:
Greg Freemyer said the following on 07/15/2011 10:36 AM:
I can say with certainty that openSUSE on that laptop gets the time horribly wrong on reboot. (ie. its off by months.)
What you are saying is that the hardware clock is out. That is a hardware problem. As long as you shut down properly the hwclock program will write the system time to the hardware clock.
Another cause of that problem is a bad "/etc/adjtime" file. The purpose of this file is to adjust or compensate for time drift in the hardware clock (the cmos clock that runs when the machine is off). When the machine boots, it reads the time from that clock, and gets adjusted by hwclock using that file. If at some time there were a huge, manual, intervention, setting the clock up by a month, the file has record of that adjustement, and will repeat it on the following boots... The cure is to delete that file, forcing it to be recalculated. As to the original question: hwclock is used, at least, on boot and on halt. It is not related to ntp, except that it assumes that the clock is perfectly adjusted when the system goes down. It doesn't matter if the reference is ntp, a gps clock, or that cronny I don't know about. It is responsible for the clock being correct after boot and before an external reference can be asked, so IMO it better not be removed. -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Fri, 2011-07-15 at 12:45 -0400, Anton Aylward wrote:
What you are saying is that the hardware clock is out. That is a hardware problem. As long as you shut down properly the hwclock program will write the system time to the hardware clock.
Not at all! The hardware clock is working fine. The hardware comes up with the same (and correct) UTC time every time. Let's leave the hardware. I know what a bad clock (e.g., dead battery, odd drift) looks like. This is not what is happening here.
Try running 'hwclock -r' to read it.
I am on a laptop that exhibits the problem. hwclock -r is showing the correct UTC time that I expect. The network is up via NetworkManager when I logged in graphically. The ntp that started when I booted is still running. But, alas, the time is incorrect. It can sit like this for hours, and the time will NEVER be corrected. Ever. Consistently. All I have to do now is run 'rcntp restart', and time will be corrected. This happens on any computer I set up with ntp starting at boot (the supplied rc script unmodified) and a network that starts some time after that outside the ifup/rc script environment. I suspect it is that the ntp rc script is assuming that since it is set to start after networking, it can assume that access to time servers is available when it starts. Alas, when a network device starts some time afterward, this assumption is faulty. This would not be a huge problem if ntp checked again if a server becomes available. If it is trying this, it is not working. The server is now available. But until I do 'rcntp restart', the time will never be corrected.
just as an experiment, try setting it, wait a bit, then red back
On your computer: 1. Is your BIOS in UTC time? 2. Do you live in a timezone other than UTC, and have your Linux set to use that timezone? 3. Are any networks (other than loopback) brought up in the rc startup scripts? 4. Is the only network you have started only after you log in (e.g., NetworkManager)? Unless you answer 1=YES 2=YES 3=NO 4=YES, you are not using the system as I am. So any conclusions you draw do not apply. Try the above setup and tell me how it works. In this configuration, when the system does have correct time when the system is shutdown (I have restarted ntp), shouldn't the time come up correct when the system is rebooted? It would if the claim that ntp kept a record of the drift and used that when it first starts. Alas, the time is always the BIOS time. Which is always the expected two hours off. The hardware clock is working. ntp is just not adjusting it when the config above is used.
It sounds like you have some hardware issues.
Roger, I suspect you need to decide if debugging the openSUSE bootup / time control is what you should be doing vs.moving to Chrony.
I agree.
I am flexible. I just need it to work reliably all over the world, no matter what silly things the users may try.
I personally suspect Chrony won't help.
I agree.
I cannot say that you are wrong. I will see when I get things set up. To be honest, I would prefer that I use ntp as it is part of the standard install.
Instead, I suspect the problem is in the order of how the init scrips are called.
Almost certainly!
Nope! The init scripts CANNOT make my wireless connection available to ntp. They have no connection to networks brought up outside the traditional ifup method. Like KDE/GNOME Network Manager-type initialization.
That is the bios clock is clearly used in the early boot phases and if you start depending on the time prior to NTP / Chrony coming to life, you get bogus data.
In my case, NTP uses the Internet sites for time but it seems to be invoked before the network is up,
Ah! Perhaps 'systemd' will be able to cure that :-)
Nope. See my comment above. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 SHAW'S PRINCIPAL Build a system that even a fool can use, and only a fool will want to use it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer said the following on 07/15/2011 07:16 PM:
Try running 'hwclock -r' to read it. I am on a laptop that exhibits the problem. hwclock -r is showing the correct UTC time that I expect. The network is up via NetworkManager when I logged in graphically. The ntp that started when I booted is still running. But, alas, the time is incorrect. It can sit like this for hours, and the time will NEVER be corrected. Ever. Consistently.
All I have to do now is run 'rcntp restart', and time will be corrected.
Hmm. That sounds to me as if the initial NTP failed and locked up. I might speculate that it came up before the network was up and went into a state that assumed an outside reference would NEVER be available. The restart killed that old one and brought up a new one that DID see the network etc etc etc. As someone said in this thread, its a boot sequence problem. Ah for 'systemd' -- Those who wish to seek out the cause of miracles, and to understand the things of nature as philosophers, and not to stare at them in astonishment like fools, are soon considered heretical and impious,and proclaimed as such by those whom the mob adores as the interpreters of nature and the gods. For these men know that once ignorance is put aside that wonderment would be taken away which is the only means by which their authority is preserved. --Spinoza -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011-07-16 01:16, Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 12:45 -0400, Anton Aylward wrote:
I am on a laptop that exhibits the problem. hwclock -r is showing the correct UTC time that I expect. The network is up via NetworkManager when I logged in graphically. The ntp that started when I booted is still running. But, alas, the time is incorrect. It can sit like this for hours, and the time will NEVER be corrected. Ever. Consistently.
All I have to do now is run 'rcntp restart', and time will be corrected.
Of course. When ntp is running, it will adjust the clock very slowly, so slow that you will not notice it is changing. If there is one minute error it may take hours to correct. However, if you restart the daemon, using the script, the first step is jump-set the clock, even by hours if needed, and after that it will run the daemon to keep it correct.
This happens on any computer I set up with ntp starting at boot (the supplied rc script unmodified) and a network that starts some time after that outside the ifup/rc script environment.
Obviously. At that time, the jump-set can not work, there is no network. Later, only slow adjustments will be made. NTP must not be started till network is up. Never earlier. If you are not using ifup scripts, and the network is not mandatory, do not start ntp on boot. Start it manually, later.
I suspect it is that the ntp rc script is assuming that since it is set to start after networking, it can assume that access to time servers is available when it starts. Alas, when a network device starts some time afterward, this assumption is faulty.
What is faulty is not starting the network earlier, ie, using network manager.
This would not be a huge problem if ntp checked again if a server becomes available. If it is trying this, it is not working. The server is now available. But until I do 'rcntp restart', the time will never be corrected.
Ntp does check, but it can not jump-set the clock once it is running. As documented.
In this configuration, when the system does have correct time when the system is shutdown (I have restarted ntp), shouldn't the time come up correct when the system is rebooted?
Only after weeks. Ie, if the conditions are stable.
It would if the claim that ntp kept a record of the drift and used that when it first starts. Alas, the time is always the BIOS time. Which is always the expected two hours off. The hardware clock is working. ntp is just not adjusting it when the config above is used.
No, ntp is not responsible to set the correct time just after booting. And the time must be correct to within seconds, without ntp, else you have a problem I already said how to correct.
I am flexible. I just need it to work reliably all over the world, no matter what silly things the users may try.
If the users move around time zones, and _they_ set the clock, weird things will happen. For this to work, bios must keep UTC time. The linux timesetting logic is not designed for people on the move. The original design is for stable machines, server type.
Nope! The init scripts CANNOT make my wireless connection available to ntp. They have no connection to networks brought up outside the traditional ifup method. Like KDE/GNOME Network Manager-type initialization.
Then you have to make sure that NTP is restarted later, no matter what.
Ah! Perhaps 'systemd' will be able to cure that :-)
Nope. See my comment above.
It might, if it can restart services on events (network goes up). -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Sat, 2011-07-16 at 02:43 +0200, Carlos E. R. wrote:
When ntp is running, it will adjust the clock very slowly, so slow that you will not notice it is changing. If there is one minute error it may take hours to correct.
However, if you restart the daemon, using the script, the first step is jump-set the clock, even by hours if needed, and after that it will run the daemon to keep it correct.
So, there is a flaw in the ntp start logic when the network interface on which it's server lives only becomes available some time after ntp starts. It seems never to re-check that a server that was initially not available later becomes available. IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives? Hence chrony. It does not give up so easily as ntp seems to do. Since it has as a core assumption that time servers may not always be present (to an apparently stronger degree than does ntp), it will try again. I am fully aware that ntp is well tested and understood, while chrony is less prevalent. But I think (don't know yet) chrony uses much logic from ntp after it has located a server.
Ntp does check, but it can not jump-set the clock once it is running. As documented.
'As documented' is not always the same thing as 'As I need' :(
If the users move around time zones, and _they_ set the clock, weird things will happen. For this to work, bios must keep UTC time. The linux timesetting logic is not designed for people on the move. The original design is for stable machines, server type.
The box does keep UTC. It is possible that they change the timezone as they move around to different countries. I suspect it depends on how long they will be in a country. I will have to investigate user activity.
Nope! The init scripts CANNOT make my wireless connection available to ntp. They have no connection to networks brought up outside the traditional ifup method. Like KDE/GNOME Network Manager-type initialization.
Then you have to make sure that NTP is restarted later, no matter what.
So I would have to make ntp start SUID or something so it would start when a user does something. Not my preferred solution.
Ah! Perhaps 'systemd' will be able to cure that :-)
Nope. See my comment above.
It might, if it can restart services on events (network goes up).
That sounds interesting. Of course, this will not help my installed systems. Our current 'official' platform is openSUSE 11.2. We are always a little behind in our use of releases... Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Sat, 2011-07-16 at 02:43 +0200, Carlos E. R. wrote:
When ntp is running, it will adjust the clock very slowly, so slow that you will not notice it is changing. If there is one minute error it may take hours to correct.
However, if you restart the daemon, using the script, the first step is jump-set the clock, even by hours if needed, and after that it will run the daemon to keep it correct.
So, there is a flaw in the ntp start logic when the network interface on which it's server lives only becomes available some time after ntp starts. It seems never to re-check that a server that was initially not available later becomes available.
I don't think that is correct. As my logs showed last week, ntp is perfectly capable of switching time source/server when the availability/quality changes. However, if ntp fails to start, it would (obviously) also not be checking any servers later. Have you looked at the output of "ntpq -p" at different points of your problem scenario?
IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives?
A daemon would just try to reach the interesting server, and when the error says "network not reachable" (or something similar) it means it's still not there. Personally I don't think there is a problem with ntp here - maybe in the network config or the ntp config, but not ntp itself. Your options are probably to 1) debug your ntp setup or 2) pursue a chrony setup. If you want, I'll be happy to help with option 1), but I'll need some more detailed info. -- Per Jessen, Zürich (16.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-07-18 at 10:28 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
On Sat, 2011-07-16 at 02:43 +0200, Carlos E. R. wrote:
When ntp is running, it will adjust the clock very slowly, so slow that you will not notice it is changing. If there is one minute error it may take hours to correct.
However, if you restart the daemon, using the script, the first step is jump-set the clock, even by hours if needed, and after that it will run the daemon to keep it correct.
So, there is a flaw in the ntp start logic when the network interface on which it's server lives only becomes available some time after ntp starts. It seems never to re-check that a server that was initially not available later becomes available.
I don't think that is correct. As my logs showed last week, ntp is perfectly capable of switching time source/server when the availability/quality changes. However, if ntp fails to start, it would (obviously) also not be checking any servers later. Have you looked at the output of "ntpq -p" at different points of your problem scenario?
ntp is started and running. I will run the suggested command when I have access to an offending system.
IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives?
A daemon would just try to reach the interesting server, and when the error says "network not reachable" (or something similar) it means it's still not there.
But how would a daemon know which network the interesting server is on? Perhaps a moot point. It could re-try each time the network configuration changed.
Personally I don't think there is a problem with ntp here - maybe in the network config or the ntp config, but not ntp itself. Your options are probably to 1) debug your ntp setup or 2) pursue a chrony setup. If you want, I'll be happy to help with option 1), but I'll need some more detailed info.
I would prefer to attempt to sort out ntp before moving to chrony. I need to set up a system with only a GPS. This is the current stumbling block as I have not sorted out how to get an antenna on the roof of our office building. My window accesses an urban canyon with a northern exposure, which is the GPS kiss of death in Nordic latitudes... Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives?
A daemon would just try to reach the interesting server, and when the error says "network not reachable" (or something similar) it means it's still not there.
But how would a daemon know which network the interesting server is on? Perhaps a moot point. It could re-try each time the network configuration changed.
It doesn't care about the network config - for arguments sake, let's assume it uses TCP. In pseudo-code, you would issue a connect(<desired server address>); If the network is not available, the connect() does not succeed. This is no different to you trying to access an external website when your network is down. Slightly different for UDP, but essentially the same. -- Per Jessen, Zürich (17.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-07-18 at 11:21 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives?
A daemon would just try to reach the interesting server, and when the error says "network not reachable" (or something similar) it means it's still not there.
But how would a daemon know which network the interesting server is on? Perhaps a moot point. It could re-try each time the network configuration changed.
It doesn't care about the network config - for arguments sake, let's assume it uses TCP. In pseudo-code, you would issue a
connect(<desired server address>);
If the network is not available, the connect() does not succeed. This is no different to you trying to access an external website when your network is down. Slightly different for UDP, but essentially the same.
Of course. But, at some point in the future, will ntp retry to make the connection? On that point the jury is still out. You have presented evidence where it seems to. I have presented a counter claim that shows up in my usage. I suspect ntp does retry the connection when it does, and does not try again when it does not... Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Mon, 2011-07-18 at 11:21 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives?
A daemon would just try to reach the interesting server, and when the error says "network not reachable" (or something similar) it means it's still not there.
But how would a daemon know which network the interesting server is on? Perhaps a moot point. It could re-try each time the network configuration changed.
It doesn't care about the network config - for arguments sake, let's assume it uses TCP. In pseudo-code, you would issue a
connect(<desired server address>);
If the network is not available, the connect() does not succeed. This is no different to you trying to access an external website when your network is down. Slightly different for UDP, but essentially the same.
Of course. But, at some point in the future, will ntp retry to make the connection? On that point the jury is still out. You have presented evidence where it seems to. I have presented a counter claim that shows up in my usage. I suspect ntp does retry the connection when it does, and does not try again when it does not...
To stick to the legal metaphors, I think the judge will dismiss your claim as hear-say :-) At least until you present evidence that the server is configured but not used ("ntpq -p" will show the peers). -- Per Jessen, Zürich (18.5°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-07-18 at 12:05 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
On Mon, 2011-07-18 at 11:21 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives?
A daemon would just try to reach the interesting server, and when the error says "network not reachable" (or something similar) it means it's still not there.
But how would a daemon know which network the interesting server is on? Perhaps a moot point. It could re-try each time the network configuration changed.
It doesn't care about the network config - for arguments sake, let's assume it uses TCP. In pseudo-code, you would issue a
connect(<desired server address>);
If the network is not available, the connect() does not succeed. This is no different to you trying to access an external website when your network is down. Slightly different for UDP, but essentially the same.
Of course. But, at some point in the future, will ntp retry to make the connection? On that point the jury is still out. You have presented evidence where it seems to. I have presented a counter claim that shows up in my usage. I suspect ntp does retry the connection when it does, and does not try again when it does not...
To stick to the legal metaphors, I think the judge will dismiss your claim as hear-say :-) At least until you present evidence that the server is configured but not used ("ntpq -p" will show the peers).
I should add that when I restart ntp, I see this: # rcntp restart Shutting down network time protocol daemon (NTPD) done 19 Jul 00:48:36 sntp[6212]: Started sntp 2011-07-19 00:48:36.113523 (-0100) -7199.729726 +/- 0.001343 secs Time synchronized with ntp1.sth.netnod.se Starting network time protocol daemon (NTPD) done # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 7 64 3 0.000 0.000 0.000 +ntp1.sth.netnod .PPS. 1 u 1 64 3 2.506 -0.626 1.228
-- Per Jessen, Zürich (18.5°C)
-- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 SHAW'S PRINCIPAL Build a system that even a fool can use, and only a fool will want to use it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-07-18 at 12:05 +0200, Per Jessen wrote:
To stick to the legal metaphors, I think the judge will dismiss your claim as hear-say :-) At least until you present evidence that the server is configured but not used ("ntpq -p" will show the peers).
I finally got a chance to run this (after boot, logged in and network up, time still wrong): # ntpq -p ntpq: read: Connection refused After boot (real time was 21.48), I see this is /var/log/messages: Jul 18 23:48:59 barracuda ntpd[3033]: ntpd 4.2.6p3@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1) Jul 18 23:48:59 barracuda ntpd[3034]: proto: precision = 0.243 usec Jul 18 23:48:59 barracuda ntpd[3034]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 Jul 18 23:48:59 barracuda ntpd[3034]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 Jul 18 23:48:59 barracuda ntpd[3034]: Listen and drop on 1 v6wildcard :: UDP 123 Jul 18 23:48:59 barracuda ntpd[3034]: Listen normally on 2 lo 127.0.0.1 UDP 123 Jul 18 23:48:59 barracuda ntpd[3034]: Listen normally on 3 lo ::1 UDP 123 Jul 18 23:48:59 barracuda ntpd[3034]: peers refreshed /var/log/ntp has (wireless up at 23:54:00): 18 Jul 23:48:59 ntpd[3034]: Deferring DNS for ntp1.sth.netnod.se 1 18 Jul 23:49:02 ntpd[3069]: host name not found: ntp1.sth.netnod.se 18 Jul 23:50:04 ntpd[3069]: host name not found: ntp1.sth.netnod.se 18 Jul 23:52:06 ntpd[3069]: host name not found: ntp1.sth.netnod.se 18 Jul 23:54:00 ntpd[3034]: Listen normally on 4 wlan0 192.168.1.17 UDP 123 18 Jul 23:54:01 ntpd[3034]: Listen normally on 5 wlan0 fe80::227:10ff:fe71:6724 UDP 123 18 Jul 23:54:01 ntpd[3034]: peers refreshed 18 Jul 23:54:01 ntpd[3034]: new interface(s) found: waking up resolver 18 Jul 23:54:03 ntpd[3069]: DNS ntp1.sth.netnod.se -> 192.36.144.22 My /etc/sysconfig has: NTPD_OPTIONS="-g -u ntp:ntp" My /etc/ntp.conf file is: server 127.127.1.0 fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift/ntp.drift logfile /var/log/ntp keys /etc/ntp.keys trustedkey 1 requestkey 1 server ntp1.sth.netnod.se iburst So, it seems that the time source is retried, but nothing happens. And, the -p option is failing. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 SHAW'S PRINCIPAL Build a system that even a fool can use, and only a fool will want to use it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Mon, 2011-07-18 at 12:05 +0200, Per Jessen wrote:
To stick to the legal metaphors, I think the judge will dismiss your claim as hear-say :-) At least until you present evidence that the server is configured but not used ("ntpq -p" will show the peers).
I finally got a chance to run this (after boot, logged in and network up, time still wrong):
# ntpq -p ntpq: read: Connection refused
At this point, could you also do 'pidof ntpd', please. I'm pretty certain ntpd isn't running.
After boot (real time was 21.48), I see this is /var/log/messages:
Jul 18 23:48:59 barracuda ntpd[3033]: ntpd 4.2.6p3@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1) Jul 18 23:48:59 barracuda ntpd[3034]: proto:
So the question now is - _who_ adjusted the system clock? It was _not_ ntpd, because that is only just starting.
/var/log/ntp has (wireless up at 23:54:00):
18 Jul 23:48:59 ntpd[3034]: Deferring DNS for ntp1.sth.netnod.se 1 18 Jul 23:49:02 ntpd[3069]: host name not found: ntp1.sth.netnod.se 18 Jul 23:50:04 ntpd[3069]: host name not found: ntp1.sth.netnod.se 18 Jul 23:52:06 ntpd[3069]: host name not found: ntp1.sth.netnod.se 18 Jul 23:54:00 ntpd[3034]: Listen normally on 4 wlan0 192.168.1.17 UDP 123 18 Jul 23:54:01 ntpd[3034]: Listen normally on 5 wlan0 fe80::227:10ff:fe71:6724 UDP 123 18 Jul 23:54:01 ntpd[3034]: peers refreshed 18 Jul 23:54:01 ntpd[3034]: new interface(s) found: waking up resolver 18 Jul 23:54:03 ntpd[3069]: DNS ntp1.sth.netnod.se -> 192.36.144.22
what about the next 20-30mins of log?
My /etc/sysconfig has:
NTPD_OPTIONS="-g -u ntp:ntp"
My /etc/ntp.conf file is:
server 127.127.1.0 fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift/ntp.drift logfile /var/log/ntp keys /etc/ntp.keys trustedkey 1 requestkey 1 server ntp1.sth.netnod.se iburst
All fine.
So, it seems that the time source is retried, but nothing happens. And, the -p option is failing.
Because ntpd has left the building. A wild guess at what is happening - before ntp starts, something adjusts your system clock 2 hours forward. ntp starts, but has no network, so just resumes normal working mode. Network comes up, ntpd say "yippee!", gets fresh time from netnod.se and then leaves as the time gap is more than the sanity check of 1000s. -- Per Jessen, Zürich (16.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
On Mon, 2011-07-18 at 12:05 +0200, Per Jessen wrote:
To stick to the legal metaphors, I think the judge will dismiss your claim as hear-say :-) At least until you present evidence that the server is configured but not used ("ntpq -p" will show the peers).
I finally got a chance to run this (after boot, logged in and network up, time still wrong):
# ntpq -p ntpq: read: Connection refused
At this point, could you also do 'pidof ntpd', please. I'm pretty certain ntpd isn't running.
But it is! I see it in the process list. It is always there. When I restart it, I get a message (in /var/log/ntp) from the original one that it is shutting down. Then the messages from the newly started one.
After boot (real time was 21.48), I see this is /var/log/messages:
Jul 18 23:48:59 barracuda ntpd[3033]: ntpd 4.2.6p3@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1) Jul 18 23:48:59 barracuda ntpd[3034]: proto:
So the question now is - _who_ adjusted the system clock? It was _not_ ntpd, because that is only just starting.
/var/log/ntp has (wireless up at 23:54:00):
18 Jul 23:48:59 ntpd[3034]: Deferring DNS for ntp1.sth.netnod.se 1 18 Jul 23:49:02 ntpd[3069]: host name not found: ntp1.sth.netnod.se 18 Jul 23:50:04 ntpd[3069]: host name not found: ntp1.sth.netnod.se 18 Jul 23:52:06 ntpd[3069]: host name not found: ntp1.sth.netnod.se 18 Jul 23:54:00 ntpd[3034]: Listen normally on 4 wlan0 192.168.1.17 UDP 123 18 Jul 23:54:01 ntpd[3034]: Listen normally on 5 wlan0 fe80::227:10ff:fe71:6724 UDP 123 18 Jul 23:54:01 ntpd[3034]: peers refreshed 18 Jul 23:54:01 ntpd[3034]: new interface(s) found: waking up resolver 18 Jul 23:54:03 ntpd[3069]: DNS ntp1.sth.netnod.se -> 192.36.144.22
what about the next 20-30mins of log?
The system had been running for about 60 minutes when I took the logs. That is all there was. Nothing more in either file.
My /etc/sysconfig has:
NTPD_OPTIONS="-g -u ntp:ntp"
My /etc/ntp.conf file is:
server 127.127.1.0 fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift/ntp.drift logfile /var/log/ntp keys /etc/ntp.keys trustedkey 1 requestkey 1 server ntp1.sth.netnod.se iburst
All fine.
So, it seems that the time source is retried, but nothing happens. And, the -p option is failing.
Because ntpd has left the building.
Or has decided to hide in the basement.
A wild guess at what is happening - before ntp starts, something adjusts your system clock 2 hours forward. ntp starts, but has no network, so just resumes normal working mode. Network comes up, ntpd say "yippee!", gets fresh time from netnod.se and then leaves as the time gap is more than the sanity check of 1000s.
Seems as good a guess as any. The other player here is boot.clock. I will try disabling ntp and see if the time comes up correctly. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
# ntpq -p ntpq: read: Connection refused
At this point, could you also do 'pidof ntpd', please. I'm pretty certain ntpd isn't running.
But it is! I see it in the process list. It is always there.
Okay - clearly something isn't quite working here. I have never seen ntpd running, yet not responding to ntpq. Could you perhaps try adding '-d' to the command line options.
The system had been running for about 60 minutes when I took the logs. That is all there was. Nothing more in either file.
Okay, then it would be interesting to add "logconfig =all" to your ntp config file.
I will try disabling ntp and see if the time comes up correctly.
You can also in /var/log/messages instead and see when you get the 2-hour time-jump. ntp was clearly starting when the time had already been adjusted. It's probably sntp that does it as part of the ntp init-script. -- Per Jessen, Zürich (17.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Okay - clearly something isn't quite working here. I have never seen ntpd running, yet not responding to ntpq. Could you perhaps try adding '-d' to the command line options.
Ignore that, there is no -d option for ntpq. -- Per Jessen, Zürich (17.5°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Roger Oberholtzer wrote:
On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
# ntpq -p ntpq: read: Connection refused
At this point, could you also do 'pidof ntpd', please. I'm pretty certain ntpd isn't running.
But it is! I see it in the process list. It is always there.
Okay - clearly something isn't quite working here. I have never seen ntpd running, yet not responding to ntpq.
I just don't understand this - it's really important to be able to use ntpq, because the configuration can be changed in-flight. Is there any chance that your DHCP server is dishing out a time- or ntp-server option that points your ntp to a local server? Try grepping through /var/log/messages looking for 'ntp.*runtime' -- Per Jessen, Zürich (18.5°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 2011-07-19 at 11:39 +0200, Per Jessen wrote:
Per Jessen wrote:
Roger Oberholtzer wrote:
On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
# ntpq -p ntpq: read: Connection refused
At this point, could you also do 'pidof ntpd', please. I'm pretty certain ntpd isn't running.
But it is! I see it in the process list. It is always there.
Okay - clearly something isn't quite working here. I have never seen ntpd running, yet not responding to ntpq.
I just don't understand this - it's really important to be able to use ntpq, because the configuration can be changed in-flight. Is there any chance that your DHCP server is dishing out a time- or ntp-server option that points your ntp to a local server? Try grepping through /var/log/messages looking for 'ntp.*runtime'
When looking for the messages I sent earlier I searched for 'ntp'. I saw nothing other than what I sent before. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Tue, 2011-07-19 at 11:39 +0200, Per Jessen wrote:
Per Jessen wrote:
Roger Oberholtzer wrote:
On Tue, 2011-07-19 at 08:35 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
# ntpq -p ntpq: read: Connection refused
At this point, could you also do 'pidof ntpd', please. I'm pretty certain ntpd isn't running.
But it is! I see it in the process list. It is always there.
Okay - clearly something isn't quite working here. I have never seen ntpd running, yet not responding to ntpq.
I just don't understand this - it's really important to be able to use ntpq, because the configuration can be changed in-flight. Is there any chance that your DHCP server is dishing out a time- or ntp-server option that points your ntp to a local server? Try grepping through /var/log/messages looking for 'ntp.*runtime'
When looking for the messages I sent earlier I searched for 'ntp'. I saw nothing other than what I sent before.
Okay, than we have strace ntpq to find out what is happening: strace -ofile ntpq -pn If you email <file> to me directly, I'll take a look. -- Per Jessen, Zürich (19.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
After boot (real time was 21.48), I see this is /var/log/messages:
Jul 18 23:48:59 barracuda ntpd[3033]: ntpd 4.2.6p3@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1)
As Per wrote, at the time of start of ntpd, system time is already set incorrect. You need to investigate that first and stop to fuss about ntpd not synchronizing to its time sources - you can do that later... ;-) First, you have to assure that book.clock works: 1) Check that "hwclock -r -u" outputs roughly correct time in UTC. 2) Check: HWCLOCK="-u" in /etc/sysconfig/clock. 3) Check that /etc/sysconfig/clock has a European timezone name as TIMEZONE value. (The value of DEFAULT_TIMEZONE doesn't matter.) 4) Check that /etc/localtime is correct: $ bash $ . /etc/sysconfig/clock $ cmp /etc/localtime /usr/share/zoneinfo/$TIMEZONE # This must output no message $ exit 5) Call "/etc/init.d/boot.clock restart" and check with "date" if the time is off by 2 hours afterwards. Report back if all of these tests are OK at your installation. If yes, debugging the ntpd startup will be the next step. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 2011-07-19 at 11:23 +0200, Joachim Schrod wrote:
Roger Oberholtzer wrote:
After boot (real time was 21.48), I see this is /var/log/messages:
Jul 18 23:48:59 barracuda ntpd[3033]: ntpd 4.2.6p3@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1)
As Per wrote, at the time of start of ntpd, system time is already set incorrect. You need to investigate that first and stop to fuss about ntpd not synchronizing to its time sources - you can do that later... ;-)
Of course. But my goal here is not so much to simply correct my broken system. I could do that is short order. My exercise is to see why it is wrong with the goal being that I can keep it from happening again (if possible). Since we will be using this time as part of a data timestamp system, I need to know what could mess it up so it does not happen again. Of course, as there are probably a zillion things that could cause this, perhaps I have a loosing battle ahead of me. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Tue, 2011-07-19 at 11:23 +0200, Joachim Schrod wrote:
Roger Oberholtzer wrote:
After boot (real time was 21.48), I see this is /var/log/messages:
Jul 18 23:48:59 barracuda ntpd[3033]: ntpd 4.2.6p3@1.2290-o Tue Jun 7 03:10:56 UTC 2011 (1)
As Per wrote, at the time of start of ntpd, system time is already set incorrect. You need to investigate that first and stop to fuss about ntpd not synchronizing to its time sources - you can do that later... ;-)
Of course. But my goal here is not so much to simply correct my broken system. I could do that is short order. My exercise is to see why it is wrong with the goal being that I can keep it from happening again (if possible).
I understand this. But to see "why it is wrong" means to find first the root cause of this issue and then decide if that's an isolated issue or one that could happen more often. And by now we can tell with a very high probability that the root cause is not ntpd itself, but either boot.clock or the ntpd start script with any action that happens before ntpd. Thus I posted the proposed actions for analysis if boot.clock runs amok or if one has to look at /etc/init.d/ntpd. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer said the following on 07/18/2011 03:00 AM:
So, there is a flaw in the ntp start logic when the network interface on which it's server lives only becomes available some time after ntp starts. It seems never to re-check that a server that was initially not available later becomes available.
IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives?
Your reasoning is valid, but it is also an example of a much more general problem, that of dependencies. You are stating, quite rightly, that NTP should be started when a specific network comes up. We've discussed a similar problem here recently, a function needing a wifi network but the "network up"of a wired network was allowing it to proceed. The real solution is a proper management of dependencies and triggers. I've said before that this is a situation that 'systemd' addresses; it was intended to address these kinds of dependencies. http://en.opensuse.org/SDB:Systemd http://en.wikipedia.org/wiki/Systemd http://fedoraproject.org/wiki/Features/systemd # zypper se systemd Loading repository data... Reading installed packages... S | Name | Summary | Type --+------------------+-------------------------------------+----------- | systemd | A System and Session Manager | package | systemd | A System and Session Manager | srcpackage | systemd-gtk | Graphical front-end for systemd | package | systemd-sysvinit | System V init tools | package # zypper info systemd Information for package systemd: Repository: mozilla Name: systemd Version: 18-1.2.4 Arch: i586 Vendor: openSUSE Installed: No Status: not installed Installed Size: 2.0 MiB Summary: A System and Session Manager Description: Systemd is a system and service manager, compatible with SysV and LSB init scripts for Linux. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit. I have Fedora 15 running on one machine with systemd. As someone who has been using init scripts since SVR4 in the late 0s it feels ... well, weird, but somehow very logical. I keep feeing that I want DBUS and Cgroups to be better explained/documented. Th examples make sense but I'm find it hard to extrapolate about DBUS and Cgroups. Systemd itself is sooooo logical I keep asking 'why didn't someone do that a decade ago?' -- APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anton Aylward wrote:
Your reasoning is valid, but it is also an example of a much more general problem, that of dependencies.
You are stating, quite rightly, that NTP should be started when a specific network comes up.
Provided that ntp is properly configured, it doesn't really matter. -- Per Jessen, Zürich (19.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-07-18 at 15:01 +0200, Per Jessen wrote:
Anton Aylward wrote:
Your reasoning is valid, but it is also an example of a much more general problem, that of dependencies.
You are stating, quite rightly, that NTP should be started when a specific network comes up.
Provided that ntp is properly configured, it doesn't really matter.
My ntp setup is out-of-the-box openSUSE. All I have done is select a time server via YaST. I have been saving the fun of learning the details of ntp configuration for when I start using GPS/PPS in a road vehicle. Have you made changes to ntp to achieve your fantasmagorical ntp robustness? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Mon, 2011-07-18 at 15:01 +0200, Per Jessen wrote:
Anton Aylward wrote:
Your reasoning is valid, but it is also an example of a much more general problem, that of dependencies.
You are stating, quite rightly, that NTP should be started when a specific network comes up.
Provided that ntp is properly configured, it doesn't really matter.
My ntp setup is out-of-the-box openSUSE. All I have done is select a time server via YaST. I have been saving the fun of learning the details of ntp configuration for when I start using GPS/PPS in a road vehicle.
Have you made changes to ntp to achieve your fantasmagorical ntp robustness?
Hehe, nothing fantastic about it, it is really standard - here is my main server config, comments omitted: server 127.127.8.1 mode 16 prefer # dcf77 server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized server ntp.metas.ch server swisstime.ethz.ch driftfile /var/lib/ntp/drift/ntp.drift # path for drift file logfile /var/log/ntp # alternate log file logconfig =all I don't use NetworkManager, and my systems run all the time. The hardware clock is of course UTC, local time is CET/CEST. -- Per Jessen, Zürich (19.5°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-07-18 at 08:49 -0400, Anton Aylward wrote:
The real solution is a proper management of dependencies and triggers.
I've said before that this is a situation that 'systemd' addresses; it was intended to address these kinds of dependencies.
http://en.opensuse.org/SDB:Systemd
http://en.wikipedia.org/wiki/Systemd http://fedoraproject.org/wiki/Features/systemd
I will have to investigate. If for no other reason than that we have our own scripts in this environment. Those will probably need to work in a systemd environment at some point in the future. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
I am on a laptop that exhibits the problem. hwclock -r is showing the correct UTC time that I expect. The network is up via NetworkManager when I logged in graphically. The ntp that started when I booted is still running. But, alas, the time is incorrect. It can sit like this for hours, and the time will NEVER be corrected. Ever. Consistently.
All I have to do now is run 'rcntp restart', and time will be corrected.
Carlos explained this issue very well. Now you need to examine why your system clock is off by two(?) hours when it is started. (Two hours discrepancy is not an inaccuracy, it is a clock that has been wrongly set).
I suspect it is that the ntp rc script is assuming that since it is set to start after networking, it can assume that access to time servers is available when it starts. Alas, when a network device starts some time afterward, this assumption is faulty.
The ntp init-script is not really intended to fix enormous hour-size gaps of time - on a normal startup the time offset of the local system might be measured in seconds, which ntp will then correct immediately provided a time source is available. If the time cannot be set, and the gap is 1000s or more, ntpd will exit immediately.
In this configuration, when the system does have correct time when the system is shutdown (I have restarted ntp), shouldn't the time come up correct when the system is rebooted?
Relatively correct, yes. If it does not, that's your problem, not ntp nor chrony.
It would if the claim that ntp kept a record of the drift and used that when it first starts.
Check the driftfile and you'll notice that it is updated once an hour (if ntp is running). See /var/lib/ntp/drift/ntp.drift
Alas, the time is always the BIOS time. Which is always the expected two hours off.
Two hours off _what_? What is your reference time?
The hardware clock is working. ntp is just not adjusting it when the config above is used.
If your hardware clock is two hours off what you want, ntp will not solve the problem unless you force it too (by lifting the sanity check). Nor will chrony, I suspect. -- Per Jessen, Zürich (16.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2011-07-16 at 10:22 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
I am on a laptop that exhibits the problem. hwclock -r is showing the correct UTC time that I expect. The network is up via NetworkManager when I logged in graphically. The ntp that started when I booted is still running. But, alas, the time is incorrect. It can sit like this for hours, and the time will NEVER be corrected. Ever. Consistently.
All I have to do now is run 'rcntp restart', and time will be corrected.
Carlos explained this issue very well. Now you need to examine why your system clock is off by two(?) hours when it is started. (Two hours discrepancy is not an inaccuracy, it is a clock that has been wrongly set).
The two hours is because the hardware clock is set to UTC time. That is two hours from local time in Sweden. So one question I have that I have not brought up (isn't the current question enough to keep us busy? :) ) is why when ntp fails does the system seem to ignore the system timezone? I have been assuming that the system does in fact set the time according to the timezone (in the hwclock startup script). Then, when the ntp startup script is run, it does it's own thing which involves setting the time back to the hardware time, expecting to correct it when a time server is found. As no time server is found, step one of the ntp startup process is all that happens, leaving the time in the original hardware state.
I suspect it is that the ntp rc script is assuming that since it is set to start after networking, it can assume that access to time servers is available when it starts. Alas, when a network device starts some time afterward, this assumption is faulty.
The ntp init-script is not really intended to fix enormous hour-size gaps of time - on a normal startup the time offset of the local system might be measured in seconds, which ntp will then correct immediately provided a time source is available. If the time cannot be set, and the gap is 1000s or more, ntpd will exit immediately.
Once again, the difference between the hardware clock and local time is because the hardware clock is in UTC time. It is not really wrong. I would have thought that was the preferred method on Linux. Things like daylight savings time switching only happen if the hardware clock is in UTC time. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Sat, 2011-07-16 at 10:22 +0200, Per Jessen wrote:
Carlos explained this issue very well. Now you need to examine why your system clock is off by two(?) hours when it is started. (Two hours discrepancy is not an inaccuracy, it is a clock that has been wrongly set).
The two hours is because the hardware clock is set to UTC time. That is two hours from local time in Sweden. So one question I have that I have not brought up (isn't the current question enough to keep us busy? :) ) is why when ntp fails does the system seem to ignore the system timezone?
ntp isn't concerned about timezones - timezones are really for interaction with humans only. Let ntp keep the time in UTC, then you (or your systems) apply your local timezone whenever you need to work with the time.
I have been assuming that the system does in fact set the time according to the timezone (in the hwclock startup script).
I'm not sure, but I don't think so. There's probably someone here who understands hwclock better than I do.
Then, when the ntp startup script is run, it does it's own thing which involves setting the time back to the hardware time, expecting to correct it when a time server is found. As no time server is found, step one of the ntp startup process is all that happens, leaving the time in the original hardware state.
The ntp init-script does essentially two things: 1) sets time when available 2) start ntp - will exit if time is not sane.
Once again, the difference between the hardware clock and local time is because the hardware clock is in UTC time. It is not really wrong. I would have thought that was the preferred method on Linux. Things like daylight savings time switching only happen if the hardware clock is in UTC time.
Right. Your system sounds like it is running exactly like mine. Where exactly do you see the wrong time? And what is the wrong time, i.e. why is it wrong? -- Per Jessen, Zürich (15.7°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-07-18 at 10:00 +0200, Per Jessen wrote:
Right. Your system sounds like it is running exactly like mine. Where exactly do you see the wrong time? And what is the wrong time, i.e. why is it wrong?
The time as used everywhere in the system is the BIOS UTC time. I see this via 'date', or in a desktop GUI clock. If I disable ntp the timezone is correctly applied during boot. If ntp is restarted after the network is available the timezone is also correctly applied (a sudden jump of two hours occurs). If the network is not available when ntp starts, the time stays the BIOS UTC time. The timezone seems to be ignored. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Mon, 2011-07-18 at 10:00 +0200, Per Jessen wrote:
Right. Your system sounds like it is running exactly like mine. Where exactly do you see the wrong time? And what is the wrong time, i.e. why is it wrong?
The time as used everywhere in the system is the BIOS UTC time. I see this via 'date', or in a desktop GUI clock. If I disable ntp the timezone is correctly applied during boot. If ntp is restarted after the network is available the timezone is also correctly applied (a sudden jump of two hours occurs).
Restarting ntp also means running 'ntpd -g -q' which disables the 1000s sanity check, sets the time and exits. Okay - can you post contents of /etc/adjtime as well as output from "date" and "date -u", please? -- Per Jessen, Zürich (16.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 10:19 -0400, Anton Aylward wrote:
Roger Oberholtzer said the following on 07/15/2011 09:55 AM:
Systems that are on all the time or for very long periods of time do not see the deficiency in ntp. It has become apparent in systems that are off and on with some frequency. It is a recurring topic on the gpsd mailing list.
You seem to have ommitted a number of things.
Many of us live on laptops that are "off and on with some frequency" and don't always have internet connections or in circumstances where the proxy doesn't allow NTP.
What NTP does do that you have ommited in this thread is also significant. It keeps track of drift of the system clock. In fact when a reference is available it keeps track of the drift continuously, so that when it starts up and isn't in contact with a reference it can make a damn good estimate of what the time really is.
First, this assessment of the shortcomings of ntp is the popular consensus of those on the gpsd list. I would not discount the knowledge and experience there. Eric Raymond, who manages gpsd is a bright guy. It could very well be that openSUSE have a hwclock/ntp setup that is far superior to what can be seen elsewhere. Perhaps it is other distro implementations that have resulted in ntp having a bad rep in some circles and for certain non-traditional uses. I am only at the fact finding stage while I decide how best to implement something that must be bullet-proof. Or as bullet-proof as I can possibly make it. I am collecting information. Perhaps ntp will work a charm. All I really asked was: what happens in openSUSE if I disable hwclock when the system is shutdown? We have veered off this. But I still think the discussion is useful. I have had issues on openSUSE with ntp and servers that are only available after a user runs NetworkManager. On a laptop out in the world using wireless, NetworkManager rather than the traditional ifup method is a fact of life. I always have to run 'rcntp restart' after I get a connection. Otherwise, even after a couple hours, ntp does not cotton on to the availability of the server - even though it is still running. Simply restarting ntp corrects that. The even more odd thing is that, when the time is correct when the system is turned off, why is it once again wrong when the system is restarted? If ntp was setting the time correct without needing the external server, I would expect a reasonable time when the system restarts. In my case, the BIOS is two hours off (UTC time, and I am in Stockholm). Until I run 'rcntp restart' AFTER the network connection is made, the time will remain incorrect by two hours. ntp seems to deal with the timezone when the server is available. Does it not deal with it when the server is not available? Hard to say. But it looks that way. It really looks to me that ntp does nothing to the time if an external time source is not found. This has been this was for as long as I remember, and is this way in 11.4
The issue is "how good", and that can only be determined in any instance by experimentation.
The other point is the _QUALITY_ of your internal clock.
I _KNOW_ my wall clocks drift, about a minute month. I expect better of my TAG Heuer Aquagraph.
I you (or your company) is unwilling to invest in the quality of baseline hardware to meet your business needs then arguing about NTP vs chrony is moot.
The hardware is not the issue. It is quite good. We do not muck about with those things. We currently check clock drift relative to the GPS in our software. It seems rather stable. We would now like to get all the various sub-systems to have the same concept of time since many new devices we integrate like to use their own GPS to time stamp their data. Perhaps not the design choice we would have made - but is seems to becoming more common. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-07-15 17:14, Roger Oberholtzer wrote:
The even more odd thing is that, when the time is correct when the system is turned off, why is it once again wrong when the system is restarted? If ntp was setting the time correct without needing the external server, I would expect a reasonable time when the system restarts. In my case, the BIOS is two hours off (UTC time, and I am in Stockholm).
The common source of that "hours" error, is that the owner set up the clock, and forgot to erase /etc/adjtime. This file gets the wrong adjustment if you move the clock up or down by an hour. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk4ghA0ACgkQtTMYHG2NR9XkKgCfYZTTfwNGDpEfDrGVaUsJQ/tE 3R8AnRJOe8ae1t8SwNqXX2c3HKxblCv3 =CkH7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 20:16 +0200, Carlos E. R. wrote:
On 2011-07-15 17:14, Roger Oberholtzer wrote:
The even more odd thing is that, when the time is correct when the system is turned off, why is it once again wrong when the system is restarted? If ntp was setting the time correct without needing the external server, I would expect a reasonable time when the system restarts. In my case, the BIOS is two hours off (UTC time, and I am in Stockholm).
The common source of that "hours" error, is that the owner set up the clock, and forgot to erase /etc/adjtime. This file gets the wrong adjustment if you move the clock up or down by an hour.
If that were the case, how would restarting ntp fix that? ntp is running from boot, and it does not work. Do NOTHING other than 'rcntp restart', and all is well again.
-- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 SHAW'S PRINCIPAL Build a system that even a fool can use, and only a fool will want to use it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-07-16 01:17, Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 20:16 +0200, Carlos E. R. wrote:
The common source of that "hours" error, is that the owner set up the clock, and forgot to erase /etc/adjtime. This file gets the wrong adjustment if you move the clock up or down by an hour.
If that were the case, how would restarting ntp fix that? ntp is running from boot, and it does not work. Do NOTHING other than 'rcntp restart', and all is well again.
Till next boot, then it will be wrong again. It is obvious. Restarting ntp forces it to set the system clock. But the cmos clock adjustment in /etc/adjtime gets the wrong idea when you set the clock that way. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk4g2egACgkQtTMYHG2NR9XtggCggD5WoVbvDo2dqGFNlZYXKwRa ssMAoIL8Cgd9SuFKh9TQxRRUh0eXefyr =avkV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
I have had issues on openSUSE with ntp and servers that are only available after a user runs NetworkManager. On a laptop out in the world using wireless, NetworkManager rather than the traditional ifup method is a fact of life. I always have to run 'rcntp restart' after I get a connection. Otherwise, even after a couple hours, ntp does not cotton on to the availability of the server - even though it is still running. Simply restarting ntp corrects that.
I sense a NetworkManager problem rather than an ntp ditto. Have you ever checked ntp's status after such a network change? I mean, check the status of the time sources.
If ntp was setting the time correct without needing the external server,
How can it? It has to rely on the stored RTC values, possibly using known drift to correct them.
I would expect a reasonable time when the system restarts. In my case, the BIOS is two hours off (UTC time, and I am in Stockholm). Until I run 'rcntp restart' AFTER the network connection is made, the time will remain incorrect by two hours.
I suspect a timezone issue, not an NTP problem.
ntp seems to deal with the timezone when the server is available. Does it not deal with it when the server is not available? Hard to say. But it looks that way. It really looks to me that ntp does nothing to the time if an external time source is not found.
Check your logs - you should see ntp sync'ing to the local clock. Unless that is not configured? -- Per Jessen, Zürich (21.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
Until I run 'rcntp restart' AFTER the network connection is made, the time will remain incorrect by two hours. ntp seems to deal with the timezone when the server is available.
If you want that rcntp restart to occur automagically, you can place a script in /etc/sysconfig/network/if-up, which will run every time a network connection starts. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
If NTP does not find an external server, it eventually falls back to localhost. localhost uses whatever the BIOS has for time.
Plus corrections for whatever drift ntp has calculated.
If your time looks correct in the absence of a ntp server, it is probably because of some mechanism other than ntp. Like the hwclock stuff openSUSE does at boot and shutdown. I think that is what maintains time between boots.
hwclock just sets the RTC - I don't know where it is today, but it used to be e.g. a little black clunky looking device, often by Dallas Semiconductor.
It requires that the time be correct when the system is shutdown. To whatever extent it is incorrect when it is shut down, it will be incorrect when it boots.
Plus or minus drift.
Given that ntp seems to only periodically re-check available servers, if the GPS is not on-line when it checks, it may be missed.
I'm not sure, but I suspect NTP check its servers and peers on every poll. When it has a stable signal from a higher-stratum server, it'll switch.
Having claimed all this, I realize that I may have a few points wrong. I can only say that I see on my laptop (on and off a lot - external time source only available after boot is long completed) the unexpected ntp behavior described by others. I have no investment in using chrony or ntp. I am only exploring options at this time.
And my real question about any possible side effects of not running hwclock at system shutdown remains unanswered.
The RTC won't be set to O/S time, that's all. I may not have understood all of your problem, but without a frequent connection to an accurate time-source, any system will have to rely on a local clock for periods of time. AFAICT, both chrony and ntp know how to determine the local oscillator drift and massage the clock such that the local clock remains fairly accurate. If you need a higher degree of accuracy without a more accurate external time source, you have to improve the local time source - temperature controlled xtal oscillator etc. -- Per Jessen, Zürich (21.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 17:04 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
I may not have understood all of your problem, but without a frequent connection to an accurate time-source, any system will have to rely on a local clock for periods of time. AFAICT, both chrony and ntp know how to determine the local oscillator drift and massage the clock such that the local clock remains fairly accurate. If you need a higher degree of accuracy without a more accurate external time source, you have to improve the local time source - temperature controlled xtal oscillator etc.
This massaging does seem to happen when ntp is running and after it has a server. But I am not convinced that anything is done when ntp starts and before it gets in contact with a server. And that is what chrony provides. A useful estimate of time before the first server is found. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 17:04 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
I may not have understood all of your problem, but without a frequent connection to an accurate time-source, any system will have to rely on a local clock for periods of time. AFAICT, both chrony and ntp know how to determine the local oscillator drift and massage the clock such that the local clock remains fairly accurate. If you need a higher degree of accuracy without a more accurate external time source, you have to improve the local time source - temperature controlled xtal oscillator etc.
This massaging does seem to happen when ntp is running and after it has a server. But I am not convinced that anything is done when ntp starts and before it gets in contact with a server.
If properly configured ntp will _always_ have a server - the local clock. The drift of the local clock oscillator will have been determined, so ntp will use that to keep massaging the clock until a better source becomes available.
And that is what chrony provides. A useful estimate of time before the first server is found.
I don't know anything about chrony, so I have to wonder what information it has that ntp does not? -- Per Jessen, Zürich (21.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen said the following on 07/15/2011 12:05 PM:
If properly configured ntp will _always_ have a server - the local clock. The drift of the local clock oscillator will have been determined, so ntp will use that to keep massaging the clock until a better source becomes available.
+1
And that is what chrony provides. A useful estimate of time before the first server is found.
I don't know anything about chrony, so I have to wonder what information it has that ntp does not?
Indeed. At startup, in the absence of an outside reference (or until an outside reference can be obtained -- however long that takes) there is the hardware clock, which may drift. NTP 'learns' the drift rate of the clock, and keeps 'learning'. So what information does chrony have that NTP doesn't? -- The emphasis should be on "why" we do a job - W. Edwards Deming -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 12:53 -0400, Anton Aylward wrote:
Per Jessen said the following on 07/15/2011 12:05 PM:
If properly configured ntp will _always_ have a server - the local clock. The drift of the local clock oscillator will have been determined, so ntp will use that to keep massaging the clock until a better source becomes available.
+1
And that is what chrony provides. A useful estimate of time before the first server is found.
I don't know anything about chrony, so I have to wonder what information it has that ntp does not?
Indeed. At startup, in the absence of an outside reference (or until an outside reference can be obtained -- however long that takes) there is the hardware clock, which may drift. NTP 'learns' the drift rate of the clock, and keeps 'learning'.
During the current run. Not so sure about between runs. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 SHAW'S PRINCIPAL Build a system that even a fool can use, and only a fool will want to use it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 18:05 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 17:04 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
I may not have understood all of your problem, but without a frequent connection to an accurate time-source, any system will have to rely on a local clock for periods of time. AFAICT, both chrony and ntp know how to determine the local oscillator drift and massage the clock such that the local clock remains fairly accurate. If you need a higher degree of accuracy without a more accurate external time source, you have to improve the local time source - temperature controlled xtal oscillator etc.
This massaging does seem to happen when ntp is running and after it has a server. But I am not convinced that anything is done when ntp starts and before it gets in contact with a server.
If properly configured ntp will _always_ have a server - the local clock. The drift of the local clock oscillator will have been determined, so ntp will use that to keep massaging the clock until a better source becomes available.
But the localclock, when ntp is used, is from the BIOS, which is UTC, which is incorrect.
And that is what chrony provides. A useful estimate of time before the first server is found.
I don't know anything about chrony, so I have to wonder what information it has that ntp does not?
It is not so much that it has different information. In fact, in many ways it is like ntp. The difference is subtle. Whereas ntp does not seem to retry non-existent servers (real 'not localhost'), chrony does. Obviously, until chrony gets a hold of an external server, the time will not be in sync. In the case of GPS receivers, chrony takes great advantage of the new PPS driver. When the GPS starts sending data, chrony detects this immediately and gets the time correct. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 SHAW'S PRINCIPAL Build a system that even a fool can use, and only a fool will want to use it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011-07-16 01:23, Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 18:05 +0200, Per Jessen wrote:
If properly configured ntp will _always_ have a server - the local clock. The drift of the local clock oscillator will have been determined, so ntp will use that to keep massaging the clock until a better source becomes available.
But the localclock, when ntp is used, is from the BIOS, which is UTC, which is incorrect.
No! X'-) You are confusing things. The BIOS clock is not used at all for this. And even if it were, it is taken into account its being UTC or local, this doesn't have any effect. If it does, it is due to the keyboard-chair interface >:-P -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 18:05 +0200, Per Jessen wrote:
This massaging does seem to happen when ntp is running and after it has a server. But I am not convinced that anything is done when ntp starts and before it gets in contact with a server.
If properly configured ntp will _always_ have a server - the local clock. The drift of the local clock oscillator will have been determined, so ntp will use that to keep massaging the clock until a better source becomes available.
But the localclock, when ntp is used, is from the BIOS, which is UTC, which is incorrect.
I would not have thought that timezone is important here. What is your priority - correct time or an accurate clock? I expect the latter, so what is the significance of the time-of-day?
And that is what chrony provides. A useful estimate of time before the first server is found.
I don't know anything about chrony, so I have to wonder what information it has that ntp does not?
It is not so much that it has different information. In fact, in many ways it is like ntp. The difference is subtle. Whereas ntp does not seem to retry non-existent servers (real 'not localhost'), chrony does.
ntp does too. You saw the logfile I posted yesterday. If your ntp setup fails to switch between the configured time sources according to their quality&availability, something is wrong with your ntp setup. -- Per Jessen, Zürich (15.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011-07-15 17:19, Roger Oberholtzer wrote:
This massaging does seem to happen when ntp is running and after it has a server. But I am not convinced that anything is done when ntp starts and before it gets in contact with a server. And that is what chrony provides. A useful estimate of time before the first server is found.
There are two corrections done. One is done by the suse boot scripts, by use of hwclock and the /etc/adjtime fiile, to compensate for the estimated drift of the cmos, battery backed, clock, while the system was unpowered. The boot or initial error. The other is done by ntp, which adjusts the speed of the system clock. Not the initial time, but the drift it will have from that point on. -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Roger Oberholtzer said the following on 07/15/2011 11:19 AM:
But I am not convinced that anything is done when ntp starts and before it gets in contact with a server. And that is what chrony provides. A useful estimate of time before the first server is found.
NTP does that. It has the hardware clock as a reference in place or a remote server reference and knows the rate of drift of the hardware clock. If you are not seeing this then you are not setting NTP up correctly. -- "Security can be viewed like a construction scenario - build part of a road, and even if and even if you don't complete it, you still have something to drive on; build part of a bridge and you have nothing! Security is like the last." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011-07-15 21:14, Anton Aylward wrote:
NTP does that. It has the hardware clock as a reference in place or a remote server reference and knows the rate of drift of the hardware clock.
Of the hardware clock, no. Of the system clock, yes. The hardware clock is only queried on boot, and not by ntp, bu by hwclock. -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Carlos E. R. wrote:
On 2011-07-15 21:14, Anton Aylward wrote:
NTP does that. It has the hardware clock as a reference in place or a remote server reference and knows the rate of drift of the hardware clock.
Of the hardware clock, no. Of the system clock, yes.
No, the drift is the inaccuracy or error of the clock frequency, i.e. of the hardware oscillator. By knowing the drift of the hardware clock, ntp is able to massage the system clock. -- Per Jessen, Zürich (15.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011-07-15 23:09, Per Jessen wrote:
Carlos E. R. wrote:
On 2011-07-15 21:14, Anton Aylward wrote:
NTP does that. It has the hardware clock as a reference in place or a remote server reference and knows the rate of drift of the hardware clock.
Of the hardware clock, no. Of the system clock, yes.
No, the drift is the inaccuracy or error of the clock frequency, i.e. of the hardware oscillator. By knowing the drift of the hardware clock, ntp is able to massage the system clock.
You are confusing names. There are two clocks. 1) The hardware clock, aka cmos clock, aka battery backed clock. It is the only one that can run when the system is powered down. 2) The system clock. It is controlled by the CPU, with different hardware types. AKA software clock. It only runs with the system up. Even if there is hardware involved in clock #2, it is not called "hardware clock". Both clocks have different drifts, taken into account differently. #1 by hwclock, #2 by ntp. Don't mix names! When the system boots, clock #1 is read, its drift calculated, and then clock #2 is set up with the result. This is done via scripts and hwclock. When the system runs, #1 is not used at all. Time is read from #2 only, and its drift is corrected by NTP (if available). When the system goes down, the system ensures that clock #1 is adjusted, and its drift calculated and noted. -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Carlos E. R. wrote:
On 2011-07-15 23:09, Per Jessen wrote:
Carlos E. R. wrote:
On 2011-07-15 21:14, Anton Aylward wrote:
NTP does that. It has the hardware clock as a reference in place or a remote server reference and knows the rate of drift of the hardware clock.
Of the hardware clock, no. Of the system clock, yes.
No, the drift is the inaccuracy or error of the clock frequency, i.e. of the hardware oscillator. By knowing the drift of the hardware clock, ntp is able to massage the system clock.
You are confusing names.
There are two clocks.
1) The hardware clock, aka cmos clock, aka battery backed clock. It is the only one that can run when the system is powered down.
2) The system clock. It is controlled by the CPU, with different hardware types. AKA software clock. It only runs with the system up.
Even if there is hardware involved in clock #2, it is not called "hardware clock".
Both clocks have different drifts, taken into account differently. #1 by hwclock, #2 by ntp. Don't mix names!
man ntp.conf: driftfile This command specifies the complete path and name of the file used to record the frequency of the local clock oscillator.
When the system boots, clock #1 is read, its drift calculated, and then clock #2 is set up with the result. This is done via scripts and hwclock. When the system runs, #1 is not used at all. Time is read from #2 only, and its drift is corrected by NTP (if available). When the system goes down, the system ensures that clock #1 is adjusted, and its drift calculated and noted.
AFAIR, ntp updates the drift file once an hour. -- Per Jessen, Zürich (15.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011-07-16 09:28, Per Jessen wrote:
Carlos E. R. wrote:
Both clocks have different drifts, taken into account differently. #1 by hwclock, #2 by ntp. Don't mix names!
man ntp.conf:
driftfile This command specifies the complete path and name of the file used to record the frequency of the local clock oscillator.
That's right, the drift of the system clock.
When the system boots, clock #1 is read, its drift calculated, and then clock #2 is set up with the result. This is done via scripts and hwclock. When the system runs, #1 is not used at all. Time is read from #2 only, and its drift is corrected by NTP (if available). When the system goes down, the system ensures that clock #1 is adjusted, and its drift calculated and noted.
AFAIR, ntp updates the drift file once an hour.
The drift of the system clock, yes; not the cmos clock (aka hardware clock, or bios clock): cer@Telcontar:~> l /etc/adjtime -rw-r--r-- 1 root root 44 Jul 16 03:39 /etc/adjtime Now is 12:34. I hibernated the machine precisely at: <5.4> 2011-07-16 03:39:46 Telcontar pm-utils - - - Hibernating (95)... <5.4> 2011-07-16 12:03:49 Telcontar pm-utils - - - Thawing (95)... So it appears the hw drift file was updated precisely when I hibernated. I have to wait half an hour (till 13:04) and see if it is updated. .... cer@Telcontar:~> date; l /etc/adjtime Sat Jul 16 13:10:16 CEST 2011 -rw-r--r-- 1 root root 44 Jul 16 03:39 /etc/adjtime Nope, the drift file for the hardware clock is not updated every half hour. I'm going out, I'll leave it running and see. -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Carlos E. R. wrote:
On 2011-07-16 09:28, Per Jessen wrote:
Carlos E. R. wrote:
Both clocks have different drifts, taken into account differently. #1 by hwclock, #2 by ntp. Don't mix names!
man ntp.conf:
driftfile This command specifies the complete path and name of the file used to record the frequency of the local clock oscillator.
That's right, the drift of the system clock.
Wait - how did you make "local clock oscillator" = system clock? The local clock oscillator is a bit of hardware essentially producing a PPS signal for advancing the hardware clock. The hardware oscillator has a instability or drift, i.e. it is slightly inaccurate. ntp uses the drift-information to fake a PPS when an external source is not available. ntp calls adjtime() to adjust the system clock (software) in tiny steps.
When the system boots, clock #1 is read, its drift calculated, and then clock #2 is set up with the result. This is done via scripts and hwclock. When the system runs, #1 is not used at all. Time is read from #2 only, and its drift is corrected by NTP (if available). When the system goes down, the system ensures that clock #1 is adjusted, and its drift calculated and noted.
AFAIR, ntp updates the drift file once an hour.
The drift of the system clock, yes; not the cmos clock (aka hardware clock, or bios clock): cer@Telcontar:~> l /etc/adjtime -rw-r--r-- 1 root root 44 Jul 16 03:39 /etc/adjtime Now is 12:34. I hibernated the machine precisely at: <5.4> 2011-07-16 03:39:46 Telcontar pm-utils - - - Hibernating (95)... <5.4> 2011-07-16 12:03:49 Telcontar pm-utils - - - Thawing (95)...
So it appears the hw drift file was updated precisely when I hibernated. I have to wait half an hour (till 13:04) and see if it is updated.
That is not the drift file I'm talking about - I'm talking about NTPs drift file, usually /var/lib/ntp/drift/ntp.drift. -- Per Jessen, Zürich (20.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Wait - how did you make "local clock oscillator" = system clock? The local clock oscillator is a bit of hardware essentially producing a PPS signal for advancing the hardware clock. The hardware oscillator has an instability or drift, i.e. it is slightly inaccurate. ntp uses the drift-information to fake a PPS when an external source is not
to fake a more accurate PPS. -- Per Jessen, Zürich (20.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-07-16 13:31, Per Jessen wrote:
Carlos E. R. wrote:
On 2011-07-16 09:28, Per Jessen wrote:
Carlos E. R. wrote:
Both clocks have different drifts, taken into account differently. #1 by hwclock, #2 by ntp. Don't mix names!
man ntp.conf:
driftfile This command specifies the complete path and name of the file used to record the frequency of the local clock oscillator.
That's right, the drift of the system clock.
Wait - how did you make "local clock oscillator" = system clock? The local clock oscillator is a bit of hardware essentially producing a PPS signal for advancing the hardware clock. The hardware oscillator has a instability or drift, i.e. it is slightly inaccurate. ntp uses the drift-information to fake a PPS when an external source is not available. ntp calls adjtime() to adjust the system clock (software) in tiny steps.
You are confusing the available clocks. Again. The hardware clock is a cmos chip running of small battery or the psu when available. It does not produce any pulse. It's drift is not adjusted by ntp. What ntp does when there is no external accurate source is a loopback to the system clock, by another name.
That is not the drift file I'm talking about - I'm talking about NTPs drift file, usually /var/lib/ntp/drift/ntp.drift.
That's the drift of the system clock. The file I'm talking is for the hardware clock. You are confusing both. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk4hi+kACgkQtTMYHG2NR9UuZgCglhR+hhaseuQL3OwYgA71yBRh 3eYAniXln0YA1XXXcNFkbpaRxWOTMGdk =j9sq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2011-07-15 at 15:14 -0400, Anton Aylward wrote:
Roger Oberholtzer said the following on 07/15/2011 11:19 AM:
But I am not convinced that anything is done when ntp starts and before it gets in contact with a server. And that is what chrony provides. A useful estimate of time before the first server is found.
NTP does that. It has the hardware clock as a reference in place or a remote server reference and knows the rate of drift of the hardware clock.
If you are not seeing this then you are not setting NTP up correctly.
It is however openSUSE has it set up. All I have specified is the server, via YaST. What option controls how it retries servers that had previously failed? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 SHAW'S PRINCIPAL Build a system that even a fool can use, and only a fool will want to use it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011-07-16 01:35, Roger Oberholtzer wrote:
What option controls how it retries servers that had previously failed?
Patience! >:-) NTP is designed to change the clock so slow that you will not notice. It is a design feature. The side efect is that you think it is not working. -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Per Jessen wrote:
If you need a higher degree of accuracy without a more accurate external time source, you have to improve the local time source - temperature controlled xtal oscillator etc.
btw, this is perfectly feasible. You can build/buy very stable TXCOs that will supply a very good PPS signal. Companies such www.rakon.com make very tiny devices with very good accuracies. -- Per Jessen, Zürich (16.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2011-07-16 at 10:35 +0200, Per Jessen wrote:
Per Jessen wrote:
If you need a higher degree of accuracy without a more accurate external time source, you have to improve the local time source - temperature controlled xtal oscillator etc.
btw, this is perfectly feasible. You can build/buy very stable TXCOs that will supply a very good PPS signal. Companies such www.rakon.com make very tiny devices with very good accuracies.
In our case, we are using high end GPS receivers with a PPS signal on the serial port. This causes a hardware interrupt when a time update is available. This is a rather accurate event when used in conjunction with a time setting daemon that can use the data and associated PPS signal from a GPS. In newer kernels, there is a PPS driver that has finally abstracted all these possible PPS signals into a single interface (/dev/pps). We currently do some of this time synchronizing in our own application. I do not want to do that anymore. It is because I am investigating what the caveats are when this is done at the system level when a system is not connected to the internet (an assumption that is unfortunately becoming more and more common) that the original question came up. And that question (still not answered) is: is there any unexpected side effect of not running the hwclock shutdown script? In my case, chrony wants to maintain the hardware clock between boots. It is understood that the jury is out as to whether chrony is a useful solution. But that was not the question. Does the hwclock shutdown script maintain any information used by any systems other than hwclock itself? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Sat, 2011-07-16 at 10:35 +0200, Per Jessen wrote:
Per Jessen wrote:
If you need a higher degree of accuracy without a more accurate external time source, you have to improve the local time source - temperature controlled xtal oscillator etc.
btw, this is perfectly feasible. You can build/buy very stable TXCOs that will supply a very good PPS signal. Companies such www.rakon.com make very tiny devices with very good accuracies.
In our case, we are using high end GPS receivers with a PPS signal on the serial port. This causes a hardware interrupt when a time update is available. This is a rather accurate event when used in conjunction with a time setting daemon that can use the data and associated PPS signal from a GPS. In newer kernels, there is a PPS driver that has finally abstracted all these possible PPS signals into a single interface (/dev/pps).
That is understood, but I thought you had an issue with the GPS PPS signal being unavailable and the local clock not being sufficiently accurate.
And that question (still not answered) is: is there any unexpected side effect of not running the hwclock shutdown script?
I can't answer that - I think you'll have to google some more.
In my case, chrony wants to maintain the hardware clock between boots.
That makes sense, I'm sure I read somewhere that it's important that only one process maintain the hardware clock. -- Per Jessen, Zürich (17.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-07-18 at 11:11 +0200, Per Jessen wrote:
That is understood, but I thought you had an issue with the GPS PPS signal being unavailable and the local clock not being sufficiently accurate.
Exactly. Sometimes the systems are powered on when the vehicle is in, say, a garage. Or under trees. The GPS may or may not provide the PPS signal before it sees satellites. It is not deterministic. At least using rules the operators can also follow reliably. This points out another requirement: we need to be able to indicate to the operator when the system thinks it has an accurate time. Meaning when the system thinks the time matches the GPS as closely as it can (ignoring the basic hardware drift that will always bring in tiny changes).
And that question (still not answered) is: is there any unexpected side effect of not running the hwclock shutdown script?
I can't answer that - I think you'll have to google some more.
It is more an openSUSE issue than a general Linux question. So I started with the openSUSE list thinking there was some rather specialized knowledge here. Which there indeed is!
In my case, chrony wants to maintain the hardware clock between boots.
That makes sense, I'm sure I read somewhere that it's important that only one process maintain the hardware clock.
Indeed. chrony point out specifically that if anyone else is fiddling with the clock between reboots all bets are off. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Mon, 2011-07-18 at 11:11 +0200, Per Jessen wrote:
That is understood, but I thought you had an issue with the GPS PPS signal being unavailable and the local clock not being sufficiently accurate.
Exactly. Sometimes the systems are powered on when the vehicle is in, say, a garage. Or under trees. The GPS may or may not provide the PPS signal before it sees satellites. It is not deterministic. At least using rules the operators can also follow reliably. This points out another requirement: we need to be able to indicate to the operator when the system thinks it has an accurate time.
ntp will tell you that - it is one of the status indicators in the ntpq display. Or you could monitor the logfile and check for stratum changes. (stratum 0 = GPS, anything else = unsynced). There might even be an SNMP trap for this, you never know. Here is an example: # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *127.127.8.1 .DCFa. 0 l 57 64 177 0.000 -8.956 2.714 127.127.1.0 .LOCL. 10 l 59 64 377 0.000 0.000 0.008 +162.23.41.34 .HBGi. 1 u 58 64 377 55.101 -5.126 120.944 +129.132.2.21 129.132.2.22 2 u 48 64 377 38.736 -12.524 99.586 192.168.7.255 .BCST. 16 u - 16 0 0.000 0.000 0.008 212.25.14.63 .BCST. 16 u - 16 0 0.000 0.000 0.008 This says that this time server is synced to DCF (the asterisk indicator), and that two good external time sources are available (stratum 1 and 2). There is also an indicator for a PPS signal, but I don't use one. -- Per Jessen, Zürich (17.9°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-07-18 at 12:22 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
On Mon, 2011-07-18 at 11:11 +0200, Per Jessen wrote:
That is understood, but I thought you had an issue with the GPS PPS signal being unavailable and the local clock not being sufficiently accurate.
Exactly. Sometimes the systems are powered on when the vehicle is in, say, a garage. Or under trees. The GPS may or may not provide the PPS signal before it sees satellites. It is not deterministic. At least using rules the operators can also follow reliably. This points out another requirement: we need to be able to indicate to the operator when the system thinks it has an accurate time.
ntp will tell you that - it is one of the status indicators in the ntpq display. Or you could monitor the logfile and check for stratum changes. (stratum 0 = GPS, anything else = unsynced). There might even be an SNMP trap for this, you never know.
Here is an example:
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *127.127.8.1 .DCFa. 0 l 57 64 177 0.000 -8.956 2.714 127.127.1.0 .LOCL. 10 l 59 64 377 0.000 0.000 0.008 +162.23.41.34 .HBGi. 1 u 58 64 377 55.101 -5.126 120.944 +129.132.2.21 129.132.2.22 2 u 48 64 377 38.736 -12.524 99.586 192.168.7.255 .BCST. 16 u - 16 0 0.000 0.000 0.008 212.25.14.63 .BCST. 16 u - 16 0 0.000 0.000 0.008
This says that this time server is synced to DCF (the asterisk indicator), and that two good external time sources are available (stratum 1 and 2). There is also an indicator for a PPS signal, but I don't use one.
This looks promising. I guess I will need to make a log file parser if SNMP is not available. Thanks for this pointer. Of course, I need to sort out the ntp issues I have before this is an issue.
-- Per Jessen, Zürich (17.9°C)
Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
This looks promising. I guess I will need to make a log file parser if SNMP is not available. Thanks for this pointer.
I _know_ there is an ntp MIB, but I have never played with it - it's on my (long) todo-list. I'm sure it must be possible to have a trap sent when the stratum changes.
Of course, I need to sort out the ntp issues I have before this is an issue.
Yup. -- Per Jessen, Zürich (18.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (8)
-
Anton Aylward -
Carlos E. R. -
Carlos E. R. -
Greg Freemyer -
James Knott -
Joachim Schrod -
Per Jessen -
Roger Oberholtzer