>Hal Murray hmurray at megapathdsl.net >Sun Jan 28 07:37:05 UTC 2018 > >There is another approach that might be interesting. Use a loopback on some >modem control signals or gpio pins. Then a test program can grab the time, >flap the pin, and grab the time, then read the PPS time. > >Things may get complicated by locks in the kernel. If they get too ugly, we >could use two machines and ping-pong back and forth. It would take a bit of >work to merge the data and correct for the time offset between the two >systems. That would work better with identical systems. > > > >> Well, that assumes you do have a serial port available that even has these >> signals connected. > >I'm interested in both GPIO and modem signals on PCs with real serial ports. >I have PCs with multiple serial ports. It may be easier for me to work with >them rather than learn how to drive the GPIO pins on a Raspberry Pi.
If you're also going to test on a PC, you might be interested in a Linux parallel port PPS driver I modified a while back to add low-latency loopback echo and a mode that uses polling instead of interrupts for pulse capture. Also, on load the driver measures IO speed. Total capture latency can then be estimated with an external time interval counter. I just placed the driver on github at https://github.com/retroman/pps_parport_polled I will eventually upload some measurements I took with various machines. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel