On 26/07/2013, at 10:33 PM, mike cook <[email protected]> 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@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
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
