Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

Mirrors should reflect a little before throwing back images. -- Jean Cocteau


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

<se9l94$l1b$2@dont-email.me>

 copy mid

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

 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:41:08 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <se9l94$l1b$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> <se98l2$1g8$1@dont-email.me>
<h0olth-cmd2.ln1@gonzo.specsol.net> <se9dml$853$1@dont-email.me>
<srslth-frh2.ln1@gonzo.specsol.net>
Injection-Date: Mon, 2 Aug 2021 20:41:08 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6669544dde06baeda06ad6948fda2f08";
logging-data="21547"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+zfI+QnTdlYMHIVfS1nj9T"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:3QSRpDJ0byrwK0h/i/FtYZLM7ac=
 by: William Unruh - Mon, 2 Aug 2021 20:41 UTC

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

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.

Re: gpsd no PPS output - Solved

<se9lg7$l1b$3@dont-email.me>

 copy mid

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

 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:44:55 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <se9lg7$l1b$3@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>
<se9amq$pdm$1@gioia.aioe.org> <6fqlth-h2g2.ln1@gonzo.specsol.net>
Injection-Date: Mon, 2 Aug 2021 20:44:55 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6669544dde06baeda06ad6948fda2f08";
logging-data="21547"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/hTmgqZcPHR4T6rc1Y/WFU"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:oHHO9magfoK0ekhgg+wzGMmAvN8=
 by: William Unruh - Mon, 2 Aug 2021 20:44 UTC

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

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

Re: gpsd no PPS output - Solved

<q43mth-d9m2.ln1@gonzo.specsol.net>

 copy mid

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

 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 14:02:52 -0700
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <q43mth-d9m2.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> <srslth-frh2.ln1@gonzo.specsol.net> <se9l94$l1b$2@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="10346"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19JgWmQHaIiiBAhY7zu41/l"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:MHAngMvkytv+NsrJYe2RZXYferg=
 by: Jim Pennino - Mon, 2 Aug 2021 21:02 UTC

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

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.

Re: gpsd no PPS output - Solved

<se9npv$btm$1@dont-email.me>

 copy mid

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

 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 22:24:15 +0100
Organization: No affiliation
Lines: 10
Message-ID: <se9npv$btm$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> <se9dml$853$1@dont-email.me>
<srslth-frh2.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 21:24:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a4de7acac1e95f9aad2d6b5ccdbcd72c";
logging-data="12214"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19FU0HzhDDqnpLMpLBRwN5N07nYaWrYy8o="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:eSMeNpIdEf5ZSz/KUJXJNQUItVo=
In-Reply-To: <srslth-frh2.ln1@gonzo.specsol.net>
Content-Language: en-GB
 by: David Woolley - Mon, 2 Aug 2021 21:24 UTC

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.

Re: gpsd no PPS output - Solved

<804mth-d9m2.ln1@gonzo.specsol.net>

 copy mid

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

 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 14:17:30 -0700
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <804mth-d9m2.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> <8hslth-frh2.ln1@gonzo.specsol.net> <se9kln$l1b$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="dff2925d9da26ca03995198afd76f9e7";
logging-data="15751"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19dAB5+n8VI17CC1X8Hxcuw"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:IDPk+ixACTctnYau0hpYqbjlVWM=
 by: Jim Pennino - Mon, 2 Aug 2021 21:17 UTC

William Unruh <unruh@invalid.ca> wrote:
> 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.

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.

Re: gpsd no PPS output - Solved

<6u4mth-r2o2.ln1@gonzo.specsol.net>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!NeTawDmIVhgskIJYLcj0Dw.user.46.165.242.75.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 14:33:28 -0700
Organization: Aioe.org NNTP Server
Message-ID: <6u4mth-r2o2.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> <6fqlth-h2g2.ln1@gonzo.specsol.net> <se9lg7$l1b$3@dont-email.me>
Injection-Info: gioia.aioe.org; logging-data="37466"; posting-host="NeTawDmIVhgskIJYLcj0Dw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
X-Notice: Filtered by postfilter v. 0.9.2
 by: Jim Pennino - Mon, 2 Aug 2021 21:33 UTC

William Unruh <unruh@invalid.ca> wrote:
> On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>> 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.
>
> With PPS. Without PPS, even the length of the nmea sentences vary more
> than that.

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.

Re: gpsd no PPS output - Solved

<se9q58$p82$1@dont-email.me>

 copy mid

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

 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 22:04:24 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <se9q58$p82$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> <se9dml$853$1@dont-email.me>
<srslth-frh2.ln1@gonzo.specsol.net> <se9l94$l1b$2@dont-email.me>
<q43mth-d9m2.ln1@gonzo.specsol.net>
Injection-Date: Mon, 2 Aug 2021 22:04:24 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6a399acd4952323cf1aae9c9b60d7d31";
logging-data="25858"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+X1ny6Bheui1eq85pfkURS"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:dUs7ao8oF/PbfV6UcPC8HJaggSE=
 by: William Unruh - Mon, 2 Aug 2021 22:04 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:
>>> 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.
>>>
>>
>> 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.
>
> 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.

>
>

Re: gpsd no PPS output - Solved

<se9qbe$p82$2@dont-email.me>

 copy mid

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

 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 22:07:42 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <se9qbe$p82$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>
<se9amq$pdm$1@gioia.aioe.org> <6fqlth-h2g2.ln1@gonzo.specsol.net>
<se9lg7$l1b$3@dont-email.me> <6u4mth-r2o2.ln1@gonzo.specsol.net>
Injection-Date: Mon, 2 Aug 2021 22:07:42 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6a399acd4952323cf1aae9c9b60d7d31";
logging-data="25858"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+iUY7sT50OInv77yjLMOCH"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:62WSQ73UNiLI5FmWSMz0dO6NAx8=
 by: William Unruh - Mon, 2 Aug 2021 22:07 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:
>>> 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.
>>
>> With PPS. Without PPS, even the length of the nmea sentences vary more
>> than that.
>
> 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.

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.

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

Re: gpsd no PPS output - Solved

<se9rdn$1i9$1@gioia.aioe.org>

 copy mid

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

 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 23:25:59 +0100
Organization: Aioe.org NNTP Server
Message-ID: <se9rdn$1i9$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> <se96b5$j8d$1@gioia.aioe.org> <se98l2$1g8$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="1609"; 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 22:25 UTC

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

Re: gpsd no PPS output - Solved

<se9sif$5v2$1@dont-email.me>

 copy mid

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

 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 22:45:35 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <se9sif$5v2$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>
<se9rdn$1i9$1@gioia.aioe.org>
Injection-Date: Mon, 2 Aug 2021 22:45:35 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6a399acd4952323cf1aae9c9b60d7d31";
logging-data="6114"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18x29btloUnubGRYeQ0NIe4"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:Yiyi98ANuF2ECda3IigOeNle4no=
 by: William Unruh - Mon, 2 Aug 2021 22:45 UTC

On 2021-08-02, chris <chris-nospam@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.

Re: gpsd no PPS output - Solved

<lu9mth-n6r2.ln1@gonzo.specsol.net>

 copy mid

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

 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 15:59:03 -0700
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <lu9mth-n6r2.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> <srslth-frh2.ln1@gonzo.specsol.net> <se9l94$l1b$2@dont-email.me> <q43mth-d9m2.ln1@gonzo.specsol.net> <se9q58$p82$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="450ee91bb9bd054efabd495e5d2c8e07";
logging-data="16566"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/t9c9B1Nn4iCnq549UbUuV"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:JCCwrSb9k9KF+dzfTIbOSwnbAjM=
 by: Jim Pennino - Mon, 2 Aug 2021 22:59 UTC

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

Re: gpsd no PPS output - Solved

<se9v2b$i69$1@dont-email.me>

 copy mid

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

 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 23:28:11 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <se9v2b$i69$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> <se9dml$853$1@dont-email.me>
<srslth-frh2.ln1@gonzo.specsol.net> <se9l94$l1b$2@dont-email.me>
<q43mth-d9m2.ln1@gonzo.specsol.net> <se9q58$p82$1@dont-email.me>
<lu9mth-n6r2.ln1@gonzo.specsol.net>
Injection-Date: Mon, 2 Aug 2021 23:28:11 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6a399acd4952323cf1aae9c9b60d7d31";
logging-data="18633"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18wiyvGLlaFTPbUP9/Ydi7i"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:r7BdRaAcYsVTmyqGFOZBh4aZQLU=
 by: William Unruh - Mon, 2 Aug 2021 23:28 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:
>
><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.
>
>

Re: gpsd no PPS output - Solved

<se9v80$19g2$1@gioia.aioe.org>

 copy mid

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

 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: Tue, 03 Aug 2021 00:31:12 +0100
Organization: Aioe.org NNTP Server
Message-ID: <se9v80$19g2$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> <se96b5$j8d$1@gioia.aioe.org> <se98l2$1g8$1@dont-email.me> <se9rdn$1i9$1@gioia.aioe.org> <se9sif$5v2$1@dont-email.me>
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="42498"; 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 23:31 UTC

On 08/02/21 23:45, William Unruh wrote:
> On 2021-08-02, chris<chris-nospam@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 )
>

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

Re: gpsd no PPS output - Solved

<se9vt4$1g48$1@gioia.aioe.org>

 copy mid

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

 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: Tue, 03 Aug 2021 00:42:28 +0100
Organization: Aioe.org NNTP Server
Message-ID: <se9vt4$1g48$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> <se96b5$j8d$1@gioia.aioe.org> <se98l2$1g8$1@dont-email.me> <h0olth-cmd2.ln1@gonzo.specsol.net> <se9dml$853$1@dont-email.me> <srslth-frh2.ln1@gonzo.specsol.net> <se9l94$l1b$2@dont-email.me> <q43mth-d9m2.ln1@gonzo.specsol.net> <se9q58$p82$1@dont-email.me> <lu9mth-n6r2.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="49288"; 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 23:42 UTC

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

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

>

Re: gpsd no PPS output - Solved

<j7cmth-1vs2.ln1@gonzo.specsol.net>

 copy mid

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

 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 16:37:57 -0700
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <j7cmth-1vs2.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> <se9rdn$1i9$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="450ee91bb9bd054efabd495e5d2c8e07";
logging-data="30963"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/4QRWxr1CN6H+6gt0x1N/p"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:t+S4Ey/jVp1nqNhnFm75ic4/d/I=
 by: Jim Pennino - Mon, 2 Aug 2021 23:37 UTC

chris <chris-nospam@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
> 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 ?...

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.

Re: gpsd no PPS output - Solved

<pscmth-1vs2.ln1@gonzo.specsol.net>

 copy mid

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

 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 16:49:15 -0700
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <pscmth-1vs2.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> <6fqlth-h2g2.ln1@gonzo.specsol.net> <se9lg7$l1b$3@dont-email.me> <6u4mth-r2o2.ln1@gonzo.specsol.net> <se9qbe$p82$2@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="450ee91bb9bd054efabd495e5d2c8e07";
logging-data="3298"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19HW2Lv4rN0T8FZY2uoc2X/"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:NHexmirPPXVDaFsSC4EkufYk6eo=
 by: Jim Pennino - Mon, 2 Aug 2021 23:49 UTC

William Unruh <unruh@invalid.ca> wrote:
> 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:
>>>> 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.
>>>
>>> With PPS. Without PPS, even the length of the nmea sentences vary more
>>> than that.
>>
>> 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.
>
> 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.

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.

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

Re: gpsd no PPS output - Solved

<gaemth-1vs2.ln1@gonzo.specsol.net>

 copy mid

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

 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 17:13:38 -0700
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <gaemth-1vs2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <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> <srslth-frh2.ln1@gonzo.specsol.net> <se9l94$l1b$2@dont-email.me> <q43mth-d9m2.ln1@gonzo.specsol.net> <se9q58$p82$1@dont-email.me> <lu9mth-n6r2.ln1@gonzo.specsol.net> <se9vt4$1g48$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="450ee91bb9bd054efabd495e5d2c8e07";
logging-data="8142"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2zFq5HqBwuLD3hL0ZfEfW"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:W/Pp1YYcWDFj7LTyTZ8Gp/kkGeo=
 by: Jim Pennino - Tue, 3 Aug 2021 00:13 UTC

chris <chris-nospam@tridac.net> wrote:
> On 08/02/21 23:59, Jim Pennino wrote:
>> William Unruh<unruh@invalid.ca> wrote:
>>> On 2021-08-02, Jim Pennino<jimp@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...

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.

Re: gpsd no PPS output - Solved

<8kdmth-1vs2.ln1@gonzo.specsol.net>

 copy mid

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

 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 17:01:46 -0700
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <8kdmth-1vs2.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <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> <srslth-frh2.ln1@gonzo.specsol.net> <se9l94$l1b$2@dont-email.me> <q43mth-d9m2.ln1@gonzo.specsol.net> <se9q58$p82$1@dont-email.me> <lu9mth-n6r2.ln1@gonzo.specsol.net> <se9v2b$i69$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="450ee91bb9bd054efabd495e5d2c8e07";
logging-data="8142"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+fmZr9ZtAFrICHOuPqXFOX"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:rWTSBSRsFbuPwBIHsNDT9fV64+E=
 by: Jim Pennino - Tue, 3 Aug 2021 00:01 UTC

William Unruh <unruh@invalid.ca> wrote:
> 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:
>>
>><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.

Re: gpsd no PPS output - Solved

<seasjd$sno$1@gioia.aioe.org>

 copy mid

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

 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: Tue, 3 Aug 2021 07:52:13 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <seasjd$sno$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>
<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-Info: gioia.aioe.org; logging-data="29432"; 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 - Tue, 3 Aug 2021 07:52 UTC

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

Re: gpsd no PPS output - Solved

<seb5hg$28e$1@dont-email.me>

 copy mid

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

 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: Tue, 3 Aug 2021 11:24:47 +0100
Organization: No affiliation
Lines: 8
Message-ID: <seb5hg$28e$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>
<se9rdn$1i9$1@gioia.aioe.org> <j7cmth-1vs2.ln1@gonzo.specsol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 3 Aug 2021 10:24:48 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6f7922abe50504bcdd5e605e70372ef0";
logging-data="2318"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/bLTN4nlDkZe7XKC+g/u5EBtXPbtnEYbQ="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:tdLHlLXYSGa5Flx+I43qWtf76+s=
In-Reply-To: <j7cmth-1vs2.ln1@gonzo.specsol.net>
Content-Language: en-GB
 by: David Woolley - Tue, 3 Aug 2021 10:24 UTC

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.

Re: gpsd no PPS output - Solved

<seb70o$ks7$1@dont-email.me>

 copy mid

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

 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: Tue, 3 Aug 2021 11:49:59 +0100
Organization: No affiliation
Lines: 15
Message-ID: <seb70o$ks7$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>
<se9rdn$1i9$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 3 Aug 2021 10:50:00 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6f7922abe50504bcdd5e605e70372ef0";
logging-data="21383"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX188lsVm/e3Rhr49oJZ2WCpheiBYRf7VkpM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:xn7k0uF6XaO8+1o6gEYtvqINEOo=
In-Reply-To: <se9rdn$1i9$1@gioia.aioe.org>
Content-Language: en-GB
 by: David Woolley - Tue, 3 Aug 2021 10:49 UTC

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.

Re: gpsd no PPS output - Solved

<seb7gv$rd6$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.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: Tue, 3 Aug 2021 11:58:39 +0100
Organization: No affiliation
Lines: 14
Message-ID: <seb7gv$rd6$1@dont-email.me>
References: <pqe8th-hsf.ln1@gonzo.specsol.net>
<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>
<srslth-frh2.ln1@gonzo.specsol.net> <se9l94$l1b$2@dont-email.me>
<q43mth-d9m2.ln1@gonzo.specsol.net> <se9q58$p82$1@dont-email.me>
<lu9mth-n6r2.ln1@gonzo.specsol.net> <se9vt4$1g48$1@gioia.aioe.org>
<gaemth-1vs2.ln1@gonzo.specsol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 3 Aug 2021 10:58:39 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6f7922abe50504bcdd5e605e70372ef0";
logging-data="28070"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18HlsGUMV5U/wbegLUFOBtrWS0sWCL9CY4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:6D96ujQVTjtHMbMOKx1m5mCZq1g=
In-Reply-To: <gaemth-1vs2.ln1@gonzo.specsol.net>
Content-Language: en-GB
 by: David Woolley - Tue, 3 Aug 2021 10:58 UTC

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.

Re: gpsd no PPS output - Solved

<p7vnth-gh04.ln1@gonzo.specsol.net>

 copy mid

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

 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: Tue, 3 Aug 2021 07:08:27 -0700
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <p7vnth-gh04.ln1@gonzo.specsol.net>
References: <pqe8th-hsf.ln1@gonzo.specsol.net> <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> <srslth-frh2.ln1@gonzo.specsol.net> <se9l94$l1b$2@dont-email.me> <q43mth-d9m2.ln1@gonzo.specsol.net> <se9q58$p82$1@dont-email.me> <lu9mth-n6r2.ln1@gonzo.specsol.net> <se9vt4$1g48$1@gioia.aioe.org> <gaemth-1vs2.ln1@gonzo.specsol.net> <seb7gv$rd6$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="450ee91bb9bd054efabd495e5d2c8e07";
logging-data="13782"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Clrqxba5qwP0eHZyftV8J"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:caanpdAlTnhATL1EhpegD/iJ0iY=
 by: Jim Pennino - Tue, 3 Aug 2021 14:08 UTC

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

Re: gpsd no PPS output - Solved

<ukvnth-gh04.ln1@gonzo.specsol.net>

 copy mid

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

 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: Tue, 3 Aug 2021 07:15:28 -0700
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <ukvnth-gh04.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> <se9rdn$1i9$1@gioia.aioe.org> <j7cmth-1vs2.ln1@gonzo.specsol.net> <seb5hg$28e$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="450ee91bb9bd054efabd495e5d2c8e07";
logging-data="13782"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cmwuuE1//iJkOnOxcrvch"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:1xMMVB99zUVpVqYSxx9o0RbC0Bg=
 by: Jim Pennino - Tue, 3 Aug 2021 14:15 UTC

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

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.

Re: gpsd no PPS output - Solved

<j20oth-gh04.ln1@gonzo.specsol.net>

 copy mid

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

 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: Tue, 3 Aug 2021 07:22:45 -0700
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <j20oth-gh04.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> <8hslth-frh2.ln1@gonzo.specsol.net> <seasjd$sno$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="450ee91bb9bd054efabd495e5d2c8e07";
logging-data="20106"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Ji02dS6mTiqJ/PgI3mHPK"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-80-generic (x86_64))
Cancel-Lock: sha1:R0FWFFVgd8q8uF39kTR+JOXrNNI=
 by: Jim Pennino - Tue, 3 Aug 2021 14:22 UTC

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

Pages:1234567
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor