[time-nuts] measuring os latency for pps

Andrew Symington andrew.c.symington at gmail.com
Tue Aug 25 19:01:54 EDT 2015

> Hi Iain
>> 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
> Wait...You mean with your driver I essentially have a A->B->C->D TIC ?
> _THAT_ I have a use or three for...
The one catch is that you can only setup a BeagleBone Black timer to be in
capture mode OR compare mode, not both. So, what I did was to set up two
parallel timers that are driven by the same oscillator (and thus I don't
drift relative to each other). I then perform synchronization against the
first free-running timer. I then bootstrap the second timer with the count
of the first one, which appears to have a fairly deterministic latency of
13 ticks. I can then setup a load/match to cause a rising edge at a very
deterministic point in time. I have sort have named this an IOTIMER.

> Since there is also code out there to drive a BBB from an external
> reference via TCLKIN, this gets very interesting.

Yes, I have a patch set for the 4.1.3x kernel, which sets up tclkin
(although I haven't tested it since the 3.x kernel branch).

My kernel module is loaded by the device tree as follows. In the snippet
below I setup two IOTIMERS, the first of which (iotimer_a) performs compare
on timer4 and event generation on timer5. The argument "1" says use the
24MHz oscillator to drive both timers -- "0" is for TCLKIN and "2" is for
the 32kHz oscillator. The last parameter describes which edge to capture --
"0" is for rising, "1" is for falling, "2" is for both and "3" is for none.

/ {
roseline {
compatible = "roseline";
status = "okay";
iotimer_a = <&timer4 &timer5 1 0>;
iotimer_b = <&timer6 &timer7 1 0>;
pinctrl-names = "default";
pinctrl-0 = <&timer_pins>;

Obviously, you'll also need to do the pinmuxes (TLKCIN causes you to lose

/* Timer configuration */
timer_pins: pinmux_timer_pins {
  pinctrl-single,pins = <
0x90  0x22 /* P8.7   MODE2 TIMER4 - 24MHz CAPTURE   */
0x98  0x02 /* P8.10  MODE2 TIMER5 - 24MHz INTERRUPT */
0x9C  0x22 /* P8.9   MODE2 TIMER6 - TCLKIN CAPTURE  */
0x94  0x02 /* P8.8   MODE2 TIMER7 - TCLKIN INTERRUPT */
0x1b4 0x2A /* P9.41A MODE2 TIMER4 TCLKIN */
0x1a8 0x0F /* P9.41B MODE7 TIMER4 INPUT (high-Z, tied to P9.41A) -
conflicts with HDMI */

Once the kernel module is loaded, you can communicate with it from
userspace using ioctl. Simple example:


I still have to implement polling to notify the userspace of capture
events. Right now you have to keep checking until the sequence number

> I might just have to compare your code against my own TIC code using
> the PRUSS  (Although that's only a traditional A-B or A-A TIC at the
> moment, extending to 3 or 4 inputs would decrease the precision and
> accuracy...)

Please do! And let me know how it performs :) And if you have released your
PRUSS code, please send me a link!

> 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.
> Oh this might be very interesting, esp with something like the BBB,
> which has the excellent counters that Andrew discusses above. Presumably
> it is a five minute job to modify your code to do something other than
> twiddle a GPIO pin.
> It would be very useful to try and characterise that kernel delay. I
> will add it to the list of things to try, once I finish moving the time
> lab around!

Great -- keep us in the loop!


More information about the time-nuts mailing list