[ntp:hackers] Audio refclocks in latest tarballs

David L. Mills mills at udel.edu
Mon Dec 5 06:14:09 PST 2005


Tim, Danny,

I can't speak to the I/O issue here, but I can speak to the WWV/H 
driver, which I have running in both Solaris and FreeBSD. The timecode 
string displayed in ntpq and debug is for beauty only; the 
refclock_sample() and refclock_receive() do the dirty work. As Tim 
notes, the ICOM autotune function works only for ICOM radios, but is 
easily hijacked for other radios. The audio drivers work with serial 
data the same way as network packet data and presumably have very low 
latency relative to the actual time of arrival. On Solaris at least, the 
latency is low enough to support a claim of submillisecond 
sychronization to the radio signal. That has been confirmed with a 
cesium standard calibrated to GPS.

The ISC has systematically hijacked the NTP mail for ntp.org. So far as 
i am concerned, the official mail goes to hackers.ntp.org and is 
redirected as required.

Dave

Danny Mayer wrote:

> 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.
>
>> Tim.
>
>
> Please use the hackers at ntp.isc.org address when sending mail to hackers.
>
> Danny




More information about the hackers mailing list