gpsd no PPS output

[Jim Pennino]

Using Ubuntu 20.04.2 and gpsd 3.20.

I replaced the long running USB GPS with a serial device, reconfigured
and rebooted.

NMEA data is just fine and ppscheck works but gpsd is not processing the
PPS signal on CTS.

ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
only NTP0, i.e. not NTP1 and NTP2.

I ran gpsd as a regular user with -D3 -N to look for errors but it
looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
did show PPS.

Guessing it was some sort of permissions issue I had introduced over the
years, I did an apt purge gpsd, apt install gpsd and started fresh with
a reboot.

No change.

Thinking maybe apparmor was doing something, I stopped it and did a
teardown.

No change.

Now I have no clue...

Any suggestions?

[chris]

One possibility might be that the pps is at ttl level, while a serial
post needs rs3232 +/- levels to trigger properly. You can buy ttl to
rs232 board level adapter for a few $ on Ebay, which is what i'm
using here. Single supply line, 5 or 12 v, don't remember, that you
can tap off from the host b/board...

[William Unruh]

Although a theoretical possibility, it is highly doubtful, as most
serial cards do NOT follow the standard for rs232 ports, but will
happily use TTL levels. This has been true now for about 40 years I
believe. One problem with the adapters is that they can easily introduce
delays into the signal. They may well be inconsequential for your
purposes, and I would expect them to be on the microsecond level, but do
not know for sure.

You do need something to actually respond to the serial port interrups--
ie a serial port interrupt driver. Linux includes on


I have a "gps" script in /etc/init.d

------------------------------

#! /bin/sh
#
# gps Support for NTP i gps clock.
#
# chkconfig: 345 70 15
# description: gps is a module to read the PPS from a gps parallel port
# clock and start the shm ntp daemon to deliver the time to ntp.
#
# processname: gps

# Get config.
. /etc/sysconfig/network

# Get functions
. /etc/rc.d/init.d/functions

module="gps"
device="gps"
mode="664"
group=wheel

echo gsp $1 >>/tmp/gps

# See how we were called.
case "$1" in
start)
echo "Starting gps pps service"
modprobe pps-ldisc
ldattach 18 /dev/ttyS0
;;
stop)
echo "Stopping gps pps service"
killall ldattach
;;
status)
status ldattach
;;

restart)
$0 stop
$0 start
;;

*)
echo "gps wildcard">>/tmp/gps
gprintf "Usage: gps {start|stop|status|restart}\n "
exit 1
;;
esac

exit 0

----------------------

I do not use gpsd however.
>
>
>
>

[Jim Pennino]

Nope, this is a RS-232 device connected to a RS-232 port and as I said,
ppscheck works fine and PPS seems to get processed if gpsd is run as an
ordinary user, but not if started by root and run as gpsd.

This is NOT a hobby device.

[Jim Pennino]

William Unruh <un...@invalid.ca> wrote:

<snip old stuff>

> You do need something to actually respond to the serial port interrups--
> ie a serial port interrupt driver. Linux includes on
>
>
> I have a "gps" script in /etc/init.d

gpsd does all that for you and simplifies configuration, which is why
I'm using gpsd at all.

I did a modprobe check to make sure all the pps stuff was loaded; it
was.

Next is a post to the gpsd support group.

If all else fails, gpsd gets dumped and ntpd gets configured for the
NMEA interface.

[chris]

Worth a try. It was the problem on the setup here, a s/hand 1u
time tools gps ntp server, and a micro atx motherboard running FreeBSD.
The time tools pps is ttl, as are all the other gps do boxes here, from
several vendors collected over the years. While such mismatch may
work with some interfaces, there's no guarantee, as the voltage levels
are incorrect. Even if it does work, there may be excessive jitter,
which doesn't help performance. Propagation delay using a drive chip is
only 10's of nS, havng measure it on a scope, so can be ignored.

If the only thing changed is the serial card then it's most likely
something related...

[chris]

\
Here's the relevant fragment from ntp.conf, dcd line as pps input:

server 127.127.22.0 minpoll 2 maxpoll 2
fudge 127.127.22.0 flag2 1 flag3 1 flag4 1

[William Unruh]

On 2021-07-28, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> William Unruh <un...@invalid.ca> wrote:
>
><snip old stuff>
>
>> You do need something to actually respond to the serial port interrups--
>> ie a serial port interrupt driver. Linux includes on
>>
>>
>> I have a "gps" script in /etc/init.d
>
> gpsd does all that for you and simplifies configuration, which is why
> I'm using gpsd at all.

Except it does not work!

>
> I did a modprobe check to make sure all the pps stuff was loaded; it
> was.

Do
cat /sys/devices/virtual/pps/pps0/assert and
cat sys/devices/virtual/pps/pps0/clear
to see if either is giving you signals once a second when the gpsd is
supposed to be servicing the interrupts.

(run each successively)
It is usually assert you want. Your gpsd might be trying to read the
clear, and it never changes.

>
> Next is a post to the gpsd support group.
>
> If all else fails, gpsd gets dumped and ntpd gets configured for the
> NMEA interface.

If all you want is the time to the nearest second then that is fine. If
you want it to better than a few tens of ms, then it is not.

>
>
>

[William Unruh]

Nice theory. But AFAIK almost noone builds RS232 chips/booards with
follow the RS232 guidelines. I do not say noone because you may well
come up with an example, but why should they follow the standards?
Nothing else does. That standard was set about 1950, (Oops I exagerate,
it was 1960)when they were
driven by tubes.

>
> If the only thing changed is the serial card then it's most likely
> something related...

It is possible. Just as it is possible that if your car does not start,
you have to insert a crank into a little hole under the radiator and
turn it.

[Jim Pennino]

What changed is I replaced the USB GPS with a GNSS disciplined OCXO
box which has an RS-232 interface and a specified PPS accuracy in the
nanoseconds.

It remains to be seen if it actually does nanoseconds, but the 10 MHz
+/- 0.0002 Hz output has been verified.

[William Unruh]

Which is pretty useless for timing purposes.
Also that is one part in 10^11, and GPS is incapable of giving that.
I presume that the PPS output is once per second, and that the pulse
width is not too small (milliseconds) , or gpsd might well have trouble recogizing it as
a pulse.
>
>

[chris]

Sorry William, but do this sort of hardware design for work and every
pc with serial ports i've seen, has some sort of level conversion to
generate the rs232 levels, or at least a negative and positive going
waveform. Might not meet the older rs232 spec and some may work
with ttl input, but that's not guaranteed. For timing applications,
it's important to avoid jitter on input transitions, so why not do
the design right, rather than bodging it ?. Might be ok for a
home hack, but not for professional work, not here anyway...

Ymmv, of course...

[Jim Pennino]

gpsd uses the type 28 driver.

Most versions of ntpd will silently change a minpoll of 2 to 4. You can
verify with ntpq -p. If it says poll is 16, your's is one of them. The
ntp documentation for reference clocks explicitly says setting minpoll
to less than 4 is a waste of time and poll will always be 16, so setting
max poll has no effect.

YMMV

[David Woolley]

On 28/07/2021 23:30, William Unruh wrote:
> But AFAIK almost noone builds RS232 chips/booards with
> follow the RS232 guidelines.

I think you will find they do. Line receivers are allowed a threshold
anywhere between -3V and +3V, so a threshold compatible with TTL is in
spec. I think there is also a part of the specification that requires
control lines to read OFF when the driver is powered down, which implies
the threshold is > 0.

[chris]

I've used ex telco gps do for frequency standard work for years and they
typically have a pps offset in the 10nS range. You can even adjust the
antenna cable length to compensate. Have a look at the time nuts
mailing list for more info...

[Jim Pennino]

William Unruh <un...@invalid.ca> wrote:
> On 2021-07-28, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>> William Unruh <un...@invalid.ca> wrote:
>>
>><snip old stuff>
>>
>>> You do need something to actually respond to the serial port interrups--
>>> ie a serial port interrupt driver. Linux includes on
>>>
>>>
>>> I have a "gps" script in /etc/init.d
>>
>> gpsd does all that for you and simplifies configuration, which is why
>> I'm using gpsd at all.
>
> Except it does not work!

Yeah, tell me about it.

It does in the general case as I have other serial systems that use gpsd
and PPS with no issue.

>> I did a modprobe check to make sure all the pps stuff was loaded; it
>> was.
>
> Do
> cat /sys/devices/virtual/pps/pps0/assert and
> cat sys/devices/virtual/pps/pps0/clear
> to see if either is giving you signals once a second when the gpsd is
> supposed to be servicing the interrupts.
>
> (run each successively)
> It is usually assert you want. Your gpsd might be trying to read the
> clear, and it never changes.

When running, gpsd takes control of /dev/pps0.

A cat of both assert and clear both give 0.000000000#0

If I run gpsd as a regular user in debug mode, I can see that it does
ouput PPS but not from the privileged shared memory segment needed for
ntp.

That says to me there is something hosed in the permissions within the
gpsd PPS processing and that it is not a signal level problem.

>> Next is a post to the gpsd support group.
>>
>> If all else fails, gpsd gets dumped and ntpd gets configured for the
>> NMEA interface.
>
> If all you want is the time to the nearest second then that is fine. If
> you want it to better than a few tens of ms, then it is not.

Well, since the 4 machines with a USB GPS all show an average error of
about 1.5 milliseconds with a standard deviation of about 0.5
milliseconds and the other PPS machine shows an average error of about
2 microseconds with a standard deviation of about 150 microseconds,
the time accuracy on the network appears to be OK.

This new device is a GNSS disciplined OCXO in a 4"X4"X2" high box which
will supposedly give me nanoseconds if I can get PPS working on that system.

The 10 MHz +/- 0.0002 Hz frequency reference output seems to be working
OK, so if I could get PPS to work with gpsd...

[Jim Pennino]

True, but it is just fine and dandy for calibrating frequency counters
without having to send them somewhere and it allows testing of radio
dial accuracy no matter the state of the ionosphere.

> Also that is one part in 10^11, and GPS is incapable of giving that.
> I presume that the PPS output is once per second, and that the pulse
> width is not too small (milliseconds) , or gpsd might well have trouble recogizing it as
> a pulse.

This is a commercial box sold specifically as a time and frequency
standard and purchased because it's specifications are only a bit worse
than a rubidium standard and about $600 cheaper.

I have already verified that gpsd CAN recognize the PPS on CTS, but NOT
running with the permissions that it needs to feed ntp.

[Jim Pennino]

chris <chris-...@tridac.net> wrote:

<snip old stuff>

> I've used ex telco gps do for frequency standard work for years and they
> typically have a pps offset in the 10nS range. You can even adjust the
> antenna cable length to compensate. Have a look at the time nuts
> mailing list for more info...

I bought this thing because I was interested in the state of the art of
affordable devices.

I am well past the point in my life when I would haunt surplus stores
looking for treasure. I might violate that if I find a good source of
really cheap wave guide.

[chris]

Interesting, as some serial device chips have internal hardware locking
between some of the control functions. I used the dcd line for the
system here, which was fine, but haven't tested with the cts line...




>

[chris]

Ignore above but how about permissions on the serial device itself ?...

[chris]

Depends on the item, but have more or less equipped the lab here with
older high end test gear, even some parts / repair. Trade time against
money. Never get tired of just making stuff work...

[Jim Pennino]

chris <chris-...@tridac.net> wrote:

<snip old stuff>

>

> Ignore above but how about permissions on the serial device itself ?...

The problem seems to be permissions related to shared memory segments.

[Jim Pennino]

The inducement here is that while GPS disciplined oscillators are very
old technology which used to live in 19" 5U rack mount boxes and cost
tens of thousands of dollars, they now consist of some chip sets on a
circuit board in a 4"X4"X2" high box and costs about $180 with shipping.

[Jim Pennino]

There are no "serial device chips", there is a commercial PCI interface
board specified to work as RS-232 ports with full hardware handshake.

[William Unruh]

But those "PCI interface board" contains "serial device chips"
>
>

[Miroslav Lichvar]

On 2021-07-28, Jim Pennino <ji...@gonzo.specsol.net> wrote:

> ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
> only NTP0, i.e. not NTP1 and NTP2.
>
> I ran gpsd as a regular user with -D3 -N to look for errors but it
> looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
> did show PPS.

How exactly is gpsd started? With the serial device specified on its
command line, or is it added only later by gpsdctl (via udev+systemd)
when gpsd already dropped the root privileges?

--
Miroslav Lichvar

[David Woolley]

On 29/07/2021 00:03, chris wrote:
>
> I've used ex telco gps do for frequency standard work for years and they
> typically have a pps offset in the 10nS range

Offset relative to what? Do you have an atomic clock that is traceable
to UTC?

The official GPS time transfer accuracy is <= 40ns, so whilst 10ns may
be achievable most of the time, it isn't guaranteed.

[Jim Pennino]

Yes, they also contain capacitors, resistors, crystals, etc.

An interface board is a commercial item with a specification, i.e. the
board is specified to work in a PCI slot, provide RS-232 ports that have
standard connectors with full hardware handshaking and work with all
native OS serial drivers.

Since the board obviously works to specification, obsessing to what may
or may not be happening at the chip level seems to me to be pointless.

[Jim Pennino]

It is started by systemd with the options in /etc/default/gpsd which
are:

# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="false"

DEVICES="/dev/ttyS4 /dev/pps0"

# Other options you want to pass to gpsd
GPSD_OPTIONS="-n -b -s9600 "
GPSD_SOCKET=/var/run/gpsd.socket

So a ps shows:

gpsd 1483 1 0 Jul28 ? 00:00:52 /usr/sbin/gpsd -n -b -s9600 /dev/ttyS4 /dev/pps0

[Miroslav Lichvar]

On 2021-07-29, Jim Pennino <ji...@gonzo.specsol.net> wrote:

> So a ps shows:
>
> gpsd 1483 1 0 Jul28 ? 00:00:52 /usr/sbin/gpsd -n -b -s9600 /dev/ttyS4 /dev/pps0

Is that /dev/pps0 necessary? IIRC that is needed only when gpsd cannot
create the PPS device on its own (similarly to ldattach). If it is
needed, is gpsd started when it already exists?

--
Miroslav Lichvar

[Jim Pennino]

I do not know if it is "needed" and /dev/pps0 is indeed created by gpsd
as it did not exist until the first time I started gpsd with the serial
interface configuration.

OK, I killed gpsd and /dev/pps0 went away.

I commented pps0 out of the file, restarted gpsd and /dev/pps0 came
back, so I guess it really isn't needed and does nothing.

Still nothing but NTP0 from ntpshmmon.

sudo ntpshmmon
ntpshmmon: version 3.20
# Name Seen@ Clock Real L Prc
sample NTP0 1627572530.002686133 1627572530.002587625 1627572530.000031780 0 -20
sample NTP0 1627572531.002298509 1627572531.002285618 1627572531.000030611 0 -20
sample NTP0 1627572532.003058043 1627572532.002332397 1627572532.000029441 0 -20
^C

sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
^C

sudo ppscheck /dev/ttyS4
# Seconds nanoSecs Signals
1627572707.885746295 TIOCM_CTS
1627572707.985778695
1627572708.885715568 TIOCM_CTS
1627572708.985741009
1627572709.885677623 TIOCM_CTS
1627572709.985701097
^C

[chris]

Depending on the chip id, some functions may be inhibited if the control
lines are in the wrong state. So yes, chip hardware architecture does
matter and not always something that can be abstracted away within the
device driver. Devil is in the detail, as usual...

[chris]

Yes, they do, but they are unlikely to have the phase noise figures of
a better quality unit, nor short term stability. In fact some gpsdo
are using cheap dil vcxo's that that are not even ovenised and wander
all over the place.

Lower cost units should be good enough for ntp use, even if not good
enough for a primary frequency standard...

[chris]

On 07/29/21 12:47, David Woolley wrote:
> On 29/07/2021 00:03, chris wrote:
>>
>> I've used ex telco gps do for frequency standard work for years and they
>> typically have a pps offset in the 10nS range
>
> Offset relative to what? Do you have an atomic clock that is traceable
> to UTC?

For telco use, they do need the accuracy for gsm cell sync reasons and
it is quite a tight spec. Have run a couple of HP types for years, the
Z3815 and Z3816 and the HP utility that drives that reports nS
offset from UTC. Perhaps the absolute time is not as important as the
cell to cell sync accuracy, but don't have data on that. As I said,
there's even a function in the utility to adjust delay in the coax
line to the antenna, so they are trying to get well within any
theoretical limits...

[Jim Pennino]

chris <chris-...@tridac.net> wrote:

<snip old stuff>

> Depending on the chip id, some functions may be inhibited if the control
> lines are in the wrong state. So yes, chip hardware architecture does
> matter and not always something that can be abstracted away within the
> device driver. Devil is in the detail, as usual...

Yeah, so?

The card obviously works to specification, i.e. RS-232 and it does see CTS.

If it did not work to specification, I would return the card to the
vendor and buy a different one.

[chris]

This is hard work, obviously never designed any hardware, nor written
code for it. While the card may very well meet spec, the spec can't
cover all the myriad cases of operation or use.The spec is often
generalised, to allow some slack in component selection and to take
account of advances in the art, but it's the corner cases that can
catch out the unwary...

[Jim Pennino]

Noise figure of what, exactly?

The box has specifications.

If the box does not meet the specifications, the box will be returned to
the vendor.

The box is specified to be a GNSS disciplined OCXO with some very tight
specifications for short and long term stability.

None of this addresses the gpsd issue.

[Jim Pennino]

Do you understand the difference between DIY and purchasing a commercial
product sold to thousands upon thousands if not millions of purchasers?

Do you understand that RS-232 is many decades old and is specified by
TIA-232-F Interface Between Data Terminal Equipment and Data
Circuit-Terminating Equipment Employing Serial Binary Data Interchange,
issued in 1997?

The box and the card are both RS-232.

The card and box combination obviously works.

None of this has ANYTHING to do with the issue of gpsd.

[chris]

That's just the spec for the signals on the wires, nothing to do
with how that is implemented inside devices, or on your pc card,
which may be implemented in many different ways, from bit banging
to fully integrated devices with buffering and even some
intelligence. It only affects your low cost gpsd if you can't
make it work, and need to dig into why it doesn't work...

[Jim Pennino]

1) I no more care how the manufacturer inplemented what is inside the
box or on the PC card than I care what kind of steel was used to make
the exhaust manifold on my car.

2) The box is low cost compared to the tens of thousands of dollars such
things used to cost.

3) If the box doesn't work, it goes back for a refund. I have no
interest in fixing things with a warrenty.

4) It is blazingly obvious to anyone paying the slightest bit of
attention that the problem is in software, i.e. gpsd, and not the box.

[William Unruh]

That is of course completely irrelevant. The same could be said of an aluminum
spoon (cost mcuch more than a gold spoon), and yet it would still not be most people's first choice for
tableware.

> Thank you for your suggestions. I always notice the host name part of the prompt string, which is different from each other for the test case discussed here, when I'm on different hosts.

>
> 3) If the box doesn't work, it goes back for a refund. I have no
> interest in fixing things with a warrenty.

But then as point 4 says, you do not know if it is the box or some
misconfiguration (the wetware behind the keyboard) or a bug in gpsd.

>
> 4) It is blazingly obvious to anyone paying the slightest bit of
> attention that the problem is in software, i.e. gpsd, and not the box.

And yet, you also have been cogitating about the possibility that the
serial port (either on the box or on the computer) does not satisfy the RS232 standards, which is hardware

How about trying the direct use of ldattach, instead of using gpsd, to
see if you can get that to work. If it does, and gpsd does not then your
hypothesis that gpsd is at fault is born out. Then you can decide
whether it is better to suffer the slings and arrows of debugging gpsd,
or with one fell swoop use ldattach and have a working system.


>

[Jim Pennino]

At one time the cost of aluminum was much higher than gold...

>
>> Thank you for your suggestions. I always notice the host name part of the prompt string, which is different from each other for the test case discussed here, when I'm on different hosts.
>>
>> 3) If the box doesn't work, it goes back for a refund. I have no
>> interest in fixing things with a warrenty.
>
> But then as point 4 says, you do not know if it is the box or some
> misconfiguration (the wetware behind the keyboard) or a bug in gpsd.

Point 4 says I DO know the problem is in gpsd.

>>
>> 4) It is blazingly obvious to anyone paying the slightest bit of
>> attention that the problem is in software, i.e. gpsd, and not the box.
>
> And yet, you also have been cogitating about the possibility that the
> serial port (either on the box or on the computer) does not satisfy the RS232 standards, which is hardware
>

No, I have not, that is someone else fixating on that. That was settled
as far as I am concerned before I made the first post.

> How about trying the direct use of ldattach, instead of using gpsd, to
> see if you can get that to work. If it does, and gpsd does not then your
> hypothesis that gpsd is at fault is born out. Then you can decide
> whether it is better to suffer the slings and arrows of debugging gpsd,
> or with one fell swoop use ldattach and have a working system.

That gpsd has some sort of issue is well established at this point.

Any further debugging of gpsd will be done with the gpsd support list.

[William Unruh]

On 2021-07-30, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> William Unruh <un...@invalid.ca> wrote:
>>>

>>> 2) The box is low cost compared to the tens of thousands of dollars such
>>> things used to cost.
>>
>> That is of course completely irrelevant. The same could be said of an aluminum
>> spoon (cost mcuch more than a gold spoon), and yet it would still not be most people's first choice for
>> tableware.
>
> At one time the cost of aluminum was much higher than gold...

Yes. Precisely. You are the one claiming that because prices are cheaper
now, it means something about the quality of the object for the purpose.

>> But then as point 4 says, you do not know if it is the box or some
>> misconfiguration (the wetware behind the keyboard) or a bug in gpsd.
>
> Point 4 says I DO know the problem is in gpsd.

No.

Why do you feel that you know that the problem is gpsd? You have tested
the interrupt handling with other programs (lets say like ldattach)? Not
that you have given any indication of. You simply say "it is obvious"
Unfortunately I have seen far far to many instances in wich someone says
"it is obvious" and they turned out to be entirely wrong.

>
>>>
>>> 4) It is blazingly obvious to anyone paying the slightest bit of
>>> attention that the problem is in software, i.e. gpsd, and not the box.
>>
>> And yet, you also have been cogitating about the possibility that the
>> serial port (either on the box or on the computer) does not satisfy the RS232 standards, which is hardware
>>
>
> No, I have not, that is someone else fixating on that. That was settled
> as far as I am concerned before I made the first post.
>
>> How about trying the direct use of ldattach, instead of using gpsd, to
>> see if you can get that to work. If it does, and gpsd does not then your
>> hypothesis that gpsd is at fault is born out. Then you can decide
>> whether it is better to suffer the slings and arrows of debugging gpsd,
>> or with one fell swoop use ldattach and have a working system.
>
> That gpsd has some sort of issue is well established at this point.

Proof by blatant assertion is always a very poor argument.

Since ldattach is a stadard part of linux, and since the use of it is
trivial, your blind refusal to test is pretty suspicious.

>
> Any further debugging of gpsd will be done with the gpsd support list.

And here I thought that the purpose was to get your time working, not to
debug gpsd. Oh well, sorry.

>
>
>

[Jim Pennino]

William Unruh <un...@invalid.ca> wrote:
> On 2021-07-30, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>> William Unruh <un...@invalid.ca> wrote:
>>>>
>>>> 2) The box is low cost compared to the tens of thousands of dollars such
>>>> things used to cost.
>>>
>>> That is of course completely irrelevant. The same could be said of an aluminum
>>> spoon (cost mcuch more than a gold spoon), and yet it would still not be most people's first choice for
>>> tableware.
>>
>> At one time the cost of aluminum was much higher than gold...
>
> Yes. Precisely. You are the one claiming that because prices are cheaper
> now, it means something about the quality of the object for the purpose.

I have never said anything like that.

What I did say was that I was interested in what such a device could do
compared to the older stuff that cost two orders of magnitude more money
new and still cost a magnitude more on the surplus market as well as
taking up 5U in a 19 inch rack.

>>> But then as point 4 says, you do not know if it is the box or some
>>> misconfiguration (the wetware behind the keyboard) or a bug in gpsd.
>>
>> Point 4 says I DO know the problem is in gpsd.
>
> No.
>
> Why do you feel that you know that the problem is gpsd?

If you actually read and understood what I wrote, you would know why.

> You have tested
> the interrupt handling with other programs (lets say like ldattach)? Not
> that you have given any indication of. You simply say "it is obvious"
> Unfortunately I have seen far far to many instances in wich someone says
> "it is obvious" and they turned out to be entirely wrong.

It is obvious from what gpsd and related programs do that CTS gets
through the plug and to the computer.

What is not obvious is why gpsd does not forward PPS through the shared
memory segment.

>>>> 4) It is blazingly obvious to anyone paying the slightest bit of
>>>> attention that the problem is in software, i.e. gpsd, and not the box.
>>>
>>> And yet, you also have been cogitating about the possibility that the
>>> serial port (either on the box or on the computer) does not satisfy the RS232 standards, which is hardware
>>>
>>
>> No, I have not, that is someone else fixating on that. That was settled
>> as far as I am concerned before I made the first post.
>>
>>> How about trying the direct use of ldattach, instead of using gpsd, to
>>> see if you can get that to work. If it does, and gpsd does not then your
>>> hypothesis that gpsd is at fault is born out. Then you can decide
>>> whether it is better to suffer the slings and arrows of debugging gpsd,
>>> or with one fell swoop use ldattach and have a working system.
>>
>> That gpsd has some sort of issue is well established at this point.
>
> Proof by blatant assertion is always a very poor argument.

And also proved though discourse with people knowledgeable with gpsd.

> Since ldattach is a stadard part of linux, and since the use of it is
> trivial, your blind refusal to test is pretty suspicious.

Since my major interest is in getting gpsd to work, it is irrelevant as
gpsd takes care of such things.

>> Any further debugging of gpsd will be done with the gpsd support list.
>
> And here I thought that the purpose was to get your time working, not to
> debug gpsd. Oh well, sorry.

The original post was to attempt to find out why ntpd was not working.

That evolved into discovering that ntpd doesn't work because gpsd has
either a bug or a configuration issue.

[Jim Pennino]

Jim Pennino <ji...@gonzo.specsol.net> wrote:

It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
breaks PPS processing.

The net result is that an application that looks at /dev/ttySx will have
no issues and will see CTS being asserted but anything that looks at
/dev/ppsx will fail.

According to Focal, a kernel update is imminent...

[William Unruh]

Do you have a reference for this-- eg a URL?

[Jim Pennino]

William Unruh <un...@invalid.ca> wrote:
> Do you have a reference for this-- eg a URL?

A reference for the kernel bug?

No, this was determined by downloading source for various GPS utility
programs and running them under a debugger noting where the failure
occured and seeing that it always happened in a ppsapi routine.

And yes, the kernel says all the pps related modules are loaded.

[William Unruh]

On 2021-07-31, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> William Unruh <un...@invalid.ca> wrote:
>> Do you have a reference for this-- eg a URL?
>
> A reference for the kernel bug?
>
> No, this was determined by downloading source for various GPS utility
> programs and running them under a debugger noting where the failure
> occured and seeing that it always happened in a ppsapi routine.

So you reported the bug? What is the bug report then.
What was the "failure"?
Note that the pps driver is highly time sensative, and a debugger could
upset that, and report bug which is due to the interaction with the
debugger.

[Jim Pennino]

William Unruh <un...@invalid.ca> wrote:
> On 2021-07-31, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>> William Unruh <un...@invalid.ca> wrote:
>>> Do you have a reference for this-- eg a URL?
>>
>> A reference for the kernel bug?
>>
>> No, this was determined by downloading source for various GPS utility
>> programs and running them under a debugger noting where the failure
>> occured and seeing that it always happened in a ppsapi routine.
>
> So you reported the bug? What is the bug report then.

As there is an immenent kernel update, I didn't bother.

If the update doesn't fix the issue, then I will consider a bug report
for that kernel.

> What was the "failure"?
> Note that the pps driver is highly time sensative, and a debugger could
> upset that, and report bug which is due to the interaction with the
> debugger.

I have been writiting and debugging software since mid 1970 and do have
some idea of how it is done, but thank you for your comments.

Quiz of the day: What does "RT" in RT-11 stand for?

[William Unruh]

On 2021-07-31, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> William Unruh <un...@invalid.ca> wrote:
>> On 2021-07-31, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>>> William Unruh <un...@invalid.ca> wrote:
>>>> Do you have a reference for this-- eg a URL?
>>>
>>> A reference for the kernel bug?
>>>
>>> No, this was determined by downloading source for various GPS utility
>>> programs and running them under a debugger noting where the failure
>>> occured and seeing that it always happened in a ppsapi routine.
>>
>> So you reported the bug? What is the bug report then.
>
> As there is an immenent kernel update, I didn't bother.

Kernels are updated for many reasons, and there seems to be no reason
why it would fix this particular bug if noone had ever reported it.

And are you sure that the evidence for this bug is not there in many of
the kernel versions? Ie, it could be a peculiarity of your own system
rather than being generic.

You were originally completely sure that this was a bug in gpsd. Now it
is a kernel bug.

[Jim Pennino]

William Unruh <un...@invalid.ca> wrote:
> On 2021-07-31, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>> William Unruh <un...@invalid.ca> wrote:
>>> On 2021-07-31, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>>>> William Unruh <un...@invalid.ca> wrote:
>>>>> Do you have a reference for this-- eg a URL?
>>>>
>>>> A reference for the kernel bug?
>>>>
>>>> No, this was determined by downloading source for various GPS utility
>>>> programs and running them under a debugger noting where the failure
>>>> occured and seeing that it always happened in a ppsapi routine.
>>>
>>> So you reported the bug? What is the bug report then.
>>
>> As there is an immenent kernel update, I didn't bother.
>
> Kernels are updated for many reasons, and there seems to be no reason
> why it would fix this particular bug if noone had ever reported it.

And as the update is immenent, I think it makes little to no difference
if I wait until the release. And, no I did not search through the bugs
data base. You may do so if you wish.

> And are you sure that the evidence for this bug is not there in many of
> the kernel versions? Ie, it could be a peculiarity of your own system
> rather than being generic.

Does the id of the kernel, i.e. 5.4.0-80-generic, give you a clue?

> You were originally completely sure that this was a bug in gpsd. Now it
> is a kernel bug.

No, I was originally sure the bug had something to do with gpsd, which
does not necessarily mean IN gpsd. The real WTF moment came when I
discovered ntpd does not work either for reasons that should be obvious
now.

And finally, to further beat this dead horse to ribbons, I have also
found some issues with apparmor for both gpsd and ntpd.

And before you even ask, put apparmor in complain for gpsd and ntpd to
see if you are effected.

>>
>> If the update doesn't fix the issue, then I will consider a bug report
>> for that kernel.
>>
>>> What was the "failure"?
>>> Note that the pps driver is highly time sensative, and a debugger could
>>> upset that, and report bug which is due to the interaction with the
>>> debugger.
>>
>> I have been writiting and debugging software since mid 1970 and do have

>> some idea of how it is done, 5.4.0-80-genericbut thank you for your comments.

>>
>> Quiz of the day: What does "RT" in RT-11 stand for?

Question too tough for you?

Here's another: What is the response if you type who on the terminal of
a RT-11 machine?

[chris]

On 07/31/21 22:11, Jim Pennino wrote:
>
> Quiz of the day: What does "RT" in RT-11 stand for?
>
>

Real Time, RT11, an early operating system for dec pdp11. It
was a single tasking / forground background os that was good
for real time control and quite lightweight.

Spent quite a few years programming macro under RT11 and RSX...

[Miroslav Lichvar]

On 2021-07-31, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
> breaks PPS processing.
>
> The net result is that an application that looks at /dev/ttySx will have
> no issues and will see CTS being asserted but anything that looks at
> /dev/ppsx will fail.

I think that is expected if you have the PPS signal connected to CTS.
AFAIK the kernel PPS serial driver works only with DCD.

gpsd supports the kernel PPS and also (a much less precise) user-space
PPS if the kernel PPS does not work.

However, I'm not sure why it worked for you only when started directly
from command line. It might help if we could compare the gpsd debug
output or strace output in both cases.

--
Miroslav Lichvar

[chris]

The dcd line is what I used, as that is what was specified for
ntpd under FreeBSD. It provides a local microsecond sync, as the
following shows:


root@ntp-host:~ # ntpq -pn
remote refid st t when poll reach delay offset jitter
====================================================================
o127.127.22.0 .PPS. 0 l 5 8 377 0.000 0.002 0.001
+192.9.200.168 .GPS. 1 u 23 64 377 0.168 0.004 0.059
*192.9.200.169 .GPS. 1 u 34 64 377 0.365 -0.002 0.042

[Jim Pennino]

Miroslav Lichvar <mlic...@redhat.com> wrote:
> On 2021-07-31, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>> It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
>> breaks PPS processing.
>>
>> The net result is that an application that looks at /dev/ttySx will have
>> no issues and will see CTS being asserted but anything that looks at
>> /dev/ppsx will fail.
>
> I think that is expected if you have the PPS signal connected to CTS.
> AFAIK the kernel PPS serial driver works only with DCD.

Then that is a bug because most real devices use CTS.

gpsmon /dev/ttyS0 shows ---PPS---- in the data window.

> gpsd supports the kernel PPS and also (a much less precise) user-space
> PPS if the kernel PPS does not work.

gpsd uses the pps_api.

> However, I'm not sure why it worked for you only when started directly
> from command line. It might help if we could compare the gpsd debug
> output or strace output in both cases.

Calling any pps_api routine from anything fails.

[David Taylor]

On 02/08/2021 14:01, Jim Pennino wrote:
>> I think that is expected if you have the PPS signal connected to CTS.
>> AFAIK the kernel PPS serial driver works only with DCD.

> Then that is a bug because most real devices use CTS.

All the real devices I've used on Windows and multiple variants of Linux use DCD.

--
Cheers,
David
Web: http://www.satsignal.eu

[Jim Pennino]

"In NTP versions after 4.0.99k23 is NMEA driver atomized what means that
for PPS processing we don't need neither ATOM driver nor PPS command in
ntp.conf."

http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm 6.2.4.3.3

Which means, assuming your PPS device outputs NMEA sentences, all you
need to get both data and PPS is:

server 127.127.20.0 mode (for your device) minpoll 4 maxpoll 4
fudge 127.127.20.0 flag1 1

[Terje Mathisen]

David Taylor wrote:
> On 02/08/2021 14:01, Jim Pennino wrote:
>>> I think that is expected if you have the PPS signal connected to CTS.
>>> AFAIK the kernel PPS serial driver works only with DCD.
>
>> Then that is a bug because most real devices use CTS.
>
> All the real devices I've used on Windows and multiple variants of Linux
> use DCD.
>

I have to agree with David here:

I have been a member of the NTP Hackers team for more than 25 years, and
I have yet to see a PPS device on RS232 which doesn't use DCD.

I have soldered together several (Motorola, Garmin, Sure) GPS reference
clocks, all of those used DCD.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Jim Pennino]

Terje Mathisen <terje.m...@tmsw.no> wrote:
> David Taylor wrote:
>> On 02/08/2021 14:01, Jim Pennino wrote:
>>>> I think that is expected if you have the PPS signal connected to CTS.
>>>> AFAIK the kernel PPS serial driver works only with DCD.
>>
>>> Then that is a bug because most real devices use CTS.
>>
>> All the real devices I've used on Windows and multiple variants of Linux
>> use DCD.
>>
> I have to agree with David here:
>
> I have been a member of the NTP Hackers team for more than 25 years, and
> I have yet to see a PPS device on RS232 which doesn't use DCD.

It is now 2021 and there have been changes.

> I have soldered together several (Motorola, Garmin, Sure) GPS reference
> clocks, all of those used DCD.
>
> Terje

I have a commercial GNSSDO, which contains an OCXO as the rubidium
option was a bit too pricey for me, and both models use CTS.

There is no soldering involved as this is, again, a commercial device
with a DB-9 on the panel with pin 8, i.e. CTS on the DTE end, labeled
1PPS.

If one runs gpsmon against this device it shows PPS being asserted on the
data display line, so whoever wrote gpsmon has seen GPS devices with PPS
on CTS.

If one runs ppstest against this device it shows PPS being asserted, so
whoever wrote ppstest has seen GPS devices with PPS on CTS.

FYI the OCXO model is about $180 and the rubidium model is about $800.

Arent't advances in technology great?

[Jim Pennino]

David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
> On 02/08/2021 14:01, Jim Pennino wrote:
>>> I think that is expected if you have the PPS signal connected to CTS.
>>> AFAIK the kernel PPS serial driver works only with DCD.
>
>> Then that is a bug because most real devices use CTS.
>
> All the real devices I've used on Windows and multiple variants of Linux use DCD.

The computer operating system has nothing to do with how some external,
commercial device is built.

[chris]

The pps line has nothing to do with nmea sentances directly, but is
a ttl level pulse that marks the beginning of each second,
typically with microsecond accuracy. It's a sync pulse for the current
second.

The nmea sentences provide the overall time of day, month, year,
but fine resolution within the second can only be provided by the
subsecond accuracy of the pps pulse. Obvious really, in that
differing times of flight of the nmea sentences and decoding
can never provide the required accuracy alone...

[chris]

They are, but if it's all now working, what output do you get
from the ntpq utility. or equivalent, in terms of accuracy ?.
If it's working properly and has been running for a few hours,
offset against UTC should be in the microsecond range, not
milliseconds, 3 orders of magnitude error...

[David Woolley]

On 02/08/2021 17:26, chris wrote:
> If it's working properly and has been running for a few hours,
> offset against UTC should be in the microsecond range, not

ntpd doesn't provide that information. It only provides the offset
between the timing source and the PC's internal clock.

[Terje Mathisen]

Jim Pennino wrote:
> Terje Mathisen <terje.m...@tmsw.no> wrote:
>> David Taylor wrote:
>>> On 02/08/2021 14:01, Jim Pennino wrote:
>>>>> I think that is expected if you have the PPS signal connected to CTS.
>>>>> AFAIK the kernel PPS serial driver works only with DCD.
>>>
>>>> Then that is a bug because most real devices use CTS.

The above is simply wrong.

>>>
>>> All the real devices I've used on Windows and multiple variants of Linux
>>> use DCD.
>>>
>> I have to agree with David here:
>>
>> I have been a member of the NTP Hackers team for more than 25 years, and
>> I have yet to see a PPS device on RS232 which doesn't use DCD.
>
> It is now 2021 and there have been changes.

Not really.

>
>> I have soldered together several (Motorola, Garmin, Sure) GPS reference
>> clocks, all of those used DCD.
>>
>> Terje
>
> I have a commercial GNSSDO, which contains an OCXO as the rubidium
> option was a bit too pricey for me, and both models use CTS.

Jim, I did not state that CTS was invalid, just that all I've personally
seen have used DCD!

In reality you can have a PPS signal on any bit line which have
interrupt capability, this includes using a classic "Centronics"
parallel port along with the serial port for NMEA or some other protocol
to number the seconds.

>
> There is no soldering involved as this is, again, a commercial device
> with a DB-9 on the panel with pin 8, i.e. CTS on the DTE end, labeled
> 1PPS.
>
> If one runs gpsmon against this device it shows PPS being asserted on the
> data display line, so whoever wrote gpsmon has seen GPS devices with PPS
> on CTS.
>
> If one runs ppstest against this device it shows PPS being asserted, so
> whoever wrote ppstest has seen GPS devices with PPS on CTS.
>
> FYI the OCXO model is about $180 and the rubidium model is about $800.
>
> Arent't advances in technology great?

Oh, absolutely! :-)

I wrote the software for Meinberg's super NTP server, i.e. a custom ntpd
version which can run on all cores and share the processing load across
them. This 1U rack server have either a TCXO or Rb internal frequency
standard which provides excellent stability, much better than the
short-term GPS stability.

[Jim Pennino]

I never said that machine is "all now working".

What part of the kernel PPS routines in the OS on that machine are broken
and do NOT process PPS did you fail to understand?

I expect the ntpq output for this device, when PPS is working, to be in
the low nanoseconds range as that is what the manufactures specifications
say. Right now the offset and and error are already in the microsecond
range.

You need to look at both the offset and estimated error fields of
loopstats and calculate the standard deviation to get any real idea of
the accuracy of ntpd.

You do do numerical analysis and graphing of loopstats, don't you?

[Jim Pennino]

Yes, I know what PPS and NMEA mean and what they do, but thank you for
your gratuitous reminder.

As for "can never provide the required accuracy alone", that depends on
what your required accuracy is. I have 3 USB GPS ntp machines that are
all CONSISTENTLY accurate to about 2 milliseconds, which is better than
you will ever get with network sources.

An analysis of the loopstats file for one of these machines shows:

loopstats
Count:3926

Avg offset: 0.00253469 milliseconds
Std dev: 1.18121 milliseconds

Avg error: 0.981876 milliseconds
Std dev: 0.302864 milliseconds

The point of my post, which you apparently totally missed judging by
your knee jerk response, was that for current releases of ntpd, you do
NOT need to use the type 22 driver to process PPS information for such
has been added to the type 20 driver and is activated by flag 1.

Of course, this OBVIOUSLY means the device must deliver both NMEA and
PPS as I already said.

This what ntpq -pn produces on such a system:

remote refid st t when poll reach delay offset jitter

==============================================================================
o127.127.20.0 .GPS. 0 l 12 16 377 0.000 0.004 0.002

Notice the 'o' at the start of the line and that the driver is type 20
and not type 22. This indicates that ntpd is processing PPS data.

An analysis of the loopstats file for that machine shows:

loopstats
Count:3923

Avg offset: 0.0643678 microseconds
Std dev: 8.36833 microseconds

Avg error: 1.98298 microseconds
Std dev: 0.100354 microseconds

Also notice that you do not need other network sources of time if you
have a real reference clock with PPS as it is at least 3 orders of
magnitude better than anything you will get over a network.

If you are concerned about GPS going away, put your device on a UPS.

[Jim Pennino]

And to state the blazingly obvious, the whole point of running ntpd at
all is to, hopefully, correct the system internal clock.

[William Unruh]

On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:

....

>
> As for "can never provide the required accuracy alone", that depends on
> what your required accuracy is. I have 3 USB GPS ntp machines that are
> all CONSISTENTLY accurate to about 2 milliseconds, which is better than
> you will ever get with network sources.

Uh, depends on your network sources. If it is nearby (eg in your
building) then you can certainly get sub-ms accuracy from a network
source (ie better than NMEA). If it is half way around the world, then
you may well be right.
....
....
....
....

[William Unruh]

On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>

> What part of the kernel PPS routines in the OS on that machine are broken
> and do NOT process PPS did you fail to understand?
>
> I expect the ntpq output for this device, when PPS is working, to be in
> the low nanoseconds range as that is what the manufactures specifications
> say. Right now the offset and and error are already in the microsecond
> range.

Well, no. The interrupt handling routines in Linux and even the line
from the gps to the machine are much slower than
"low nanoseconds"

>
> You need to look at both the offset and estimated error fields of
> loopstats and calculate the standard deviation to get any real idea of
> the accuracy of ntpd.

That may give you the random errors, not the systematic (eg from the
interrupt time, signal propagation time, etc)

[David Woolley]

On 02/08/2021 18:52, Jim Pennino wrote:
> And to state the blazingly obvious, the whole point of running ntpd at
> all is to, hopefully, correct the system internal clock.

But not against UTC, but rather against various secondary standards, and
also not on the basis that the secondary standard is always right (in
which case offset would always be exactly zero, immediately after a poll).

People treat offset as too much of a holy grail when it is actually
measured against something which is wrong, and doesn't have a stable
error. Jitter is probably a better measure of the quality of the source

(Incidentally, it is impossible to achieve zero offset from UTC in real
time, as UTC isn't known until days, or maybe weeks, later.)

[Jim Pennino]

Terje Mathisen <terje.m...@tmsw.no> wrote:
> Jim Pennino wrote:
>> Terje Mathisen <terje.m...@tmsw.no> wrote:
>>> David Taylor wrote:
>>>> On 02/08/2021 14:01, Jim Pennino wrote:
>>>>>> I think that is expected if you have the PPS signal connected to CTS.
>>>>>> AFAIK the kernel PPS serial driver works only with DCD.
>>>>
>>>>> Then that is a bug because most real devices use CTS.
>
> The above is simply wrong.

OK, let me restate that.

Most current, commercial devices not intended for the experimenter or
hobbist market use CTS.

FWIW, I did some research of such devices with a DB-9 connector on them.

>>>> All the real devices I've used on Windows and multiple variants of Linux
>>>> use DCD.
>>>>
>>> I have to agree with David here:
>>>
>>> I have been a member of the NTP Hackers team for more than 25 years, and
>>> I have yet to see a PPS device on RS232 which doesn't use DCD.
>>
>> It is now 2021 and there have been changes.
>
> Not really.

Yes, really, e.g. GNSS and relatively cheap rubidium oscillators.

With GNSS and a $15 USB GPS, one can obtain consistent time accuracy in
the single digit milliseconds these days.

>>> I have soldered together several (Motorola, Garmin, Sure) GPS reference
>>> clocks, all of those used DCD.
>>>
>>> Terje
>>
>> I have a commercial GNSSDO, which contains an OCXO as the rubidium
>> option was a bit too pricey for me, and both models use CTS.
>
> Jim, I did not state that CTS was invalid, just that all I've personally
> seen have used DCD!

Then I guess you have learned something new today. Count that as a plus.

>
> In reality you can have a PPS signal on any bit line which have
> interrupt capability, this includes using a classic "Centronics"
> parallel port along with the serial port for NMEA or some other protocol
> to number the seconds.

Sure all kinds of things are possible.

However, one of my goals was off the shelf plug and play, not DYI of cables,
interfaces, software, etc.

>> There is no soldering involved as this is, again, a commercial device
>> with a DB-9 on the panel with pin 8, i.e. CTS on the DTE end, labeled
>> 1PPS.
>>
>> If one runs gpsmon against this device it shows PPS being asserted on the
>> data display line, so whoever wrote gpsmon has seen GPS devices with PPS
>> on CTS.
>>
>> If one runs ppstest against this device it shows PPS being asserted, so
>> whoever wrote ppstest has seen GPS devices with PPS on CTS.
>>
>> FYI the OCXO model is about $180 and the rubidium model is about $800.
>>
>> Arent't advances in technology great?
>
> Oh, absolutely! :-)
>
> I wrote the software for Meinberg's super NTP server, i.e. a custom ntpd
> version which can run on all cores and share the processing load across
> them. This 1U rack server have either a TCXO or Rb internal frequency
> standard which provides excellent stability, much better than the
> short-term GPS stability.
>
> Terje

The box I have is 4WX4DX2H inches, provides a DB-9 connector for NMEA
data and PPS and has outputs for 10 MHZ +/- 0.0002 Hz and 1PPS rated for
jitter in the low nanoseconds. Though PPS for ntpd is not working yet, I
have been able to recalibrate my frequency counter.

I was concidering hanging it off a Rasberry Pi, which would make for a
nice, neat system.

However there is no neat and clean RS-232 interface that has CTS for the
Pi.

[Jim Pennino]

If it is only in the next city, I am right.

FYI for personal reasons I am doing a survey of current GPS devices and
do statistical analysis and graphing of ntpd performance on 5 machines of
various configurations.

The graphing clearly shows that network sources, and even the ISP
sources only a few hops away, are VERY subject to random perturbations.

If the case is limited to servers on your own network, then the random
perturbations are very minimal, if any, on a 1G network.

[Jim Pennino]

David Woolley <da...@ex.djwhome.demon.invalid> wrote:
> On 02/08/2021 18:52, Jim Pennino wrote:
>> And to state the blazingly obvious, the whole point of running ntpd at
>> all is to, hopefully, correct the system internal clock.
>
> But not against UTC, but rather against various secondary standards, and
> also not on the basis that the secondary standard is always right (in
> which case offset would always be exactly zero, immediately after a poll).

Assuming such a standard existed, which it doesn't.

> People treat offset as too much of a holy grail when it is actually
> measured against something which is wrong, and doesn't have a stable
> error. Jitter is probably a better measure of the quality of the source

Which is why I analyze and graph MUCH more than just offset.

> (Incidentally, it is impossible to achieve zero offset from UTC in real
> time, as UTC isn't known until days, or maybe weeks, later.)

The people that run GPS claim the GPS offset from USNO UTC to be less
than 40 nanoseconds worst case. That is good enough for me.

[Jim Pennino]

William Unruh <un...@invalid.ca> wrote:
> On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>>
>> What part of the kernel PPS routines in the OS on that machine are broken
>> and do NOT process PPS did you fail to understand?
>>
>> I expect the ntpq output for this device, when PPS is working, to be in
>> the low nanoseconds range as that is what the manufactures specifications
>> say. Right now the offset and and error are already in the microsecond
>> range.
>
> Well, no. The interrupt handling routines in Linux and even the line
> from the gps to the machine are much slower than
> "low nanoseconds"

We shall see...

However, the absolute speed of everything is far less important than
the consistency of PPS processing.

That is, if one has an absolutely accurate PPS signal that is exactly
1Hz, it doesn't matter how long, within reason, it takes to process the
PPS signal. What matters is how much jitter the hardware and software
has in processing the signal. Since the jitter in modern digital
electronic is in the picosecond, that is not a factor. That means the
determining factor will be the jitter in the interrupt handling.

Which with 1 Ghz+ multiple core CPUs is hopefully in the low
nanoseconds.

>>
>> You need to look at both the offset and estimated error fields of
>> loopstats and calculate the standard deviation to get any real idea of
>> the accuracy of ntpd.
> That may give you the random errors, not the systematic (eg from the
> interrupt time, signal propagation time, etc)

Such will show up in the graphing of the various ntpd statistics files,
and if it doesn't, that means the people that wrote the documentation
for the ntpd statistics files were lying, which I highly doubt.

[William Unruh]

On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> William Unruh <un...@invalid.ca> wrote:
>> On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>>>
>>> What part of the kernel PPS routines in the OS on that machine are broken
>>> and do NOT process PPS did you fail to understand?
>>>
>>> I expect the ntpq output for this device, when PPS is working, to be in
>>> the low nanoseconds range as that is what the manufactures specifications
>>> say. Right now the offset and and error are already in the microsecond
>>> range.
>>
>> Well, no. The interrupt handling routines in Linux and even the line
>> from the gps to the machine are much slower than
>> "low nanoseconds"
>
> We shall see...
>
> However, the absolute speed of everything is far less important than
> the consistency of PPS processing.
>
> That is, if one has an absolutely accurate PPS signal that is exactly
> 1Hz, it doesn't matter how long, within reason, it takes to process the
> PPS signal. What matters is how much jitter the hardware and software
> has in processing the signal. Since the jitter in modern digital
> electronic is in the picosecond, that is not a factor. That means the
> determining factor will be the jitter in the interrupt handling.
>

That may be true for your purposes. However, accuracy is Computer time -
UTC. So clearly if to 1 ns the difference is always 3 days, one would
not call that accurate. The interrupt handling/propagation delays are
one way. They always make the computer time later than UTC. My
measurements a few years ago showed that the interrupt delay was about 1
microsecond.

> Which with 1 Ghz+ multiple core CPUs is hopefully in the low
> nanoseconds.

There is no way that the interrupt processing is that fast. Even the
reading of the local clock is not that fast.

>
>>>
>>> You need to look at both the offset and estimated error fields of
>>> loopstats and calculate the standard deviation to get any real idea of
>>> the accuracy of ntpd.
>> That may give you the random errors, not the systematic (eg from the
>> interrupt time, signal propagation time, etc)
>
> Such will show up in the graphing of the various ntpd statistics files,
> and if it doesn't, that means the people that wrote the documentation
> for the ntpd statistics files were lying, which I highly doubt.

There is no way that ntpd can measure the delay. It has no idea what UTC
actually is. All it has is reading of the computer system time when the
interrupt comes in-- which takes a while to process.
You could get a measure if, as soon as the interrupt process measured
the system time, it toggled some output port up, and then you attached a
oscilliscope to that port, and the gps input and looked at the delay
between the two.
>

[William Unruh]

On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:

And apparently usually a sawtooth error. But the fact that the leading
edge of the pulse is within 40ns does not mean that the system time is
within 40ns. As I said, the computer receives the signal. At some point
in the rise time of the pulse (smeared out by propagation delays and
impedance mismatches in the cable connecting the gps to the computer) it
triggers and interrupt. The computer has to stop what it is doing,
branch out to the interrupt handler (assuming that some non-maskable
interrupt is not running which delays that) start running the interrupt
handler program, send out a command to another subroutine in the kernel
to read the system clock and translate that into time, and deliver that
time back to the interrupt handler. All of that take time. As I said, my
measurements gave something like 1 microsecond in best case (2 or 3 or
even 10 in worst cases) in delay. There is nothing that ntp can do to to
know what that delay is. You can, with diffuculty, measure it, and you
could tell ntpd to subtract that from the time, but it is not
necessarily consistant, and will depend on the state of use of the cpus.

[William Unruh]

On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> Terje Mathisen <terje.m...@tmsw.no> wrote:
>> Jim Pennino wrote:
>>> Terje Mathisen <terje.m...@tmsw.no> wrote:
>>>> David Taylor wrote:
>>>>> On 02/08/2021 14:01, Jim Pennino wrote:
>>>>>>> I think that is expected if you have the PPS signal connected to CTS.
>>>>>>> AFAIK the kernel PPS serial driver works only with DCD.
>>>>>
>>>>>> Then that is a bug because most real devices use CTS.
>>
>> The above is simply wrong.
>
> OK, let me restate that.
>
> Most current, commercial devices not intended for the experimenter or
> hobbist market use CTS.
>
> FWIW, I did some research of such devices with a DB-9 connector on them.
>
>>>>> All the real devices I've used on Windows and multiple variants of Linux
>>>>> use DCD.
>>>>>
>>>> I have to agree with David here:
>>>>
>>>> I have been a member of the NTP Hackers team for more than 25 years, and
>>>> I have yet to see a PPS device on RS232 which doesn't use DCD.
>>>
>>> It is now 2021 and there have been changes.
>>
>> Not really.
>
> Yes, really, e.g. GNSS and relatively cheap rubidium oscillators.
>
> With GNSS and a $15 USB GPS, one can obtain consistent time accuracy in
> the single digit milliseconds these days.

With PPS. Without PPS, even the length of the nmea sentences vary more
than that.

[Jim Pennino]

Absolute and consistent delay is irrelevaent.

The processes of reading the PPS edge and getting the system time are
independent processes.

If things were as you say, rubidium clocks would not work.

[David Woolley]

On 02/08/2021 20:15, Jim Pennino wrote:
>> But not against UTC, but rather against various secondary standards, and
>> also not on the basis that the secondary standard is always right (in
>> which case offset would always be exactly zero, immediately after a poll).

> Assuming such a standard existed, which it doesn't.
>

I was describing an algorithm that would do this, not a source. Such an
algorithm wouldn't normally be a good one.

[Jim Pennino]

Whop dee fucking do.

Have you tried your measurements with a rubidium standard?

>
>> Which with 1 Ghz+ multiple core CPUs is hopefully in the low
>> nanoseconds.
>
> There is no way that the interrupt processing is that fast. Even the
> reading of the local clock is not that fast.

We shall see what happens.

BTW, bumble bees can't fly, the Earth is flat, and disease is caused by
bad vapors.

>>>>
>>>> You need to look at both the offset and estimated error fields of
>>>> loopstats and calculate the standard deviation to get any real idea of
>>>> the accuracy of ntpd.
>>> That may give you the random errors, not the systematic (eg from the
>>> interrupt time, signal propagation time, etc)
>>
>> Such will show up in the graphing of the various ntpd statistics files,
>> and if it doesn't, that means the people that wrote the documentation
>> for the ntpd statistics files were lying, which I highly doubt.
>
> There is no way that ntpd can measure the delay. It has no idea what UTC
> actually is. All it has is reading of the computer system time when the
> interrupt comes in-- which takes a while to process.
> You could get a measure if, as soon as the interrupt process measured
> the system time, it toggled some output port up, and then you attached a
> oscilliscope to that port, and the gps input and looked at the delay
> between the two.

So what you are saying is that rubidium clocks are a hoax?

With an attached GPS, the computer knows what UTC actually is within some
number of milliseconds which varies with the quality of the GPS and it's
jitter.

With a MODERN GNSS receiver, that number of milliseconds is less than 10
after the settling time.

With an attached MODERN GNSS receiver and PPS with a decent oscillator,
the computer knows what UTC actually is within some number of nanoseconds
less than 1,000.

What that number of nanoseconds will be is determined by the jitter in
the PPS signal and how quickly the computer can process interrupts.

While the first GPS receive used vacuum tubes, stood six feet tall, and
had two seats for operator(s), things have changed a bit.

[Jim Pennino]

No, without PPS.

How much the NMEA sentences vary depends on the speed of the electronics
in the receiver and how many satellites the receiver can process.

Some old USB GPS pucks have jitter at the hundred millisecond level and
a very few at the tens of millisecond level, and what you said used to
be true.

Modern USB GNSS pucks have jitter at the millsecond level and a standard
deviation of about 1 millisecond.

So, in summary, CURRENT, MODERN GNSS receivers have better sensitity,
can see and process more satellites, and have faster electronics inside
them.

How do I know this you say?

As I have said many times before, I am doing a study of CURRENT, MODERN
GNSS devices and how well they work with ntpd.

[William Unruh]

Rubidium clocks are not general purpose computers. Their electronics are
all specially built to reduce the errors as much as possible.
Absolute and consistant delay is NOT irrelevant. It is part of the error
budget that determines the accuracy of the clock. Or would you not care
if your clock was 3 days out in its time? If not, that is fine, but most
people would not call it accurate.

>
>

[William Unruh]

No. The NMEA sentences themselves are variable length. And the RS22
standard means that the data goes up the line not very fast. Each
character takes milliseconds to be transmitted.

>
> Some old USB GPS pucks have jitter at the hundred millisecond level and
> a very few at the tens of millisecond level, and what you said used to
> be true.

It is RS232 that is the problem.

>
> Modern USB GNSS pucks have jitter at the millsecond level and a standard
> deviation of about 1 millisecond.
>
> So, in summary, CURRENT, MODERN GNSS receivers have better sensitity,
> can see and process more satellites, and have faster electronics inside
> them.

Of course.

[chris]

Correct me if i'm wrong, but pps is traceable to UTC, so that would be
used within ntpd to set the system clock. In the case of several
ntp server sources, ntpd will weed out the outliers, keep the best and
use that to set local system time. ntpq then provides a list showing
what it thinks are the timing relationships between them, with pps utc
as the primary reference ?...

[William Unruh]

On 2021-08-02, chris <chris-...@tridac.net> wrote:
> On 08/02/21 18:05, David Woolley wrote:
>> On 02/08/2021 17:26, chris wrote:
>>> If it's working properly and has been running for a few hours,
>>> offset against UTC should be in the microsecond range, not
>>
>> ntpd doesn't provide that information. It only provides the offset
>> between the timing source and the PC's internal clock.
>
> Correct me if i'm wrong, but pps is traceable to UTC, so that would be
> used within ntpd to set the system clock. In the case of several

If one wants sub-microsecond accuracy, then how it is used within ntpd
becomes important. Lets assume that the gps module itself is good. The
hardware inside the receiver delivers a pps pulse at the UTC second (it
does not, it fluctuates a few 10s of nanoseconds from that). That pulse
then travels down the cable to the computer. If the impedance matching
between the receiver and the computer is not good, then that pulse gets
smeared out over many travel times down the cable. At a certain voltage
level, a trigger in the driver flips, and that raises and interrupt
voltage. The hardware watches for that flip, and tells the cpu to stop
(controllably) what it is doing, caches the currently running program,
loads the interrupt driver program, and branches to that program. If
that program is well written, it then calls a kernel subroutine, loading
it into memory if need be, and calls a program to convert the counter,
which is the system clock, reads out the count, and converts that count
to a time. It then returns that time to the interrupt driver routine.
All of that takes time. All of that takes a variable amount of time. For
example, if another interrupt service routine is running ( eg due to
disk reads) this one will wait for it to finish (in the sense of
signalling that it is OK for it to be interrupted )

> ntp server sources, ntpd will weed out the outliers, keep the best and
> use that to set local system time. ntpq then provides a list showing
> what it thinks are the timing relationships between them, with pps utc
> as the primary reference ?...

No. The PPS timing is simply one amongst the lot. It may well be the
chosen one, and its low stratum will mean that ntpd will be more likely
to choose it. But not necessarily.

[Jim Pennino]

William Unruh <un...@invalid.ca> wrote:
> On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:

<snip old crap>

>> Absolute and consistent delay is irrelevaent.
>>
>> The processes of reading the PPS edge and getting the system time are
>> independent processes.
>>
>> If things were as you say, rubidium clocks would not work.
>
> Rubidium clocks are not general purpose computers. Their electronics are
> all specially built to reduce the errors as much as possible.
> Absolute and consistant delay is NOT irrelevant. It is part of the error
> budget that determines the accuracy of the clock. Or would you not care
> if your clock was 3 days out in its time? If not, that is fine, but most
> people would not call it accurate.

Rubidium clocks are NOT clocks and do not tell time.

A modern rubidium clock is a box containing a rubidium oscillator that is
disciplined by an included GNSS receiver. The electronics is off the shelf
chips.

And there are no vacuum tubes in there either.

The GNSS receiver provides the GNSS data output and the precision
rubidium oscillator provides the PPS signal.

A rubidium clock has PPS jitter of around 1 nanosecond and to a computer
looks like an extremely low jitter GNSS receiver.

Most also provide an output as a frequency standard.

You keep arm waving about "3 days", why?

Why would you say something as blazingly obvious as "Rubidium clocks are
not general purpose computers"?

Are you purposely trying to be condescending?

[William Unruh]

On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> William Unruh <un...@invalid.ca> wrote:
>> On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>
><snip old crap>
>
>>> Absolute and consistent delay is irrelevaent.
>>>
>>> The processes of reading the PPS edge and getting the system time are
>>> independent processes.
>>>
>>> If things were as you say, rubidium clocks would not work.
>>
>> Rubidium clocks are not general purpose computers. Their electronics are
>> all specially built to reduce the errors as much as possible.
>> Absolute and consistant delay is NOT irrelevant. It is part of the error
>> budget that determines the accuracy of the clock. Or would you not care
>> if your clock was 3 days out in its time? If not, that is fine, but most
>> people would not call it accurate.
>
> Rubidium clocks are NOT clocks and do not tell time.

Neither is your computer. It also just has a crystal and a counter. You
computer converts that counting to a time after calibrating that counter
(ticks per second).

>
> A modern rubidium clock is a box containing a rubidium oscillator that is
> disciplined by an included GNSS receiver. The electronics is off the shelf
> chips.
>
> And there are no vacuum tubes in there either.
>
> The GNSS receiver provides the GNSS data output and the precision
> rubidium oscillator provides the PPS signal.
>
> A rubidium clock has PPS jitter of around 1 nanosecond and to a computer
> looks like an extremely low jitter GNSS receiver.
>
> Most also provide an output as a frequency standard.
>
> You keep arm waving about "3 days", why?

As an obviously huge error which noone would regard as accurate, even if
that offset has vary small fluctuation.

>
> Why would you say something as blazingly obvious as "Rubidium clocks are
> not general purpose computers"?

Because you compared a Rubidium clock to a general purpose computer.

>
> Are you purposely trying to be condescending?

Obvious perhaps, condescending no.
>
>

[chris]

Thanks for that detailed description. I do real time embedded
hw and sw work here and am familiar with interrupt processing
and priorities. Even with all the processing and assuming a
stripped down and lightly loaded, dedicated intermediate host
running ntpd, I would expect the processing delays to be in
the order of a handfull of microseconds on a say an i3 or core
2 level platform. Yes, there will be jitter, but still within
a small margin related to that. This is born out by the
consistent reports from the ntpq utility, once the sytem has
settled down for a few hours.

>
>> ntp server sources, ntpd will weed out the outliers, keep the best and
>> use that to set local system time. ntpq then provides a list showing
>> what it thinks are the timing relationships between them, with pps utc
>> as the primary reference ?...
>
> No. The PPS timing is simply one amongst the lot. It may well be the
> chosen one, and its low stratum will mean that ntpd will be more likely
> to choose it. But not necessarily.
>

From the results here, the pps always seesm to be the primary
reference, once the system has settled down. That would make
sense, since it will always be the most accurate measure
against UTC, if it is a local source...

[chris]

On 08/02/21 23:59, Jim Pennino wrote:
> William Unruh<un...@invalid.ca> wrote:
>> On 2021-08-02, Jim Pennino<ji...@gonzo.specsol.net> wrote:
>
> <snip old crap>
>
>>> Absolute and consistent delay is irrelevaent.
>>>
>>> The processes of reading the PPS edge and getting the system time are
>>> independent processes.
>>>
>>> If things were as you say, rubidium clocks would not work.
>>
>> Rubidium clocks are not general purpose computers. Their electronics are
>> all specially built to reduce the errors as much as possible.
>> Absolute and consistant delay is NOT irrelevant. It is part of the error
>> budget that determines the accuracy of the clock. Or would you not care
>> if your clock was 3 days out in its time? If not, that is fine, but most
>> people would not call it accurate.
>
> Rubidium clocks are NOT clocks and do not tell time.
>
> A modern rubidium clock is a box containing a rubidium oscillator that is
> disciplined by an included GNSS receiver. The electronics is off the shelf
> chips.
>
> And there are no vacuum tubes in there either.
>
> The GNSS receiver provides the GNSS data output and the precision
> rubidium oscillator provides the PPS signal.

Not really the full story. The rb source or vcxo is locked to
gps 1pps, also providing the external pps signal to ntpd. The
rb is typically used as a low phase noise frequency standard
for external equipment such as signal generators, counters etc.
They are not separate entities, but are intimately connected.
Suggest swot up on gps disciplined oscillators, for more
background on how the systems work...

[Jim Pennino]

PPS has no information. The purpose of PPS is to provide a reference
that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.

It is the NMEA sentences that contain the date and time along with stuff
irrelevant to time, e.g. altitude, speed, etc.

When the NMEA sentences appear is not specified by anything and their
appearance times have a LOT of jitter in them.

To VASTLY simplify, what ntpd does is look at the GPS time, which is in
nanoseconds, and the computer system clock time when the PPS occurs
and correlate them. ntpd either slows or speeds up the computer system
clock until the computer system clock is in sync with the GPS time at
the time of the PPS to the best accuacy it can achieve with the given
hardware.

A receiver does not get data from one, satellite, it gets data from all
the satellites it can see to the limit of how many channels the receiver
was designed to see at once and provides a NMEA sentence type as the
best average from all the data it gets.

A recent, modern receiver is not just GPS, but GNSS which means it can
see more systems, e.g. GLONASS, has more channels than old receivers,
has better receiver sensitivity and faster electronics.

The net result is a modern GNSS receiver has better data as it is the
average of more satellites and less jitter because data is processed
faster.

It also seems the ntpd algorithms fall apart if you have multiple high
accuracy reference clocks attached. I doubt any of the designers ever
envisioned the day would come when someone could afford more than one as
at that time such things would set you back many tens of thousands of
dollars.

Now they cost less than $50.

This is irrelevant as if you have a high accuracy reference clock, you
only need one and ntpd will sort itself out just fine.

[Jim Pennino]

Yes, NMEA sentences themselves are variable length.

I never said they were not.

The jitter in NMEA sentences is the sum of the jitter due to sentence
variability and the speed at which the receiver electronics can process
all the data to create all the NMEA sentences.

Many people have tested RS-232 speeds and have documented that speeds
faster than 9600 baud do little to nothing for jitter. If you doubt
that, spend some time on ntp.org and read the documentation.

>>
>> Some old USB GPS pucks have jitter at the hundred millisecond level and
>> a very few at the tens of millisecond level, and what you said used to
>> be true.
> It is RS232 that is the problem.

Nope.

RS-232 has nothing to do with USB and USB is MUCH faster than 9600 baud.

[Jim Pennino]

Sigh, you are just sort of parroting the definition of a disciplined clock
which these days go by the name GNSSDO with a qualifier of either OCXO
or rubidium.

Also, VCXO means voltage controlled crystal oscillator, and rubidium
clocks are neither voltage controlled these days or crystals.

In a modern GNSSDO, there is a GNSS receiver consisting of a chip set,
a rubidium oscillator and some off the shelf chips to discipline the
oscillator and provide I/O for the system.

[Jim Pennino]

William Unruh <un...@invalid.ca> wrote:
> On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>> William Unruh <un...@invalid.ca> wrote:
>>> On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>>
>><snip old crap>
>>
>>>> Absolute and consistent delay is irrelevaent.
>>>>
>>>> The processes of reading the PPS edge and getting the system time are
>>>> independent processes.
>>>>
>>>> If things were as you say, rubidium clocks would not work.
>>>
>>> Rubidium clocks are not general purpose computers. Their electronics are
>>> all specially built to reduce the errors as much as possible.
>>> Absolute and consistant delay is NOT irrelevant. It is part of the error
>>> budget that determines the accuracy of the clock. Or would you not care
>>> if your clock was 3 days out in its time? If not, that is fine, but most
>>> people would not call it accurate.
>>
>> Rubidium clocks are NOT clocks and do not tell time.
>
> Neither is your computer. It also just has a crystal and a counter. You
> computer converts that counting to a time after calibrating that counter
> (ticks per second).

WTF???

My computer tells time better than my wrist watch, but so what?

>> A modern rubidium clock is a box containing a rubidium oscillator that is
>> disciplined by an included GNSS receiver. The electronics is off the shelf
>> chips.

Didn't even bother to read this part before your WTF, knee jerk reply,
did you?

>>
>> And there are no vacuum tubes in there either.
>>
>> The GNSS receiver provides the GNSS data output and the precision
>> rubidium oscillator provides the PPS signal.
>>
>> A rubidium clock has PPS jitter of around 1 nanosecond and to a computer
>> looks like an extremely low jitter GNSS receiver.
>>
>> Most also provide an output as a frequency standard.
>>
>> You keep arm waving about "3 days", why?
>
> As an obviously huge error which noone would regard as accurate, even if
> that offset has vary small fluctuation.

And obviously just arm waving.

>>
>> Why would you say something as blazingly obvious as "Rubidium clocks are
>> not general purpose computers"?
>
> Because you compared a Rubidium clock to a general purpose computer.

No, I did not.

That would be blazingly asinine and I utterly fail to see how you could
ever come to such a conclusion.

>>
>> Are you purposely trying to be condescending?
>
> Obvious perhaps, condescending no.
>>

More like oblivious to whatever I say.

[Miroslav Lichvar]

On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> That is, if one has an absolutely accurate PPS signal that is exactly
> 1Hz, it doesn't matter how long, within reason, it takes to process the
> PPS signal. What matters is how much jitter the hardware and software
> has in processing the signal. Since the jitter in modern digital
> electronic is in the picosecond, that is not a factor. That means the
> determining factor will be the jitter in the interrupt handling.
>
> Which with 1 Ghz+ multiple core CPUs is hopefully in the low
> nanoseconds.

No, a typical jitter of the interrupt-based PPS timestamping on a
computer serial port is around 1 microsecond and there is a delay of at
least few microseconds. If you didn't disable the CPU power-saving
features, the delay can easily get to tens of microseconds and a large
offset can be observed when the CPU is loaded on and off.

It does not matter if your PPS signal is stable to 1 or 50 nanoseconds.
It makes no difference in that noise. A $10 GPS from ebay would likely
perform the same as long as it can get a good signal.

If you were serious about accuracy and stability, you wouldn't be
connecting PPS to a serial port. You need something that has hardware
timestamping, like a networking card (e.g. the I210). That would get you
to the low nanosecond range, at least for the hardware clock.

Synchronization of the system clock to the hardware clock is the weakest
link of the chain. It is typically accurate only to few hundreds of
nanoseconds. The problem is large and asymmetric latency of the PCIe
bus, which cannot be easily measured and compensated. Still, that's at
least an order of magnitude better that the serial port.

A new feature that some NICs have is PTM, which is basically a hardware
implementation of NTP on PCIe. It should improve the accuracy
significantly. I have not had a chance to play with it yet.

--
Miroslav Lichvar

[David Woolley]

On 03/08/2021 00:37, Jim Pennino wrote:
> PPS has no information. The purpose of PPS is to provide a reference
> that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.
>

PPS provides information on where within the cycle the true UTC second
transition most probably lies. You pretty much acknowledge that later
in your description.

[David Woolley]

On 02/08/2021 23:25, chris wrote:

> Correct me if i'm wrong, but pps is traceable to UTC

Pedantically, only with hindsight, as UTC is determined by
retrospectively comparing many clocks, and the corrections are only
published monthly.

It is also subject to being obtained from a source which is itself
traceable, typically a satellite navigation receiver which has a clear
view of the whole sky, working with a built in antenna, and not subject
to a jamming or spoofing attack. Having atmospheric conditions that
match the the model use also helps.

ntpd will lock onto a 1pps signal from a free running clock.

[David Woolley]

On 03/08/2021 01:13, Jim Pennino wrote:

> And there are no vacuum tubes in there either.

I'm sure the reference to vacuum tubes was rhetorical, as I don't think
GPS was started until well into the solid state age.

However, some quick research on how rubidium clocks work suggests that a
vacuum tube would be a good description of the rubidium containing part
of the system, as they are low pressure discharge lamps. They have to
be low pressure to prevent atoms interacting with each other.

Also rubidium oscillator is something of a misnomer, as they are really
rubidium controlled crystal oscillators.

[Jim Pennino]

David Woolley <da...@ex.djwhome.demon.invalid> wrote:
> On 03/08/2021 01:13, Jim Pennino wrote:
>
>> And there are no vacuum tubes in there either.
>
> I'm sure the reference to vacuum tubes was rhetorical, as I don't think
> GPS was started until well into the solid state age.

The first GPS receiver was built in 1977 and vacuum tube equipment was
still quite common.

It sat on the roof of the Rockwell Collins building waiting for the
first GPS satellite to be turned on and was manned by Rockwell
engineers.

It was in a 6 foot tall rack with 2 seats for operator(s).

They did not build it from component parts unless there was some part
that did not exist, ergo any module such as a RF receiver, RF amplfier,
signal amplifier, etc. was likely full of tubes of some sort.

> However, some quick research on how rubidium clocks work suggests that a
> vacuum tube would be a good description of the rubidium containing part
> of the system, as they are low pressure discharge lamps. They have to
> be low pressure to prevent atoms interacting with each other.

So do incandescent light bulbs.

> Also rubidium oscillator is something of a misnomer, as they are really
> rubidium controlled crystal oscillators.

Sing it to the heavens above and see how it plays.

[Jim Pennino]

Nope.

In fact if one were to build a highly stable oscillator totally
independent of GPS, it would still work as a PPS signal.

If you think otherwise, please provide the GPS specification.

[Jim Pennino]

Miroslav Lichvar <mlic...@redhat.com> wrote:
> On 2021-08-02, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>> That is, if one has an absolutely accurate PPS signal that is exactly
>> 1Hz, it doesn't matter how long, within reason, it takes to process the
>> PPS signal. What matters is how much jitter the hardware and software
>> has in processing the signal. Since the jitter in modern digital
>> electronic is in the picosecond, that is not a factor. That means the
>> determining factor will be the jitter in the interrupt handling.
>>
>> Which with 1 Ghz+ multiple core CPUs is hopefully in the low
>> nanoseconds.
>
> No, a typical jitter of the interrupt-based PPS timestamping on a
> computer serial port is around 1 microsecond and there is a delay of at
> least few microseconds. If you didn't disable the CPU power-saving
> features, the delay can easily get to tens of microseconds and a large
> offset can be observed when the CPU is loaded on and off.

That has not been my experience.

> It does not matter if your PPS signal is stable to 1 or 50 nanoseconds.
> It makes no difference in that noise. A $10 GPS from ebay would likely
> perform the same as long as it can get a good signal.

The cheapest, current, commercial GPS with a serial connector and PPS
that I can find is over $100.

> If you were serious about accuracy and stability, you wouldn't be
> connecting PPS to a serial port. You need something that has hardware
> timestamping, like a networking card (e.g. the I210). That would get you
> to the low nanosecond range, at least for the hardware clock.

I never said anything about being serious.

I said I was researching the utility of cheap devices to drive ntpd.

> Synchronization of the system clock to the hardware clock is the weakest
> link of the chain. It is typically accurate only to few hundreds of
> nanoseconds. The problem is large and asymmetric latency of the PCIe
> bus, which cannot be easily measured and compensated. Still, that's at
> least an order of magnitude better that the serial port.
>
> A new feature that some NICs have is PTM, which is basically a hardware
> implementation of NTP on PCIe. It should improve the accuracy
> significantly. I have not had a chance to play with it yet.

We shall see...