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 naddy@mips.inka.de
No comments:
Post a Comment