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 <[email protected] > 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 < > [email protected]> > 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 > > <[email protected]> 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 <[email protected]> > 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 -- [email protected] > > >> To unsubscribe, go to > > >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > >> and follow the instructions there. > > >> > > > _______________________________________________ > > > time-nuts mailing list -- [email protected] > > > 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 -- [email protected] > > To unsubscribe, go to > > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
