Re: [chrony-dev] makestep command sometimes makes chrony stop reading its sources

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Wed, 20 Jan 2010, Hattink, Tjalling (FINT) wrote:

> The tricky part ofcourse is handling the situations where the GPS time
> is not synchronised or when the RTC is way off. So far I've found two
> issues with Chrony regarding these border cases. In this mail I'll
> describe my first issue. The second one will be in the next mail to
> properly separate the discussion of both issues.
>
> What I'm testing is how chrony recovers when the RTC is way off during
> boot. In the bios I adjust the RTC clock with one year. Because Chrony
> is only slewing the clock it would take ages to recover from this
> situation, so I made a script that checks if the offset is too large

chrony already handles this, with the configuration command
initstepslew 30 124.45.6.7
means when chrony starts up, it sends a number of ntp packets to the location
123.45.6.7 and it steps the clock to put the chrony time into sync with that
clock if chrony finds that the system clock ( after being set with rtc) is out
by more than 30 sec.

 You can adjust that 30 to anything you want.

So no need for you to make your own script.


> (more than 30 seconds), and if so, issue a "makestep" command through
> chronyc to chronyd. This command immediately causes the system clock to
> be in sync with the GPS clock. Chrony keeps working fine when I adjust
> the RTC clock back one year in the past in the BIOS, but when I advance
> the RTC clock by one year Chrony stops reading its sources after the
> makestep command. It does not recover anymore. I had this running for 15
> hours and the sources command told me the LastRx was 15h for all
> sources. This problem is reproducable.
>
> I think there are some absolute timestamps used in chrony that are not
> updated when makestep is issued.

I have never seen this, but it needs looking at.


> For now I've solved this issue by completely restarting chronyd after
> issuing the makestep command. It is a drastic measure but at least the
> system recovers from a wrong RTC clock.
>
> If you need more information or you want me to test patches regarding
> this issue, don't hesitate to contact me!
>
> Kind regards,
>
> Tjalling Hattink
>
> For reference, my configuration file looks like this:
>
> # driftfile
> driftfile /mnt/intcfdrive/cache/chrony.drift
>
> # dump measurements dir
> dumpdir /mnt/intcfdrive/cache/chrony.dump
> dumponexit
>
> # allow access from any NTP client
> allow
>
> # set linux hz
> linux_hz 100
>
> # log data
> log tracking
> logdir /mnt/intusbdrive/ntp
>
> # rtc configuration
> rtcfile /mnt/intcfdrive/cache/chrony.rtc
>
> # chronyc security
> commandkey 1
> keyfile /etc/chrony.keys
>
> # reference clocks
> refclock SHM 0 refid SPMC delay 0.1
> refclock PPS /dev/pps1 refid PPSE

--
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.