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
>
> On 25/07/2013, at 1:21 PM, James Peroulas <ja...@peroulas.com> wrote:
>
>> I was hoping to measure the ppm error of a Raspberry Pi's crystal using an
>> NTP client running on the Pi itself. The NTP client reports a ppm
>> correction that I find to be consistently (measurements performed over
>> several days) off by about 10 ppm compared to what I measure using my GPS
>> calibrated frequency counter (HP5328). Specifically, the Pi reports a
>> required ppm correction of -33 ppm whereas I consistently measure a
>> required correction of -43 ppm on my frequency counter.
>>
>> Any ideas on where I can look to track down the discrepancy? Perhaps the
>> timers on the RPi are configured incorrectly in the kernel? Or is this the
>> best I can expect from NTP? I would understand the situation if the NTP
>> reported correction drifted above and below -43ppm, but it seldom departs
>> from -33ppm by more than 1 or 2 ppm...
>>
>> Thanks,
>> James
>>
>> P.S. I apologize if this isn't time-nutty enough :) I only need about 1ppm
>> accuracy in my corrections :)
>>
>> --
>> *Integrity is a binary state - either you have it or you don’t.* - John
>> Doerr
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
