On 11/17/2011 00:25, Dave Hart wrote:
On Thu, Nov 17, 2011 at 07:31, A C<[email protected]> 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
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.
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
like it.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
