[ntp:questions] Performance estimation

David Taylor david-taylor at blueyonder.co.uk.invalid
Tue Jun 16 07:20:20 UTC 2020


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.

-- 
Cheers,
David
Web: http://www.satsignal.eu



More information about the questions mailing list