[ntp:questions] Reference clock driver for /dev/rtc
unruh at wormhole.physics.ubc.ca
Sat Jun 26 15:33:54 UTC 2010
On 2010-06-26, Rob <nomail at example.com> wrote:
> unruh <unruh at wormhole.physics.ubc.ca> wrote:
>> On 2010-06-26, David Woolley <david at ex.djwhome.demon.invalid> wrote:
>>> unruh wrote:
>>>> Linux, depending on the setting of a flag in the adjtimex setup, sets
>>>> the rtc from the system time once every 11 min. . This is a disaster if
>>> I think you missed Dave Mills' point that ntpd does this every 60
>>> minutes, so will also break mechanisms for compensating for RTC drift
>>> whilst the processor is powered down.
>> His point seemed to be that a) He did not know aboutthe Linux 11 min
>> mode (a statement that may have been a rheotorical device) and b) that
>> ntp did it every 60 min. I do hope that ntp's mechanismcan be switched
>> off by some option. That 60 min mode is as silly as the 11 min mode
>> (except giving the rtc more time to drift if wha you want is to minimize
>> the rtc offset while the computer is running and rtc is never used.)
>> Of course this is in the context of VM using the rtc driver to read the
>> underlying system clock, a misuse of the rtc concept IMHO, and either
>> mode would be a disaster if the rtc driver on the VM actually had
>> permission to change the system clock on the underlying real machine.
> Of course it hasn't! The VM monitor will either ignore setting of the
> RTC, or it will keep an offset between host time and the VM time and
> change that when the guest attempts to change the RTC.
> (so that the guest sees the effect of its operation like it would see in a
> physical machine)
> You seem to be ignorant about the problems of keeping time in a
> virtual machine. Many techniques used in modern operating systems
> simply don't virtualize very well, making it very difficult to keep
> accurate time in a VM. You should not downplay an effort to serve
> correct time to a VM without understanding all the problems.
??? I am certain that keeping correct time on the VM is very
problematic, and keeping a clock going accurately on the vm is virtually
impossible. I would expect therefor that any request for time on the VM
would not go to some problematic clock internal to the VM operating
system but would would automatically be redirected to the underlying OS
which could keep good time. Just as the VM disk driver does not
actually read and write the disks but hands off that task to the
underlying system, I would expect the same to happen with clock reads.
The VM is liable to have large and violent
timing swings, sometimes loosing may ticks ( and probably regularly
exceeding the 500PPM that ntp handles) with the VM clock
rate with respect to real time fluctuating wildly. That is NOT a
situation ntp is designed to handle. Overloading /dev/rtc to deliver the
underlying system time to ntpwhich then tries to discipline the unruly
VM system time does not seem to me to be the right approach. But maybe
your VM is more well behaved than I am imagining it to be.
More information about the questions