[ntp:questions] Re: Jonathan Buzzard's radioclkd and FreeBSD
ntp-200203 at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Sun Nov 9 11:47:27 UTC 2003
[Valid address above works over IPv6 only, when I'm online, and then only
from certain sites, not including yours, hajo]
Hejsa Hans Jørgen,
> > On Thu, 6 Nov 2003 22:57:17 +0000, Chris Hastie wrote:
> > Has anybody out there managed to compile Jonathan Buzzard's radioclkd
> ><http://www.buzzard.org.uk/jonathan/radioclock.html>. Since I live only
> > 30Km from the MSF transmitter I thought I'd give it a go, but gmake
> > gives up saying "*** [radioclkd.o] Error 1"
> I had trouble too and have made some modifcations:
I've heavily hacked it, and sometime during my copious offline time, I
should clean up my hacks (now that I know a bit more about what I was
trying to do) and post them for general perusal... Especially if there
> As I only have one clock (DCF type) I didnt try to have the decoding
> on cts and dsr survive.
I haven't worked on the latest version, but I did hack the FreeBSD
kernel to not only give me PPS ioctl times from the DCD line, but also
from the RI, CTS, and DSR lines, so I have four clocks (all DCF77)
connected to one serial port. Rather than do multi-clock decoding,
I run four instances of radiockld, one for each data status line.
I still have to use polling, since I gave up on hacking to notify a
status change via interrupt a la Linux. But at least the start-of-
second timing is accurate, without taking too much system time polling.
I also used the parallel port nACK pin, but never really tried to
get that working with interrupts too. Or getting other parallel port
pins to allow me multiple clocks. I give up easily. Also, the machine
whose parallel port I was hacking exploded, so I've had to turn my
attention to more vital matters like its replacements.
> 2) I have made some DCF specific filtering of the input to remove
> spurious pulses. This might disable other non dcf decoding.
I added a few sanity checks, plus auto-polarity detection for DCF,
but spurious pulses had never been a serious problem for me, though
I'm not as far removed from Mainflingen as you are. Whether the
auto-polarity detection might also work for other than 100/200msec
signals, I haven't looked at the other clock pulse formats to guess.
One other change I made to ntpd because of the radioclk program and/or
the GENERIC driver, was to be more tolerant of wildly-off time data,
and instead of exiting when it decides to trust a jump of, say, 3600
seconds (often seen induced by lightning), it continues running in
hopes the next data will be better. This has saved me several times
when ntpd would have bailed needlessly.
I also added PPS updating of the shared memory segment, greatly
reducing the jitter, and allowing ntpd to use accurate time data
at minpoll of 16 seconds, plus whichever option nabs several samples
to smooth the data.
The code also compiles and works under NetBSD (haven't tried any
other BSDen). I haven't tried to see what I need to do to get mlockall()
added somewhat recently to FreeBSD 5 to work -- I recall there being
some ntpd-related problems with that a while ago with the FreeBSD
implementation, that probably are fixed, I hope.
I've been running my hacked code with no problems for quite some time,
as can be seen by poking ntp.nospam.dyndns.dk (over IPv6 only)...
remote refid st t when poll reach delay offset jitter
+GENERIC(0) .DCFa. 0 ? 11 16 377 0.000 -0.005 0.197
oPPS(1) .PPS. 0 ? 11 16 377 0.000 0.034 0.085
LOCAL(2) LOCAL(2) 9 ? 20 64 377 0.000 0.000 0.015
+SHM(0) .DCFa. 0 ? 10 16 377 0.000 -0.008 0.142
+SHM(1) .dcf2. 0 ? - 16 377 0.000 0.711 1.104
xSHM(2) .ALDI. 0 ? 7 16 377 0.000 -0.904 1.587
xSHM(3) .dcfB. 0 ? 11 16 377 0.000 -5.360 0.987
As you can see, the SHM(0) clock figures are comparable to the same
DCD-pin data defrobricated by the GENERIC PPS-enabled driver, which
also supplies the better-filtered PPS refclock data seen above. The
other two clocks are less well-tuned to the signal, and in fact SHM(3)
is the same as SHM(2) with the serial pin tied between the two lines,
with offset tuned for a different clock. The higher jitter seen is a
function of the clock quality, as I could easily swap a known-better
clock in for better-looking numbers.
My code is based on 0.7, FWIW. My FreeBSD hacks were based on 4.5.
I need to get on the ball and hop into the 20th century sometime RSN.
To the original poster, your first compilation failure was due to the
lack of a few include file hacks. I can post those separately from
my other bug^H^H^Hfeature-inducing hacks, so you can apply only what
you need to get the thing to work for you. Also, others may want to
go over my hacks with a rototiller before letting them into their code.
will mutilate code for beer
More information about the questions