[ntp:questions] Ignore one server except in extreme conditions?
agcarver+ntp at acarver.net
Thu Nov 17 17:48:57 UTC 2011
On 11/17/2011 00:25, Dave Hart wrote:
> On Thu, Nov 17, 2011 at 07:31, A C<agcarver+ntp at acarver.net> wrote:
>> On 11/16/2011 23:06, Dave Hart wrote:
>> I will probably try this later on another identical system.
> Please do.
>> I'm going to
>> switch to a shared memory driver because my eventual desire was to have gpsd
>> running to collect position and timing data to use for another experiment.
>> But that requires SiRF binary mode which precludes using the NMEA driver.
> gpsd may still be easier, but depending on what you need, you might be
> able to stick with the NMEA driver and harvest the NMEA sentences ntpd
> uses from its clockstats file.
There are a few bits of data that don't come through NMEA including
constellation statistics information, DGPS data (technically SBAS data),
and a few internal GPS status bits. All of those come through the SiRF
protocol so using gpsd as a decoder/siphon/tee would give me access to
the data and still give ntpd access to the timing data.
>> I am mostly convinced that the lack of PPS on the NMEA driver comes down to
>> the NetBSD serial driver on sparc hardware not behaving quite right, close
>> but not quite right. Kernel PPS behaves the same way, I can't use a serial
>> port for kernel PPS and also pull serial data through it simultaneously, the
>> PPS disappears. But if I run the PPS into a port all by itself and never
>> try to read data from the port, it's fine. That's why I ended up leaving the
>> ports split, it just worked properly at that point. Otherwise trying to use
>> the port twice (once to get DCD signals and once for the TX/RX data) fails.
> Yes, I followed your saga on port-sparc. I'm still confused about why
> NMEA's PPSAPI support doesn't work using /dev/gpspps0 pointing to a
> different serial port than /dev/gps0, as it is then doing the same
> thing as NMEA + ATOM -- opening two ports, each only once. I
> understand why you would suspect as you do, but NMEA and ATOM really
> do use the same PPSAPI code, the only differences are how they number
> the seconds and how they open the PPS device.
Entertaining thread, no? However, I'm very thankful that the NetBSD
list listens more to users posting questions than a few other lists.
It's also the only OS left that supports most of the serial port
functions on sparc hardware. I had tried OpenBSD first on the machine
about a year ago but somehow all of the code for the serial port
signaling (other than TX/RX) was removed from the codebase so OpenBSD
couldn't even support DCD, CTS, RTS or anything else. I got a couple
test patches from the list that didn't work and never heard back from
anyone again after that.
I'll be sure to try on the second system. I'm to the point where this
first system is now just about working so it's making me hesitant to
break it but I may just do it if I can't get the duplicate system
working in a reasonable time frame.
>> PS: 4.2.7 with the C99 snprintf workaround is working fine. No crashes or
> Now that is interesting, thanks for the info. Too often I don't hear
> when workarounds work, as there's no question burning in the mind of
> the person who had the problem once it's solved. That does seem to
> suggest a bug in the C runtime dtoa(), so if you want to track it
> down, a little test program which generates random doubles and dtoa()s
> them in a tight loop (printing their 64-bit hex dump first as two
> %lx's, four %lu's, or 8 %u's fed characters) might reveal a pattern to
> the inputs that send dtoa() into the infinite loop. Let me know if
> you want help writing such a test program.
Actually yes, if you have a suggestion for a test program that might
work better than the one I cobbled together I'll try it out. The one I
wrote is trying to use snprintf but perhaps it would be better to use
dtoa direct. I just based the code off of the snippet of ntpd.c that
you posted in that thread earlier. I'll send you what I've got if you'd
More information about the questions