Sounds like a good driver to learn from for driver dev stuff.
On 8/2/2021 6:11 PM, Christian Weisgerber wrote:
> 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.
>
No comments:
Post a Comment