ntpsec: reference driver 38/hopf 6021
m-ntp at kotzan.net
Tue Jul 5 20:22:14 UTC 2016
On 2016-07-05 11:32, Eric S. Raymond wrote:
> Looking over old email, I find I may have made a mistake. A few weeks
> ago I
> discovered that the generic driver supports the Hopf 6021 - it's
> subtype 12.
> Accordingly, forgetting that I had received this request, I deleted the
> dedicated Hopf 6021 driver.
> The dedicated 6021 driver can be restored, but I would prefer not to do
> if generic subtype 12 works. Parse drivers are smaller and better
> than the standalone ones - the right direction is to move code into the
> generic driver, not out.
> Martin, would you please test that generic mode 12 on a 6021?
I tested a Hopf 6855 with ntp classic (4.2.4p3), but the test clock was
connected to an antenna (normal for our test systems), so the output
byte contains a few bits marking the clock source as "crystal operation"
(the Hopf clock guarantees high accuracy during reception outages).
The Hopf driver can be configured to ignore this, the PARSE driver has a
more advanced method for this feature that doesn't work for crystal-only
Relevant snippet of ntp.conf with the HOPF driver:
fudge 127.127.38.1 flag1 1"
=> Ok .
Same for the PARSE driver:
"server 127.127.8.1 mode 12
fudge 127.127.8.1 time2 1000000000 flag1 1"
=> No sync, "reach" is zero. I added the fudge values time2 and flag1 to
the driver accept unconfirmed time values , but as documented they
only work if sync is lost during runtime.
The parameters are parsed successfully (log message
"PARSE receiver #1: new trust time 11574d+01:46:40"), but there is no
effect on sync.
The serial connection is working fine:
ntpq -c clocklist
assID=0 status=0404 clk_badsignal, last_clk_badsignal,
device="HOPF 6021", timecode="\x024A125340050716\x0a\x0d\x03", poll=12,
noreply=0, badformat=0, baddata=1, fudgetime1=0.000, stratum=0,
refclock_time="db262c54.00000000 Tue, Jul 5 2016 12:53:40.000",
refclock_status="TIME CODE NOT CONFIRMED; UTC DISPLAY; TIME CODE",
refclock_format="hopf Funkuhr 6021",
refclock_states="*PROPAGATION DELAY: 00:12:08 (99.86%); ILLEGAL DATE:
00:00:01 (0.13%); running time: 00:12:09"
I assume the normal case with the clock attached to an antenna will
do you want me to test that? I should be able to find a test system for
sometime next week.
Documentation of flag parameter:
flag1 0 | 1
When set to 1, driver sync's even if only crystal driven.
If flag1 is 0, time2 specifies the offset of the PPS signal from the
time (PPS fine tuning). If flag1 is 1, time2 specifies the number of
receiver with a premium local oscillator can be trusted after losing
More information about the devel