Thanks for that James.
Le 27 juil. 2013 à 04:26, James Peroulas a écrit :
>>
>> Date: Fri, 26 Jul 2013 12:27:50 +0200
>> From: mike cook
>> To: Discussion of precise time and frequency measurement
>>
>> Subject: Re: [time-nuts] NTP to discipline Ras
Le 27 juil. 2013 à 03:18, Julien Ridoux a écrit :
>
> 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.
>
>
> Date: Fri, 26 Jul 2013 12:27:50 +0200
> From: mike cook
> To: Discussion of precise time and frequency measurement
>
> Subject: Re: [time-nuts] NTP to discipline Raspberry Pi
> Message-ID:
> Content-Type: text/plain; charset=windows-1252
>
> Le 25 juil
On 26/07/2013, at 10:33 PM, mike cook 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 t
> There is another quirk with NTP. It measures the tick rate and fills in
the
> bottom bits with random. (I can't explain why. If you are unlucky, you
can
> see time going backwards.)
I think this is equivalent to dithering which is useful when making
quantitized measurements of many physical p
mc235...@gmail.com said:
> 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 supporte
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/1
Le 25 juil. 2013 à 05:21, James Peroulas a écrit :
> 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
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
ja...@peroulas.com said:
> This would be my first time looking at kernel sources. Any suggestions as to
> where to start?
I don't have a Raspberry Pi so I'm not familiar with how they do things.
The main Linux kernel sources are available at kernel.org. It's driven by a
config file, and there
>
> Date: Wed, 24 Jul 2013 20:46:51 -0700
> From: Hal Murray
> ja...@peroulas.com said:
> > Any ideas on where I can look to track down the discrepancy?
>
> Dig out the kernel sources.
>
This would be my first time looking at kernel sources. Any suggestions as
to where to start?
> Who but
> a t
ja...@peroulas.com said:
> Any ideas on where I can look to track down the discrepancy?
Dig out the kernel sources.
There are 2 sources of error. One is the calibration routine. It's
comparing the CPU cycle counter with another counter that runs at a specified
frequency. I think recent kern
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 fr
13 matches
Mail list logo
