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:

https://github.com/JamesP6000/WsprryPi/pull/1 Commit Summary

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

File Changes

• M READMEhttps://github.com/JamesP6000/WsprryPi/pull/1/files#diff-0(2)
• M wspr.cpphttps://github.com/JamesP6000/WsprryPi/pull/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/JamesP6000/WsprryPi/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/JamesP6000/WsprryPi/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/JamesP6000/WsprryPi/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?