[time-nuts] NTP to discipline Raspberry Pi

[Julien Ridoux]

On 26/07/2013, at 10:33 PM, mike cook <mc235960 at gmail.com> wrote:

> 
> Le 26 juil. 2013 à 01:54, Julien Ridoux a écrit :
> 
>> Hi James,
>> 
>> We have done some measurements of the stability of the STC clocksource that the kernel relies on to build its system clock. I believe this link could be the answer to your question:
>> http://www.synclab.org/?post=blog/2012/11/radclock-raspberry-stability-nic-noise.html
>> 
>> Please note that these measurements are made with our custom kernel patches and bypass any kernel system clock PLL driven by ntpd. So the results have to be interpreted in this context -- especially, they do not rely on the nominal frequency reported by the clocksource.
>> 
>> Cheers,
>> Julien
>> 
> 
>   Hi Julien,
>  Most interesting.  I do however have an issue with your wording. 
> "Already, this tells us that the smallest meaningful timestamp resolution on the Pi is 1 microsecond."
> 
>  Timer resolution may be limited ( I haven't trawled the code), but timestamps are supported to nanosecond resolution as timespec{} is 64 bits. and clock_gettime() returns that.
>  That said NTP limits itself to timeval{} stamps, ie usecs.
> 
> from Markus Kuhn's little prog on my PI.
> mike at raspberrypi ~/src $ ./timelog
> #             gettimeofday				gettimeofday			REALTIME			MONOTONIC			PROCESS               THREAD      
> 0         2013-07-26T11:50:40Z 1374839440.667447 1374839440.667508382     696669.170759074          0.008485000          0.008490000
> 1         2013-07-26T11:50:40Z 1374839440.916650 1374839440.916656359     696669.419906051          0.136284000          0.136289000
> 2         2013-07-26T11:50:41Z 1374839441.182422 1374839441.182428671     696669.685678363          0.264474000          0.264479000
> 3         2013-07-26T11:50:41Z 1374839441.434640 1374839441.434646527     696669.937897219          0.394819000          0.394824000
> 
> Regards



Hi Mike,

Thanks for the interest in the data. You are quite right for everything regarding data structure, but let me explain what we meant by that comment.

Timespec{} is a 64 bit data structure and support nanoseconds. Yes.

However, it doesn't mean that the digits below the micro-second are actually representative of anything real.

For the nanosecond digits to be something else than noise you need to make sure that:
- the hardware counter on top of which the system clock is build has a frequency of at least 1GHz
- the kernel does not increase the granularity of the counter readings (see the implementation of 'TSC-low' timecounter on FreeBSD for an example: http://svnweb.freebsd.org/base/stable/9/sys/x86/x86/tsc.c?view=markup) 

In the case of the raspberry pi, the relevant source code can be found around line 155 in the following kernel source file:
https://github.com/raspberrypi/linux/blob/rpi-3.6.y/arch/arm/mach-bcm2708/bcm2708.c

As you can see, from the comments in the code, the STC counter runs at 1MHz. Any digit representing a quantity below one microsecond would have to be interpolated in some way (please don't ask me on how this is done, I am sure someone will know how the bit stuffing is done better than me).

In any case, I don't see how we can trust anything below the microsecond resolution on the Raspberry Pi when it comes to assessing the stability of the actual hardware -- again I am coming from an angle where we bypass all system clock inner mechanics driven by ntpd or equivalent.

I hope this clarifies what we meant by that comment. I agree that using 'meaningful' to describe a timestamp resolution may not be the best choice of words, I would be happy to listen to suggestions if you email me directly :-)

Cheers,
Julien