> > As the hwclock manpage says:
> >
> > If your system runs with 11 minute mode on, don't use
> > hwclock --adjust or hwclock --hctosys. You'll just make a
> > mess.
>
> I don't know whether this is true or why it is there, but I'm sure
> it's not a problem of the kernel.
The point of view I describe is that it is an unfortunate historical
accident that the 11 minute mode was added to the kernel.
Better user space solutions exist but are harmed by the kernel 11 minute mode.
> You are aware that the average quarz drifts by 2PPM per °C?
I can imagine that there is a temperature dependency.
But compare: (i) kernel 11 minute mode: every 11 minutes the system time
is written to the RTC. (ii) user space 11 minute mode: every 11 minutes
RTC is read out and the pair (system time, RTC) is written to file.
Some time later, for example after a reboot, we want to know the time
but do not have (yet) a good outside reference.
Your solution: it is found in RTC.
My solution: it is found in RTC adjusted by the known offset and drift.
You see, your solution is a zero-th order approximation.
It is perfect when the drift is zero.
My solution is a first order approximation.
It is perfect when the drift is constant.
There are no circumstances where kernel 11 minute mode is better.
> "calculate the actual time" is an interesting concept. Maybe you can
> explain how it works, especially if a system is up several months. My
> RTC drifts about a minute per week during summer...
I think you can solve linear equations yourself.
It looks like you are arguing that a first order approximation is not perfect
and use that to defend a zeroth order approximation...
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/