[ntp:questions] Meinberg NTP monitor, silly question

David Lord snews at lordynet.org
Wed Dec 23 00:42:21 UTC 2009

unruh wrote:
> On 2009-12-22, David Lord <snews at lordynet.org> wrote:
>> Richard B. Gilbert wrote:
>>> unruh wrote:
>>>> On 2009-12-22, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>>>>> David J Taylor wrote:
>>>>>> "Richard B. Gilbert" <> wrote in message 
>>>>>> news:ZJydnVuvufm1Wa3WnZ2dnUVZ_h2dnZ2d at giganews.com...
>> Yes, I've used chronyd along with ntpd for a while. I've moved
>> desktops and notebooks to chronyd.
>> What chronyd seems not to provide is peering ability with ntpd
>> (or it may be I've never been able to get it working), and up
>> to recently lacked any refclock support.
> Not sure what "peering" ability means. It can certainly use ntpd as a
> server source.  It now has refclock support (shm, socket) and you can
> set up ntpd so that it feeds its refclock output to chrony via the
> socket ( and via the hacked ntpd that M Lichvar has created which uses
> ntpd purely to get the refclock times and feed it to chrony-- so you
> have all of the refclock support that ntpd has.)

If I have two systems with chrony specifying other as peer
in chrony.conf, along with other servers lines, it all works
ok and also systems running ntpd can use the systems running
chrony as servers without problem.

When I've tried with a system running chrony and system
running ntpd with both set as peer for the other, the ntpd
system doesn't appear to see the system running chrony
whilst the chrony system just seems to use the ntpd system
as server. I can't really say I'm suprised at that but if
not just a quirk of my setup it's a significant limitation.

> These are in 1.24-pre1 from chrony.tuxfamily.org

I might give that a try. I'd like to run a radioclock signal
or at least pps to each desktop but don't yet have suitable
hardware for that. Currently MSF (UK 60kHz time signal) is
giving loop summary:
296+/-2123, rms 492, freq -50.5+/- 0.095, var 0.039

That's with 0.5-5V input at serial port and I'm expecting
some improvement with full rs232 levels.

>> For ntpd I've had problems with long periods to come into sync,
>> temperature, system load or network disturbance causing
>> instability. With older systems it was possible to reduce these
>> effects by fiddling system clock frequency to within 10ppm or
>> so, but with most recent software some systems where previously
>> I had ntpd tamed are now back to being unstable due to self
>> calibration putting them 50ppm or more out, but not consistent
>> between reboots, (that isn't due to ntpd, just that it
>> exacerbates the problems and I suspect this will also affect
>> chronyd).
> Yes, a real problem with Linux these days. Chrony takes about 15 min to
> adjust to the new rate, rather than the 10 hours it takes ntpd. 

Sometimes it seems like never, or for longer than I'm willing
to wait. I've had this quite recently with frequency being set
in ever increasing amounts in opposite directions up to over
500ppm when driftfile initially had what should have been a
reasonable starting value, then after a restart it still hit
+/-50ppm but then converged over a day to within 1ppm of
starting value.


More information about the questions mailing list