Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

<wiggy> bwah, vodka in my mouse


devel / comp.protocols.time.ntp / Re: gpsd no PPS output - Solved

SubjectAuthor
* gpsd no PPS outputJim Pennino
+* Re: gpsd no PPS outputchris
|+* Re: gpsd no PPS outputWilliam Unruh
||`* Re: gpsd no PPS outputJim Pennino
|| `* Re: gpsd no PPS outputWilliam Unruh
||  `- Re: gpsd no PPS outputJim Pennino
|`* Re: gpsd no PPS outputJim Pennino
| `* Re: gpsd no PPS outputchris
|  +* Re: gpsd no PPS outputchris
|  |`- Re: gpsd no PPS outputJim Pennino
|  +* Re: gpsd no PPS outputWilliam Unruh
|  |+- Re: gpsd no PPS outputchris
|  |`- Re: gpsd no PPS outputDavid Woolley
|  `* Re: gpsd no PPS outputJim Pennino
|   +* Re: gpsd no PPS outputWilliam Unruh
|   |`* Re: gpsd no PPS outputJim Pennino
|   | `* Re: gpsd no PPS outputchris
|   |  +* Re: gpsd no PPS outputchris
|   |  |`- Re: gpsd no PPS outputJim Pennino
|   |  `* Re: gpsd no PPS outputJim Pennino
|   |   `* Re: gpsd no PPS outputWilliam Unruh
|   |    `* Re: gpsd no PPS outputJim Pennino
|   |     `* Re: gpsd no PPS outputchris
|   |      `* Re: gpsd no PPS outputJim Pennino
|   |       `* Re: gpsd no PPS outputchris
|   |        `* Re: gpsd no PPS outputJim Pennino
|   |         `* Re: gpsd no PPS outputchris
|   |          `* Re: gpsd no PPS outputJim Pennino
|   |           `* Re: gpsd no PPS outputWilliam Unruh
|   |            `* Re: gpsd no PPS outputJim Pennino
|   |             `* Re: gpsd no PPS outputWilliam Unruh
|   |              `- Re: gpsd no PPS outputJim Pennino
|   `* Re: gpsd no PPS outputchris
|    +* Re: gpsd no PPS outputJim Pennino
|    |`* Re: gpsd no PPS outputchris
|    | `* Re: gpsd no PPS outputJim Pennino
|    |  `* Re: gpsd no PPS outputchris
|    |   `- Re: gpsd no PPS outputJim Pennino
|    `* Re: gpsd no PPS outputDavid Woolley
|     `- Re: gpsd no PPS outputchris
+* Re: gpsd no PPS outputMiroslav Lichvar
|`* Re: gpsd no PPS outputJim Pennino
| `* Re: gpsd no PPS outputMiroslav Lichvar
|  `- Re: gpsd no PPS outputJim Pennino
`* Re: gpsd no PPS output - SolvedJim Pennino
 +* Re: gpsd no PPS output - SolvedWilliam Unruh
 |`* Re: gpsd no PPS output - SolvedJim Pennino
 | `* Re: gpsd no PPS output - SolvedWilliam Unruh
 |  `* Re: gpsd no PPS output - SolvedJim Pennino
 |   +* Re: gpsd no PPS output - SolvedWilliam Unruh
 |   |`- Re: gpsd no PPS output - SolvedJim Pennino
 |   `- Re: gpsd no PPS output - Solvedchris
 `* Re: gpsd no PPS output - SolvedMiroslav Lichvar
  +* Re: gpsd no PPS output - Solvedchris
  |`* Re: gpsd no PPS output - SolvedJim Pennino
  | `* Re: gpsd no PPS output - Solvedchris
  |  `* Re: gpsd no PPS output - SolvedJim Pennino
  |   `* Re: gpsd no PPS output - SolvedWilliam Unruh
  |    `- Re: gpsd no PPS output - SolvedJim Pennino
  `* Re: gpsd no PPS output - SolvedJim Pennino
   `* Re: gpsd no PPS output - SolvedDavid Taylor
    +* Re: gpsd no PPS output - SolvedTerje Mathisen
    |`* Re: gpsd no PPS output - SolvedJim Pennino
    | +* Re: gpsd no PPS output - Solvedchris
    | |+* Re: gpsd no PPS output - SolvedDavid Woolley
    | ||+* Re: gpsd no PPS output - SolvedJim Pennino
    | |||`* Re: gpsd no PPS output - SolvedDavid Woolley
    | ||| `* Re: gpsd no PPS output - SolvedJim Pennino
    | |||  +* Re: gpsd no PPS output - SolvedWilliam Unruh
    | |||  |`* Re: gpsd no PPS output - SolvedJim Pennino
    | |||  | `* Re: gpsd no PPS output - SolvedWilliam Unruh
    | |||  |  `* Re: gpsd no PPS output - SolvedJim Pennino
    | |||  |   +* Re: gpsd no PPS output - SolvedWilliam Unruh
    | |||  |   |`- Re: gpsd no PPS output - SolvedJim Pennino
    | |||  |   `* Re: gpsd no PPS output - Solvedchris
    | |||  |    `* Re: gpsd no PPS output - SolvedJim Pennino
    | |||  |     `* Re: gpsd no PPS output - SolvedDavid Woolley
    | |||  |      `- Re: gpsd no PPS output - SolvedJim Pennino
    | |||  `- Re: gpsd no PPS output - SolvedDavid Woolley
    | ||`* Re: gpsd no PPS output - Solvedchris
    | || +* Re: gpsd no PPS output - SolvedWilliam Unruh
    | || |`- Re: gpsd no PPS output - Solvedchris
    | || +* Re: gpsd no PPS output - SolvedJim Pennino
    | || |+* Re: gpsd no PPS output - SolvedDavid Woolley
    | || ||`* Re: gpsd no PPS output - SolvedJim Pennino
    | || || `* Re: gpsd no PPS output - Solvedchris
    | || ||  +* Re: gpsd no PPS output - SolvedJim Pennino
    | || ||  |`* Re: gpsd no PPS output - Solvedchris
    | || ||  | `* Re: gpsd no PPS output - SolvedJim Pennino
    | || ||  |  +* Re: gpsd no PPS output - Solvedchris
    | || ||  |  |`* Re: gpsd no PPS output - SolvedJim Pennino
    | || ||  |  | `* Re: gpsd no PPS output - Solvedchris
    | || ||  |  |  `* Re: gpsd no PPS output - SolvedJim Pennino
    | || ||  |  |   +* Re: gpsd no PPS output - Solvedchris
    | || ||  |  |   |+* Re: gpsd no PPS output - Solvedchris
    | || ||  |  |   ||`- Re: gpsd no PPS output - SolvedJim Pennino
    | || ||  |  |   |`- Re: gpsd no PPS output - SolvedJim Pennino
    | || ||  |  |   `* Re: gpsd no PPS output - SolvedTerje Mathisen
    | || ||  |  |    `* Re: gpsd no PPS output - SolvedJim Pennino
    | || ||  |  |     `* Re: gpsd no PPS output - SolvedTerje Mathisen
    | || ||  |  |      +* Re: gpsd no PPS output - SolvedJim Pennino
    | || ||  |  |      `* Re: gpsd no PPS output - SolvedDavid Woolley
    | || ||  |  `* Re: gpsd no PPS output - SolvedDavid Woolley
    | || ||  `* Re: gpsd no PPS output - SolvedTerje Mathisen
    | || |`* Re: gpsd no PPS output - SolvedTerje Mathisen
    | || `- Re: gpsd no PPS output - SolvedDavid Woolley
    | |`* Re: gpsd no PPS output - SolvedJim Pennino
    | `* Re: gpsd no PPS output - SolvedTerje Mathisen
    `- Re: gpsd no PPS output - SolvedJim Pennino

Pages:1234567
Re: gpsd no PPS output - Solved

<oqugth-gvo2.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=134&group=comp.protocols.time.ntp#134

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Sat, 31 Jul 2021 15:18:34 -0700
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <oqugth-gvo2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se3uqe$9st$1@dont-email.me> <qjlgth-enh2.ln1@gonzo.specsol.net> <se4d0n$7cf$1@dont-email.me> <ptqgth-61l2.ln1@gonzo.specsol.net> <se4h1s$5h1$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="b53a8b6b3c95ca87a29024a278b63c01";
logging-data="22827"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+AvLV5IC52lyev2srYn6no"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:+Xo9WUJhdb8ildMsXoXfxruYC7c=
 by: Jim Pennino - Sat, 31 Jul 2021 22:18 UTC

William Unruh <unruh@invalid.ca> wrote:
> On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>> William Unruh <unruh@invalid.ca> wrote:
>>> On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>>>> William Unruh <unruh@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?

Re: gpsd no PPS output - Solved

<se4nnf$1k59$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=135&group=comp.protocols.time.ntp#135

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!jazQyxryRFiI4FEZ51SAvA.user.46.165.242.75.POSTED!not-for-mail
From: chris-nospam@tridac.net (chris)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Sun, 01 Aug 2021 00:52:15 +0100
Organization: Aioe.org NNTP Server
Message-ID: <se4nnf$1k59$1@gioia.aioe.org>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se3uqe$9st$1@dont-email.me> <qjlgth-enh2.ln1@gonzo.specsol.net> <se4d0n$7cf$1@dont-email.me> <ptqgth-61l2.ln1@gonzo.specsol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="53417"; posting-host="jazQyxryRFiI4FEZ51SAvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
X-Notice: Filtered by postfilter v. 0.9.2
 by: chris - Sat, 31 Jul 2021 23:52 UTC

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...

Re: gpsd no PPS output - Solved

<se8h2q$691$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=136&group=comp.protocols.time.ntp#136

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!wqF6YW3b7B3ExDozbCCFcA.user.46.165.242.75.POSTED!not-for-mail
From: mlichvar@redhat.com (Miroslav Lichvar)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 10:23:22 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <se8h2q$691$1@gioia.aioe.org>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<8j2gth-nm22.ln1@gonzo.specsol.net>
Injection-Info: gioia.aioe.org; logging-data="6433"; posting-host="wqF6YW3b7B3ExDozbCCFcA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: slrn/1.0.3 (Linux)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Miroslav Lichvar - Mon, 2 Aug 2021 10:23 UTC

On 2021-07-31, Jim Pennino <jimp@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

Re: gpsd no PPS output - Solved

<se8odv$1m0d$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=137&group=comp.protocols.time.ntp#137

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!jazQyxryRFiI4FEZ51SAvA.user.46.165.242.75.POSTED!not-for-mail
From: chris-nospam@tridac.net (chris)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 02 Aug 2021 13:28:47 +0100
Organization: Aioe.org NNTP Server
Message-ID: <se8odv$1m0d$1@gioia.aioe.org>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="55309"; posting-host="jazQyxryRFiI4FEZ51SAvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
X-Notice: Filtered by postfilter v. 0.9.2
 by: chris - Mon, 2 Aug 2021 12:28 UTC

On 08/02/21 11:23, Miroslav Lichvar wrote:
> On 2021-07-31, Jim Pennino<jimp@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.
>

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

Re: gpsd no PPS output - Solved

<1u6lth-9ls1.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=138&group=comp.protocols.time.ntp#138

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!rocksolid2!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 06:01:23 -0700
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <1u6lth-9ls1.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="20942"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+9r0LZdpny98JJzrYQ3j9Z"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:mleixqRDb/ZPsE7vfGw5rxq54nQ=
 by: Jim Pennino - Mon, 2 Aug 2021 13:01 UTC

Miroslav Lichvar <mlichvar@redhat.com> wrote:
> On 2021-07-31, Jim Pennino <jimp@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.

Re: gpsd no PPS output - Solved

<se902j$292$1@dont-email.me>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=139&group=comp.protocols.time.ntp#139

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david-taylor@blueyonder.co.uk.invalid (David Taylor)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 15:39:15 +0100
Organization: A noiseless patient Spider
Lines: 12
Message-ID: <se902j$292$1@dont-email.me>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
<1u6lth-9ls1.ln1@gonzo.specsol.net>
Reply-To: david-taylor@blueyonder.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 2 Aug 2021 14:39:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="816894cd24509d0ee58bf2749c724a1a";
logging-data="2338"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Dmq6f4MQTY8ot7mWLHUXAVWP9pdrEV+c="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
Cancel-Lock: sha1:PMvoHR0yWMRSSM7uRs+7emR5Qks=
In-Reply-To: <1u6lth-9ls1.ln1@gonzo.specsol.net>
Content-Language: en-GB
 by: David Taylor - Mon, 2 Aug 2021 14:39 UTC

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

Re: gpsd no PPS output - Solved

<bbclth-qn32.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=140&group=comp.protocols.time.ntp#140

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 07:33:49 -0700
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <bbclth-qn32.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <se8odv$1m0d$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="6905"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/RBjgHkHYvbnUjGjzLosj/"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:qTnVDLkd55BZN+BFvNoCD/+QrMc=
 by: Jim Pennino - Mon, 2 Aug 2021 14:33 UTC

chris <chris-nospam@tridac.net> wrote:
> On 08/02/21 11:23, Miroslav Lichvar wrote:
>> On 2021-07-31, Jim Pennino<jimp@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.
>>
>
> 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
"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

Re: gpsd no PPS output - Solved

<se911q$1nfb$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=141&group=comp.protocols.time.ntp#141

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!aoTW/Fm1++YcllHDt9jnUQ.user.46.165.242.91.POSTED!not-for-mail
From: terje.mathisen@tmsw.no (Terje Mathisen)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 16:55:54 +0200
Organization: Aioe.org NNTP Server
Message-ID: <se911q$1nfb$1@gioia.aioe.org>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
<1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="56811"; posting-host="aoTW/Fm1++YcllHDt9jnUQ.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.8.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Mon, 2 Aug 2021 14:55 UTC

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"

Re: gpsd no PPS output - Solved

<s6glth-b082.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=142&group=comp.protocols.time.ntp#142

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 08:39:42 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <s6glth-b082.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me> <se911q$1nfb$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="351"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Zj7i3ewiFktl9E9AiujGX"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:wpKYaeJSvefnF1Wou/af8S2kJiw=
 by: Jim Pennino - Mon, 2 Aug 2021 15:39 UTC

Terje Mathisen <terje.mathisen@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?

Re: gpsd no PPS output - Solved

<baglth-b082.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=143&group=comp.protocols.time.ntp#143

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!news.niel.me!news.gegeweb.eu!gegeweb.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 08:41:33 -0700
Organization: A noiseless patient Spider
Lines: 12
Message-ID: <baglth-b082.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="351"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX196w+L/GcMxAZb/mRwOePai"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:1MN+Q0OCVfUBMpoTxMDRITEdgio=
 by: Jim Pennino - Mon, 2 Aug 2021 15:41 UTC

David Taylor <david-taylor@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.

Re: gpsd no PPS output - Solved

<se95v8$cvs$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=144&group=comp.protocols.time.ntp#144

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!jazQyxryRFiI4FEZ51SAvA.user.46.165.242.75.POSTED!not-for-mail
From: chris-nospam@tridac.net (chris)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 02 Aug 2021 17:19:52 +0100
Organization: Aioe.org NNTP Server
Message-ID: <se95v8$cvs$1@gioia.aioe.org>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <se8odv$1m0d$1@gioia.aioe.org> <bbclth-qn32.ln1@gonzo.specsol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="13308"; posting-host="jazQyxryRFiI4FEZ51SAvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
X-Notice: Filtered by postfilter v. 0.9.2
 by: chris - Mon, 2 Aug 2021 16:19 UTC

On 08/02/21 15:33, Jim Pennino wrote:
> chris<chris-nospam@tridac.net> wrote:
>> On 08/02/21 11:23, Miroslav Lichvar wrote:
>>> On 2021-07-31, Jim Pennino<jimp@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.
>>>
>>
>> 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
>
> "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
>

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...

Re: gpsd no PPS output - Solved

<se96b5$j8d$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=145&group=comp.protocols.time.ntp#145

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!jazQyxryRFiI4FEZ51SAvA.user.46.165.242.75.POSTED!not-for-mail
From: chris-nospam@tridac.net (chris)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 02 Aug 2021 17:26:13 +0100
Organization: Aioe.org NNTP Server
Message-ID: <se96b5$j8d$1@gioia.aioe.org>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me> <se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="19725"; posting-host="jazQyxryRFiI4FEZ51SAvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
X-Notice: Filtered by postfilter v. 0.9.2
 by: chris - Mon, 2 Aug 2021 16:26 UTC

On 08/02/21 16:39, Jim Pennino wrote:
> Terje Mathisen<terje.mathisen@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?
>

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...

Re: gpsd no PPS output - Solved

<se98l2$1g8$1@dont-email.me>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=146&group=comp.protocols.time.ntp#146

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 18:05:38 +0100
Organization: No affiliation
Lines: 6
Message-ID: <se98l2$1g8$1@dont-email.me>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
<1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me>
<se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net>
<se96b5$j8d$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 2 Aug 2021 17:05:38 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a4de7acac1e95f9aad2d6b5ccdbcd72c";
logging-data="1544"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ry1qxE3gtqMCZBIW4hm+CGPUfyUun+0Y="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:/v2J9FIqxsx3sWWD1PHoB85zPHs=
In-Reply-To: <se96b5$j8d$1@gioia.aioe.org>
Content-Language: en-GB
 by: David Woolley - Mon, 2 Aug 2021 17:05 UTC

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.

Re: gpsd no PPS output - Solved

<se9amq$pdm$1@gioia.aioe.org>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=147&group=comp.protocols.time.ntp#147

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!aoTW/Fm1++YcllHDt9jnUQ.user.46.165.242.91.POSTED!not-for-mail
From: terje.mathisen@tmsw.no (Terje Mathisen)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 19:40:42 +0200
Organization: Aioe.org NNTP Server
Message-ID: <se9amq$pdm$1@gioia.aioe.org>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
<1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me>
<se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="26038"; posting-host="aoTW/Fm1++YcllHDt9jnUQ.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.8.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Mon, 2 Aug 2021 17:40 UTC

Jim Pennino wrote:
> Terje Mathisen <terje.mathisen@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.

Terje

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

Re: gpsd no PPS output - Solved

<3enlth-cmd2.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=148&group=comp.protocols.time.ntp#148

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 10:43:01 -0700
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <3enlth-cmd2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me> <se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net> <se96b5$j8d$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="20704"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/svvmN8GXbSs9YyhwswsxN"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:hLATcgXY5UQ4GBIvpYTz1k+Ns6c=
 by: Jim Pennino - Mon, 2 Aug 2021 17:43 UTC

chris <chris-nospam@tridac.net> wrote:
> On 08/02/21 16:39, Jim Pennino wrote:
>> Terje Mathisen<terje.mathisen@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?
>>
>
>
> 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...

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?

Re: gpsd no PPS output - Solved

<vnmlth-cmd2.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=149&group=comp.protocols.time.ntp#149

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 10:31:13 -0700
Organization: A noiseless patient Spider
Lines: 114
Message-ID: <vnmlth-cmd2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <se8odv$1m0d$1@gioia.aioe.org> <bbclth-qn32.ln1@gonzo.specsol.net> <se95v8$cvs$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="20704"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/hnay2fiVh/PTYyzIvKn9o"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:CC7d30bx3ldL9ndUgVOLrCp22O8=
 by: Jim Pennino - Mon, 2 Aug 2021 17:31 UTC

chris <chris-nospam@tridac.net> wrote:
> On 08/02/21 15:33, Jim Pennino wrote:
>> chris<chris-nospam@tridac.net> wrote:
>>> On 08/02/21 11:23, Miroslav Lichvar wrote:
>>>> On 2021-07-31, Jim Pennino<jimp@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.
>>>>
>>>
>>> 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
>>
>> "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
>>
>
> 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...

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.

Re: gpsd no PPS output - Solved

<h0olth-cmd2.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=150&group=comp.protocols.time.ntp#150

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 10:52:51 -0700
Organization: A noiseless patient Spider
Lines: 12
Message-ID: <h0olth-cmd2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me> <se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net> <se96b5$j8d$1@gioia.aioe.org> <se98l2$1g8$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="27146"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19G7bLTFP3yFsXMmJbia0YJ"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:JiUHHo5oCIx3jRVCBvYTr8ViL1c=
 by: Jim Pennino - Mon, 2 Aug 2021 17:52 UTC

David Woolley <david@ex.djwhome.demon.invalid> 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.

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

Re: gpsd no PPS output - Solved

<se9d11$vjj$1@dont-email.me>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=151&group=comp.protocols.time.ntp#151

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: unruh@invalid.ca (William Unruh)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 18:20:17 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <se9d11$vjj$1@dont-email.me>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
<se8odv$1m0d$1@gioia.aioe.org> <bbclth-qn32.ln1@gonzo.specsol.net>
<se95v8$cvs$1@gioia.aioe.org> <vnmlth-cmd2.ln1@gonzo.specsol.net>
Injection-Date: Mon, 2 Aug 2021 18:20:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6669544dde06baeda06ad6948fda2f08";
logging-data="32371"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TRcbeIHguk2sTWV4eMPNp"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:ut8pdMM86cf7KmZ8rAivbCNKX6k=
 by: William Unruh - Mon, 2 Aug 2021 18:20 UTC

On 2021-08-02, Jim Pennino <jimp@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.
.....
.....
.....
.....

Re: gpsd no PPS output - Solved

<se9d9k$vjj$2@dont-email.me>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=152&group=comp.protocols.time.ntp#152

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: unruh@invalid.ca (William Unruh)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 18:24:52 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <se9d9k$vjj$2@dont-email.me>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
<1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me>
<se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net>
<se96b5$j8d$1@gioia.aioe.org> <3enlth-cmd2.ln1@gonzo.specsol.net>
Injection-Date: Mon, 2 Aug 2021 18:24:52 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6669544dde06baeda06ad6948fda2f08";
logging-data="32371"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+FLqZoIo3Nl4P1PvJi0eON"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:L/qNwIvQna5k6RpGtTf9eQN0k3E=
 by: William Unruh - Mon, 2 Aug 2021 18:24 UTC

On 2021-08-02, Jim Pennino <jimp@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)

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

Re: gpsd no PPS output - Solved

<se9dml$853$1@dont-email.me>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=153&group=comp.protocols.time.ntp#153

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 19:31:48 +0100
Organization: No affiliation
Lines: 14
Message-ID: <se9dml$853$1@dont-email.me>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
<1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me>
<se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net>
<se96b5$j8d$1@gioia.aioe.org> <se98l2$1g8$1@dont-email.me>
<h0olth-cmd2.ln1@gonzo.specsol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 2 Aug 2021 18:31:49 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a4de7acac1e95f9aad2d6b5ccdbcd72c";
logging-data="8355"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/c39EF6g2ac/CUAO++38dLjhsE6SYcp00="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:bL+rrORnclP29LgDLw1ylF7MVJQ=
In-Reply-To: <h0olth-cmd2.ln1@gonzo.specsol.net>
Content-Language: en-GB
 by: David Woolley - Mon, 2 Aug 2021 18:31 UTC

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.)

Re: gpsd no PPS output - Solved

<6fqlth-h2g2.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=154&group=comp.protocols.time.ntp#154

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 11:34:48 -0700
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <6fqlth-h2g2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me> <se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net> <se9amq$pdm$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="14141"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18mrkkCKe+QORpSednWlLH2"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:/RH3GZnKmWsQLZao/4sW6kOhiRY=
 by: Jim Pennino - Mon, 2 Aug 2021 18:34 UTC

Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> Jim Pennino wrote:
>> Terje Mathisen <terje.mathisen@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.

Re: gpsd no PPS output - Solved

<3brlth-h2g2.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=155&group=comp.protocols.time.ntp#155

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 11:49:41 -0700
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <3brlth-h2g2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <se8odv$1m0d$1@gioia.aioe.org> <bbclth-qn32.ln1@gonzo.specsol.net> <se95v8$cvs$1@gioia.aioe.org> <vnmlth-cmd2.ln1@gonzo.specsol.net> <se9d11$vjj$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="20311"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+AYb6ivA/rsHCgEip24Pk+"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:MIieflJ/TlgzXqGSHGGJYPsI3ME=
 by: Jim Pennino - Mon, 2 Aug 2021 18:49 UTC

William Unruh <unruh@invalid.ca> wrote:
> On 2021-08-02, Jim Pennino <jimp@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.
>

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.

Re: gpsd no PPS output - Solved

<srslth-frh2.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=156&group=comp.protocols.time.ntp#156

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 12:15:42 -0700
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <srslth-frh2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me> <se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net> <se96b5$j8d$1@gioia.aioe.org> <se98l2$1g8$1@dont-email.me> <h0olth-cmd2.ln1@gonzo.specsol.net> <se9dml$853$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="26848"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/nOmLLZ08SuIafCNGPYZyu"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:GAX2FN+RpIrvoBzR68vK2yZ6CsA=
 by: Jim Pennino - Mon, 2 Aug 2021 19:15 UTC

David Woolley <david@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.

Re: gpsd no PPS output - Solved

<8hslth-frh2.ln1@gonzo.specsol.net>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=157&group=comp.protocols.time.ntp#157

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jimp@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 12:10:02 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <8hslth-frh2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org> <1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me> <se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net> <se96b5$j8d$1@gioia.aioe.org> <3enlth-cmd2.ln1@gonzo.specsol.net> <se9d9k$vjj$2@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="26848"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18f/NvrjvqhJgQfOUulxg/k"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:6YrVT5u03jvtCODHg053ivX31rg=
 by: Jim Pennino - Mon, 2 Aug 2021 19:10 UTC

William Unruh <unruh@invalid.ca> wrote:
> On 2021-08-02, Jim Pennino <jimp@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.

Re: gpsd no PPS output - Solved

<se9kln$l1b$1@dont-email.me>

 copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=158&group=comp.protocols.time.ntp#158

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: unruh@invalid.ca (William Unruh)
Newsgroups: comp.protocols.time.ntp
Subject: Re: gpsd no PPS output - Solved
Date: Mon, 2 Aug 2021 20:30:47 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <se9kln$l1b$1@dont-email.me>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<8j2gth-nm22.ln1@gonzo.specsol.net> <se8h2q$691$1@gioia.aioe.org>
<1u6lth-9ls1.ln1@gonzo.specsol.net> <se902j$292$1@dont-email.me>
<se911q$1nfb$1@gioia.aioe.org> <s6glth-b082.ln1@gonzo.specsol.net>
<se96b5$j8d$1@gioia.aioe.org> <3enlth-cmd2.ln1@gonzo.specsol.net>
<se9d9k$vjj$2@dont-email.me> <8hslth-frh2.ln1@gonzo.specsol.net>
Injection-Date: Mon, 2 Aug 2021 20:30:47 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6669544dde06baeda06ad6948fda2f08";
logging-data="21547"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/cjPpgbe2Zb4bFBTjqyWAw"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:hJqe5p+cj6b6LlX/9iA4cpA1g0s=
 by: William Unruh - Mon, 2 Aug 2021 20:30 UTC

On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
> William Unruh <unruh@invalid.ca> wrote:
>> On 2021-08-02, Jim Pennino <jimp@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.
>

Pages:1234567
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor