[LinuxPPS] [PATCH 02b/12] PPS: Make pps_event capturing lockless.

[Hal V. Engel]

On Wednesday 11 February 2009 12:17:22 am Bernhard Schiffner wrote:
> On Tuesday 10 February 2009 22:59:53 Hal V. Engel wrote:
> > On Tuesday 10 February 2009 01:25:00 am Bernhard Schiffner wrote:
> > > On Tuesday 10 February 2009 04:57:48 George Spelvin wrote:
> > > > Rather than using spinlock mutual exclusion between pps_event
> > > > and PPS_FETCH, store captured timestamps into a circular buffer
> > > > and atomically update the sequence number to publish them to
> > > > PPS_FETCH.
> > > >
> > > > This technically has a race if more than 5 pps_events of a single
> > > > type arrive during one PPS_FETCH; given a typical 1 Hz rate, is that
> > > > really likely?
> > >
> > > (general)
> > > pps does timestamp interrupts.
> > > It's regular use is real "PPS". But it'is not limited to this.
> > >
> > > (more then5 events)
> > > PPS-events derivated form TAI (as in GPS-receivers) are very close
> > > together in their slopes  (<1µs).
> >
> > Some will be well under 100 nanoseconds and some of the better devices
> > are closer to +-10 nanoseconds.
> >
> > > If you want this accuracy it makes no sense to use more then one
> > > (reliable) source.
> > > If you use two similar sources their respective interrupts block each
> > > other (a "long" time, ca. 30 µs) before getnstimeofday() can happen.
> > > This does not improve accuracy...
> > > So 5 "parallel" events should be ok FAPP.
> > >
> > > Bernhard
> >
> > Some devices like the Oncore GPS allow us to have the PPS signal offset
> > from actual time by a user specified amount for each device to avoid the
> > issue with multiple devices causing interrupt collisions.  Even under
> > those circumstances using more than 5 reference clocks seems like a real
> > stretch and is probably highly unlikely.
> >
> > Hal
>
> Thanks for this comment.
> (Your are the first mentioning this nice feature. Do you have data what is
> a needed shift between two clocks? (My setting is +100µs.)

I have not used this feature yet so I can't answer how large the shift needs 
to be.  But it only needs to be large enough to allow for the interrupt 
handler to complete it's work before the next PPS pulse for that logical epoch 
occurs.  This seems like it is machine dependent to me but when I get around 
to trying this I will likely use offsets that are several milliseconds since 
this will for sure prevent contention and the actual setting does not actually 
matter as long as ntp is correctly configured for this.  

>
> The problem will be solved at an other level. Rodolfo said that a certain
> peace of code should be without (visible) problems by design. And he is IMO
> right.

Although I agree that systems like this should be correctly designed I don't 
know if this issue can be fixed by the PPS code since resource contention like 
this is really a hardware issue.  So the contention needs to be removed at the 
hardware level somehow.  This either requires some type of per-device hardware 
that captures the clocks time (IE. specialized PPS specific time hardware) or 
the PPS pulses need to be separated. 

Another related issue is serial ports that share an interrupt.  On my system I 
have a motherboard serial port and a serial card with 4 additional ports.  The 
motherboard serial port is on interrupt 3 but the all the serial ports of the 
add in card are using interrupt 19.  If two clocks were attached to the serial 
ports with the shared interrupt and if the PPS pulses were not separated by a 
significant interval this could result in lost interrupts which would likely 
be worse than momentarily blocked interrupts. 

>
> (But it's definitly something nice to play with two or more clocks and
> different input paths.)
>
> Bernhard