Clock drift. Not strictly a Linux question.

[Roger Oberholtzer]

It's Friday. Time for a weekend-think-about-it question.

I think I am doing my maths correct. I am checking a PC's clock against a 
high-end Trimble receiver (> $2000), using the pulse per second signal. 
Unless I am doing something wrong, I seem to see a 0.02 % linear (over the 
time I have looked) drift in the PC's clock (via gettimeofday()) compared to 
the pulse from the GPS. Doesn't that seem a bit large? Here is a bit of the 
sample data. There is one line for each pulse detected from the GPS.

pulse   1: 07-047-12:51:23.741
pulse   2: 07-047-12:51:24.741
pulse   3: 07-047-12:51:25.741
pulse   4: 07-047-12:51:26.741
pulse   5: 07-047-12:51:27.741
pulse   6: 07-047-12:51:28.740
pulse   7: 07-047-12:51:29.740
pulse   8: 07-047-12:51:30.740
pulse   9: 07-047-12:51:31.740
pulse  10: 07-047-12:51:32.740
pulse  11: 07-047-12:51:33.740
pulse  12: 07-047-12:51:34.739
pulse  13: 07-047-12:51:35.739
pulse  14: 07-047-12:51:36.739
pulse  15: 07-047-12:51:37.739
pulse  16: 07-047-12:51:38.739
pulse  17: 07-047-12:51:39.739
pulse  18: 07-047-12:51:40.738
pulse  19: 07-047-12:51:41.738
pulse  20: 07-047-12:51:42.738
pulse  21: 07-047-12:51:43.738
pulse  22: 07-047-12:51:44.738
pulse  23: 07-047-12:51:45.738

Every 5 seconds, the time is off by another millisecond. The PC clock seems to 
be running slower than the GPS.

The PPS signal is detected via an ioctl() that monitors changes in serial 
lines. The GPS only gives this signal when it has access to multiple 
satelites. So, it is provides the signal, it is good. If there is inadequate 
coverage, it will not send the signal. I think the operator said there were 
11 satelites at the time this was done.

I know the real system clock update is at 100 Hz (a 2.6 kernel). Maybe that is 
involved here. I am not using ntp or any of that, so there should be no 
active code doing any funny clock time changes.

Any thoughts?

-- 
Roger Oberholtzer
OPQ Systems AB