Reference clocks.

[Hal Murray]

verm at darkbeer.org said:
[Serial vs GPIO]
> Because modern serial ports can suck, so do serial cables.  I wouldn't trust
>  anything other than a high-end serial card to handle the data it's not
> something that's given much thought in modern motherboards.

I haven't had any troubles with serial ports.  (other than not finding them 
on modern systems)

There is a potential problem with feeding a "TTL" signal into a RS-232 
receiver.  3V CMOS signals may not be high enough voltage to cross the 
threshold.  I think the threshold is usually 1.4V, but I doubt if it's in the 
specs.  It's clearly cheating and something to keep an eye on, but I haven't 
had any problems.

There is a problem with the typical 10 to 20 microsecond PPS pulses from 
GPSDOs.  They aren't wide enough and/or the driver is buggy.  The GPIO code 
may be simpler and cleaner and less likely to miss short pulses.  You can get 
a pulse stretcher from TAPR.


verm at darkbeer.org said:
> This is for live testing since I can control the GPS signals I can expect
> the same data to be received by the clock and then ntpd.  I will need a way
> to dump that info but it's easy.

Even if you broadcast the same GPS data, there is noise in the system and 
edge cases may not get the same results.  Even if the GPS unit spits out the 
exact same text strings the timing may be slightly different in interesting 
ways.

Going in at the GPS level lets you test the Kernel.  That's got to be worth 
something.

If you also run in record mode, we can save interesting patterns for 
regression testing at places other than your site.


-- 
These are my opinions.  I hate spam.