[ntp:questions] TrueTime refclock Users?
David L. Mills
mills at udel.edu
Thu Apr 19 03:33:32 UTC 2007
I recall that Paul Vixie was the author of that much-mangled driver. He
intended to support a number of TrueTime devices, including the GOES and
WWVB clocks which are no longer manufactured. The code has little
wiggles designed to support most if not all historic TrueTime devices
with one driver. Should you make serious changes to adapt your a model
not supported by the driver, it might lose the valuable feature of one
driver fits all.
TrueTime of course has been eaten by Symmetricom and it appears all
except the GPS receivers have become extinct except on eBay. What I'm
saying is that it might be better to clone another driver and leave the
TrueTime one alone. The best choice would be to find a driver that with
minimal compile or configuration changes could support both the original
and your driver. Several drivers now automatically detect which radio is
hot and configure accordingly.
Jason Rabel wrote:
> Yes, I checked out those links, nobody else listed with a NTS and there
> isn't any additional information, but that's okay.
> I was swearing up and down the other day wondering why the driver wasn't
> working. I knew my C skills were rusty, but the driver code isn't *that*
> complex. I must of re-written the driver routines about 3 or 4 different
> ways. Not knowing what all the debug references were (I think a few led me
> down a false path), I was having to dig through even more code trying to
> figure out their meaning.
> I finally tossed the true driver completely and re-wrote it based on the
> nmea driver. This eliminated a lot of the old testing routines for ancient
> TrueTime devices and was much cleaner.
> Finally a light dawned upon me when I was staring at the time output from
> the NTS... It was in local time, not UTC time! DOH! lol....
> I switched the TZ on the NTS and BAM, it worked! Unfortunately I was less
> than impressed with the timing accuracy. I tried both the continuous
> once-a-second automatic output and the time on request polling method (which
> returns the time with milliseconds). I think I could get a little bit better
> resolution if I knew exactly how the time routines worked and could set the
> point in time that the received data represents. The automatic output seemed
> to give slightly better performance, probably because there isn't the delay
> from the whole request, process, and receive.
> Part of the poor accuracy could be due to the serial port on the Linux box,
> I'm about to recompile the code on my geode box that is running FreeBSD (it
> just takes a long time to compile NTP, which is why I do the testing on a
> faster machine). The time came out to be about 1-2ms off (it states accuracy
> within 1ms in the manual), but I want to compare it with my GPS on the same
> machine before finally calling it quits.
> I know this was a pretty round-about way of doing things, and there are much
> easier methods for getting more accurate time, but I just wanted to see if
> it could be done. At the very least I learned a lot about how the refclock
> drivers worked. It's entirely possible with a little more hacking (both on
> the NTS and the driver), PPS support could be added. But at that point it
> would just be easier (and cheaper) to use a regular GPS receiver.
> So that's my story about getting time output via the serial port on a
> NTS-100. :)
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions