[ntp:questions] Hints to write a clock driver

Juergen Beisert jbeisert at netscape.net
Mon Jun 1 16:09:49 UTC 2009


Frank Kardel wrote:
> Juergen Beisert wrote:
>> Frank Kardel wrote:
>>>> currently I'm trying to write a clock driver for my selfmade USB
>>>> based DCF77 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 they all 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.
>> 
>> I do not want ntpd to call my driver more than once a second. Polling my
>> USB device is (currently) done in a separate thread.
> 
> Ok - the separate thread would be the first thread in ntpd in Unix (on
> Windows ntpd is running multithreaded). So you enter new terrain here
> especially since ntpd makes use of signals (SIGALM, SIGIO/SIGPOLL). You
> might want to insure that signals are only processed by the main thread.

Oh, thanks for this hint. (/me is now reading all the manpages again...and I
also will think again about the shared memory driver)
 
>>> 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.
>> 
>> Who is called once a second? "struct refclock.clock_poll"?
>> 
> struct refclock.clock_timer
> 
> clock_poll wants to collect a data sample.

Ah, now I understand.

>>> Results are processed as they arrive via the input loop (in Unix-like
>>> environments when the SIGIO/SIGPOLL signal arrives).
>> 
>> Triggered by the serial device for the DCF77 clock drivers for example?
>> Or triggered by the clock driver itself?
> 
> By the serial input or more precisely availability of input data on the
> file descriptor.

Makes sense now. 

Juergen




More information about the questions mailing list