Quoting David Taylor:
The clock on a Raspberry Pi ranges from 700 to 1500 MHz, so clock
resolution is in the nanosecond range.  There is mention of 250 MHz as
well, which would be 4 nanoseconds.  It would be nice to see numbers
which distinguish a little better than earlier RPi is "3" and more
recent ones are "1"!

The system's time (kernel "clocksource") on the RPI is actually not running at the same speed as the CPU clock.

From dmesg: arch_timer: cp15 timer(s) running at 19.20MHz (phys).

This gives you around 52ns of resolution. I believe it's the same on all the rpi models.

I would also like to see whether the characteristics of the GPS and its
location make a measurable difference to the RPi's timekeeping.  For
example: is it better to have a GPS with 3 service capability at a
location where the signal is poor, or is it masked by the RPi's
performance?  All this with kernel-mode PPS.

What I've used for this is a percentile of offsets. Looking at the 1% and 99% values on a histogram is an estimate of the system's stability.

For instance (not an rpi): https://dan.drown.org/cheese/run3/offset-histogram.png

So from that graph, I can say that 98% of the time, the system clock is within +/-80ns of the PPS.

I believe you're using ntpd, and my code to generate that graph from ntpd logs is here: https://github.com/ddrown/chrony-graph/tree/ntpd


Quoting William Unruh:
The question then is how rapidly the system can respond to an
interrupt,. This at least used to be of the order of a microsecond.
Also, how logd does it take to read the clock with the kernel gettime
routines. They all limit the accuracy of your clock using gps refclock
(and also how long the wire is between the gps unit and the computer)

On different ARM hardware (beaglebone black), I've measured interrupt latency:

https://blog.dan.drown.org/content/images/2014/Dec/interrupt-latency.png

I'd expect the rpi to have a similar magnitude. Somewhere around +10us delay and 1us jitter.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to