> Systematic errors: I assume the gps pps sets out synchronized to UTC,
> suffers cable delays (well, a few ns), hits the DCD pin, goes thorough
> a gate or two, is picked up by the os, then the pps driver finds out
> about it, and it is only then that a (pps time, system time) stamp is
> made.
> Has anyone any feel for these delays on a modern pc running linux?
I have a hack that reads the clock (gettimeofday) and builds a histogram of
the differences between each pair of samples. I just patched it to wait
until just before a second before starting.
Typical results on 566 MHz box with a 2.4 kernel:
Collecting 1000 samples via gettimeofday.
Index uSec Hits
0 0 42
1 1 956
13 13 1
20 20 1
It took 0.001 seconds to read the clock 1000 times.
That's 0.990 microseconds each.
The "13" above ranges from 12 to 14.
The "20" ranges from 19 to 26, eyeball says it's a bell shaped distribution.
I assume they are the times for processing an interrupt. I'm not sure why
there are two interrupts happening close to a second tick. Maybe the other
side of the PPS signal? (The HP Z3801A on this box has a PPS signal that is
a 10 uSec pulse rather than a square wave.)
Another approach would be to patch the PPS interrupt handler to wiggle
something like a printer port pin and put a scope on it.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
