| Re: [chrony-dev] Question / Feature suggestion - trimrtc on start? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Wed, 20 Jul 2011, Ed W wrote:
Hi, a good repost, but...
Thus calling trinrtc at anytime while running should not
make a difference. But doing it on bootup seems not a good idea. The system
time is not good then.
I'm not seeing why it makes a difference what the system time is at this
point? In fact by definition the system time at this point will simply
be the RTC time + estimated offset?
Because you presumably want the rtc to be close to the right time, or what is
the point?
Essentially, the goal at boot would be to step the RTC by the estimated
offset and maintain the current estimated drift params. Much later we
will learn that the step wasn't correct, but hopefully it's better than
nothing.
Why is it better than nothing? With nothing on the next boot, the system
offset and drift will be corrected by chrony, and with it, the system offset
and drift (maybe smaller, maybe larger) will be corrected by chrony.
(Case in point is that my clock has drifted by 20 seconds over some
period of not running trimrtc. The bootscripts all see a time of some 20
seconds slow until chrony starts, then they see a 20 second jump and a
few things get upset? I outlined a few ways to fix this, but trimrtc on
every boot reduces the scale of the problem somewhat for my requirements)
You can of course do whatever you want on your machine. But what you are
asking for is to make it general for everyone. Introducing another potential
for bugs to creep in, having people use the option when they have no idea what
it means.
Now, If you really wanted you could do a chronyc trimrtc as part of the halt
script ( just as now in Mandriva, hwclock is called to reset the rtc to the
current time). The case where your system comes up and crashes is an anomaly
that I would not waste any time thinking about.
There will always be a jump ( if you tell chrony to jump the time at startup.
You do not have to . You can tell chrony it should slew the offset even at
startup if some of your programs object to a step). Or you could start chrony
early in the sequence with a offline command so it did not try to contact the
servers since the network is not yet up. THen once the network is up, put the
sources online.
You should wait until the system time has settled down.
This would only appear to be useful from the point of view of improving
the estimate of drift? (arguably we get an update on the size of error
between real time and RTC, but my question was how often we can sensibly
use that to update the RTC without upsetting our current drift measurements?
That is what trimrtc does. It writes to the rtc and then changes all of the
earlier measuments of the rtc offset by the amount it has changed the rtc.
This leaves the drift rate the same.
Note that I believe hwclock now also estimates the rtc drift rate as
well, so chrony's rtc stuff is of less use now.
I wasn't aware that it now did an automatic estimate? The version I
have doesn't seem to do that, and in any case it would seem to rely on
the box being correctly shutdown for it to update it's drift rate
estimate? Chrony appears to give a realtime update of estimate
Yes, there may be two versions of hwclock running around. A version written by
the original person who wrote hwclock (which includes the drift) and another
version which others have munged and does not include that drift.
The other problem is that the drift rate is highly temperature
dependent.
Sure - remember it's a router that isn't permanently connected to the
internet. We can do the best we can, but clearly it will be imperfect.
Uh, but that means that if the clock is shut down for any period of time, even
the drift corrected time will be many seconds off.
Adjusting for clock drift appears *likely* to be beneficial to accuracy
despite the change in drift between on/off (I get that there exist
situations where this wouldn't be true and likewise I haven't measured
my situation either)
The rtc is pretty temperature sensitive (more so than the system clock-- much
cheaper clock crystal than computer crystal?) And the temp of a computer on vs
off is liable to be 20C.
There is an argument for
not having the rtc stuff in chrony anymore.
I guess I will measure and try to estimate the effect
I would say that there is more of a case for ditching hwclock from init
scripts though?
It is not the problem in the init scripts, but in the halt scripts.
Cheers
Ed W
---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.