[ntp:questions] Hints to write a clock driver
kardel at ntp.org
Mon Jun 1 13:04:55 UTC 2009
Juergen Beisert wrote:
> currently I'm trying to write a clock driver for my selfmade USB
> receiver. Communication works trough the "usblib", there is no kernel
> driver involved. But now I'm in trouble how to forward the time to the
> NTPD. There are various DCF77 drivers in the ntp source tree. But
> are based on a serial device. I have no. I have to poll my USB device two
> times a second.
Hmmm, the basic heartbeat of ntpd is at once per sec. Going faster will
be requiring some work. Also we try to avoid any lengthy synchronous
transactions where ntpd processing is blocked for longer times. Thus an
asynchronous programming model has evolved where the request to the
device are sent via the transmit path or the periodic 1 sec call for
refclocks. Results are processed as they arrive via the input loop (in
Unix-like environments when the SIGIO/SIGPOLL signal arrives). For this
to work the communication library should provide means to facilitate
asynchronous notification or the interactions (request/reply) need to be
short and the timestamping problem (fetching the local time at the
second event) needs to be solved.
> My clock device generates a data set with a reference
> second pulse - synced to/by the DCF signal - and also provides the
> information sent via DCF in 59 bits for the next minute (one bit per
> like the DCF77 signal does, but already filtered and converted to binary
> Is there a way to use anything from the libparse/ directory to let it
> the DCF bit stream, but _not_ registering and using a serial device?
You could extract that code. See libparse/clock_rawdcf.c.
cvt_rawdcf() converts serial 50 baud data to 1/0 sequences - You solved
that already. convert_rawdcf() converts the bit sequence to a time.
> Another question: How does the time flow works? I read
> the "refclock_hopfpci.c" clock driver, as it also does not use a serial
> device. It does something in "hopfpci_poll" (struct refclock.clock_poll).
> But the comment of this function (and in all the other implementations I
> found) is: "called by the transmit procedure". ????? Will this
> called periodically (by ntp)? Or does the clock driver trigger
> let it be called?
See above for the asynchronous I/O model.
> Any hints are welcome.
Another way to do it, is to use the shm driver. Create a program that
controls your device and does the timestamping. This program can feed
ntpd via shared memory with the data. No need to mess with ntpd at all.
See gpsd for an example of an implementation.
More information about the questions