Re: [time-nuts] NTP to discipline Raspberry Pi
Le 27 juil. 2013 à 03:18, Julien Ridoux a écrit :
snip
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.
Oh spit.
To illustrate, Hal suggested that I string some calls to clock_gettime().
Here's the result
mike@raspberrypi ~/src $ ./test_clock_gettime_on_RPI
return from 10 succesive calls to clock_gettime(CLOCK_MONOTONIC)
766112 s 68807594 ns
766112 s 68811593 ns elapsed 3999 ns
766112 s 68812593 ns elapsed 1000 ns
766112 s 68812593 ns elapsed 0 ns
766112 s 68813593 ns elapsed 1000 ns
766112 s 68814593 ns elapsed 1000 ns
766112 s 68815593 ns elapsed 1000 ns
766112 s 68816593 ns elapsed 1000 ns
766112 s 68816593 ns elapsed 0 ns
766112 s 68817593 ns elapsed 1000 ns
Looks like I need a new platform.
Thanks for your input Julien
___
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.
Re: [time-nuts] NTP to discipline Raspberry Pi
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 mc235...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] NTP to discipline Raspberry Pi Message-ID: d7f2de71-32bc-4f54-8fff-5e2027a57...@gmail.com Content-Type: text/plain; charset=windows-1252 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 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 consistenngtly measure a required correction of -43 ppm on my frequency counter. Could you let us know what crystal you were measuring? From the design docs there are 2 on the board , one at 25 MHz and one at 19,2MHz. The 19.2MHz is the one used to derive the ARM clocks. Apparently, the 25MHz crystal is used only for the ethernet port, so I didn't bother with it at all. To measure the 19.2MHz clock, I brought it out to one of the GPIO pins, after dividing by 2. Assuming that the internal divider was working properly, I _should_ have been measuring the crystal's PPM error, but I didn't actually probe the crystal itself... I just added the utility I used for this (gpioclk) to my WSPR fork, in case you find it useful. You can place either the crystal or PLLD (after dividing) on the gpioclk pin using the gpioclk program: https://github.com/JamesP6000/WsprryPi NTP reports the system clock frequency drift ( which I guess is the pll drift), and not the crystal frequency drift, so that may explain what you are seeing. Well, the pll output error would be the same as the crystal error, assuming that NTP was correctly informed of the nominal PLL frequency. What I think might be happening is that the NTP reference clock might have a nominal frequency of (something like) 1.02MHz but NTP was incorrectly told (through kernel headers) that the nominal frequency was 1.00MHz. It would then have to apply a -2PPM correction in addition to the actual PPM error of the crystal in order to discipline the clock. I'm embarrassed to admit it, but I hadn't updated the system on this RPi's SD card. After a dist-upgrade, there is still a bias, but it's only 2.5 PPM or so now, which isn't a problem for WSPR. I'm still going to try to track it down. This does at least show that there is a software issue somewhere... James -- *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.
Re: [time-nuts] NTP to discipline Raspberry Pi
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 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 consistenngtly measure a required correction of -43 ppm on my frequency counter. Could you let us know what crystal you were measuring? From the design docs there are 2 on the board , one at 25 MHz and one at 19,2MHz. The 19.2MHz is the one used to derive the ARM clocks. NTP reports the system clock frequency drift ( which I guess is the pll drift), and not the crystal frequency drift, so that may explain what you are seeing. On your measuring method, how were you preventing stray capacitance from altering the crystal frequency? How about protection ? I have a PI that I would like to do the same test on but do not want to destroy. 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.
Re: [time-nuts] NTP to discipline Raspberry Pi
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
REALTIMEMONOTONIC PROCESS
THREAD
0 2013-07-26T11:50:40Z 1374839440.667447 1374839440.667508382
696669.170759074 0.008485000 0.00849
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.
Re: [time-nuts] NTP to discipline Raspberry Pi
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 supported to nanosecond resolution as timespec{} is 64 bits.
and clock_gettime() returns that.
Right. But if you read the clock many times in a row, you will get several
copies of the same value followed by several copies of the next value...
There are two different ideas here. One is do you see low bits (below
microsecond) when you read the clock. The other is what size are the steps
between values that you see.
Suppose the clock on your system is nominally 1 microsecond. In reality, it
will be slightly off. If you are running ntpd, it will tell the kernel how
far off. The kernel will then adjust the clock by 1.37492 microseconds
per tick rather than 1.0, so you will see low bits.
That said NTP limits itself to timeval{} stamps, ie usecs.
Huh? NTP has been doing sub-microsecond for years.
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.)
--
These are my opinions. I hate spam.
___
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.
Re: [time-nuts] NTP to discipline Raspberry Pi
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 processes. Other places in NTP
use the ntp_random routine to introduce dither where appropriate as well.
Upstream of the dithered values, NTP is tracking jitter which is actually
very important to be representative of the actual measurements for the peer
selection math to work right.
…[O]ne of the earliest [applications] of dither came in World War II.
Airplane bombers used mechanical computers to perform navigation and bomb
trajectory calculations. Curiously, these computers (boxes filled with
hundreds of gears and cogs) performed more accurately when flying on board
the aircraft, and less well on ground. Engineers realized that the
vibration from the aircraft reduced the error from sticky moving parts.
Instead of moving in short jerks, they moved more continuously. Small
vibrating motors were built into the computers, and their vibration was
called dither from the Middle English verb didderen, meaning to
tremble. Today, when you tap a mechanical meter to increase its accuracy,
you are applying dither, and modern dictionaries define dither as a highly
nervous, confused, or agitated state. In minute quantities, dither
successfully makes a digitization system a little more analog in the good
sense of the word.
—Ken Pohlmann, *Principles of Digital Audio*
Tim N3QE
On Fri, Jul 26, 2013 at 1:13 PM, Hal Murray hmur...@megapathdsl.net wrote:
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 supported to nanosecond resolution as timespec{} is 64
bits.
and clock_gettime() returns that.
Right. But if you read the clock many times in a row, you will get several
copies of the same value followed by several copies of the next value...
There are two different ideas here. One is do you see low bits (below
microsecond) when you read the clock. The other is what size are the steps
between values that you see.
Suppose the clock on your system is nominally 1 microsecond. In reality,
it
will be slightly off. If you are running ntpd, it will tell the kernel how
far off. The kernel will then adjust the clock by 1.37492 microseconds
per tick rather than 1.0, so you will see low bits.
That said NTP limits itself to timeval{} stamps, ie usecs.
Huh? NTP has been doing sub-microsecond for years.
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.)
--
These are my opinions. I hate spam.
___
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.
Re: [time-nuts] NTP to discipline Raspberry Pi
On 26/07/2013, at 10:33 PM, mike cook mc235...@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@raspberrypi ~/src $ ./timelog
# gettimeofdaygettimeofday
REALTIMEMONOTONIC
PROCESS THREAD
0 2013-07-26T11:50:40Z 1374839440.667447 1374839440.667508382
696669.170759074 0.008485000 0.00849
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 -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] NTP to discipline Raspberry Pi
Date: Fri, 26 Jul 2013 12:27:50 +0200 From: mike cook mc235...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] NTP to discipline Raspberry Pi Message-ID: d7f2de71-32bc-4f54-8fff-5e2027a57...@gmail.com Content-Type: text/plain; charset=windows-1252 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 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 consistenngtly measure a required correction of -43 ppm on my frequency counter. Could you let us know what crystal you were measuring? From the design docs there are 2 on the board , one at 25 MHz and one at 19,2MHz. The 19.2MHz is the one used to derive the ARM clocks. Apparently, the 25MHz crystal is used only for the ethernet port, so I didn't bother with it at all. To measure the 19.2MHz clock, I brought it out to one of the GPIO pins, after dividing by 2. Assuming that the internal divider was working properly, I _should_ have been measuring the crystal's PPM error, but I didn't actually probe the crystal itself... I just added the utility I used for this (gpioclk) to my WSPR fork, in case you find it useful. You can place either the crystal or PLLD (after dividing) on the gpioclk pin using the gpioclk program: https://github.com/JamesP6000/WsprryPi NTP reports the system clock frequency drift ( which I guess is the pll drift), and not the crystal frequency drift, so that may explain what you are seeing. Well, the pll output error would be the same as the crystal error, assuming that NTP was correctly informed of the nominal PLL frequency. What I think might be happening is that the NTP reference clock might have a nominal frequency of (something like) 1.02MHz but NTP was incorrectly told (through kernel headers) that the nominal frequency was 1.00MHz. It would then have to apply a -2PPM correction in addition to the actual PPM error of the crystal in order to discipline the clock. I'm embarrassed to admit it, but I hadn't updated the system on this RPi's SD card. After a dist-upgrade, there is still a bias, but it's only 2.5 PPM or so now, which isn't a problem for WSPR. I'm still going to try to track it down. This does at least show that there is a software issue somewhere... James -- *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.
Re: [time-nuts] NTP to discipline Raspberry Pi (Hal Murray)
Date: Wed, 24 Jul 2013 20:46:51 -0700 From: Hal Murray hmur...@megapathdsl.net 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 time-nut would care if the crystal was off by 33 ppm or 43 ppm? So 10ppm qualifies me as a time nut? Yay! :) James -- *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.
Re: [time-nuts] NTP to discipline Raspberry Pi (Hal Murray)
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 is a curses based menu program to select the options you want. You get there via make menuconfig. There is also a make oldconfig that takes an old config file (copied from someplace) and asks what you want to do with the new options. Each distribution usually has their own software collection which includes patches made to upstream packages they use that haven't been accepted by the upstream yet. If you poke around the Raspberry Pi web site, you should be able to find the recipe for downloading, building, and installing their (probably modified) version of the kernel. There is probably a mailing list to discuss things like that. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] NTP to discipline Raspberry Pi
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 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] NTP to discipline Raspberry Pi
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.
Re: [time-nuts] NTP to discipline Raspberry Pi
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 kernels have cleaned up this area but it used to generate a lot of noise. Boot a system several times and you will get several different answers, off by up to 100 ppm. Grep your log file looking for things like: Detected 430.931 MHz processor. See if you get the same answer each time you boot. The other possible error is just the main timekeeping routines. Maybe some constant is off a bit. Unless somebody does your type of measurement, nobody would notice as long as it was close enough that NTP could fix it. (Who but a time-nut would care if the crystal was off by 33 ppm or 43 ppm?) but it seldom departs from -33ppm by more than 1 or 2 ppm... What do you expect? Ballpark is 1 ppm/C. How stable is your temperature? -- These are my opinions. I hate spam. ___ 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.
