[time-nuts] measuring os latency for pps

Andrew Symington andrew.c.symington at gmail.com
Wed Aug 26 16:52:38 UTC 2015


Dan Drown has also done some interesting work with PPS latency measurements
on BBB (it's been posted to time-nuts before). He essentially measured the
difference between the PPS input capture count and the count at which the
ISR was serviced in a kernel module. His experiments suggest somewhere
between 6us and 8us. GPIO is much better at around 70ns, but input-capture
based PPS is half of that. Reference:
http://blog.dan.drown.org/beaglebone-black-timer-capture-driver/

There's also some PPS code available, which helped bootstrap my code:
https://github.com/ddrown/pps-gmtimer

Cheers
Andrew


On Wed, Aug 26, 2015 at 12:42 AM, Anders Wallin <anders.e.e.wallin at gmail.com
> wrote:

> Back in 2012 while playing with LinuxCNC, a program for real-time control
> of CNC machines, I made a few graphs on the real-time vs. normal kernel
> performance:
> http://www.anderswallin.net/?s=latency
> These are purely software generated and measured events (i.e. we set a
> thread to run at 1 ms intervals and in software measure when it actually
> runs).
>
> It would be interesting to hear what (if any?) real-time kernels are used
> on NTP servers and if that is one way to measure/generate 1PPS
> input/output.
>
> Anders
>
>
> On Wed, Aug 26, 2015 at 3:04 AM, Chris Albertson <
> albertson.chris at gmail.com>
> wrote:
>
> > What are you measuring?  Seriously.  What is it you need to know, is it?
> >
> > 1) The time between the raising edge of the PPS and when the OS samples
> > the time
> >
> > 2) The time it takes between the PPS edge and when a user land process
> > is notified.
> >
> > There are other things you can measure but if you want to see #1 above
> > you can't use a TIC.  And you can't have the user space process set s
> > GPIO bit.   The reason is that the PPS interrupt handler dramatically
> > shortens the time removing ALL of the kernel process or latency.
> > Look at the interrupt code.  The clock is sampled there.  The edge
> > triggers the interrupt then while inside the handler the internal
> > clock is sampled and stored and a flag is set to indicate the PPS was
> > received.  Som tie MUCH later the flag is checked and the user-land
> > process is told the PPS has detected   The delay does not matter
> > because the clock was sampled with very low latency even if the user
> > process was not notified right away.
> >
> > I think the details are platform dependent, hardware on a PC is not
> > the same as a Raspberry Pi.  So you need to look at the source.
> >
> > On Tue, Aug 25, 2015 at 10:53 AM, Andrew Symington
> > <andrew.c.symington at gmail.com> wrote:
> > > Hi Folkert
> > >
> > > If you have a board with a hardware timer that supports
> > load/match/compare
> > > then you can schedule an external interrupt to be generated at a
> > > predetermined point in the hardware count. Thus, if you know the
> > transform
> > > between your disciplined clock and the hardware counter of the timer
> that
> > > drives it, then you should be able to do this. I have spent some time
> > > working with the (pretty neat) timers on board a beaglebone black, and
> > I've
> > > written some code to setup input capture and compare on up to 4 timers:
> > >
> >
> https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master
> > >
> > > Cheers
> > > Andrew
> > >
> > >
> > > On Tue, Aug 25, 2015 at 8:24 AM, folkert <folkert at vanheusden.com>
> wrote:
> > >
> > >> Hi,
> > >>
> > >> Not sure if it is interesting for you guys but I wrote a simple
> program
> > >> for e.g. Linux (or any other system with the pps api implemented) that
> > >> listens on a pps source waiting for a pulse and then toggles a gpio
> > >> pin. That way you can measure the latency introduced by the the kernel
> > >> when listening from userspace. Note that there's a little extra
> latency
> > >> due to the gpio-pin handling.
> > >>
> > >> It is on github: https://github.com/flok99/pps2gpio
> > >>
> > >>
> > >> Folkert van Heusden
> > >>
> > >> --
> > >> MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen
> > >> kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff-
> > >> view', vs.  http://www.vanheusden.com/multitail/
> > >> ----------------------------------------------------------------------
> > >> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
> > >> _______________________________________________
> > >> time-nuts mailing list -- time-nuts at febo.com
> > >> To unsubscribe, go to
> > >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > >> and follow the instructions there.
> > >>
> > > _______________________________________________
> > > time-nuts mailing list -- time-nuts at febo.com
> > > To unsubscribe, go to
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > > and follow the instructions there.
> >
> >
> >
> > --
> >
> > Chris Albertson
> > Redondo Beach, California
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at febo.com
> > To unsubscribe, go to
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
> >
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



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