[ntp:hackers] Audio refclocks in latest tarballs
mayer at ntp.isc.org
Fri Nov 4 19:38:03 PST 2005
Tim Shoppa wrote:
> 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 did make changes to the read loop in ntp_io.c in the last few months,
but ntp_io.c knows nothing about the clock code and just calls the
configured clock read function. I can take a look to make sure that it
does the right thing in case of an error but it's up to the clock code
to do the right thing.
> 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 :-)!!!
Dave would know.
Please use the hackers at ntp.isc.org address when sending mail to hackers.
More information about the hackers