[time-nuts] NTP to discipline Raspberry Pi

[mike cook]

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

> 
> On 25/07/2013, at 1:21 PM, James Peroulas <james at 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 at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.