| Re: [chrony-dev] Let the kernel write the sys clock to RTC |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Mon, 17 May 2010, Piotr Grudzinski wrote:
> > > > I would like to use chronyd on a small uClinux based system
> > > > running unattended 24/7.
> > > > The kernel can write the system time to the RTC every 11 minute if
> > > > the clock status ever
> > > > becomes SYNC; but it seems to be intentionally kept UNSYNC by
> > > > chronyd.
> > > > Reading some latest posts, there seems to be some agreement that
> > > > this would be a useful feature.
> > > > Are there any plans to have it implemented?
> > >
> > > Please try the rtcsync directive added in the latest git push. Note
> > > that it can't be used when the normal RTC tracking is enabled.
> > >
> > > --
> > > Miroslav Lichvar
> > >
> >
> > Thanks!
> > Still testing but seems to be working just fine.
> >
> > --
> > Piotr
>
> Running on the same hardware, with this git version of chronyd program,
> the frequency error in chrony.drift stabilizes at about -4ppm.
> With ver 1.24, the error value is 27ppm. It doesn't seem to be right.
> (?)
The drift rate depends both on the crystal frequency AND on the clock
calibration done by Linus at bootup. Until the latest kernels the
calibration
was all over the map, and the clock rate could change by 50PPM between two
bootups. You do not tell us if there was a reboot between the two versions
of
chrony. Nor do you tell us which kernel you are running (not even which
operating system)
It could of course also be a bug in chrony. Pls run the different versions
on
the same system without rebooting it.
After reboot, before running chronyd, the adjtimex command shows the same
result.
/ # adjtimex
mode: 0
-o offset: 0
-f frequency: 0
maxerror: 16384000
esterror: 16384000
status: 64 (UNSYNC)
-p timeconstant: 2
precision: 1
tolerance: 33554432
-t tick: 10000
time.tv_sec: 1274131047
time.tv_usec: 836776
return value: 5 (clock not synchronized)
That is irrelevant. The system thinks it is on time. It is the calibration of
the crystal that the older versions of the kernel had trouble with.
Again which version of the kernel are you running?
And than the drift depends on which version of the chrony I will use. I
?? Does this mean that you run one version of chrony for a few hours, look at
its statistics (chronyc ->tracking) then kill that version of chronyd, and run
the other version of chronyd let it run for a few hours and do
chronyc->tracking using ITS version of chronyc?
always
start with the same chrony.drift file:
Why do you always start with this drift file? How long do you give the system
to settle down? What is your poll interval ( you need to wait at least about
10 poll intervals).
/ # cat /etc/chrony.drift
27.5596 1.5206
--
Piotr
---
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.