[ntp:questions] Performance estimation

William Unruh unruh at invalid.ca
Tue Jun 16 16:11:10 UTC 2020


On 2020-06-16, David Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
> On 15/06/2020 19:00, David Woolley wrote:
> []
>> What is the clock resolution?  If you try and measure jitters that 
>> aren't several times the resolution, they are not going to be 
>> particularly valid.
>> 
>> If the hardware clock is almost dead on, and the peak to peak dither is 
>> just less than the resolution, there will be long periods in which it 
>> will read as as zero, even though it is actually close to one resolution 
>> unit.  You could also get cases where dither was very low but read as 
>> one resolution unit for long periods.  In fact, if it was possible to 
>> find tune the actual clock oscillator, during an ideal lock you would 
>> have peak to peak dither, as measured, of one or two resolution units, 
>> even though the actual phase noise was much less.
>> 
>> (Arguably, a jitter that is less than the clock resolution will result 
>> in worse time accuracy than one that a few times it, as the clock 
>> resolution will not be dithered out.
>> 
>> That makes the, normally unrealistic, assumption that the systematic 
>> error is less than the clock resolution.)
>
> 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"!
>
> 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.

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)



More information about the questions mailing list