On 2011-03-14, Ralph <ra...@depth.net> wrote: > On Sunday, March 13, 2011 11:41:59 PM UTC-7, unruh wrote: >> >> Sure. Teh Hw clock ( rtc) is on its own timer which does not depend on >> any of the system timers. However it typically has a rate that is many >> PPM out and that rate cannot be adjusted. This makes it completely >> unsuitable for the clock adjustment that ntp uses. Also setting that >> clock is tough and it is not very accurate ( only delivers time to the >> second-- and on modern system even that can be somewhat inaccurate since >> the rtc interrupt has been screwed up in modern versions of Linux. Also >> setting the clock only occurs .5 sec after the adjustment is actually >> made.). The rtc makes for a lousy clock. >> >> >> Nope. The HW clock is a clock which is completely separate from the >> operating system. >> > > You are thinking of HW clocks that run on hardware. This is about a HW clock > within a VM guest. And a hardware clock within a VM is not hardware anymore, > it > is software on the HOST that is emulating the hardware. And the software > that > is doing that emulation is doing it based on the [system] clocking on the > host O/S. > So if one has the HOST O/S clocking getting adjusted to fairly good accuracy, > then the HW clock within the guest will be close to as accurate as the > [system] clocking on the HOST. If you believe that the HW clock on the guest > is run otherwise, then find some evidence to that effect because everything > I've found so far indicates that the guest HW clock is emulated just like all > the other pieces of 'hardware' in the guest.
If that is true, then by all means read the hardware clock. Ufortunately all the software on Linux assumes that the hardware clock gives time to the nearest second. It can read to very close to exactly that second mark by the harware issuing an interrupt at the 1 second mark (like a PPS) but Linux has largely destroyed that usefulness because of the reallocation of its interrupt handling. It thus polls to find the second mark. > > Now Linux's inability to read / set the HW clock accurately is something I > can't speak to, but as Uwe points out, I'm not looking for super accuracy. Then by all means use the hardware clock. > > And I don't think you understood what I was describing... I wasn't advocating > adjusting the HW clock the way ntpd adjusts the system clock. I was > advocating > allowing the use of the HW clock to provide ntpd with a 'stable' clock for it > to use in calculations. Maybe the precision isn't as good, but it would > still > be a good enough level of precision for my purposes and would allow ntpd to > determine the level of adjustment that needs to be made to the system clock > in order to get it to run closer to reality. Well, you could run hwclock once every 10 sec say or once a minute, and simply step the system clock to the right time each time (eg a cron job). That might make timing a bit ropey (ie if you wanted to have parogram run for exaclty 20ms, that might get messed up if that 20ms occured on a clock resetting boundary-- that is one reason why ntp resets the clock by adjusting the rate.) _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
