[ntp:hackers] Audio refclocks in latest tarballs
Tim Shoppa
shoppa at trailing-edge.com
Fri Nov 4 06:47:35 PST 2005
OK, I'm a guy who lurks on this list, occasionally posting some
random opinion about some NTP-wide topic, but usually just tinkering
with the audio refclocks.
A few years back I added some code to the October 15 2003 ntp-dev
tarball to deal with audio refclocks and audio latency issues under
linux. This seems to be succesful, and I know at least a couple people
using this version under not only Linux but also NetBSD. And I see
that the latency patches were incorporated into the latest ntp-dev
tarball in the meantime, a good deal.
But when I try to build and use the latest ntp-dev tarballs, I get
a continual (hundreds per second) of this message:
addto_syslog: clock read fd 8: Invalid argument
when I configure the audio refclock in. I do not get this message
when I do not configure the audio refclock in my /etc/ntp.conf.
Looking at the source it seems this comes from ntp_io.c when it tries
to read the serial port hooked to a refclock. But of course with an
audio refclock this isn't appropriate.
I wonder if there's a configuration line I need to put in my /etc/ntp.conf
to tell it "hey, this isn't really a serial refclock, it really uses
the audio port", or if there's something I have to tinker with in the
new source code to make this works right.
(This is all with the "icom driver" serial-port radio control disabled
too, so it's not that serial port either. I have my own custom hacked
icom driver that drives my Ten-Tec RX320 but because that's all disabled
I don't think it matters now.)
Looking at the source code that works, I honestly do not understand
how the string-timestamp from the WWV audio decoder gets passed back
to the rest of NTP, it looks like it must be pretending to be a serial
port at a file descriptor but I do not really grok the details of how
it works there, so naturally I cannot fix what's going on with the
new tarball :-)!!!
Tim.
More information about the hackers
mailing list