| Re: [chrony-users] Requesting some insight regarding preferred servers and RTCSYNC/RTCFILE |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
With bad sources, chrony cannot give good time. RTC tends to be bad -- it can
have large drifts (100 PPM is not unheard of which would put it out be seconds
per day, which would just grow on successive reboots). Inaccessible locations
also suggests to me varying temperatures which would make the above worse
(more unpredictable). And in specific, the various rtcs on the various devices
are apt to have wildly different drift rates.
You say it only may be connected to the internet. Thus your pool sources are
highly unreliable. You do not say what the source DUM1 is. Is it anything?
You do not say how your system can query other devices on the lan.At present
it is either the internet, the unkown source DUM1, or the RTC.
It does not query any of the other devices. You need to put a reliable source
of time onto the lan, and have the machines query that, or those (eg have
three GPS disciplined devices on the lan and have the machines query those.
On Mon, 29 Oct 2018, Martin Janse wrote:
Hi all,
I have recently taken over the development of an embedded project. It runs a custom Linux build
on a Colibri T30 system, including Chrony.
The device has an RTC on-board and is also connected to a LAN with multiple of the device.
However, the LAN is not necessarily connected to internet.
The main purpose of the device is monitoring and logging, applying some statistical analysis on
data and wrapping it into accessible data formats. For this purpose, somewhat accurate time (a
few minutes off max) is necessary. The devices are placed in hard-to-reach locations and should
be able work autonomously for years at a time. The devices can reboot on a moments notice with
unknown intervals, at least once every 48 hours.
The device with its current settings seems to work as expected but I have my doubts that the
device is really working as expected or if it just seems to be close enough. I have two main
concerns I would like to have straightened out that I could not clearly do away with by reading
the manual and some installation guides. The current configuration file is as follows:
refclock SOCK /var/run/chrony.DUM1.sock refid DUM1
refclock SOCK /var/run/chrony.RTC.sock refid RTCC delay 1e-3
pool 0.nl.pool.ntp.org iburst
pool 1.nl.pool.ntp.org iburst
pool 2.nl.pool.ntp.org iburst
pool 3.nl.pool.ntp.org iburst
allow all
manual
local stratum 10
makestep 300 -1
logdir /var/log/chrony
log measurements statistics tracking refclocks rtc
logchange 60
cmdallow 127.0.0.1
pidfile /var/run/chronyd.pid
My first concern lies with the RTC. In the current configuration, neither RTCSYNC nor RTCFILE
are defined. Does Chrony still correct the system time while it's running? Or only at boot? Or
never?
Secondly, a new feature needs to be added to the system. Other than syncing to the RTC or other
devices on the network, an NTP server needs to be added that has precedence over any other
source. I saw in the manual that the parameter 'prefer' can be added to the server, causing
Chrony to prefer that server. However, is there a scenario where Chrony still picks a
non-preferred source? Is there a degree of 'quality' that the preferred server needs to have in
order to have guaranteed precedence?
I understand that the current configuration is not exactly 'as it should be'. The development
of this embedded system was really messy and the engineer who made this is no longer working
for the company. He left no documentation behind on this part, so I can only guess what exactly
the reasons were for setting stratum to 10 or the makestep to -1. But I don't want to change
anything that is not necessary because failure of logging is unacceptable.
If anyone can address my concerns and/or explain why this configuration works, I would be very
grateful.
kind regards,
Martin Janse