[time-nuts] Re: PPS latency? User vs kernel mode

Andrew Kalman aekalman at gmail.com
Mon Dec 13 20:47:25 UTC 2021


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 at gmail.com> wrote:

> On Mon, Dec 13, 2021 at 6:56 AM Poul-Henning Kamp <phk at phk.freebsd.dk>
> wrote:
> >
> > In FreeBSD you get all that for free:
> >
> >
> https://papers.freebsd.org/2002/phk-timecounters.files/timecounter.pdf
> >
>
> "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.
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe send
> an email to time-nuts-leave at lists.febo.com
> To unsubscribe, go to and follow the instructions there.
>
>




More information about the Time-nuts_lists.febo.com mailing list