Messages in this thread | | | From | "Ulrich Windl" <> | Date | Mon, 22 Nov 1999 16:09:55 +0200 | Subject | Re: updating the RTC automagically |
| |
On 22 Nov 99, at 15:11, Guest section DW wrote:
> On Mon, Nov 22, 1999 at 08:18:31AM +0200, Ulrich Windl wrote: > > > Wel, well. How do you explain that the system clock is still the same > > after having used "date -s" several times? > > Ulrich, > If you have a buggy date(1) program, get a better one or complain > to its maintainer. > If you have a buggy kernel, complain on this list that the kernel > is broken, preferably with details about what goes wrong. > But the present discussion was not about fixing something, > but about adding new functionality, and I and others thought > that that might be a bad idea.
run RTC is localtime; date -s; reboot; wrong time if time corrected more than a few minutes. I think it's an issue. (Imagine power failure instead of ordinary reboot)
> > By the way, on many alpha's the settimeofday system call is broken.
Wouldn't be much surprised, but can't comment.
> > > Should each system have a cron job to update the RTC via hwclock > > hourly, or maybe update it during system shutdown? > > The scheme where every 11 min RTC is overwritten by system time > has disadvantages if one wants high precision. > One can observe the drift of the RTC with very high precision > by leaving it alone for a long time.
Already implemented. (See earlier message)
> > The ideal setup would never write the RTC, but only read it, > and keep notes on the deviation and the drift, so that some > user space program can set system time from RTC plus this > information in case no better outside time source is available.
That's a big matter of taste IMHO.
> > The scheme where RTC is set every 11 min is much worse - > each time an error of up to 0.5 sec is introduced, and > such schemes make it impossible to get very reliable data > on the drift of the RTC.
Why do you think I fixed it? Maybe just for you ;-)
> > Many programs that try to adjust for drift are now confronted > with a sawtooth effect that is much more complicated to handle > than a linear drift. And while the linear drift is to a first
The sawtooth you are referring has many different reasons.
> approximation constant, independent of the OS running, this > sawtooth is present only when the machine is up, running Linux, > and with STA_UNSYNC unset.
[...]
U.
- 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/
| |