Disable or restart PPS in gpsd?

[Alexander Carver]

I'm having some trouble with PPS on version 3.6 in kernel 3.2

Once in a while I get an issue with the PPS signal that seems to hang up
gpsd and fills the system log with:

Sep 2 20:06:57 tick gpsd[14556]: gpsd:ERROR: KPPS kernel PPS failed
Sep 2 20:06:58 tick gpsd[14556]: gpsd:ERROR: KPPS kernel PPS failed
Sep 2 20:06:58 tick gpsd[14556]: gpsd:ERROR: KPPS kernel PPS failed
Sep 2 20:06:59 tick gpsd[14556]: gpsd:ERROR: KPPS kernel PPS failed
Sep 2 20:06:59 tick gpsd[14556]: gpsd:ERROR: KPPS kernel PPS failed
Sep 2 20:07:00 tick gpsd[14556]: gpsd:ERROR: KPPS kernel PPS failed

I get this once per second, as you can see, until I restart gpsd. The
problem is that gpsd is also creating the pps0 device which ntpd is
attempting to use as well. Restarting gpsd alone without restarting
ntpd does not remove pps0 and instead recreates it as pps1. I have to
restart both services to fix gpsd and restore pps0. Using ldattach
outside of gpsd prevents gpsd from connecting to the serial port at all.

I would either like to let ldattach handle the pps0 device and somehow
let gpsd connect to the serial port (I'm missing something here to do
this with ldattach since my understanding is that it should be possible
to do) or be able to kick gpsd without restarting it completely so that
I don't have to restart ntpd each time.

[Alexander Carver]

Yo Alexander!
On Wed, 03 Sep 2014 00:06:09 -0700

Post by Alexander Carver
I'm having some trouble with PPS on version 3.6 in kernel 3.2

Both those are petty old, you'll need to upgrade.

The kernel is the latest image in Debian's stable branch. There isn't
one available up from that. I can replace gpsd with a tarball instead
of a package, not sure it will help in this case, though.

Post by Alexander Carver
I get this once per second, as you can see, until I restart gpsd. The
problem is that gpsd is also creating the pps0 device which ntpd is
attempting to use as well. Restarting gpsd alone without restarting
ntpd does not remove pps0 and instead recreates it as pps1. I have to
restart both services to fix gpsd and restore pps0.

If gpsd is using the PPS then no need for ntpd to use PPS as well.
Avoid the confusion and just let gps handle the PPS fpr ntpd.

It's not working properly which is why I'm resorting to ntpd's PPS
driver. If there's even the slightest hiccup in the SHM(0) stream, ntpd
boots both SHM's and I'm left with nothing. The SHM(1) stream is also
unstable (jitter) compared to the actual PPS signal. Using the PPS
driver, the jitter is much better. Also with the PPS driver, the system
will fall back to another source if gpsd fails to deliver a timestamp
properly and the PPS will continue ticking using the next available
source for numbering the seconds. The problem then is my logs fill up
with once-per-second messages about the KPPS error until I restart gpsd.

[Gary E. Miller]

Yo Alexander!

On Wed, 03 Sep 2014 00:18:40 -0700

Post by Alexander Carver

Yo Alexander!
On Wed, 03 Sep 2014 00:06:09 -0700

Post by Alexander Carver
I'm having some trouble with PPS on version 3.6 in kernel 3.2

Both those are petty old, you'll need to upgrade.

The kernel is the latest image in Debian's stable branch. There isn't
one available up from that. I can replace gpsd with a tarball instead
of a package, not sure it will help in this case, though.

Just do not expect any patches on such an old gpsd.

Post by Alexander Carver

Post by Alexander Carver
I get this once per second, as you can see, until I restart gpsd.
The problem is that gpsd is also creating the pps0 device which
ntpd is attempting to use as well. Restarting gpsd alone without
restarting ntpd does not remove pps0 and instead recreates it as
pps1. I have to restart both services to fix gpsd and restore
pps0.

If gpsd is using the PPS then no need for ntpd to use PPS as well.
Avoid the confusion and just let gps handle the PPS fpr ntpd.

It's not working properly which is why I'm resorting to ntpd's PPS
driver. If there's even the slightest hiccup in the SHM(0) stream,
ntpd boots both SHM's and I'm left with nothing. The SHM(1) stream
is also unstable (jitter) compared to the actual PPS signal. Using
the PPS driver, the jitter is much better. Also with the PPS driver,
the system will fall back to another source if gpsd fails to deliver
a timestamp properly and the PPS will continue ticking using the next
available source for numbering the seconds. The problem then is my
logs fill up with once-per-second messages about the KPPS error until
I restart gpsd.

Sounds like you just want KPPS off in gpsd. So just compile it without
pps support.

What sort of jitter difference are you seeing?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
***@rellim.com Tel:[phone]

[Alexander Carver]

Yo Alexander!
On Wed, 03 Sep 2014 00:18:40 -0700

Post by Alexander Carver

Yo Alexander!
On Wed, 03 Sep 2014 00:06:09 -0700

Post by Alexander Carver
I'm having some trouble with PPS on version 3.6 in kernel 3.2

Both those are petty old, you'll need to upgrade.

The kernel is the latest image in Debian's stable branch. There isn't
one available up from that. I can replace gpsd with a tarball instead
of a package, not sure it will help in this case, though.

Just do not expect any patches on such an old gpsd.

Of course not. As I said I can compile a new version which is fine by
me, I just can't go up on the kernel right now since a newer image is
not available in the stable branch. I may at a later time investigate
the backports which I understand may potentially be up to 3.14.

Post by Alexander Carver

Post by Alexander Carver
I get this once per second, as you can see, until I restart gpsd.
The problem is that gpsd is also creating the pps0 device which
ntpd is attempting to use as well. Restarting gpsd alone without
restarting ntpd does not remove pps0 and instead recreates it as
pps1. I have to restart both services to fix gpsd and restore
pps0.

If gpsd is using the PPS then no need for ntpd to use PPS as well.
Avoid the confusion and just let gps handle the PPS fpr ntpd.

It's not working properly which is why I'm resorting to ntpd's PPS
driver. If there's even the slightest hiccup in the SHM(0) stream,
ntpd boots both SHM's and I'm left with nothing. The SHM(1) stream
is also unstable (jitter) compared to the actual PPS signal. Using
the PPS driver, the jitter is much better. Also with the PPS driver,
the system will fall back to another source if gpsd fails to deliver
a timestamp properly and the PPS will continue ticking using the next
available source for numbering the seconds. The problem then is my
logs fill up with once-per-second messages about the KPPS error until
I restart gpsd.

Sounds like you just want KPPS off in gpsd. So just compile it without
pps support.

If I disable KPPS in gpsd will it still create the pps0 device or will
it skip that part? If it skips that, how do I share the port with
ldattach and gpsd?

What sort of jitter difference are you seeing?

Jitter using the PPS ATOM driver is nominally 6 microseconds. Jitter
using SHM(1) from gpsd is up to 5 milliseconds. So about 1000 times
worse. And this assumes that KPPS doesn't go belly up for some reason.

Right now, SHM(0) isn't even reporting, gpsd is spewing KPPS errors, but
ntpd's ATOM is happily ticking away with 1 microsecond jitter and less
than 5 microseconds offset. I used another one of my machines as a
second preferred peer for seconds counting which is why ATOM is still
running even though SHM(0) is dead. SHM(1) does not work at all if
ntpd's ATOM is configured and when I only use SHM(0,1) with no ATOM,
SHM(1) shows the bad jitter compared to ATOM's jitter.

[Gary E. Miller]

Yo Alexander!

On Wed, 03 Sep 2014 12:59:41 -0700

Post by Alexander Carver

Post by Gary E. Miller
Just do not expect any patches on such an old gpsd.

Of course not. As I said I can compile a new version which is fine by
me, I just can't go up on the kernel right now since a newer image is
not available in the stable branch. I may at a later time investigate
the backports which I understand may potentially be up to 3.14.

I do not think there is anything in newer kernels to affect this.

Post by Alexander Carver

Post by Gary E. Miller
Sounds like you just want KPPS off in gpsd. So just compile it
without pps support.

If I disable KPPS in gpsd will it still create the pps0 device or will
it skip that part?

Creating pps0 is how KPPS works. No KPPS, then no pps0 from gpsd.

Post by Alexander Carver
If it skips that, how do I share the port with
ldattach and gpsd?

gpsd never uses ldattach. Port sharing of a GPS is problematic as
autobaud and auto configure will get confused between two GPS clients.

Just have ntpd read the GPS by way of gpsd.

Post by Alexander Carver

Post by Gary E. Miller
What sort of jitter difference are you seeing?

Jitter using the PPS ATOM driver is nominally 6 microseconds. Jitter
using SHM(1) from gpsd is up to 5 milliseconds. So about 1000 times
worse. And this assumes that KPPS doesn't go belly up for some reason.

Something wrong with your setup then. No way gpsd adds 1000x jitter.
I routinely see around 1 microSec using gpsd and SHM(). Even better
with chronyd.

Post by Alexander Carver
Right now, SHM(0) isn't even reporting, gpsd is spewing KPPS errors,
but ntpd's ATOM is happily ticking away with 1 microsecond jitter and
less than 5 microseconds offset.

Likely because only one can use the port at a time.

Post by Alexander Carver
I used another one of my machines
as a second preferred peer for seconds counting which is why ATOM is
still running even though SHM(0) is dead. SHM(1) does not work at
all if ntpd's ATOM is configured and when I only use SHM(0,1) with no
ATOM, SHM(1) shows the bad jitter compared to ATOM's jitter.

You gotta pick ntpd or gpsd to run the GPS. You can't share and get
good timing.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
***@rellim.com Tel:[phone]

[Alexander Carver]

Yo Alexander!
On Wed, 03 Sep 2014 12:59:41 -0700

Post by Alexander Carver

Post by Gary E. Miller
Just do not expect any patches on such an old gpsd.

Of course not. As I said I can compile a new version which is fine by
me, I just can't go up on the kernel right now since a newer image is
not available in the stable branch. I may at a later time investigate
the backports which I understand may potentially be up to 3.14.

I do not think there is anything in newer kernels to affect this.

Post by Alexander Carver

Post by Gary E. Miller
Sounds like you just want KPPS off in gpsd. So just compile it
without pps support.

If I disable KPPS in gpsd will it still create the pps0 device or will
it skip that part?

Creating pps0 is how KPPS works. No KPPS, then no pps0 from gpsd.

Post by Alexander Carver
If it skips that, how do I share the port with
ldattach and gpsd?

gpsd never uses ldattach. Port sharing of a GPS is problematic as
autobaud and auto configure will get confused between two GPS clients.
Just have ntpd read the GPS by way of gpsd.

You misunderstand. I need the pps device to allow ATOM to work. The
other times are coming in from SHM(0). So the GPSr is being read by
gpsd and passed over but the PPS portion just doesn't work well so I
need to share that single port with pps0 for ntpd and the rest (ttyS0)
for gpsd. I'm not asking ntpd to do anything with the port. I'm not
using the NMEA driver, I'm using ATOM. The GPS isn't even NMEA, it's SiRF.

Post by Alexander Carver

Post by Gary E. Miller
What sort of jitter difference are you seeing?

Jitter using the PPS ATOM driver is nominally 6 microseconds. Jitter
using SHM(1) from gpsd is up to 5 milliseconds. So about 1000 times
worse. And this assumes that KPPS doesn't go belly up for some reason.

Something wrong with your setup then. No way gpsd adds 1000x jitter.
I routinely see around 1 microSec using gpsd and SHM(). Even better
with chronyd.

There's very little setup that could go wrong. There's no config file
for gpsd as you're very well aware. It starts and goes and nothing else
to do. For ntpd, I point it at SHM(1) and it should collect data. It
does collect data (assuming ATOM is disabled, of course) but the jitter
is bad. If I do not use SHM(1) and stick to ATOM, the jitter is much
better.

Post by Alexander Carver
Right now, SHM(0) isn't even reporting, gpsd is spewing KPPS errors,
but ntpd's ATOM is happily ticking away with 1 microsecond jitter and
less than 5 microseconds offset.

Likely because only one can use the port at a time.

Well yes I understand that to an extent. SHM(0) plus ATOM actually does
work. It's SHM(1) that has trouble which is why I'm using ATOM in the
first place. ATOM does far better with jitter than SHM(1). SHM(0)'s
jitter is going to be bad since it's just the time stamps from the GPS
itself without the aid of the PPS as that comes in by SHM(1).

Post by Alexander Carver
I used another one of my machines
as a second preferred peer for seconds counting which is why ATOM is
still running even though SHM(0) is dead. SHM(1) does not work at
all if ntpd's ATOM is configured and when I only use SHM(0,1) with no
ATOM, SHM(1) shows the bad jitter compared to ATOM's jitter.

You gotta pick ntpd or gpsd to run the GPS. You can't share and get
good timing.

I'm not picking ntpd to run the GPS. I'm using gpsd to run the GPS.
But gpsd is giving me terrible results for PPS via SHM(1) so I must
resort to having ntpd listen to pps0 using ATOM. I'm still using SHM(0)
to get the regular GPS clock data for seconds numbering. This is not an
abnormal configuration, it's discussed many times in various places but
PPS via gpsd is just not doing well in terms of stability. PPS via the
pps0 device and sent to ntpd directly via ATOM does work fine.

[Alexander Carver]

Yo Alexander!
On Wed, 03 Sep 2014 17:22:22 -0700

Post by Alexander Carver

Post by Gary E. Miller
gpsd never uses ldattach. Port sharing of a GPS is problematic as
autobaud and auto configure will get confused between two GPS clients.
Just have ntpd read the GPS by way of gpsd.

You misunderstand. I need the pps device to allow ATOM to work.

I do not know what ATOM is.

ATOM is the Type 22 refclock. It listens for the PPS notices on the pps
device.

Post by Alexander Carver
The
other times are coming in from SHM(0). So the GPSr is being read by
gpsd and passed over but the PPS portion just doesn't work well so I
need to share that single port with pps0 for ntpd and the rest (ttyS0)
for gpsd.

I still do not think that is possible, maybe if you write a shim.

It seems to be possible for OpenBSD. In fact the documentation I've
found online suggests ldattach followed by gpsd in many cases.

Post by Alexander Carver
I'm not asking ntpd to do anything with the port. I'm not
using the NMEA driver, I'm using ATOM. The GPS isn't even NMEA, it's SiRF.

Really no benfit to using a SiRF in binary mode for time. And since
the SiRF binary sometimes needs a handshake doubly hard to duplex.

Post by Alexander Carver

Post by Gary E. Miller
Something wrong with your setup then. No way gpsd adds 1000x
jitter. I routinely see around 1 microSec using gpsd and SHM().
Even better with chronyd.

There's very little setup that could go wrong.

Yes, but something is clearly wrong, those are aweful numbers you see.

Right, they are awful coming through gpsd, they are great when using the
kernel's PPS mechanism directly (by way of the ATOM refclock).

Post by Alexander Carver
There's no config file
for gpsd as you're very well aware. It starts and goes and nothing
else to do. For ntpd, I point it at SHM(1) and it should collect
data. It does collect data (assuming ATOM is disabled, of course)
but the jitter is bad. If I do not use SHM(1) and stick to ATOM, the
jitter is much better.

Which is all very odd. I have never seen or heard of bad SHM(1) results
like you say you are getting.

Post by Alexander Carver

Post by Gary E. Miller

Post by Alexander Carver
Right now, SHM(0) isn't even reporting, gpsd is spewing KPPS
errors, but ntpd's ATOM is happily ticking away with 1 microsecond
jitter and less than 5 microseconds offset.

Likely because only one can use the port at a time.

Well yes I understand that to an extent. SHM(0) plus ATOM actually
does work. It's SHM(1) that has trouble which is why I'm using ATOM
in the first place. ATOM does far better with jitter than SHM(1).
SHM(0)'s jitter is going to be bad since it's just the time stamps
from the GPS itself without the aid of the PPS as that comes in by
SHM(1).

Yes, all SHM(0) is good for is coarse adjustment. The SHM(1) should
be riock stable.

Post by Alexander Carver

Post by Gary E. Miller
You gotta pick ntpd or gpsd to run the GPS. You can't share and get
good timing.

I'm not picking ntpd to run the GPS. I'm using gpsd to run the GPS.
But gpsd is giving me terrible results for PPS via SHM(1) so I must
resort to having ntpd listen to pps0 using ATOM. I'm still using
SHM(0) to get the regular GPS clock data for seconds numbering. This
is not an abnormal configuration, it's discussed many times in
various places but PPS via gpsd is just not doing well in terms of
stability. PPS via the pps0 device and sent to ntpd directly via
ATOM does work fine.

Then why do you need gpsd at all? And if it is fine, there is no problem?

I need gpsd to read the GPS (because ntpd can't read a SiRF GPS) for
seconds numbering when there are issues with the network. It should be
the first clock to use among all the clocks with the PPS keeping
everything together. It just isn't working in a variety of ways.

When the KPPS error message shows up, gpsd turns off SHM(0) entirely.
It never turns back on. I have to restart gpsd to make that work but,
because of gpsd controlling the existence of /dev/pps0, I have to also
stop and restart ntpd or it won't be able to see pps0.

So that's also where I seem to be stuck. If I allow pps0 to be created
by gpsd, then I can read the GPS data through gpsd not just for ntpd but
for other programs as well and ntpd still has access to pps0. If I use
ldattach to create pps0 independently, then gpsd has no access to ttyS0
to get any GPS data.

One thing to note, when SHM(0) stops working, the TCP/IP port on gpsd is
still fine and gpsd is still reading data from the GPS. I can get
position data, satellite data, etc. all from the socket. It just stops
updating any of the SHMs unless I restart gpsd.

[Gary E. Miller]

Yo Alexander!

On Thu, 04 Sep 2014 06:18:36 -0700

Post by Alexander Carver

Yo Alexander!
On Wed, 03 Sep 2014 17:22:22 -0700

Post by Alexander Carver

Post by Gary E. Miller
gpsd never uses ldattach. Port sharing of a GPS is problematic
as autobaud and auto configure will get confused between two GPS
clients.
Just have ntpd read the GPS by way of gpsd.

You misunderstand. I need the pps device to allow ATOM to work.

I do not know what ATOM is.

ATOM is the Type 22 refclock. It listens for the PPS notices on the
pps device.

So just the ntpd PPS only reference clock?

Post by Alexander Carver

Post by Alexander Carver
The
other times are coming in from SHM(0). So the GPSr is being read
by gpsd and passed over but the PPS portion just doesn't work well
so I need to share that single port with pps0 for ntpd and the
rest (ttyS0) for gpsd.

I still do not think that is possible, maybe if you write a shim.

It seems to be possible for OpenBSD. In fact the documentation I've
found online suggests ldattach followed by gpsd in many cases.

The way the KPPS RFC works on BSD is only vaguely similar to how it
works on Linux. And since gpsd does not support KPPS on OpenBSD not
relevant at all to linux.

Post by Alexander Carver

Post by Alexander Carver

Post by Gary E. Miller
Something wrong with your setup then. No way gpsd adds 1000x
jitter. I routinely see around 1 microSec using gpsd and SHM().
Even better with chronyd.

There's very little setup that could go wrong.

Yes, but something is clearly wrong, those are aweful numbers you see.

Right, they are awful coming through gpsd, they are great when using
the kernel's PPS mechanism directly (by way of the ATOM refclock).

So, we agree something wrong on your setup.

Post by Alexander Carver

Post by Alexander Carver
I'm not picking ntpd to run the GPS. I'm using gpsd to run the
GPS. But gpsd is giving me terrible results for PPS via SHM(1) so
I must resort to having ntpd listen to pps0 using ATOM. I'm still
using SHM(0) to get the regular GPS clock data for seconds
numbering. This is not an abnormal configuration, it's discussed
many times in various places but PPS via gpsd is just not doing
well in terms of stability. PPS via the pps0 device and sent to
ntpd directly via ATOM does work fine.

Then why do you need gpsd at all? And if it is fine, there is no problem?

I need gpsd to read the GPS (because ntpd can't read a SiRF GPS) for
seconds numbering when there are issues with the network. It should
be the first clock to use among all the clocks with the PPS keeping
everything together. It just isn't working in a variety of ways.

And since SiRF binary adds nothing, turn it off, problem solved.

Post by Alexander Carver
When the KPPS error message shows up, gpsd turns off SHM(0) entirely.
It never turns back on. I have to restart gpsd to make that work but,
because of gpsd controlling the existence of /dev/pps0, I have to also
stop and restart ntpd or it won't be able to see pps0.

Yeah, the GPS stream got hosed. So don't do that.

Post by Alexander Carver
So that's also where I seem to be stuck. If I allow pps0 to be
created by gpsd, then I can read the GPS data through gpsd not just
for ntpd but for other programs as well and ntpd still has access to
pps0. If I use ldattach to create pps0 independently, then gpsd has
no access to ttyS0 to get any GPS data.

Yup, one or the other, that is how the RFC works, exclusive access.

Post by Alexander Carver
One thing to note, when SHM(0) stops working, the TCP/IP port on gpsd
is still fine and gpsd is still reading data from the GPS. I can get
position data, satellite data, etc. all from the socket. It just
stops updating any of the SHMs unless I restart gpsd.

So, back to my original thought, compile gpsd wwithout KPPS.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
***@rellim.com Tel:[phone]

[Alexander Carver]

Yo Alexander!
On Thu, 04 Sep 2014 06:18:36 -0700

Post by Alexander Carver

Yo Alexander!
On Wed, 03 Sep 2014 17:22:22 -0700

Post by Alexander Carver

Post by Gary E. Miller
gpsd never uses ldattach. Port sharing of a GPS is problematic
as autobaud and auto configure will get confused between two GPS
clients.
Just have ntpd read the GPS by way of gpsd.

You misunderstand. I need the pps device to allow ATOM to work.

I do not know what ATOM is.

ATOM is the Type 22 refclock. It listens for the PPS notices on the
pps device.

So just the ntpd PPS only reference clock?

Right, just PPS alone. It relies on other refclocks or servers to count
seconds.

Post by Alexander Carver

Post by Alexander Carver
The
other times are coming in from SHM(0). So the GPSr is being read
by gpsd and passed over but the PPS portion just doesn't work well
so I need to share that single port with pps0 for ntpd and the
rest (ttyS0) for gpsd.

I still do not think that is possible, maybe if you write a shim.

It seems to be possible for OpenBSD. In fact the documentation I've
found online suggests ldattach followed by gpsd in many cases.

The way the KPPS RFC works on BSD is only vaguely similar to how it
works on Linux. And since gpsd does not support KPPS on OpenBSD not
relevant at all to linux.

Ok, unfortunate but would have been nice. Obviously that's not going to
change.

Post by Alexander Carver

Post by Alexander Carver

Post by Gary E. Miller
Something wrong with your setup then. No way gpsd adds 1000x
jitter. I routinely see around 1 microSec using gpsd and SHM().
Even better with chronyd.

There's very little setup that could go wrong.

Yes, but something is clearly wrong, those are aweful numbers you see.

Right, they are awful coming through gpsd, they are great when using
the kernel's PPS mechanism directly (by way of the ATOM refclock).

So, we agree something wrong on your setup.

No, we disagree. My setup as far as I can tell is just fine and matches
pretty much everything documented on any site searchable by search
engines. SHM(1) is just doing a terrible job. There's nothing I can
configure in gpsd so there isn't anything for me to "setup" other than
plug in the GPS and point gpsd at it. The fact that ntpd is able to use
the kernel PPS signal quite well on its own implies that everything
starting from the GPS going up to gpsd is fine. Once inside gpsd,
something is not going well and SHM(1) is terrible.

Post by Alexander Carver

Post by Alexander Carver
I'm not picking ntpd to run the GPS. I'm using gpsd to run the
GPS. But gpsd is giving me terrible results for PPS via SHM(1) so
I must resort to having ntpd listen to pps0 using ATOM. I'm still
using SHM(0) to get the regular GPS clock data for seconds
numbering. This is not an abnormal configuration, it's discussed
many times in various places but PPS via gpsd is just not doing
well in terms of stability. PPS via the pps0 device and sent to
ntpd directly via ATOM does work fine.

Then why do you need gpsd at all? And if it is fine, there is no problem?

I need gpsd to read the GPS (because ntpd can't read a SiRF GPS) for
seconds numbering when there are issues with the network. It should
be the first clock to use among all the clocks with the PPS keeping
everything together. It just isn't working in a variety of ways.

And since SiRF binary adds nothing, turn it off, problem solved.

Can't turn it off. It's SiRF binary or nothing. Aside from that I'm
using data from other SiRF messages that are not available in NMEA so
the GPS would have to stay in SiRF binary even if it was capable of
NMEA. This is the other reason for gpsd, the shared access to the GPS data.

Post by Alexander Carver
When the KPPS error message shows up, gpsd turns off SHM(0) entirely.
It never turns back on. I have to restart gpsd to make that work but,
because of gpsd controlling the existence of /dev/pps0, I have to also
stop and restart ntpd or it won't be able to see pps0.

Yeah, the GPS stream got hosed. So don't do that.

How about turning SHM(0) back on once the stream comes back? The stream
never died. The only thing that happens is poor satellite coverage (one
or two good satellite signals at most). Everyone is going to lose
signal at some point, that's a given. But to force the need to restart
all of gpsd when it really should start serving time again once the time
is available seems harsh. You do it at startup, why can't it warm start
itself after the stream returns?

Post by Alexander Carver
So that's also where I seem to be stuck. If I allow pps0 to be
created by gpsd, then I can read the GPS data through gpsd not just
for ntpd but for other programs as well and ntpd still has access to
pps0. If I use ldattach to create pps0 independently, then gpsd has
no access to ttyS0 to get any GPS data.

Yup, one or the other, that is how the RFC works, exclusive access.

Post by Alexander Carver
One thing to note, when SHM(0) stops working, the TCP/IP port on gpsd
is still fine and gpsd is still reading data from the GPS. I can get
position data, satellite data, etc. all from the socket. It just
stops updating any of the SHMs unless I restart gpsd.

So, back to my original thought, compile gpsd wwithout KPPS.

Then I can't connect the kernel PPS (using ldattach) and still read from
the GPS because ldattach is blocking the serial port.

I would probably be fine if SHM(0) would actually come back on its own
without user intervention. Without that it can't be used as a preferred
peer for either SHM(1) or ATOM(PPS) because if it dies, it takes the
whole system out. And SHM(1) I have already stated is not working
properly but that's entirely internal to gpsd. There's no knob for me
to twiddle to fix either problem. I can't make SHM(0) come back without
forcibly restarting gpsd and there are no adjustments to make to gpsd
that fix the jitter in SHM(1). The kernel on its own and using ntpd's
PPS driver performs extremely well but if I trade out the PPS driver for
SHM(1) the jitter is poor. So the data coming from SHM(1) is just poor
in general but the PPS signal is clean and the jitter on it is very low.

[Gary E. Miller]

Yo Alexander!

On Thu, 04 Sep 2014 12:57:30 -0700

Post by Alexander Carver

Post by Gary E. Miller

Post by Alexander Carver

Post by Alexander Carver

Post by Gary E. Miller
Something wrong with your setup then. No way gpsd adds 1000x
jitter. I routinely see around 1 microSec using gpsd and SHM().
Even better with chronyd.

There's very little setup that could go wrong.

Yes, but something is clearly wrong, those are aweful numbers you see.

Right, they are awful coming through gpsd, they are great when
using the kernel's PPS mechanism directly (by way of the ATOM
refclock).

So, we agree something wrong on your setup.

No, we disagree. My setup as far as I can tell is just fine and
matches pretty much everything documented on any site searchable by
search engines. SHM(1) is just doing a terrible job. There's
nothing I can configure in gpsd so there isn't anything for me to
"setup" other than plug in the GPS and point gpsd at it. The fact
that ntpd is able to use the kernel PPS signal quite well on its own
implies that everything starting from the GPS going up to gpsd is
fine. Once inside gpsd, something is not going well and SHM(1) is
terrible.

Since many people use gpsd and SHM(1) with microSec jitter, and you
are the only outlier, I have to conclude something wrong on your end.

I suspect it is the effect of two GPS readers. That is a very unusual
and previously unsuppoerted configuration.

Post by Alexander Carver

Post by Gary E. Miller

Post by Alexander Carver
I need gpsd to read the GPS (because ntpd can't read a SiRF GPS)
for seconds numbering when there are issues with the network. It
should be the first clock to use among all the clocks with the PPS
keeping everything together. It just isn't working in a variety
of ways.

And since SiRF binary adds nothing, turn it off, problem solved.

Can't turn it off. It's SiRF binary or nothing. Aside from that I'm
using data from other SiRF messages that are not available in NMEA so
the GPS would have to stay in SiRF binary even if it was capable of
NMEA. This is the other reason for gpsd, the shared access to the GPS data.

What model? We have never heard of a SiRF that can not run NMEA.

Post by Alexander Carver

Post by Gary E. Miller

Post by Alexander Carver
When the KPPS error message shows up, gpsd turns off SHM(0)
entirely. It never turns back on. I have to restart gpsd to make
that work but, because of gpsd controlling the existence
of /dev/pps0, I have to also stop and restart ntpd or it won't be
able to see pps0.

Yeah, the GPS stream got hosed. So don't do that.

How about turning SHM(0) back on once the stream comes back? The
stream never died. The only thing that happens is poor satellite
coverage (one or two good satellite signals at most). Everyone is
going to lose signal at some point, that's a given. But to force the
need to restart all of gpsd when it really should start serving time
again once the time is available seems harsh. You do it at startup,
why can't it warm start itself after the stream returns?

Well, that is a new data point, you did not say you had bad sky coverage.
That is the first step to good time. And I have never seen SHM(0)
not recover after bad sky conditions. SO once again an outlier here.

Post by Alexander Carver

Post by Gary E. Miller
Yup, one or the other, that is how the RFC works, exclusive access.

Post by Alexander Carver
One thing to note, when SHM(0) stops working, the TCP/IP port on
gpsd is still fine and gpsd is still reading data from the GPS. I
can get position data, satellite data, etc. all from the socket.
It just stops updating any of the SHMs unless I restart gpsd.

So, back to my original thought, compile gpsd wwithout KPPS.

Then I can't connect the kernel PPS (using ldattach) and still read
from the GPS because ldattach is blocking the serial port.

Well, then you are hosed, because while gpsd does not use ldattach, it
uses the same system call as ldattach. So there should be no difference
in how the serial port works.

Post by Alexander Carver
I would probably be fine if SHM(0) would actually come back on its own
without user intervention. Without that it can't be used as a
preferred peer for either SHM(1) or ATOM(PPS) because if it dies, it
takes the whole system out.

And that is just weird, never seen that before either.

Post by Alexander Carver
And SHM(1) I have already stated is not
working properly but that's entirely internal to gpsd.

I disagree, many people have it running many places very well, and no
complaints until now.

I suggest at a minimum you compile the latest release.

Post by Alexander Carver
There's no
knob for me to twiddle to fix either problem. I can't make SHM(0)
come back without forcibly restarting gpsd and there are no
adjustments to make to gpsd that fix the jitter in SHM(1). The
kernel on its own and using ntpd's PPS driver performs extremely well
but if I trade out the PPS driver for SHM(1) the jitter is poor. So
the data coming from SHM(1) is just poor in general but the PPS
signal is clean and the jitter on it is very low.

Which comes back to something wrong with your setup since others do
not see results like you are getting.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
***@rellim.com Tel:[phone]

[Gary E. Miller]

Yo Alexander!

On Wed, 03 Sep 2014 00:06:09 -0700

Post by Alexander Carver
I'm having some trouble with PPS on version 3.6 in kernel 3.2

Both those are petty old, you'll need to upgrade.

Post by Alexander Carver
I get this once per second, as you can see, until I restart gpsd. The
problem is that gpsd is also creating the pps0 device which ntpd is
attempting to use as well. Restarting gpsd alone without restarting
ntpd does not remove pps0 and instead recreates it as pps1. I have to
restart both services to fix gpsd and restore pps0.

If gpsd is using the PPS then no need for ntpd to use PPS as well.
Avoid the confusion and just let gps handle the PPS fpr ntpd.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
***@rellim.com Tel:[phone]