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