Jan Stary: > playing with ntpd a bit, I am looking for a working > nmea or udcf sensor. Can people please recommend > an easy to use device known to work?
The Gude mouseCLOCKs were discontinued years ago, so I don't think you could buy any udcf(4) hardware even if you wanted to, and udcf is literally the most stupid device possible. Don't believe me? The hardware supplies a single bit of information that needs to be polled for changes. In practice, it is read by the kernel at HZ (= 100 on most archs) times per second, limiting the precision correspondingly. From ntpd's point of view, a udcf sensor will frequently jump back and forth by 10 ms. ntpd's frequency correction is effectively a differentiator, which is not very happy with jumps. I mean, you can keep time with it, but it's just poor compared to the ~1 ms precision you get from public NTP servers on the Internet. 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. Also, GPS doesn't work well indoors and mounting a roof antenna presumably does not qualify as "easy to use". Basically, OpenBSD does not support any useful sensor devices unless you are desperate and need to keep time in a remote mountain cabin without Internet access. -- Christian "naddy" Weisgerber na...@mips.inka.de
