The process of reading the PC-Funkuhr is like this: the kernel is told to read the clock from pcf77. Of course, time elapses between reading the PC-Funkuhr and printing the time by pcf77.

In principle, it is not known, when exactly the clock has been read, because the kernel doesn't log this moment. In order to check this delay, I added the option "-D" to pcf77.

A systematical logging of the difference between system-time and PC-Funkuhr-time yields the following surprising picture, where the time-difference is plottet against the time of reading the clock:

What we see is a global drift of the PC-Funkuhr, which gets corrected at 2:00 at night, which is the time of synchronizing the clock with the DCF77 signal. It seems that the clock isn't as precise as the vendor says and that it is important to synchronize with DCF77 every night.

What made me nervous, was the hourly "fast" drift, where the peaks happen nearly exactly every full hour. Is there an error in my pcf77 routines? Or what's happening there?

I tested the functions of pcf77 but was not able to find an error. (ok, who is not blind against his own faults?) However, at present I think that the clock itself corrects the drift hourly, which seems to be not completely succesful. Even if I misadjust system-time by an amount of, say, 27 minutes, the peaks of the sawtooth pattern happen at the very hour of the Funkuhr-time!

Maybe there is somebody "out there" who knows that phenomenon and can tell me what's happening.

When I know better what the reason for this behaviour is, I would be able to improve the routines for reading the Funkuhr. As you can see above the error reading the clock is - depending on the time-of-day and the relative position with respect to the hourly peak - not only some milliseconds but can reach the order of a second.

Send questions and suggestions via mail to <matthias AT familie-schuetze DOT de>, please.