[ntp:questions] Ignore one server except in extreme conditions?

Dave Hart hart at ntp.org
Thu Nov 17 08:25:09 UTC 2011


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.

> I have all the hardware required to create a duplicate system, I just need a
> bit of time to do it.  I may also have to try and find a couple SBUS serial
> cards and see if things work any better with them.
>
> 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.

> PS: 4.2.7 with the C99 snprintf workaround is working fine.  No crashes or
> lockups.

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.

Cheers,
Dave Hart


More information about the questions mailing list