Ignore one server except in extreme conditions?

[A C]

Is there a way to configure ntpd to ignore a particular clock unless
there is no other choice? What I'm thinking is to ignore the GPS
receiver NMEA data and use only the PPS plus Internet servers for most
of the synchronization. But if the Internet servers go down, accept the
GPS NMEA data for seconds numbering and let the tick be controlled by PPS.

I guess I'm asking for something opposite to the "prefer" flag, a "not
unless you have to" flag. The GPS does get selected among the various
clock sources but it's the worst of the bunch with respect to jitter and
offset. Those two wander all over while the rest of the Internet
servers and the PPS are stable. It is almost never rejected as an
outlier or false ticker even if it's way out of line with the other sources.

[Harlan Stenn]

And you are sure the PPS signal goes away when your NMEA source is no
syncd?

H

[A C]

On 11/15/2011 22:09, Harlan Stenn wrote:
> And you are sure the PPS signal goes away when your NMEA source is no
> syncd?

I'm not talking about losing sync on the GPS. I'm talking about
purposefully ignoring the NMEA data because it has a lot more drift than
the other servers so I'd like ntpd to use only PPS plus Internet when
the Internet is available. If the Internet ceases to be available, fall
back to the NMEA. Obviously if the GPS loses sync at the same time as a
loss of the Internet connection then the clock is just going to wander
away but would eventually come back when sync/connections are restored.

In my case, I am supplying two different refclocks with the single GPS.
The PPS is being fed through a serial port using the PPS refclock
(22). The NMEA refclock (20) data is coming from a different serial
port with no PPS signal and the clock is not configured to us its own
PPS routines.

[Harlan Stenn]

OK, and you understand that the NMEA sentence is expected to be correct
to only +/- 0.5sec, as the PPS signal is un-numbered and the purpose of
the NMEA data is to identify the time at the pulse of the PPS signal.

H

[A C]

Yes, the PPS is unnumbered however if I have valid and reachable
Internet server then I have numbers from them, too. PPS is only serving
as the clock tick, I understand that fully. But you're missing the
point of my question:

I don't care about the exact accuracy of the NMEA. I mention the NMEA
to point out that it is unstable and I would like it to not be part of
the timing computations unless no other server is available. That's
what I'm asking. If I use the "noselect" option, it is never a valid
time server no matter what. If I use "prefer", it's always a valid time
server. I'm asking if there's a way to configure ntpd such that
everything EXCEPT NMEA is a preferred peer unless all the other peers
are dead in which case fall back to NMEA (all predicated on the GPS
being functional, if not that's a completely different issue).

Right now, it is almost always part of the valid group of servers. It
is never marked as a false ticker or an outlier even if its data is
terrible compared to any of the other five configured Internet servers.

[Harlan Stenn]

What sort of offset/jitter are you seeing on the NMEA signal? By
default we expect it to be correct to about 2ms.

H

[David Lord]

A C wrote:
> Is there a way to configure ntpd to ignore a particular clock unless
> there is no other choice? What I'm thinking is to ignore the GPS
> receiver NMEA data and use only the PPS plus Internet servers for most
> of the synchronization. But if the Internet servers go down, accept the
> GPS NMEA data for seconds numbering and let the tick be controlled by PPS.

Doesn't ntp do that already?

If you have nmea + pps the pps will be used for sync.
If your gps + pps is down your internet servers will be used for sync.


Wed Nov 2 00:00:00 GMT 2011
remote refid st t when poll reach delay offset
jitter

==============================================================================
*GPS_NMEA(2) .GPSb. 0 l 29 64 377 0.000 -52.888
11.213
oPPS(2) .PPSb. 0 l 28 64 377 0.000 -0.001
0.004
p4x2400b.home.l 192.168.59.61 2 u 6 64 377 1.157 -3.917
0.908
p4x2400c.home.l 192.168.59.61 2 u 19 64 377 0.729 2.298
0.619
pd6000e1.home.l 192.168.59.61 2 u 11 64 377 0.544 1.767
0.551
pd6000e2.home.l 192.168.59.61 2 u 54 64 377 0.494 0.983
0.535
+ntp1.lordynet.o 81.187.61.74 2 u 7 128 377 0.854 2.089
0.520
+ntp0.lordynet.o .MSFa. 1 u 1 128 377 0.934 1.548
0.572

offset: -0.000001 s
frequency: -35.833 ppm
poll adjust: 30
watchdog timer: 28 s
ntp_gettime() returns code 0 (OK)
time d25b0680.8615a8ac Wed, Nov 2 2011 0:00:00.523, (.523768144),
maximum error 14934 us, estimated error 4 us, TAI offset 34
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 1.094 us, frequency -35.833 ppm, interval 256 s,
maximum error 14934 us, estimated error 4 us,
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
time constant 6, precision 0.001 us, tolerance 496 ppm,
pps frequency -35.833 ppm, stability 0.020 ppm, jitter 2.688 us,
intervals 17356, jitter exceeded 15439, stability exceeded 0, errors 19.


David

[A C]

On 11/16/2011 00:15, Harlan Stenn wrote:
> What sort of offset/jitter are you seeing on the NMEA signal? By
> default we expect it to be correct to about 2ms.

I posted more data in another reply but the NMEA tends to have offsets
of +/- 50 ms and jitters of +/- 10 ms while the PPS and Internet servers
are all much more stable. PPS has a jitter of only 0.061 ms reported by
ntpd (but probably better than that, the jitter value never drops below
0.061 for any server, in fact it's present in the entire billboard
jitter column when ntpd first starts up so it must be a floating point
calculation/rounding issue). A couple of the Internet servers can
wander off if the network is bad but most of them stay within +/- 5 ms
of offset and +/- 1 ms of jitter.


This is from my other reply:

By way of example, one of the Internet servers in my peer list has an
offset of 1.887 and jitter of 0.586 and is labeled an outlier. The NMEA
data at that same moment has an offset of 21.863 and a jitter of 10.290
and it's labeled as accepted.

[A C]

On 11/16/2011 03:20, David Lord wrote:
> A C wrote:
>> Is there a way to configure ntpd to ignore a particular clock unless
>> there is no other choice? What I'm thinking is to ignore the GPS
>> receiver NMEA data and use only the PPS plus Internet servers for most
>> of the synchronization. But if the Internet servers go down, accept
>> the GPS NMEA data for seconds numbering and let the tick be controlled
>> by PPS.
>
> Doesn't ntp do that already?
>
> If you have nmea + pps the pps will be used for sync.
> If your gps + pps is down your internet servers will be used for sync.
>

Not if PPS and NMEA are independent clock sources. Two lines in the
config file, one is 127.127.22.1 and the other is 127.127.20.1 (not
including the Internet servers). The PPS is synced almost all the time
but the choice of clock sources moves around from Internet to NMEA. In
my case the NMEA sentences wander but the NMEA clock is always listed as
a member of the accepted clocks (the "+" indicator) even if its own data
is so bad that another clock with similar offset and jitter has been
labeled an outlier/false ticker.

Note I'm not talking at all about the GPS going away. I'm talking about
the NMEA sentence wandering around dragging the clock with it because
it's part of the overall computed solution. By way of example, one of

the Internet servers in my peer list has an offset of 1.887 and jitter
of 0.586 and is labeled an outlier. The NMEA data at that same moment
has an offset of 21.863 and a jitter of 10.290 and it's labeled as accepted.

What I'm looking to do is to ignore the NMEA in favor of the Internet
clocks as long as they are available then fall back to NMEA in case the
network drops out.

Before anyone asks, the GPS itself is fine and functioning normally. It
was designed as a PPS reference for a fixed location telemetry network
over GSM. The PPS portion is very accurate but it sacrifices some
stability in the NMEA data to achieve the PPS stability (PPS pulse
generation is higher priority for the CPU than NMEA generation). Since
the telemetry device was intended to be in a fixed location it wasn't
considered important to have very precise NMEA data, only PPS pulses to
control timing and slotting. Jitter on the PPS signal is reported by
ntpd to be 0.061 ms (ntpd never shows jitter numbers lower than this for
any source, must be something in the floating point calculations) and
doesn't wander away from that (I can see the same thing on an
oscilloscope, the pulse is quite stable).

[Miguel Gonçalves]

Hi!

On 16 November 2011 16:11, A C <agcarv...@acarver.net> wrote:

> On 11/16/2011 00:15, Harlan Stenn wrote:
>
>> What sort of offset/jitter are you seeing on the NMEA signal? By
>> default we expect it to be correct to about 2ms.
>>
>
> I posted more data in another reply but the NMEA tends to have offsets of
> +/- 50 ms and jitters of +/- 10 ms while the PPS and Internet servers are
> all much more stable. PPS has a jitter of only 0.061 ms reported by ntpd
> (but probably better than that, the jitter value never drops below 0.061
> for any server, in fact it's present in the entire billboard jitter column
> when ntpd first starts up so it must be a floating point
> calculation/rounding issue). A couple of the Internet servers can wander
> off if the network is bad but most of them stay within +/- 5 ms of offset
> and +/- 1 ms of jitter.
>

In one of my servers I have

tos mindist 0.250

This enables PPS and NMEA to differ 250 ms. I hope I am not saying anything
wrong but you can check the NTP documentation regarding this keyword.

Cheers,
Miguel

[Dave Hart]

On Wed, Nov 16, 2011 at 16:14, A C <agcarv...@acarver.net> wrote:
> The PPS is synced almost all the time but the choice of
> clock sources moves around from Internet to NMEA.  In my case the NMEA
> sentences wander but the NMEA clock is always listed as a member of the
> accepted clocks (the "+" indicator) even if its own data is so bad that
> another clock with similar offset and jitter has been labeled an
> outlier/false ticker.
>
> Note I'm not talking at all about the GPS going away.  I'm talking about the
> NMEA sentence wandering around dragging the clock with it because it's part
> of the overall computed solution.

No, it's not part of the solution. When you have 'o' in the peers
billboard, the PPS is disciplining the clock alone. Ignore the rest
of the tally codes as long as the PPS is reachable.

>  By way of example, one of the Internet
> servers in my peer list has an offset of 1.887 and jitter of 0.586 and is
> labeled an outlier.  The NMEA data at that same moment has an offset of
> 21.863 and a jitter of 10.290 and it's labeled as accepted.

This is because NTP doesn't depend solely on offset and jitter. Root
dispersion plays a factor, and reference clocks (even NMEA) have a 0
root dispersion, while your internet sources have root dispersion
accumulated from the error in your path to them and their path to the
stratum 1 server with the refclock.

> What I'm looking to do is to ignore the NMEA in favor of the Internet clocks
> as long as they are available then fall back to NMEA in case the network
> drops out.
>
> Before anyone asks, the GPS itself is fine and functioning normally.  It was
> designed as a PPS reference for a fixed location telemetry network over GSM.
>  The PPS portion is very accurate but it sacrifices some stability in the
> NMEA data to achieve the PPS stability (PPS pulse generation is higher
> priority for the CPU than NMEA generation).  Since the telemetry device was
> intended to be in a fixed location it wasn't considered important to have
> very precise NMEA data, only PPS pulses to control timing and slotting.
>  Jitter on the PPS signal is reported by ntpd to be 0.061 ms (ntpd never
> shows jitter numbers lower than this for any source, must be something in
> the floating point calculations) and doesn't wander away from that (I can
> see the same thing on an oscilloscope, the pulse is quite stable).

The reason you see a minimum jitter reported of 0.061 is the precision
of the host clock. 1/16384 is 0.061 msec. When ntpd starts, it
measures the minimum nonzero difference between subsequent reads of
the system clock. Your host clock is in the neighborhood of that
value. ntpd converts the precision to a power of 2 -- yours is coming
up with precision 2 ** -16, and ntpd is using that precision as a
floor to the reported jitter values. In older versions of ntpd (4.2.4
and earlier), the delay values are also floored at the precision, and
David Taylor and I have seen evidence that delay flooring may be
useful for low-precision host clocks (where ntpd measures precision 2
** -10 or 0.977 msec).

The idea is your host clock is incapable of measuring intervals less
than about 2 ** -16 seconds. As a result, ntpd "fuzzes" its reads of
the system clock replacing the bits below 2 ** -16 with
normally-distributed random noise. It also conveys its -16 precision
in its responses to network clients, which factor it into the
calculation of the dispersion attributable to the last NTP hop. The
response also includes the root dispersion as seen by the server. The
root dispersion of a client using your server is the root dispersion
your host has calculated plus the peer dispersion your client
calculates factoring in the network delay, your clock precision and
its clock precision.

With a PPS, you should not care about the peer billboard tally codes
dancing once PPS is controlling the clock. All you need worry about
is ensuring that whether or not you have internet sources, ntpd is
able to determine the seconds numbering so it can use the PPS. From
your report that the NMEA data is arriving within +/- 50 msec of the
PPS, this should be a slam dunk, and there should be no need to even
use a separately-listed PPS source in ntp.conf -- you should be able
to to use a single NMEA refclock with PPS enabled, and thereby not
need prefer anywhere. NMEA will number the seconds for its associated
PPS.

Note the NMEA driver supports two different time fudges. fudge time1
applies to the PPS signal, fudge time2 to the NMEA end-of-line
timestamp. time2 compensates both for the systemic delay after the
top of the second before the NMEA sentence being used starts arriving,
and for the time to transmit that sentence through its terminating
CR/LF. fudge time1 compensates for systemic delay of your system in
timestamping the PPS, including cable delay and debouncing delay in
the UART before it recognizes the state change of CTS, and delay
between the UART asserting the interrupt and the interrupt routine's
execution, and the time to actually read the system clock.

Cheers,
Dave Hart

[David Lord]

A C wrote:
> On 11/16/2011 03:20, David Lord wrote:
>> A C wrote:
>>> Is there a way to configure ntpd to ignore a particular clock unless
>>> there is no other choice? What I'm thinking is to ignore the GPS
>>> receiver NMEA data and use only the PPS plus Internet servers for most
>>> of the synchronization. But if the Internet servers go down, accept
>>> the GPS NMEA data for seconds numbering and let the tick be controlled
>>> by PPS.
>>
>> Doesn't ntp do that already?
>>
>> If you have nmea + pps the pps will be used for sync.
>> If your gps + pps is down your internet servers will be used for sync.
>>
>
> Not if PPS and NMEA are independent clock sources. Two lines in the
> config file, one is 127.127.22.1 and the other is 127.127.20.1 (not
> including the Internet servers). The PPS is synced almost all the time
> but the choice of clock sources moves around from Internet to NMEA. In
> my case the NMEA sentences wander but the NMEA clock is always listed as
> a member of the accepted clocks (the "+" indicator) even if its own data
> is so bad that another clock with similar offset and jitter has been
> labeled an outlier/false ticker.
>

*GPS_NMEA(2) .GPSb. 0 l 29 64 377 0.000 -52.888 11.213

offset: -0.000001 s

So are you saying that the -52.888ms is making a significant
contribution to the offset of -0.000001s ?


David

[A C]

Yes, if I disable the NMEA source with a "noselect" and leave the
Internet servers and the PPS clock (22) running, my overall system
offset drops and holds at a few tens of microseconds. If I leave it in,
the system offset wanders around. The magnitude of the wander appears
to correlate with the magnitude of the NMEA offset. For very large NMEA
offsets (sometimes exceeding +/- 50ms) the system itself starts to drift
away to large ms offsets. Overall I seem to get better performance
without the NMEA driver contributing than with it included hence the
desire to make it accessible only when all the other Internet sources
fail (but GPS is still working).

Both PPS and NMEA are coming from the same physical GPS just using two
serial ports, one for the PPS and one for the serial data (this split is
required due to serial port driver limitations).

[Harlan Stenn]

A C wrote:
> > So are you saying that the -52.888ms is making a significant
> > contribution to the offset of -0.000001s ?
>
> Yes, if I disable the NMEA source with a "noselect" and leave the
> Internet servers and the PPS clock (22) running, my overall system
> offset drops and holds at a few tens of microseconds. If I leave it in,
> the system offset wanders around. The magnitude of the wander appears
> to correlate with the magnitude of the NMEA offset. For very large NMEA
> offsets (sometimes exceeding +/- 50ms) the system itself starts to drift
> away to large ms offsets. Overall I seem to get better performance
> without the NMEA driver contributing than with it included hence the
> desire to make it accessible only when all the other Internet sources
> fail (but GPS is still working).

This doesn't make a lot of sense. NMEA is known to be pretty much
useless without a PPS. So if your NMEA time data is "off" I gotta wonder
if your PPS is "off" too.

Does your GPS report any "health" information?

> Both PPS and NMEA are coming from the same physical GPS just using two
> serial ports, one for the PPS and one for the serial data (this split is
> required due to serial port driver limitations).

Are you *certain* that your GPS is producing a "locked" PPS signal when
the NMEA time is wandering?

H

[unruh]

On 2011-11-16, A C <agcarv...@acarver.net> wrote:
> On 11/15/2011 22:09, Harlan Stenn wrote:
>> And you are sure the PPS signal goes away when your NMEA source is no
>> syncd?
>
> I'm not talking about losing sync on the GPS. I'm talking about
> purposefully ignoring the NMEA data because it has a lot more drift than

Tthe NMEA certainly should not have more drift. Maybe more jitter.
You should use the nmea for numbering the seconds, and pps for defining
the second start. You do not care that the nmea is 200ms off if you do
not use it for the subsecond timing.

[Dave Hart]

On Wed, Nov 16, 2011 at 23:09, A C <agcarv...@acarver.net> wrote:
> Yes, if I disable the NMEA source with a "noselect" and leave the Internet
> servers and the PPS clock (22) running, my overall system offset drops and
> holds at a few tens of microseconds.  If I leave it in, the system offset
> wanders around.  The magnitude of the wander appears to correlate with the
> magnitude of the NMEA offset.  For very large NMEA offsets (sometimes
> exceeding +/- 50ms) the system itself starts to drift away to large ms
> offsets.  Overall I seem to get better performance without the NMEA driver
> contributing than with it included hence the desire to make it accessible
> only when all the other Internet sources fail (but GPS is still working).

Which version of ntpd are you seeing this with? Based on

http://www.eecis.udel.edu/~mills/ntp/html/prefer.html

I would expect the PPS to control the clock on its own, when it's
active. The combine algorithm is run, but the averaged offset is then
replaced with the PPS offset which actually drives the clock. I
suspect you're running 4.2.6 or older and it may not be following the
current mitigation rules.

> Both PPS and NMEA are coming from the same physical GPS just using two
> serial ports, one for the PPS and one for the serial data (this split is
> required due to serial port driver limitations).

You don't have to use two separate drivers for NMEA and PPS, even with
the signals coming in on different serial ports. At least in 4.2.7,
the NMEA driver tries /dev/gpsppsX for PPSAPI before falling back to
using the same port as for NMEA, /dev/gpsX. In this configuration,
you don't need to mark any peers as prefer, which I much prefer
compared to using ATOM and marking all your network peers and NMEA
prefer, because prefer has profound effects on mitigation which are
tricky to wrap your head around.

I encourage you to try a recent 4.2.7 ntpd with only the NMEA driver
with its PPS handling enabled

Cheers,
Dave Hart

[Richard B. Gilbert]

Which GPS receiver are you using? I have an old Motorola that has been
ticking away flawlessly for the last six or seven years.

I found that getting time over the internet was not very satisfactory.
From local midnight until about 7:00 AM it was pretty good but once
people woke up and started using the internet, NTP wasn't working very well.

I'd offer to serve time but my contract with Comcast forbids operating a
server of any kind!

[David J Taylor]

> On 11/16/2011 12:47 AM, A C wrote:

[]

>> I guess I'm asking for something opposite to the "prefer" flag, a "not
>> unless you have to" flag. The GPS does get selected among the various
>> clock sources but it's the worst of the bunch with respect to jitter
>> and
>> offset. Those two wander all over while the rest of the Internet
>> servers
>> and the PPS are stable. It is almost never rejected as an outlier or
>> false ticker even if it's way out of line with the other sources.

Could you fudge its stratum to a very high value - 10 for instance?

Cheers,
David

[A C]

I compiled the latest development version 4.2.7p234. The NMEA driver
does not pick up /dev/gpspps for whatever reason even if I have the
symlink defined. PPS is only working through the PPS driver, it does
not function with the NMEA driver and I suspect it's related to the
serial drivers. I haven't marked any peers as prefer in any way
including the NMEA source. This behavior is seen using all the sources
without the keyword.

[A C]

On 11/16/2011 17:41, Richard B. Gilbert wrote:
> On 11/16/2011 12:47 AM, A C wrote:
>> Is there a way to configure ntpd to ignore a particular clock unless
>> there is no other choice? What I'm thinking is to ignore the GPS
>> receiver NMEA data and use only the PPS plus Internet servers for most
>> of the synchronization. But if the Internet servers go down, accept the
>> GPS NMEA data for seconds numbering and let the tick be controlled by
>> PPS.
>>
>> I guess I'm asking for something opposite to the "prefer" flag, a "not
>> unless you have to" flag. The GPS does get selected among the various
>> clock sources but it's the worst of the bunch with respect to jitter and
>> offset. Those two wander all over while the rest of the Internet servers
>> and the PPS are stable. It is almost never rejected as an outlier or
>> false ticker even if it's way out of line with the other sources.
>
> Which GPS receiver are you using? I have an old Motorola that has been
> ticking away flawlessly for the last six or seven years.

This is a Globalsat ET212 OEM board. It's running just fine it just
doesn't give high priority to ensuring that the NMEA sentences are
emitted in a timely manner. It spends most of its CPU cycles ensuring
the PPS is on time and stable in phase. I can watch the NMEA sentence
wander around relative to the PPS but the PPS doesn't move a bit.

> I found that getting time over the internet was not very satisfactory.
> From local midnight until about 7:00 AM it was pretty good but once
> people woke up and started using the internet, NTP wasn't working very
> well.

Internet time with local PPS seems to be doing quite well. I may just
give up and drop the NMEA entirely and use external force to switch
configurations if a net connection drops but that means a restart of ntpd.

> I'd offer to serve time but my contract with Comcast forbids operating a
> server of any kind!

The idea is to provide a local reference clock to the rest of my
machines on the home network (including IP cameras, the various routers,
the computers, and an IP clock). I just want all those to work even if
the network drops.

[A C]

Yes, I'm certain the PPS signal is not wandering. That's what this
particular GPS receiver was designed to do. It keeps the phase of PPS
steady but sacrifices the NMEA sentence timing. Health reports are
fine, it passes all the diagnostics and is locked on an average of seven
satellites. Most of the time it's more like nine or ten.

[Dave Hart]

On Thu, Nov 17, 2011 at 06:35, A C <agcarv...@acarver.net> wrote:
> On 11/16/2011 16:09, Dave Hart wrote:
>> You don't have to use two separate drivers for NMEA and PPS, even with
>> the signals coming in on different serial ports.  At least in 4.2.7,
>> the NMEA driver tries /dev/gpsppsX for PPSAPI before falling back to
>> using the same port as for NMEA, /dev/gpsX.  In this configuration,
>> you don't need to mark any peers as prefer, which I much prefer
>> compared to using ATOM and marking all your network peers and NMEA
>> prefer, because prefer has profound effects on mitigation which are
>> tricky to wrap your head around.
>>
>> I encourage you to try a recent 4.2.7 ntpd with only the NMEA driver
>> with its PPS handling enabled
>
> I compiled the latest development version 4.2.7p234.  The NMEA driver does
> not pick up /dev/gpspps for whatever reason even if I have the symlink
> defined.

Did you try /dev/gpspps0, assuming server 127.127.20.0? Did you
"fudge 127.127.20.0 flag1 1" to enable NMEA's PPSAPI support?

Cheers,
Dave Hart

[A C]

Yeah, I did all that and it never worked. It would not find and use the
PPS signal. But as soon as I split it to its own driver (and got the
flags right on the PPS driver) it worked fine.

[Dave Hart]

On Thu, Nov 17, 2011 at 06:51, A C <agcarv...@acarver.net> wrote:
> On 11/16/2011 22:43, Dave Hart wrote:
>> On Thu, Nov 17, 2011 at 06:35, A C<agcarv...@acarver.net>  wrote:
>>> I compiled the latest development version 4.2.7p234.  The NMEA driver
>>> does not pick up /dev/gpspps for whatever reason even if I have the
>>> symlink defined.
>>
>> Did you try /dev/gpspps0, assuming server 127.127.20.0?  Did you
>> "fudge 127.127.20.0 flag1 1" to enable NMEA's PPSAPI support?
>

> Yeah, I did all that and it never worked.  It would not find and use the PPS
> signal.  But as soon as I split it to its own driver (and got the flags
> right on the PPS driver) it worked fine.

I can't see why not. When /dev/gpsppsX can be opened, NMEA's PPSAPI
opens it and uses that device with PPSAPI using the same common PPSAPI
code as ATOM. I am baffled. If you add

logconfig =clockall +peerall +sysall +syncall
and possibly
logfile /some/path/to/ntpd.log

with the NMEA-only PPSAPI configuration, do you see a message logged
to syslog or ntpd.log including " flag1 1 but PPSAPI fails"? If so,
try changing refclock_nmea.c as follows:

pps_fd = open(device, PPSOPENMODE, S_IRUSR | S_IWUSR);

if (-1 == pps_fd)
pps_fd = pp->io.fd;

change the if block to:

if (-1 == pps_fd) {
pps_fd = pp->io.fd;
msyslog(LOG_WARNING, "%s cannot open %s: %d %m",
refnumtoa(&peer->srcadr), errno);
}

And try again, so we can narrow down the reason for the failure.

Thanks for you patience,
Dave Hart

[Dave Hart]

Ooops, see corrected suggested code:

On Thu, Nov 17, 2011 at 07:02, Dave Hart <ha...@ntp.org> wrote:
> change the if block to:
>
>        if (-1 == pps_fd) {
>                pps_fd = pp->io.fd;
>                msyslog(LOG_WARNING, "%s cannot open %s: %d %m",
>                        refnumtoa(&peer->srcadr), errno);
>        }
>
> And try again, so we can narrow down the reason for the failure.

That should be:

       if (-1 == pps_fd) {
               pps_fd = pp->io.fd;
               msyslog(LOG_WARNING, "%s cannot open %s: %d %m",

                       refnumtoa(&peer->srcadr), device, errno);
       }

The version above left out device. There is still one more format
specifier than argument, %m, but it doesn't consume an argument.

Red faced,
Dave Hart

[A C]

I will probably try this later on another identical system. 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. 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.



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

[Dave Hart]

On Thu, Nov 17, 2011 at 07:31, A C <agcarv...@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

[A C]

On 11/17/2011 00:25, Dave Hart wrote:
> On Thu, Nov 17, 2011 at 07:31, A C<agcarv...@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
>> 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.