[ntp:questions] PARSE refclock for DCF77

[Matthias Fuchs]

Hi,

I am experiencing strange issues with the PARSE refclock in mode 5.
I have a simple DCF77 recevier connected to a serial port.
In general the refclock works with this setup and ntp syncs.
Since this simple DCF77 receiver is not very reliable the refclock
sometimes receives a wrong date/time. This makes ntpd very unhappy.

Am I right that this refclock driver does nearly no checking
on the received telegrams? Parity checking is not enough for DCF77.
Has anybody experience with this reference clock driver and those
simple DCF77 receivers with NTP?

Matthias

[Rob]

Post by Matthias Fuchs
Hi,
I am experiencing strange issues with the PARSE refclock in mode 5.
I have a simple DCF77 recevier connected to a serial port.
In general the refclock works with this setup and ntp syncs.
Since this simple DCF77 receiver is not very reliable the refclock
sometimes receives a wrong date/time. This makes ntpd very unhappy.
Am I right that this refclock driver does nearly no checking
on the received telegrams? Parity checking is not enough for DCF77.
Has anybody experience with this reference clock driver and those
simple DCF77 receivers with NTP?

It depends on the actual version of the software that you use.

I have seen versions that simply crashed when they receive bad DCF77
data, or that exited with some error message about the offset being
too large. Not good, indeed.

But the version I currently use (4.2.4p5) is not showing any undesirable
behaviour. It seems to ignore incorrect data as it should.

So what is your problem?

Of course you should add a couple of other sources (say 3 internet time
servers) in addition to your DCF77 refclock.

[Rob]

The refclock driver is doing a good job of checking the validity of
each DCF77 'telegram'.
If a telegram is invalid, NTP freewheels until reception improves.

But that surely has not been the case in all versions. Bad things have
happened if trash was received.

So it all depends on the actual version of ntpd in use.

[Matthias Fuchs]

Post by Rob

The refclock driver is doing a good job of checking the validity of
each DCF77 'telegram'.
If a telegram is invalid, NTP freewheels until reception improves.

But that surely has not been the case in all versions. Bad things have
happened if trash was received.
So it all depends on the actual version of ntpd in use.

I expect that you do not really know any more details, right?

I am doing my tests with ntpd 4.2.2p4. Do I expect to much from you
when I ask if this is a "bad" version when using the parse refclock in
mode 5 for a simple dcf77 receiver?

Matthias

[Rob]

Post by Matthias Fuchs

Post by Rob

The refclock driver is doing a good job of checking the validity of
each DCF77 'telegram'.
If a telegram is invalid, NTP freewheels until reception improves.

But that surely has not been the case in all versions. Bad things have
happened if trash was received.
So it all depends on the actual version of ntpd in use.

I expect that you do not really know any more details, right?
I am doing my tests with ntpd 4.2.2p4. Do I expect to much from you
when I ask if this is a "bad" version when using the parse refclock in
mode 5 for a simple dcf77 receiver?

No I don't have a table of ntp versions and their performance...
I would advise to first update the ntpd and then check again.

[Paul.Croome]

Matthias,

I have a similar configuration with a simple DCF77 receiver connected
to the serial interface of an old Sun.

The clockstats show poor signal reception:

refclock_states="*NOMINAL: 27d+16:12:06 (54.58%); NO RESPONSE: 2d
+23:36:07 (5.88%); ILLEGAL DATE: 20d+00:53:58 (39.52%); ILLEGAL TIME:
00:04:24 (0.00%); running time: 50d+16:46:35"

but NTP is ticking happily:

offset=-0.007, frequency=-22.766, jitter=0.539, noise=0.627,
stability=0.000

The refclock driver is doing a good job of checking the validity of
each DCF77 'telegram'.
If a telegram is invalid, NTP freewheels until reception improves.

Paul