[ntp:hackers] Questions on refclock to ntpd interface

Hal Murray hmurray at megapathdsl.net
Mon Aug 20 05:40:41 UTC 2007


I'm trying to understand how refclock drivers do and/or should work.

I'm interested in the case where the device automatically sends a packet 
every second.

Take the NMEA driver for example.  Assuming the device is setup correctly 
(aka send every second), the normal case goes like this:

  Each second, the receive routine gets called with a new packet.  It calls 
refclock_process to add the new sample to a fifo.

  When the poll routine gets called, it just sets a flag.

  The next time the receive routine is called, it notices the flag and calls 
refclock_report to actually process the data in the fifo.


Is there a reason to shift the call to refclock_report from poll to receive?  
Is there some magic I don't know about in the context?  Am I only allowed to 
call refclock_report from receive routines and not from poll routines?

Doing that context switch looks like an unnecessary complication to me, but 
maybe that's just the way my head works.  The poll routine has to handle the 
timeout case anyway, so you have to flip between two chunks of code to figure 
out what's going on.


The comment at the top of the poll routine says:
   * We go to great pains to avoid changing state here, since there may be
   * more than one eavesdropper receiving the same timecode.
That looks interesting, but I can't figure out what it means and/or what 
problem it is avoiding.

There is only one thread.  Right?  I think there is a signal when a packet 
arrives, but I think this level of code is protected from that sort of 
complication.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.





More information about the hackers mailing list