I’m kinda puzzled with the PPM-readings i get from my machines. It seems to differ at each restart. Sometimes they are high (around +100 PPM) and stay high and sometimes they trend low and stay low (-8 PPM).
What drives the PPM reading and should I care?
PS: All antenna’s are installed indoors, which is not a great setup.
Current readings from my machines:
M300GPS (DHQ OXCO): -22 PPM
M200 DCF77 (TXCO): -50 PPM
M300GPS (TXCO): -8 PPM
If those machines have a very old version of the Linux kernel, I think it’s normal. The frequency calibration of the TSC clocksource used a very short interval to avoid delaying the boot too much. It gives very different values across reboots.
Modern kernels replace the initial estimate with a more accurate value measured over a longer interval without blocking the boot. On (some?) modern hardware it can also determine the CPU/TSC frequency without doing any measurements and this is perfectly stable.
As far as i am aware these machines run a 4.xx kernel. This is an older kernel (2018/2019).
Which versions experience the behavior you describe?
Low PPM only means that they are off so much parts per minute.
But, that is only when the synchrosignal is off, e.g. no recepetion.
These clocks are typical local-clocks that keep ticking when your signal is gone for a bit.
Like a GPS in a tunnel, the GPS will continue to tell you where you are, it’s guessing your speed until the GPS signal is back.
DCF isn’t a very accurate signal compared to GPS with PPS, as such it will be more off then both GPS.
DCF77 doesn’t need an outdoor antenna, the signal is on the VLF band and penetrates almost all structures.
GPS doesn’t need to be outside as long as it has a signal-lock, behind a screen or under a wooden roof they perform fine.
I doubt you have a problem if you leave them running for longer times.
My systems are wrong after a restart too, but it goes back to normal in a few inutes.
I think the speed of the CPU got something to do with it too, it’s an AMD Geode:
That is about the worst CPU ever made and put in the market.
I have run a desktop computer with it and dumped it in the dustbin within a week 
Because of the Geode CPU in all 3 machines, I would be happy it’s that accurate at all.
I think it’s this commit included in 2.6.38:
Doesn’t matter, do you know the Geode AMD CPU?
You can hardly call it a processor, it’s that bad.
Other samples of bad CPU’s are the Pentium Pro, 80286, 80386, a few AMD64 CPU’s, and several Intel low-power CPU’s that are not stable.
The Geode is nothing else but a joke for being called a CPU.
The problem is there.
The Geode is not a good CPU, not even at the time it was released.
If you ever tried this CPU you know what I’m talking about.
No worries at all
Those values are from the clockmodule and not from the CPU and only need if the clock isn’t synchronized.
The DHQ need about >2-4h synchronized to get most stability.
@apuls
thanks!
If indeed the PPM is provided by the clock module, shouldnt it be more precise tgan -22 PPM for a high-quality crystal?
After all 22 PPM (parts per million) equals to a drift of 1.9 seconds per day! Or am i mistaken?
According to the manual the drift shall be around 1 ms per 24 hours for the OXCO-HQ version in case of no-GPS-lock.
Arghh… I’ve looked today into the webinterface.
You got those values from the Syncmon Page, right ?
Thoses values are from the local NTP client - if it’s not synced. It will be synced by the clockmodule.
And the ppm values for the clock can you see here: Oscillator Options for Meinberg Receivers - Rubidium, OCXO or TCXO - Accuracy of Frequency Outputs
@apuls
Yes, you are right. the -22 ppm i got from the syncmon page.
Unfortunately i don’t understand your comment. It’s the local ntp drift, but how is this not relevant? Isn’t local clock steered directly by the OXCO?
How can the local clock have such a high drift if the oxco steers it?
Ok, i will try to explain it
All the ppm stuff is (mostly) related to unsynchronized system (either local ntp or clock module).
The clock module (DCF77/PZF/GPS receiver) have their own oscillator with the accuracy from the above link. The clock module generates the NMEA string and the PPS.
The accuracy from the Osc. link is only for free running / not synchronized.
If the clock is synced, the Osc. will be continuously adjusted. Same for the Local NTP Clock.
The local NTP is on the CPU - as Bas wrote it’s an Geode (LX800). The NTP is feed by the NMEA + PPS from the clock module.
If the clock module is now free running it have the accuracy from Osc. and still feed the NTP with it’s high accuracy.
If the NTP don’t get a valid signal anymore (NMEA + PPS) it will also goes into free running and using the local “CPU Clock/Osc”.
At this point you will get the estimated drift value from the Syncmon page.
It doesn’t.
The local clock is the RTC on the motherboard.
It’s only after starting and NTPd or Chronyd are working it will set the RTC correct.
However it will drift again.
One big problem could be the CR-2032 battery is low voltage or almost died, then it wanders off in the distance.
Typical those batteries last 5 years, often less in desktop PC’s…you may want to replace it.
The ‘precise’ clocks do not stear the system/rtc clock, only after the OS has started and NTPd or Chronyd set the on time (again).
Your machines are old, so big chance the battery died…or barely hold the cmos, let alone the cmos-clock.
This battery doesn’t have much power, it isn’t designed to keep time or anything, it’s designed to keep the cmos-data in tact. It does help time a tiny bit…like not being off to many minutes a day 
The CPU modules dosen’t have a backup battery at all… the age is irrelevant
Are you sure…as the RTC is not CPU related. The RTC is a chip on the motherboard.
The CPU doesn’t contain the CMOS Clock, most referred as RTC.
If the motherboard doesn’t have an RTC, it will be off for many years.
He doesn’t talk about that. So I do believe the battery is low, very low.
You may want to read up on how motherboards are designed…
Ohh jesus Bas…
Yeah i know the cpu modules, and i know the Lantime M-Series he is using - and trust me the CPU Board don’t have backup battery…
You may want to take a look at the hardware he is using
ps: a RaspberryPi don’t have a RTC too… OK it’s a SBC and there are RTC addon modules…
@Bas thanks for the suggestion. i don’t know if a low-power battery is a likely cause, but i will replace it this weekend. we’ll see.
Well, to please you I have started investigating these devices.
And you are wrong and right.
The battery is not on the mainboard but on the Receiver-Time module.
Look, at the module, at the top, the silver shiny round battery 
That battery is pretty sure making the RTC ticking for reboot, powerloss or signalloss.
From the manual:
NDT167 Features
The hardware of NDT167 is a 100 mm x 160 mm microprocessor board. The front
panel integrates a 2 x 40 character LC display, two LED indicators and 5 push
buttons. A correction value computed from the offset to the external NTP server
increases the accuracy of the board’s HQ-OCXO to 10-9 and automatically
compensates the oscillators aging. The last recent value is restored from the battery
buffered memory at power-up.
and
Skilled/Service-Personnel only: Replacing the Lithium Battery
The life time of the lithium battery on the board is at least 10 years. If the need arises
to replace the battery, the following should be noted:
Strange Meinberg tells you it should be replaced every 10 years
And again wrong, the RPi5 does contain an RTC and it can be powered with an external-battery, unlike the older models. I wonder why they added an RTC
Clocks can not be stored, they either stop ticking or they tick on a battery.
In a PC the RTC is not the battery main purpose, as the OS that will synch time later on. That is all I said.
Well it’s my best guess, as the battery should be pretty old by now, it won’t hurt to replace it anyway. It may be long overdue.
Bas, you have talked about the “Motherboard / Mainboard” not the Clockmodule.
The Motherboard / Mainboard / CPU Module (the left card with the shiny golden heatspreader) don’t have a RTC Backupbattery (normaly).
Did you see the three holes near the barcode on the CPU Module, left from the speaker ? That’s the place for CR1/2AA (battery holder or tree pin battery)
And yes on the clockmodule is as CR2023 and on a older Clock you will find a CR1/2AA where the barcode is placed.
The battery (Clockmodule) backups the Clockmodule RTC (time, date) and also the almanach for the satelites. The DAC value for the Osc. is stored in an EEProm.
You can remove the battery and start the system. It will take about 15min to sync.
The NDT167 is old and strangen one… 
This is a M300/GPS
The battery can stay longer but the battery manufactor gives only 10 years warrenty on the sealing.
Don’t use / have a PI5 
At the end you can operate a Lantime M-Series without any backup battery at all.
Removed. As it’s not helping.