On 2021-08-02, Christian Weisgerber <na...@mips.inka.de> wrote: > I don't have any practical experience with nmea(4), but I'd like > to draw attention to ldattach(8)'s -t option. Unless your receiver > offers a pulse per second signal, you are limited to a very jittery > timestamp from the serial telegram, mirroring udcf's fundamental > problem. The last time I looked--admittedly it's been a few years-- > if you wanted to have a PPS on a serial port, you had to get some > industrial GPS module and do your own soldering. And you can't do > it over USB.
The problem isn't getting the pulses generated, it's getting them hooked up to the computer and figuring out accurately when they occurred. The old cheap method was using the elan cpu on Soekris 45xx (https://www.usenix.org/system/files/login/articles/160-vandrunen.pdf, http://phk.freebsd.dk/soekris/pps/), which had accurate hardware imestamping of external signals (probably added for some particular customer use case, not common in PC hardware). The last gps-backed ntp server I built was an rpi with Linux and a u-blox GPS HAT which fed a PPS signal via a GPIO pin. It was a bit of a faff but not too bad (there are lots of guides - search "raspberry pi ntp gps kernel pps"). That's probably the cheapest way with accuracy acceptable for most purposes. But if budget allowed I'd just buy a leontp, higher accuracy, less hassle. OpenBSD really isn't the ideal OS for this. Bumping HZ it will be less bad, but if you need accuracy you can do a lot better.
