Use the system call ntp_adjtime() instead of the program ntpdc.

[kukabu]

I don't ham but NTP, RPi and amateur radio is interesting to me. I hope this patch will be useful to you.
ps. I can't test the patch but it looks right. :)

[JamesP6000]

Thanks Michael! This is really great! I'm going to try to test it tonight
and then accept the pull request. Does this require any special packages to
be installed, or will all RPi distributions have access to ntp_adjtime()?

Perhaps you can help me with the last remaining problem with calibrating
the Pi's clock using NTP? Basically, when I first started the code, there
was a fixed offset of about 10ppm between the 'real' ppm value as measured
by my external frequency counter (gps calibrated) and the NTP reported PPM
value. I updated the RPi's software (apt-get dist-upgrade) and the offset
became much better, at around 2.5ppm. So, clearly, this offset is affected
by the configuration parameters of the RPi (most likely the kernel).

Do you know where I can look to track this down? I suspect that there is a
hardware timer inside the Pi that's being used for kernel timing and that
the kernel has been informed that the timer is running at X MHz when it is
actually running at X+2.5ppm MHz.

Thanks again for the patch,
James
james@peroulas.com

On Thu, Aug 15, 2013 at 3:34 AM, Michael Tatarinov <notifications@github.com

wrote:

I don't ham but NTP, RPi and amateur radio is interesting to me. I hope
this patch will be useful to you.

ps. I can't test the patch but it looks right. :)

You can merge this Pull Request by running

git pull https://github.com/kukabu/WsprryPi master

Or view, comment on, or merge it at:

#1
Commit Summary

• Use the system call ntp_adjtime() instead of the program ntpdc.

File Changes

• M READMEhttps://github.com/Use the system call ntp_adjtime() instead of the program ntpdc. #1/files#diff-0(2)
• M wspr.cpphttps://github.com/Use the system call ntp_adjtime() instead of the program ntpdc. #1/files#diff-1(41)

Patch Links:

• https://github.com/JamesP6000/WsprryPi/pull/1.patch
• https://github.com/JamesP6000/WsprryPi/pull/1.diff

Integrity is a binary state - either you have it or you don’t. - John
Doerr

[kukabu]

Special packages aren't required. The ntp_adjtime() is kernel call and it exists on most modern UNIX.
man 2 adjtimex for details. adjtimex() is the Linux name for ntp_adjtime(), but ntp_adjtime() is more portable name.

Is the ntpd synchronized with the network source? It can be a problem, so many factors affect the network synchronization. You can try to synchronize RPi to your external frequency counter.
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html - this is a good article about NTP and RPi.

[JamesP6000]

On Thu, Aug 15, 2013 at 11:58 AM, Michael Tatarinov <
notifications@github.com> wrote:

Special packages aren't required. The ntp_adjtime() is kernel call and it
exists on most modern UNIX.
man 2 adjtimex for details. adjtimex() is the Linux name for
ntp_adjtime(), but ntp_adjtime() is more portable name.

Great! I was hoping to not have to switch to cmake just yet :)

Is the ntpd synchronized with the network source? It can be a problem, so
many factors affect the network synchronization.

Agreed, but the issue is that the offset is always the same at around
+2.5ppm. If it varied from -2.5ppm to +2.5ppm, then I would just conclude
that the system was being limited by the jitter/ noise of the NTP
synchronization. However, with a fixed offset, that changed from 2.5ppm to
10ppm just with a software upgrade, I'm thinking it's a configuration
issue. Note that right before I upgraded the software, the offset was
consistently 10ppm measured over a span of several days. Once I did the
upgrade, immediately the offset became 2.5ppm and again was consistent for
several days.

You can try to synchronize RPi to your external frequency counter.
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html - this is a good
article about NTP and RPi.

Really great link, thanks!

James

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-22713659
.

Integrity is a binary state - either you have it or you don’t. - John
Doerr

[kukabu]

Yes, it's true if link between you and ntp servers are symmetrical but Internet links are asymmetrical and you can get a persist error that the depend on the routing, bandwidth and etc.

[JamesP6000]

Oh, wow, didn't know that. It could be that the recent software update made
the rpi internal processing more symmetrical and that's what improved the
offset.

Thanks!
James

James
On Aug 16, 2013 12:18 AM, "Michael Tatarinov" notifications@github.com
wrote:

Yes, it's true if link between you and ntp servers are symmetrical but
Internet links are asymmetrical and you can get a persist error that the
depend on the routing, bandwidth and etc.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-22748017
.

[kukabu]

No, you restart the ntpd after updating and ntpd selected an another servers from pool with different characteristics.
I think the monitor can help you identify the problem.

statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

http://www.eecis.udel.edu/~mills/ntp/html/monopt.html

[JamesP6000]

Hi Michael,

Thanks for your input! Just trying to understand a few things. If there's
an asymmetric delay, I would expect a fixed time offset between the time
reported by the Pi and the network time, but how can this produce a fixed
frequency offset?

For example, suppose the oscillator in the Pi happened to have no frequency
error in that the frequency stamped on the can (19.2MHz) was the actual
frequency, accurate to 10^-12 or better. With asymmetrical network delays,
I would expect that the Pi would have a fixed time offset compared to the
reference clock that could only be measured externally by directly
comparing the time reported from the two clocks. NTP would have no way of
measuring or correcting for this fixed time offset.

However, I would expect the PPM frequency error reported by NTP to be 0
PPM. Assuming fixed but asymmetric network delays, between any two NTP
updates separated by s seconds, NTP would expect to have counted s_19.2e6
local clock cycles. If the actual measured number of clock cycles is
s_19.2e6, then NTP would conclude that the PPM error is zero, despite there
being an asymmetric network delay. If the asymmetric delay is actually
varying, due to network load, then the measured number of clock cycles
would vary above and below s*19.2e6, but the NTP loop filter would average
these out and, over time, would still give a 0 PPM frequency correction.

What I'm finding is that even with a perfect 19.2MHz clock, NTP on the Pi
would still report a frequency correction of 2.5PPM...

Thanks,
James

On Fri, Aug 16, 2013 at 12:56 AM, Michael Tatarinov <
notifications@github.com> wrote:

No, you restart the ntpd after updating and ntpd selected an another
servers from pool with different characteristics.
I think the monitor can help you identify the problem.

statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

http://www.eecis.udel.edu/~mills/ntp/html/monopt.html

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-22748924
.

Integrity is a binary state - either you have it or you don’t. - John
Doerr

[kukabu]

I think you're right. The asymmetric delay added persist offset error, not frequency.
but it would still be wondering whether there will be an error with an external reference clock.

[kukabu]

@JamesP6000
http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=82369
Maybe this is your 2.5PPM?