On Mon, Dec 13, 2021 at 6:56 AM Poul-Henning Kamp phk@phk.freebsd.dk wrote:

"It is painfully obvious that the interrupt latency is the dominant
noise factor in PPS timestamping in the second case."

This is exactly what I found when I did this 15 years after your
paper.  Though what I think is more interesting, is that despite using
15 years newer hardware, the resulting PPS precision ends up being
nearly the same for both timestamping methods.  Your final graphs are
very similar the one I have tried (succeeded?) at posting, other than
you using a time series I used a histogram.

This issue of interrupt latency is one place where cooperative RTOSes (as
opposed to preemptive ones) have a clear advantage.

The reason is that since context switching is explicitly called out
(cooperative) instead of it happening at the interrupt level (preemptive),
in a cooperative RTOS, the only latency is the MCU's own interrupt handling
mechanism.

So if you have nested interrupts, you just "punch through" immediately to
the interrupt you want/need to service (no need to manage the context
switching register saves, etc.). If no nesting, then you do have to wait
until the currently-being-served ISR is finished. But good coding practices
and careful choices of priorities can reduce these issues to times much
smaller than 500us (that's forever!). I could see easily reaching < 1us
jitter in a PIC24EP MCU, I suspect you could get to 100ns pretty easily
when running the MCU at 60MHz.

Disclaimer: I'm the author of a proven cooperative RTOS called Salvo
http://www.pumpkininc.com/(TM)  -- the User Manual
http://www.pumpkininc.com/content/doc/manual/SalvoUserManual.pdf (that I
wrote eons ago) has a lot of background material. It's been very surprising
to me (and to Salvo users) how little you end up giving up when going to a
cooperative scheduler (in constrained, but not uncommon applications). I
can guarantee that the presence of the Salvo RTOS on an MCU can (when
properly applied) have ZERO instruction cycles of impact on the operation
of the MCU's interrupt handler (and I use this to great effect in my
embedded coding).

--Andrew

Andrew E. Kalman, Ph.D.

On Mon, Dec 13, 2021 at 12:19 PM Trent Piepho tpiepho@gmail.com wrote:

Andrew Kalman writes:

Which, as I explained earlier in the thread, is increasingly rubbish
on any high-end platform these days because it is gone "soft" and become
a message-passing phenomena across several clock domains etc.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

I wrote something this evening that just busy-loops waiting for a
raising edge and then writes down the current time to feed that to ntp.

My testing is of course still running but the program is at
https://github.com/folkertvanheusden/poll-pps

I delete it if it is not working so be quick :-)