Discussion:
[chrony-users] ntpd refclock drivers with chrony
Miroslav Lichvar
2017-11-28 17:36:50 UTC
Permalink
There is a new wrapper for refclock drivers implemented in ntpd, which
should allow chronyd to use any refclock supported by ntpd. It's
primarily intended for users with refclocks which are not supported by
gpsd, but if anyone would like to try it with a GPS, it should work
too.

https://github.com/mlichvar/ntp-refclock

Comments, bug reports and pull requests are welcome. It should work
with the latest ntp release (ntp-4.2.8p10). A man page will be added
later.

The command line syntax is similar to the server and fudge directives
of ntpd. Here is an example using the NMEA driver at 115200 bps with
PPS enabled:

# ntp-refclock -s /var/run/chrony-GPS.sock -d -c log \
127.127.20.0 mode 80 time2 +0.5 flag1 1

With the SHM, ATOM and GPSD drivers in ntpd, it seems we now have 13
options how a GPS NMEA+PPS device can be used with chronyd. :)
Currently, I'd not recommend using the ATOM driver as it produces
samples even when the system clock is not synchronized. I don't have
much experience with the GPSD driver.

1) gpsd SOCK
2) gpsd SHM 0 + /dev/pps0
3) gpsd SHM 0 + ntp-refclock 127.127.22.0 (ATOM)
4) gpsd SHM 1
5) ntp-refclock 127.127.20.0 (NMEA) + /dev/pps0
6) ntp-refclock 127.127.20.0 (NMEA) + ntp-refclock 127.127.22.0 (ATOM)
7) ntp-refclock 127.127.20.0 flag1 1 (NMEA with PPS)
8) gpsd + ntp-refclock 127.127.28.0 (SHM) + /dev/pps0
9) gpsd + ntp-refclock 127.127.28.0 (SHM) + ntp-refclock 127.127.22.0 (ATOM)
10) gpsd + ntp-refclock 127.127.28.1 (SHM)
11) gpsd + ntp-refclock 127.127.46.0 (GPSD) + /dev/pps0
12) gpsd + ntp-refclock 127.127.46.0 (GPSD) + ntp-refclock 127.127.22.0 (ATOM)
13) gpsd + ntp-refclock 127.127.46.0 mode 1 (GPSD with PPS)
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Rob Janssen
2017-11-28 18:20:10 UTC
Permalink
Post by Miroslav Lichvar
There is a new wrapper for refclock drivers implemented in ntpd, which
should allow chronyd to use any refclock supported by ntpd.
The examples al refer to gps but this should work with refclock 8 (parse) too, right?
I have a DCF77 receiver connected to a serial port that I used with ntpd and is not supported in chrony.

Rob
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Miroslav Lichvar
2017-11-28 18:37:45 UTC
Permalink
Post by Rob Janssen
Post by Miroslav Lichvar
There is a new wrapper for refclock drivers implemented in ntpd, which
should allow chronyd to use any refclock supported by ntpd.
The examples al refer to gps but this should work with refclock 8 (parse) too, right?
I have a DCF77 receiver connected to a serial port that I used with ntpd and is not supported in chrony.
Yes, all drivers should work, at least in theory. I have not tested
the PARSE driver. If you try it, please let me know how it works. The
SOCK refclock probably should be configured with "poll 6 filter 1", as
there is only one sample per minute.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Rob Janssen
2017-11-28 19:52:18 UTC
Permalink
Post by Miroslav Lichvar
Post by Rob Janssen
Post by Miroslav Lichvar
There is a new wrapper for refclock drivers implemented in ntpd, which
should allow chronyd to use any refclock supported by ntpd.
The examples al refer to gps but this should work with refclock 8 (parse) too, right?
I have a DCF77 receiver connected to a serial port that I used with ntpd and is not supported in chrony.
Yes, all drivers should work, at least in theory. I have not tested
the PARSE driver. If you try it, please let me know how it works. The
SOCK refclock probably should be configured with "poll 6 filter 1", as
there is only one sample per minute.
It logs this message regularly:

ntp-refclock[13791]: PARSE receiver #0: local_receive: bad size (got 1 expected 480)

also it sometimes logs:

ntp-refclock[13791]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 37 bits

which is quite normal for this refclock, it happens when a pulse is missing due to interference.

I have also got this message:

ntp-refclock[12400]: parse: convert_rawdcf: start bit / parity check FAILED for "--##---##-#-#--R---Ls12--1-4p1-----P1---1-1-4-2---1248-2--p?"

That is another receiver error indication and it would seem to indicate that things are at least partially working.
My DCF77 reception is not very solid (also wasn't with ntpd) so a bit too early to say it does not work at all.

Rob
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Miroslav Lichvar
2017-11-29 17:48:53 UTC
Permalink
Post by Rob Janssen
Post by Miroslav Lichvar
Post by Rob Janssen
The examples al refer to gps but this should work with refclock 8 (parse) too, right?
I have a DCF77 receiver connected to a serial port that I used with ntpd and is not supported in chrony.
Yes, all drivers should work, at least in theory. I have not tested
the PARSE driver. If you try it, please let me know how it works. The
SOCK refclock probably should be configured with "poll 6 filter 1", as
there is only one sample per minute.
ntp-refclock[13791]: PARSE receiver #0: local_receive: bad size (got 1 expected 480)
Thanks. This is helpful. The PARSE driver is different from the other
drivers in that it uses a "direct" input. It seems there were at least
two bugs in ntp-refclock related to that.

Could you please pull from git and try again?
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Rob Janssen
2017-11-29 18:57:06 UTC
Permalink
Thanks. This is helpful. The PARSE driver is different from the other drivers in that it uses a "direct" input. It seems there were at least two bugs in ntp-refclock related to that. Could you please pull from git and try again?
Ok now it is better!

2017-11-29T19:55:00.221331+01:00 linux ntp-refclock[6883]: PARSE receiver #0: STATE CHANGE: -> TIME CODE; (LEAP INDICATION; CALLBIT)
2017-11-29T19:55:00.221586+01:00 linux ntp-refclock[6883]: PARSE receiver #0: SYNCHRONIZED

chronyc sources
210 Number of sources = 9
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#* PPS 0 4 377 14 -122ns[ -234ns] +/- 215ns
#? DCF 0 6 1 9 -421us[ -421us] +/- 43ns
(and a couple of network sources)

Rob
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Bill Unruh
2017-11-29 02:01:17 UTC
Permalink
It seems to be superfluity of ways to connect. I suspect users are going to
want some guidance as to which would be better to use. Criteria are probably
ease of setting up and use
accuracy of clock discipline.
computer resources needed.

Also, one might want to separate the nmea use from the pps use. They are
really independent, with nmea having pretty shitty timing (10s of ms rather
than microseconds) which might be OK for some, but for accuracy is useful only
for getting the conting of the seconds for the pps.

I have not tested the various pps timing methods. I am using pps-ldisc myself
even though I know that the serial port is slower at responding to an
interrupt than is the paralled port (unfortunately almost nothing has a
parallel port anymore). I have not tested gpio vs serial port. and my parallel
port tests are 20 years old by now.




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 |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
Post by Miroslav Lichvar
There is a new wrapper for refclock drivers implemented in ntpd, which
should allow chronyd to use any refclock supported by ntpd. It's
primarily intended for users with refclocks which are not supported by
gpsd, but if anyone would like to try it with a GPS, it should work
too.
https://github.com/mlichvar/ntp-refclock
Comments, bug reports and pull requests are welcome. It should work
with the latest ntp release (ntp-4.2.8p10). A man page will be added
later.
The command line syntax is similar to the server and fudge directives
of ntpd. Here is an example using the NMEA driver at 115200 bps with
# ntp-refclock -s /var/run/chrony-GPS.sock -d -c log \
127.127.20.0 mode 80 time2 +0.5 flag1 1
With the SHM, ATOM and GPSD drivers in ntpd, it seems we now have 13
options how a GPS NMEA+PPS device can be used with chronyd. :)
Currently, I'd not recommend using the ATOM driver as it produces
samples even when the system clock is not synchronized. I don't have
much experience with the GPSD driver.
1) gpsd SOCK
2) gpsd SHM 0 + /dev/pps0
3) gpsd SHM 0 + ntp-refclock 127.127.22.0 (ATOM)
4) gpsd SHM 1
5) ntp-refclock 127.127.20.0 (NMEA) + /dev/pps0
6) ntp-refclock 127.127.20.0 (NMEA) + ntp-refclock 127.127.22.0 (ATOM)
7) ntp-refclock 127.127.20.0 flag1 1 (NMEA with PPS)
8) gpsd + ntp-refclock 127.127.28.0 (SHM) + /dev/pps0
9) gpsd + ntp-refclock 127.127.28.0 (SHM) + ntp-refclock 127.127.22.0 (ATOM)
10) gpsd + ntp-refclock 127.127.28.1 (SHM)
11) gpsd + ntp-refclock 127.127.46.0 (GPSD) + /dev/pps0
12) gpsd + ntp-refclock 127.127.46.0 (GPSD) + ntp-refclock 127.127.22.0 (ATOM)
13) gpsd + ntp-refclock 127.127.46.0 mode 1 (GPSD with PPS)
--
Miroslav Lichvar
--
with "unsubscribe" in the subject.
with "help" in the subject.
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Loading...