Re: [chrony-users] RTC Trimming Issues

[John.Florian@xxxxxxxx]

Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote on 10/30/2012
11:32:00:
> 
> On Tue, 30 Oct 2012, John.Florian@xxxxxxxx wrote:
> 
> > Ed W <lists@xxxxxxxxxxxxxx> wrote on 10/29/2012 18:03:36:
> >>
> >> On 29/10/2012 21:01, John.Florian@xxxxxxxx wrote:
> >>
> >> Any ideas how to get these RTCs to do the right thing and
join us in
> >> this decade?
> >>
> >>
> >> Fun problem!
> >
> > I'm glad you think so and thank you for responding!
> >
> >
> >> Out of curiousity, have you taken one dodgy machine, logged
in and
> >> figured out of it's a problem setting the RTC, or with it
*staying* set?
> >>
> >> eg
> >> - run "trimrtc", then after a few seconds do you
see the correct
> >> date with "rtcdata"?
> >
> > Nope.
> >
> > chronyc> password SuperSecretSquirrelSauce
> > 200 OK
> > chronyc> rtcdata
> > RTC ref time (UTC) : Wed Jan  1 00:05:05 2003
> > Number of samples  : 0
> > Number of runs     : 4
> > Sample span period :    0
> > RTC is fast by     : -310217856.000000 seconds
> > RTC gains time at  :    17.773 ppm
> > chronyc> trimrtc
> > 200 OK
> > chronyc> rtcdata
> > RTC ref time (UTC) : Wed Jan  1 00:05:05 2003
> > Number of samples  : 0
> > Number of runs     : 4
> > Sample span period :    0
> > RTC is fast by     : -310217856.000000 seconds
> > RTC gains time at  :    17.773 ppm
> > chronyc> rtcdata
> > RTC ref time (UTC) : Wed Jan  1 00:05:05 2003
> > Number of samples  : 0
> > Number of runs     : 4
> > Sample span period :    0
> > RTC is fast by     : -310217856.000000 seconds
> > RTC gains time at  :    17.773 ppm
> > chronyc> ^D
> 
> I have always had trouble getting trimrtc to work. I usually do it
4 or 5
> times in a row, and sometime log out of chronyc in between. This hasbeen
true
> from way back (I'd say 10 years ago). The problem is that the rtc
on most
> machines is a hardware mess. There used to be a ubiquitous chip, butnow
there
> is hpet and various other versions, and the interrupts from the rtc
have been
> destroyed, leaving it as a mess. One feature of chrony is that it
can even use
> a totally broken rtc by recording the offset and drift of the rtc
for future
> use to set the system clock correctly.

I was afraid it was going to come down to something
like this.  Still seems odd that it works on most of these units.
 I guess that just means that it can work, but is dependent on some
condition that doesn't always hold constant for all units.


> > So this would indicate that the write to
the RTC is failing, right?  Even
> > if that's true (which sounds bad), shouldn't the "RTC ref
time (UTC)" be
> > advancing forward?
> 
> Why? The rtc is ticking and utc is ticking at approx the same rate.

I thought about that as being a possible behavior
.... since I really wasn't sure what I should be seeing.  I made that
statement after looking into another unit that was working correctly and
found that the value on that unit *was* advancing forward like the wall
clock.

> >> - if you stop chrony, does hwclock show the correct time
in the RTC?
> >
> > It's been awhile since I last dug deep into this, so I don't
recall
> > hwclock behavior well, but this looks fishy:
> >
> > # systemctl stop chronyd.service
> 
> No need to stop chrony.

I had done this in accordance to Ed having said, "-
if you stop chrony, does hwclock show the correct time in the RTC? "

 
> > # hwclock --show
> > hwclock: select() to /dev/rtc to wait for clock tick timed out:
Success
> > # hwclock --show
> > hwclock: select() to /dev/rtc to wait for clock tick timed out:
Success
> 
> All right, the rtc is not working. You now know that it is not chrony,
but the
> rtc on your system that is at fault.

Something I have since learned is that if I run hwclock
--show while chronyd is running, then I instead get a message like:
Tue 30 Oct 2012 10:46:02 AM EDT  -0.997601 seconds
                     
                     
                     

I don't know why hwclock --show behaves this way.
 When chronyd is not running, hwclock gives me a timed out message
which is a success?!?  Yet when it is running, I see a value that
presumably tells me what's presently stored in the RTC.


--
John Florian