[ntp:hackers] refclock_atom.c

Mark Martinec Mark.Martinec at ijs.si
Thu Dec 16 16:37:13 PST 2004


Dave,

> ...In fact, the sequence number checks are superflous, since better checks
> are available. The range gate is designed to reject samples outside of a
> band of 5 ms either side of the next second.

Really?

refclock_atom.c:
#define RANGEGATE    500000 /* range gate (ns) */

Since when is 500.000 ns = 5 ms?!

This now also probably explains why my ntpd with pps from a cheap radio
clock receiver without a local oscillator behaved so inexplicably (the pps 
jitter is somewhere around 2 ms with a reasonably nice normal distribution):

Every time when a radio signal was regained (few times per day
after a loss of about an hour), ntpd would lock on to a pps at some
seemingly random offset of something like two or three ms,
and it would keep near that offset (compared to other sources)
until the next signal loss. The next time some quite different offset
would be chosen and kept during the good reception period.

No wonder: there are always some available sample points within
a +- 2 ms spread that are inside the current capture range of +- 0.5 ms
around some random offset!

Now I bumped up the RANGEGATE  to 6 ms and things
started behaving much more predictably (during last couple of hours).


> You describe a problem that lasts for several minutes - no amount of
> pulse-to-pulse grooming can fix that. What you suggest is called a noise
> gate

Indeed.

> that amounts to puncturing the sequence when the interval between 
> samples is greater than nominal one second. This assumes that the noise
> mechanism is primarily erasures, not large time errors, which would be
> caught by the range gate. I'll see that I can do.

In my case the 'noise' comes in the form of spurious pulses on the pps line.
A noise gate could just as well be triggered by excessive number of pulses.
The range gate does its job well, but it wouldn't hurt to squelch the signal
on this additional information.

> However, your code snip won't work. The driver is polled at nominal
> one-second intervals; however, this is not synchronous with the PPS
> signal. In principle, zero, one or two events could occur between polls.

> Also, since the poll interval does not exactly match the PPS 
> interval, the two intervals will precess past each other and some polls 
> will see zero, one and two PPS increments.

It does happen to work in my case, but I agree that it does not work
well in a general situation (unnecessarily ignores the two-event cases).

This brings up a consideration: every time the two streams of events
switch places, we lose one sample (when sequence count is 2).
If calibrated 'time1' keyword offset is close to zero, this loss of samples
could start to lose valuable information too often.

Wouldn't it be prudent to artificially offset the two streams (when necessary) 
so that the precession would be unlikely? In the hw world of counters and 
clocks and gates this is a usual technique to avoid race conditions.



P.S. keeping old topic warm: this is still apparently not fixed:

> >>from me:
> >>>The atom_start() passes a correct mode (obtained from the mode keyword)
> >>>to the atom_ppsapi(), but then the atom_control() runs, recomputes
> >>>the mode according to its own idea (flag2), and calls atom_ppsapi again,
> >>>clobbering the already correctly configured ppsapi.
> >>
> >>Mark, the atom driver should be fixed.
> >
> >I presume the change hasn't made it to the repository yet
> >  (apart from fixing the uninitialized pointer (pp=peer->procptr))
> >so I'll wait a bit.


And one more:

The rfc2783 only allows the least significant two bits in the 'edge' parameter 
of time_pps_kcbind, the echo and other mode bits are not really allowed:

   The edge parameter indicates which edge of the PPS signal causes a
   timestamp to be delivered to the kernel consumer.  It may have the
   value PPS_CAPTUREASSERT, PPS_CAPTURECLEAR, or PPS_CAPTUREBOTH,
   depending on particular characteristics of the PPS source.  It may
   also be zero, which removes any binding between the PPS source and
   the kernel consumer.

I thinks this would be more politically correct:

--- refclock_atom.c~    Thu Dec 16 21:48:53 2004
+++ refclock_atom.c     Fri Dec 17 01:25:04 2004
@@ -293,3 +293,3 @@
                if (time_pps_kcbind(up->handle, PPS_KC_HARDPPS,
-                   up->pps_params.mode & ~PPS_TSFMT_TSPEC,
+                   up->pps_params.mode & PPS_CAPTUREBOTH,
                    PPS_TSFMT_TSPEC) < 0) {


Mark



More information about the hackers mailing list