[ntp:questions] Raspberry Pi error in PPM offset

james.peroulas at gmail.com james.peroulas at gmail.com
Fri Aug 23 15:28:31 UTC 2013

Answering both unruh and David Taylor here!

I haven't changed the configuration of NTP on the Raspberry Pi so it is still using the default time servers:
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

The RPi is connected via wired ethernet through two switches to a router to AT&T Uverse.

To measure the RPI's actual clock frequency, I'm using the gpioclk program from https://github.com/JamesP6000/WsprryPi. Basically, the 19.2MHz crystal on the Pi is being used to generate the internal PLLD clock running at 500MHz which I then divide down by a factor of 50 to produce a 10 MHz clock on the RPI's GPIO4 pin.

I measure the actual frequency on GPIO4 using an HP5328 counter which has been recently GPS calibrated and has a frequency error of better than 0.010 PPM. From this, I calculate the actual PPM error of the crystal to be around -43 PPM. It varies a bit with room temperature, but rarely differing by more than 0.5 PPM from -43 PPM.

I use "ntpdc -c loopinfo" to query the NTP measured frequency offset and I consistently get values around -45.5 PPM. Again due to temperature variations and network jitter/ load I do see some variations around -45.5, but rarely exceeding 0.5 PPM.

The difference between the actual PPM error and the NTP measured PPM error seems to consistently be about 2.5 PPM, plus or minus 0.5 PPM. If the difference varied from -2.5 PPM to +2.5 PPM, for example, then I would simply attribute this to measurement error or network jitter or network load. However, with a consistent frequency offset, I suspect that there might be a configuration issue with the Pi.

I'm suspecting that NTP has been told that the reference timer it is using has a frequency of X MHz when it actually has a frequency of X*(1+2.5e-6)MHz. Where would I look for such configuration information? I'm suspecting that it's in one of the kernel headers.

Are there any other explanations for this behavior?


More information about the questions mailing list