| RE: [chrony-dev] makestep command sometimes makes chrony stop reading its sources |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Thu, 21 Jan 2010, Hattink, Tjalling (FINT) wrote:
On Wed, Jan 20, 2010 at 10:50:39AM +0100, Hattink, Tjalling (FINT)
wrote:
So far the results are very good under normal conditions. When a
properly synchronised SHM and PPS clock is provided and the rtc clock
was already somewhat in sync the system converges in minutes after a
cold boot! Also temperature changes are corrected a lot faster by
Chrony than normally done by ntpd. Sometimes ntpd was off for
milliseconds for hours when the temperature increased with 5 degrees,
but Chrony was only drifting 300 nSec for half an hour.
Just curious, what vendor/model is the GPS card and what std dev is
reported in sourcestats in normal conditions?
The GPS card is a commercial grade board from NovAtel, type OEMV3. It is
used for high-precision positioning on survey boats. According to specs
its time accuracy is 20 ns RMS. What I see in chronyc for the PPS signal
is a std dev of around 140 ns.
chrony works only with microseconds, not nanoseconds. Thus it cannot
discipline to better than a microsecond, even if the dispersion reads less
than that.
All of chrony is designed with 1usec as the quantization limit.
Please note that currently chrony can't slew below microseconds, so
even
when the reported std dev is very low, the real offset can't be better
than 0.25 us on average. (the remaining offset is reported in the
tracking
output).
I have to correct myself. Chrony was drifting 300 uSec for half an hour,
not 300 nSec ! I have to say that the system clock on this system is
really
bad. On other systems I've seen it drifting for only 100 uSec for 10
minutes.
?? Not sure what you mean by "was drifting 300usec"? drifting usually refers
to rate of change. Do you mean chrony time was offset by 300usec which then
decayed to aroung 1usec?
I use a separate pc that reads out the ntp time from chrony every second
and compares it with its own PPS corrected time using a in-house
developed
application used for timekeeping our systems. It is quite precise and it
shows a std dev of 10 uSec for the ntp time for chrony.
I suspect that the "read out time" makes for most of that.
I think there are some absolute timestamps used in chrony that are
not
updated when makestep is issued.
Correct, the timestamps used in scheduler aren't updated when makestep
is
performed. The problem is that scheduler needs to use raw time (unlike
pretty much everything else in chronyd) and adjusting only raw time
isn't
reported by the ParameterChange system.
Probably the easiest fix is to move the makestep code from system
drivers
where it goes unnoticed to local module and do two adjustments, one to
cancel the remaining slew and second to do the actual step. This also
makes
the makestep command available on all systems.
Please try the attached patch.
I'll try the patch and let you know of the results today.
---
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.