[LinuxPPS] Feedbacks

[Remco den Besten]

Hello Bernard,

Although a bit off topic, but perhaps soon 'hot': 'an auto time1 fudge 
generator for rubidium standards in
conjunction with an analogous refclock like DCF' (or something like that. 
Hmmm should be nice if the ATOM refclock
has such an option: read the mean offset from a certain refclock and use 
that as the time1 fudge when you have
accurate PPS's not locked to UTC epochs, like my Rb87 standard :-)

Concerning DCF(a).:

remco at helium [/home/remco]> peerstats
       ident     cnt     mean     rms      max     delay     dist     disp
==========================================================================
127.127.30.0    1409   -0.001    0.006    0.017    0.000  439.091    2.453
127.127.8.1      345    0.129    0.171    0.533    0.000    1.020    0.995
*snip*

Of course, 8.1 being the DCFa and 30.0 the Oncore (which behaves 
significantly better than my Rockwell Jupiter
by the way *but* I discovered this morning that ntpd sometimes syncs to my 
DCFa clock, although the Oncore is preferred
in ntp.conf (?) :

16 Apr 12:01:23 ntpd[30349]: synchronized to GENERIC(1), stratum 0
16 Apr 12:02:35 ntpd[30349]: synchronized to GPS_ONCORE(0), stratum 0
16 Apr 12:13:55 ntpd[30349]: synchronized to GENERIC(1), stratum 0
16 Apr 12:18:06 ntpd[30349]: synchronized to GPS_ONCORE(0), stratum 0
16 Apr 18:22:43 ntpd[30349]: synchronized to GENERIC(1), stratum 0
16 Apr 18:23:41 ntpd[30349]: synchronized to GPS_ONCORE(0), stratum 0

)

I first used radioclkd2 because this driver also handles MSF and I obtained 
accuracies within +/- 2 ms.
Recently I tried Frank Kardel's parse_clock driver as this driver claims to 
be fully compliant with PPSAPI's like
LinuxPPS..
However, I run my DCF in mode 5. I did not experiment with PPS on the same 
interface yet (mode 133).

Concerning the fudge/time1 offset for the DCF receiver: with radioclkd2 I 
used a time1 of 0.0268 (26.8 ms).
With the parse driver my time1 is 0.2154. I tuned it by hand. However, I 
cannot understand 215.4 ms (Mainflingen
is not *that* far away from me, concerning the speed of light ;-).

For example, I can tweak it a little more, as the offset is averagely 0.129 
ms to high (see above). So, perhaps next
time I have to start ntpd I will try a time1 of 0.215271 (or 0.2153) and see 
what the accuracy will be after a while.

So.. your initial guess of 210 ms is suspicously accurate!

I experience that Kardels parse_clock behaves better or somewhat more 
'relaxed' than radioclkd2, also when you look at the amount of interrupts 
generated every second. With driver 8 mode 5 it is 1 interrupt/DCF-pulse 
(and thus 1 interrupt/sec and
not in the last second of the minute), while with radioclkd2 two (and I 
noticed even three on one system) interrupts
are created. My feelings are that when you have several interrupts every 
tick, there is more dispersion.

Franlky, the quality of my ntpd with DCFa only is more than enough for the 
ntp.pool.

FYI, this is my current ntpq -p:
remco at helium [/home/remco/ntp-dev-4.2.5p113/ntpd]> ntpq -p
     remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
*GPS_ONCORE(0)   .GPPS.           0 l    4   16  377    0.000   -0.003 
0.001
+GENERIC(1)      .DCFa.           0 l   23   64  377    0.000    0.093 
0.099
+ptbtime1.ptb.de .PTB.            1 u    6   64  377   32.296    0.704 
0.857

Regards,

Remco

> Remco,
>
> a .DCFa. with less then 1 ms offset is very good. (It's quasi suspicious.)
> Can you tell me your fudgetime for this receiver please?
> My guess is about 210 ms?
> Did you "tune" this fudgetime by hand?
>
> Gratulations doing the oncore!
>
> Bernhard