Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

There are bugs and then there are bugs. And then there are bugs. -- Karl Lehenbauer


devel / comp.protocols.time.ntp / Re: GPS+PPS vs NTP server, why a huge offset ?

SubjectAuthor
* GPS+PPS vs NTP server, why a huge offset ?Thibaut HUMBERT
+* Re: GPS+PPS vs NTP server, why a huge offset ?Thibaut HUMBERT
|+* Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
||+- Re: GPS+PPS vs NTP server, why a huge offset ?Thibaut HUMBERT
||+* Re: GPS+PPS vs NTP server, why a huge offset ?Thibaut HUMBERT
|||+* Re: GPS+PPS vs NTP server, why a huge offset ?David Taylor
||||+* Re: GPS+PPS vs NTP server, why a huge offset ?Thibaut HUMBERT
|||||+* Re: GPS+PPS vs NTP server, why a huge offset ?Jim Pennino
||||||`* Re: GPS+PPS vs NTP server, why a huge offset ?chris
|||||| `* Re: GPS+PPS vs NTP server, why a huge offset ?Jim Pennino
||||||  `* Re: GPS+PPS vs NTP server, why a huge offset ?chris
||||||   `* Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
||||||    `* Re: GPS+PPS vs NTP server, why a huge offset ?chris
||||||     `* Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
||||||      +* Re: GPS+PPS vs NTP server, why a huge offset ?Terje Mathisen
||||||      |`- Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
||||||      `* Re: GPS+PPS vs NTP server, why a huge offset ?chris
||||||       `- Re: GPS+PPS vs NTP server, why a huge offset ?chris
|||||+- Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
|||||`- Re: GPS+PPS vs NTP server, why a huge offset ?William Unruh
||||+* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Daniel O'Connor
|||||`* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Jim Pennino
||||| +* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
||||| |`* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Jim Pennino
||||| | `- Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
||||| `- Re: [questions] GPS+PPS vs NTP server, why a huge offset ?Daniel O'Connor
||||`- Re: [questions] GPS+PPS vs NTP server, why a huge offset ?Daniel O'Connor
|||+* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Daniel O'Connor
||||+- Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
||||`* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Jim Pennino
|||| `* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
||||  `* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Jim Pennino
||||   `* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?David Woolley
||||    `- Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Jim Pennino
|||`* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?Daniel O'Connor
||| `* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?chris
|||  `* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?David Woolley
|||   `* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?chris
|||    `* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?David Woolley
|||     +- Re: [questions] GPS+PPS vs NTP server, why a huge offset ?David Woolley
|||     `* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?chris
|||      `* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?David Woolley
|||       `* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?chris
|||        `* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?Thibaut HUMBERT
|||         +* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?David Taylor
|||         |`* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?Thibaut HUMBERT
|||         | +* Re: [questions] GPS+PPS vs NTP server, why a huge offset ?David Taylor
|||         | |`- Re: [questions] GPS+PPS vs NTP server, why a huge offset ?Thibaut HUMBERT
|||         | `- Re: [questions] GPS+PPS vs NTP server, why a huge offset ?David Taylor
|||         `- Re: [questions] GPS+PPS vs NTP server, why a huge offset ?Harlan Stenn
||`* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Daniel O'Connor
|| +- Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Jim Pennino
|| +- Re: [questions] GPS+PPS vs NTP server, why a huge offset ?Daniel O'Connor
|| +* Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?David Taylor
|| |`- Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Jim Pennino
|| `- Re: [questions] GPS+PPS vs NTP server, why a huge offset ?Daniel O'Connor
|`- Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Dan Drown
+- Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?Daniel O'Connor
`- Re: [questions] GPS+PPS vs NTP server, why a huge offset ?David Taylor

Pages:123
Re: GPS+PPS vs NTP server, why a huge offset ?

<t8iju3$q4n$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Fri, 17 Jun 2022 21:16:19 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t8iju3$q4n$1@gioia.aioe.org>
References: <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<t8epif$l1r$1@dont-email.me>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<t8ff7b$alv$1@dont-email.me>
<caf5e073-ed36-4ff2-987f-fc0938d3b63cn@googlegroups.com>
<4burni-fja2.ln1@gonzo.specsol.net> <t8gd8a$pla$1@gioia.aioe.org>
<c9rsni-i8f1.ln1@gonzo.specsol.net> <t8gft4$1h3h$1@gioia.aioe.org>
<t8hopb$rke$1@dont-email.me> <t8i6tc$1bhk$1@gioia.aioe.org>
<t8iieb$k0f$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="26775"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.12
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Fri, 17 Jun 2022 19:16 UTC

David Woolley wrote:
> On 17/06/2022 16:34, chris wrote:
>> As for compatibility, while a mismatched connection may work, it's bad
>> practice to do that, where you are dealing with microsecond timing
>> and want to avoid jitter. Use the correct interfaces and do the job
>> right, then you can fit and forget:-)...
>
> RS232 isn't optimal for PPS as it is slew rate limited to 30V/µs, which
> means it will take at least 0.5µs from a resting level until it has
> fully cleared the transition region, if implemented to standard.
>
> TTL is the more natural logic family for high accuracy PPS.
>
> GPS should be able of achieving time transfer accuracies of better than
> .03µs.

GPS, even at the $80 Shure evaluation board level, have been directly
measured at the ~25 ns level, which is pretty much what you claim here. :-)

The key idea is of course that in order to know where a GPS is located
with better than 3 m precision, the unit by implication also knows what
time it is, to within 10 ns of UTC(USNO). The only problem is to be able
to convey that info to a connected NTP server.

Terje

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

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

<t72vni-kqh4.ln1@gonzo.specsol.net>

 copy mid

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

 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: jim...@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Fri, 17 Jun 2022 12:45:35 -0700
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <t72vni-kqh4.ln1@gonzo.specsol.net>
References: <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <vk8tni-2ft1.ln1@gonzo.specsol.net> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <t8epif$l1r$1@dont-email.me> <t8ff7b$alv$1@dont-email.me> <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au> <e2euni-bug3.ln1@gonzo.specsol.net> <t8iili$le6$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="9165e10d9c8d95653dc81c71a9607a39";
logging-data="11610"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+2puHesmQUhTy7pZHz+OOU"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-120-lowlatency (x86_64))
Cancel-Lock: sha1:J2RmI0DSm/jBoy+iycxksBmzKu0=
 by: Jim Pennino - Fri, 17 Jun 2022 19:45 UTC

David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 17/06/2022 15:01, Jim Pennino wrote:
>> OK, then to which of the USB connector pins do you connect the PPS
>> signal to get "PPS over USB"?
>
> D+ and D-, using for example a Communications Device Class module to
> encode it for transmission. I guess HID would be more appropriate, for
> an isolated digital signal, but HID often uses low rates.

Have fun writting the necessary device driver...

Re: GPS+PPS vs NTP server, why a huge offset ?

<t8imna$ili$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dav...@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Fri, 17 Jun 2022 21:03:53 +0100
Organization: No affiliation
Lines: 22
Message-ID: <t8imna$ili$1@dont-email.me>
References: <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<t8epif$l1r$1@dont-email.me>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<t8ff7b$alv$1@dont-email.me>
<caf5e073-ed36-4ff2-987f-fc0938d3b63cn@googlegroups.com>
<4burni-fja2.ln1@gonzo.specsol.net> <t8gd8a$pla$1@gioia.aioe.org>
<c9rsni-i8f1.ln1@gonzo.specsol.net> <t8gft4$1h3h$1@gioia.aioe.org>
<t8hopb$rke$1@dont-email.me> <t8i6tc$1bhk$1@gioia.aioe.org>
<t8iieb$k0f$1@dont-email.me> <t8iju3$q4n$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 17 Jun 2022 20:03:54 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0389d063b82fd42e75c6e383ae2cfb34";
logging-data="19122"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/iz/hFD7SZfVQT3dGnqWrbrOnDDwPrShU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:V1WF0T0nIOR2xx+WmysydNBVchE=
In-Reply-To: <t8iju3$q4n$1@gioia.aioe.org>
Content-Language: en-GB
 by: David Woolley - Fri, 17 Jun 2022 20:03 UTC

On 17/06/2022 20:16, Terje Mathisen wrote:
> The key idea is of course that in order to know where a GPS is located
> with better than 3 m precision, the unit by implication also knows what
> time it is, to within 10 ns of UTC(USNO). The only problem is to be able
> to convey that info to a connected NTP server.

It only needs the time relative to the visible constellation, as the
ultimate position accuracy depends on time differences not absolute
time. Absolute time errors affect position at about 7.5mm/µs.

<https://www.gps.gov/systems/gps/performance/accuracy/> quotes ≤30
nanoseconds, 95% of the time. That probably includes uplink allowances.
Also, I'm not sure if UTC(xxxx) exists in real time. UTC proper only
exists some weeks after the event. There might have to be an allowance
for the difference between the instantaneous estimate of UTC(USNO) and
the final value.

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

<t8imsv$ili$2@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dav...@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Fri, 17 Jun 2022 21:06:55 +0100
Organization: No affiliation
Lines: 5
Message-ID: <t8imsv$ili$2@dont-email.me>
References: <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<vk8tni-2ft1.ln1@gonzo.specsol.net>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au>
<t8epif$l1r$1@dont-email.me> <t8ff7b$alv$1@dont-email.me>
<459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au>
<e2euni-bug3.ln1@gonzo.specsol.net> <t8iili$le6$1@dont-email.me>
<t72vni-kqh4.ln1@gonzo.specsol.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 17 Jun 2022 20:06:55 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0389d063b82fd42e75c6e383ae2cfb34";
logging-data="19122"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+9vqc0VnoW5s/QJrfhrph0x2gYgSkOUr4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:ywjUWlfbOEkc/lRY+uZyRkSl0Po=
In-Reply-To: <t72vni-kqh4.ln1@gonzo.specsol.net>
Content-Language: en-GB
 by: David Woolley - Fri, 17 Jun 2022 20:06 UTC

On 17/06/2022 20:45, Jim Pennino wrote:
> Have fun writting the necessary device driver...

You can buy chips preloaded with the relevant code for the encode side,
for single figure sums and most OSes already include the decode side code.

Re: GPS+PPS vs NTP server, why a huge offset ?

<t8j3ds$1v7j$1@gioia.aioe.org>

 copy mid

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

 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-no...@tridac.net (chris)
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sat, 18 Jun 2022 00:40:44 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t8j3ds$1v7j$1@gioia.aioe.org>
References: <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <t8epif$l1r$1@dont-email.me> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <t8ff7b$alv$1@dont-email.me> <caf5e073-ed36-4ff2-987f-fc0938d3b63cn@googlegroups.com> <4burni-fja2.ln1@gonzo.specsol.net> <t8gd8a$pla$1@gioia.aioe.org> <c9rsni-i8f1.ln1@gonzo.specsol.net> <t8gft4$1h3h$1@gioia.aioe.org> <t8hopb$rke$1@dont-email.me> <t8i6tc$1bhk$1@gioia.aioe.org> <t8iieb$k0f$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="64755"; 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 - Fri, 17 Jun 2022 23:40 UTC

On 06/17/22 19:50, David Woolley wrote:
> On 17/06/2022 16:34, chris wrote:
>> As for compatibility, while a mismatched connection may work, it's bad
>> practice to do that, where you are dealing with microsecond timing
>> and want to avoid jitter. Use the correct interfaces and do the job
>> right, then you can fit and forget:-)...
>
> RS232 isn't optimal for PPS as it is slew rate limited to 30V/µs, which
> means it will take at least 0.5µs from a resting level until it has
> fully cleared the transition region, if implemented to standard.
>
> TTL is the more natural logic family for high accuracy PPS.

Agreed, and many gpsdo / ntp boxes do have a pps signal as ttl. The
problem is that the most common supported method of getting the pps
signal into ntpd is via the rs232 data carrier detect line. I believe
there is another supported input option, but when I queried that with
PHK, he thought that it had not been tested in years and not sure if
it even worked, so I had no choice but to use the dcd line for input.
Afaics, there are no other options for getting pps into the system,
but perhaps there have been later developments ?.

Since ntpq -pn resolution is only down to the nearest microsecond,
i'm not concerned if the level shifting introduces a few 10's of
nanoseconds offset, as that will be lost in the noise anyway. It
works well here and typically get 0 or 1 uS offset and usually zero
uS jitter. Good enough in fact...

>
> GPS should be able of achieving time transfer accuracies of better than
> .03µs.
>

The old HP GPS DO ex telco boxes used here as a lab frequency standards
typically show 10-30 ns uncertainty referenced to UTC. Pretty impressive
really, but overkill for ntp over unreliable udp paths...

Chris

Re: GPS+PPS vs NTP server, why a huge offset ?

<t8j4jt$9fo$1@gioia.aioe.org>

 copy mid

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

 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-no...@tridac.net (chris)
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sat, 18 Jun 2022 01:01:01 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t8j4jt$9fo$1@gioia.aioe.org>
References: <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <t8epif$l1r$1@dont-email.me> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <t8ff7b$alv$1@dont-email.me> <caf5e073-ed36-4ff2-987f-fc0938d3b63cn@googlegroups.com> <4burni-fja2.ln1@gonzo.specsol.net> <t8gd8a$pla$1@gioia.aioe.org> <c9rsni-i8f1.ln1@gonzo.specsol.net> <t8gft4$1h3h$1@gioia.aioe.org> <t8hopb$rke$1@dont-email.me> <t8i6tc$1bhk$1@gioia.aioe.org> <t8iieb$k0f$1@dont-email.me> <t8j3ds$1v7j$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="9720"; 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, 18 Jun 2022 00:01 UTC

On 06/18/22 00:40, chris wrote:
> On 06/17/22 19:50, David Woolley wrote:
>> On 17/06/2022 16:34, chris wrote:
>>> As for compatibility, while a mismatched connection may work, it's bad
>>> practice to do that, where you are dealing with microsecond timing
>>> and want to avoid jitter. Use the correct interfaces and do the job
>>> right, then you can fit and forget:-)...
>>
>> RS232 isn't optimal for PPS as it is slew rate limited to 30V/µs, which
>> means it will take at least 0.5µs from a resting level until it has
>> fully cleared the transition region, if implemented to standard.
>>
>> TTL is the more natural logic family for high accuracy PPS.
>
> Agreed, and many gpsdo / ntp boxes do have a pps signal as ttl. The
> problem is that the most common supported method of getting the pps
> signal into ntpd is via the rs232 data carrier detect line. I believe
> there is another supported input option, but when I queried that with
> PHK, he thought that it had not been tested in years and not sure if
> it even worked, so I had no choice but to use the dcd line for input.
> Afaics, there are no other options for getting pps into the system,
> but perhaps there have been later developments ?.
>
> Since ntpq -pn resolution is only down to the nearest microsecond,
> i'm not concerned if the level shifting introduces a few 10's of
> nanoseconds offset, as that will be lost in the noise anyway. It
> works well here and typically get 0 or 1 uS offset and usually zero
> uS jitter. Good enough in fact...
>
>>
>> GPS should be able of achieving time transfer accuracies of better than
>> .03µs.
>>
>
> The old HP GPS DO ex telco boxes used here as a lab frequency standards
> typically show 10-30 ns uncertainty referenced to UTC. Pretty impressive
> really, but overkill for ntp over unreliable udp paths...
>
> Chris
>
>
>

Checking notes, the other supported option for pps input is one of
the parallel printer port interface lines, which is at ttl. Would
have been the preferred option here, but could not find a way to
make it work under FreeBSD 12 and no one seemed to know if the code
works at all, so a dead end. Perhaps you know someone who has made it
work ?...

Chris

Re: GPS+PPS vs NTP server, why a huge offset ?

<t8jjum$qai$1@dont-email.me>

 copy mid

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

 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: unr...@invalid.ca (William Unruh)
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sat, 18 Jun 2022 04:22:46 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 9
Message-ID: <t8jjum$qai$1@dont-email.me>
References: <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<t8epif$l1r$1@dont-email.me>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<t8ff7b$alv$1@dont-email.me>
<caf5e073-ed36-4ff2-987f-fc0938d3b63cn@googlegroups.com>
Injection-Date: Sat, 18 Jun 2022 04:22:46 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="738886639e647492032bf3fdb9fd73e7";
logging-data="26962"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19y005ht2fzQ0AaYC1KXeN0"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:KYqmDplkr/Sel80bys1Mn6hc9EQ=
 by: William Unruh - Sat, 18 Jun 2022 04:22 UTC

On 2022-06-16, Thibaut HUMBERT <planetibo@gmail.com> wrote:
>
> I have a serial port, but I don't know how to convert the PPS output (0 / 3.3V) to RS232 (-5V / +5V).

Don't bothere since almost all serial ports will handle the 3 V just
fine. The 5 V standard is still there in the specs, but ignored by
almost all manufacturers.

Anyway, just try it. Nothing lost if you do.

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

<ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: dar...@dons.net.au (Daniel O'Connor)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 06:38:00 -0000 (UTC)
Organization: Taughannock Networks, Trumansburg NY
Message-ID: <ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au>
References: <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <t8ff7b$alv$1@dont-email.me> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <t8epif$l1r$1@dont-email.me> <e2euni-bug3.ln1@gonzo.specsol.net> <vk8tni-2ft1.ln1@gonzo.specsol.net> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
Reply-To: questions@lists.ntp.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 19 Jun 2022 06:38:00 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="35915"; mail-complaints-to="abuse@iecc.com"
To: questions@lists.ntp.org
Return-Path: <questions+bounces-76-ntpquestions=iecc.com@lists.ntp.org>
Delivered-To: ntpquestions@iecc.com
Delivered-To: questions@lists.ntp.org
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on gal.iecc.com
X-Spam-Status: No, score=-2.5 required=4.4 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.5
Authentication-Results: iecc.com; spf=pass spf.mailfrom=questions+bounces-76-ntpquestions=iecc.com@lists.ntp.org spf.helo=mail0.chi1.ntfo.org smtp.remote-ip="204.93.207.17"; dkim=fail (bad body hash) header.d=dons.net.au header.s=default header.a=rsa-sha256 header.b="o2sbt0Zu"; dmarc=fail header.from=dons.net.au polrec.p=quarantine polrec.pct=100
X-Original-To: questions@lists.ntp.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1655620389; bh=sh9VIgplFpMmz4scxBTrKL9v1bFOfa2pCjaDi8wXCJk=; h=Subject:From:In-Reply-To:Date:References:To; b=o2sbt0Zu133jAnhIuF54vyhBbY+6bh6boeJebqOfqIdxPZx/GSQDYv4VxKaf8LJKY y4fB2IUEIDDNge9ZOVVLAWXpYFRrQkPwLIhf0jRtasl0Ov+1bePuJRXs6qbzHFwshk 6/JhpDdwCun6n0yf77/ASl/npwF+cI/qiClt8I8E=
X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403: 5800:5200:4700:2462:5424:375e:b53b
List-unsubscribe: mailto: questions+unsubscribe@lists.ntp.org
X-BeenThere: questions@lists.ntp.org
List-Id: questions.lists.ntp.org
Precedence: list
In-Reply-To: <e2euni-bug3.ln1@gonzo.specsol.net>
X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1
X-DCC-iecc-Metrics: gal.iecc.com 1107; Body=1 Fuz1=1 Fuz2=1
Mail-to-news: iecc.com
 by: Daniel O'Connor - Sun, 19 Jun 2022 06:38 UTC

> On 17 Jun 2022, at 23:31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>
> Daniel O'Connor <darius@dons.net.au> wrote:
>>
>>> You of course can get the ASCII data over USB, but to get a PPS signal
>>> you in general have to hack a USB GPS and add a signal wire for PPS then
>>> hack some interface on the computer to accept PPS.
>>
>> This is absolutely not true in any meaningful sense.
>
> OK, then to which of the USB connector pins do you connect the PPS
> signal to get "PPS over USB"?

You can connect them to CTS or RTS, on FreeBSD these can then hook into the kernel PPS API.

It works very well in practise, especially for the cost & effort required.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<F6F22D4C-ECD9-4D19-A97B-6D9889298C71@dons.net.au>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: dar...@dons.net.au (Daniel O'Connor)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 09:03:00 -0000 (UTC)
Organization: Taughannock Networks, Trumansburg NY
Message-ID: <F6F22D4C-ECD9-4D19-A97B-6D9889298C71@dons.net.au>
References: <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <t8ff7b$alv$1@dont-email.me> <t8epif$l1r$1@dont-email.me> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au> <vk8tni-2ft1.ln1@gonzo.specsol.net> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <07c7d33d-6e11-49ec-8ee1-d2465fb0dc2d@meinberg.de>
Reply-To: questions@lists.ntp.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 19 Jun 2022 09:03:00 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="974"; mail-complaints-to="abuse@iecc.com"
To: questions@lists.ntp.org
Return-Path: <questions+bounces-77-ntpquestions=iecc.com@lists.ntp.org>
Delivered-To: ntpquestions@iecc.com
Delivered-To: questions@lists.ntp.org
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on gal.iecc.com
X-Spam-Status: No, score=-2.5 required=4.4 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.5
Authentication-Results: iecc.com; spf=pass spf.mailfrom=questions+bounces-77-ntpquestions=iecc.com@lists.ntp.org spf.helo=mail0.chi1.ntfo.org smtp.remote-ip="204.93.207.17"; dkim=fail (bad body hash) header.d=dons.net.au header.s=default header.a=rsa-sha256 header.b="EaLhusi4"; dmarc=fail header.from=dons.net.au polrec.p=quarantine polrec.pct=100
X-Original-To: questions@lists.ntp.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1655620149; bh=y0EHqqZKoOycMjhmJ5kpvl3fdBtn6rREhTMlcWaTnV4=; h=Subject:From:In-Reply-To:Date:References:To; b=EaLhusi4MJyIH324H3DkxdmTn7mPMhub0iO4oRr2Hvy0m5NoI8zLAf3Z/J7N5qyCd IcRxKGTdt6pTbNw0xze/0qL+scD7n+CEghMOg0qX+sREJb/9rk0oeZ2xeQoYJvA8u5 5t3qzDtkFmlEdaD+gbU3yIBbssLr5bStkx1R5APo=
X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403: 5800:5200:4700:2462:5424:375e:b53b
List-unsubscribe: mailto: questions+unsubscribe@lists.ntp.org
X-BeenThere: questions@lists.ntp.org
List-Id: questions.lists.ntp.org
Precedence: list
In-Reply-To: <07c7d33d-6e11-49ec-8ee1-d2465fb0dc2d@meinberg.de>
X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1
X-DCC-iecc-Metrics: gal.iecc.com 1107; Body=1 Fuz1=1 Fuz2=1
Mail-to-news: iecc.com
 by: Daniel O'Connor - Sun, 19 Jun 2022 09:03 UTC

> On 17 Jun 2022, at 17:12, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
>
> Daniel O'Connor wrote:
>>> On 17 Jun 2022, at 12:52, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>>> If all you need is accuracy in the 2 millisecond range, most recent USB
>>> GNSS dongles will achieve that without PPS.
>> You can easily do better than that with GPS/PPS over USB.
>
> Hm, USB v1 has only 1 ms timing frames, so if some USB v1 device (e.g. an USB hub) is involved, the accuracy may indeed be only in the range of ms.

Finding a USB 1 hub in this day and age would be an achievement in and of itself.

I do not think it is useful to claim it "might" be so poor when you would have to try very hard to make it that bad.

The basic case of "buy USB GPS interface, connect to PC" would be vastly better.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

<t8mrtp$12k$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dav...@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 10:57:13 +0100
Organization: No affiliation
Lines: 11
Message-ID: <t8mrtp$12k$1@dont-email.me>
References: <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<t8ff7b$alv$1@dont-email.me>
<633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au>
<t8epif$l1r$1@dont-email.me> <e2euni-bug3.ln1@gonzo.specsol.net>
<vk8tni-2ft1.ln1@gonzo.specsol.net>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 19 Jun 2022 09:57:13 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="36aef9898cfc0962ee427492d93d4d99";
logging-data="1108"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18TkH+pAdzWrcn2PGLXfqTk93TAMNsAvYE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:QdGMdrSjQMoUHrbs9gA71gNhFKQ=
In-Reply-To: <ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au>
Content-Language: en-GB
 by: David Woolley - Sun, 19 Jun 2022 09:57 UTC

On 19/06/2022 07:38, Daniel O'Connor wrote:
>> OK, then to which of the USB connector pins do you connect the PPS
>> signal to get "PPS over USB"?

> You can connect them to CTS or RTS, on FreeBSD these can then hook into the kernel PPS API.
>
> It works very well in practise, especially for the cost & effort required.

Taking the other side for this one, which of Ground, D+, D-, and VBus
have alternative names of CTS and RTS? (I guess I should add StdA_SSRX-,
StdA_SSRX+, StdA_SSTX+, and StdA_SSTX-, for USB 3.0, compatibility.)

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<11B648A2-0E66-436E-BF18-B531466FB34C@dons.net.au>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.gal.iecc.com!not-for-mail
From: dar...@dons.net.au (Daniel O'Connor)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 11:38:00 -0000 (UTC)
Organization: Taughannock Networks, Trumansburg NY
Message-ID: <11B648A2-0E66-436E-BF18-B531466FB34C@dons.net.au>
References: <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <vk8tni-2ft1.ln1@gonzo.specsol.net> <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au> <ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au> <t8epif$l1r$1@dont-email.me> <t8ff7b$alv$1@dont-email.me> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <t8mrtp$12k$1@dont-email.me> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <e2euni-bug3.ln1@gonzo.specsol.net>
Reply-To: questions@lists.ntp.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 19 Jun 2022 11:38:00 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="gal.iecc.com:64.57.183.53";
logging-data="82191"; mail-complaints-to="abuse@iecc.com"
To: questions@lists.ntp.org
Return-Path: <questions+bounces-82-ntpquestions=iecc.com@lists.ntp.org>
Delivered-To: ntpquestions@iecc.com
Delivered-To: questions@lists.ntp.org
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on gal.iecc.com
X-Spam-Status: No, score=-2.5 required=4.4 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.5
Authentication-Results: iecc.com; spf=pass spf.mailfrom=questions+bounces-82-ntpquestions=iecc.com@lists.ntp.org spf.helo=mail0.chi1.ntfo.org smtp.remote-ip="204.93.207.17"; dkim=fail (bad body hash) header.d=dons.net.au header.s=default header.a=rsa-sha256 header.b="irqsLfCd"; dmarc=fail header.from=dons.net.au polrec.p=quarantine polrec.pct=100
X-Original-To: questions@lists.ntp.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1655638476; bh=0MNCWXbEHWJeqkHe8aWWWNrkqzRwfSOmki6cL7gQErY=; h=Subject:From:In-Reply-To:Date:References:To; b=irqsLfCduHB1o6C/L09/zpgdlpg0rIIMB3twh3jc4BWW6HDFAM8Fj/AQvGAcrIh63 h+8fYtsW8ryOxEVvcL+Hofl84b3RoQHhTR21bfCfNx0zgRJ8FMAmR30RDFVoePLMlS 359gv9rAY7u2FkdCsOXq2kYTVLIM65afCOlVRXjE=
X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403: 5800:5200:4700:3837:1cb7:50d6:d527
List-unsubscribe: mailto: questions+unsubscribe@lists.ntp.org
X-BeenThere: questions@lists.ntp.org
List-Id: questions.lists.ntp.org
Precedence: list
In-Reply-To: <t8mrtp$12k$1@dont-email.me>
X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1
X-DCC-iecc-Metrics: gal.iecc.com 1107; Body=1 Fuz1=1 Fuz2=1
Mail-to-news: iecc.com
 by: Daniel O'Connor - Sun, 19 Jun 2022 11:38 UTC

> On 19 Jun 2022, at 19:27, David Woolley <david@ex.djwhome.demon.invalid> wrote:
>
> On 19/06/2022 07:38, Daniel O'Connor wrote:
>>> OK, then to which of the USB connector pins do you connect the PPS
>>> signal to get "PPS over USB"?
>
>> You can connect them to CTS or RTS, on FreeBSD these can then hook into the kernel PPS API.
>> It works very well in practise, especially for the cost & effort required.
>
> Taking the other side for this one, which of Ground, D+, D-, and VBus have alternative names of CTS and RTS? (I guess I should add StdA_SSRX-, StdA_SSRX+, StdA_SSTX+, and StdA_SSTX-, for USB 3.0, compatibility.)

None of course, but how do you think the CPU gets to know when a PPS edge appears on a 16550?

It is not magically wired into it, an IRQ is generated and has to be serviced before a timestamp can be taken. The bus it is on (LPC) is not designed for low latency and is not directly connected to the CPU..

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: dar...@dons.net.au (Daniel O'Connor)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 12:03:00 -0000 (UTC)
Organization: Taughannock Networks, Trumansburg NY
Message-ID: <D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au>
References: <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <t8i1t0$sj2$1@dont-email.me> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <t8epif$l1r$1@dont-email.me> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <t8ff7b$alv$1@dont-email.me>
Reply-To: questions@lists.ntp.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 19 Jun 2022 12:03:00 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="86628"; mail-complaints-to="abuse@iecc.com"
To: david-taylor@blueyonder.co.uk, questions@lists.ntp.org
Return-Path: <questions+bounces-83-ntpquestions=iecc.com@lists.ntp.org>
Delivered-To: ntpquestions@iecc.com
Delivered-To: questions@lists.ntp.org
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on gal.iecc.com
X-Spam-Status: No, score=-2.5 required=4.4 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.5
Authentication-Results: iecc.com; spf=pass spf.mailfrom=questions+bounces-83-ntpquestions=iecc.com@lists.ntp.org spf.helo=mail0.chi1.ntfo.org smtp.remote-ip="204.93.207.17"; dkim=fail (bad body hash) header.d=dons.net.au header.s=default header.a=rsa-sha256 header.b="cVRJvxsc"; dmarc=fail header.from=dons.net.au polrec.p=quarantine polrec.pct=100
X-Original-To: questions@lists.ntp.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1655620271; bh=3EhopUBYZU5YvS+nItzskdcVKSlaBYKfZom/VaCJUDE=; h=Subject:From:In-Reply-To:Date:References:To; b=cVRJvxsc5LBRFrpq3foauVcK6hITdHnOGEPOVpEdZ5bQ8hADvuXxSpS1J2hEGaLTT w9xfuMikunqzP3D/Fs32ra2woVe2a8e4K9MiWo4C3yPK2Z4ZJIKuoNfr5eFBClnIE3 GJ10DoYdhk2c5D56HGY1Uyffrn/L2a0PYVqb2YPs=
X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403: 5800:5200:4700:2462:5424:375e:b53b
List-unsubscribe: mailto: questions+unsubscribe@lists.ntp.org
X-BeenThere: questions@lists.ntp.org
List-Id: questions.lists.ntp.org
Precedence: list
In-Reply-To: <t8i1t0$sj2$1@dont-email.me>
X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1
X-DCC-iecc-Metrics: gal.iecc.com 1107; Body=1 Fuz1=1 Fuz2=1
Mail-to-news: iecc.com
 by: Daniel O'Connor - Sun, 19 Jun 2022 12:03 UTC

> On 17 Jun 2022, at 23:38, David Taylor <david-taylor@blueyonder.co..uk.invalid> wrote:
>
> On 17/06/2022 03:03, Daniel O'Connor wrote:
>>> Yes, Thiebaud, USB is not good enough for PPS signals!
>> This is absolutely false.
>> If you are using it for NTP then GPS+PPS over USB is quite adequate (from personal experience).
>> Ian Lepore (RIP) who worked for Micro Semi and worked on FreeBSD did a bunch of tests on a PPS over USB setup and found it more than
>> acceptable for keeping a PC in (good) time. Here's the thread:https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html
>>> See if your motherboard has a true serial port - perhaps just as a header but not a back connector. If not, just set the offset of the PPS to ~10.3 milliseconds (10.3 - IIRC the offsets are in milliseconds but please check). Plus or minus 10.3, try it and see! Not perfect, but better than nothing.
>>>
>>> You might find better results using that GPS/PPS with a Raspberry Pi as a stratum-1 server and offering that as a server on your LAN.
>> The next level would be something where you can do an input capture on the PPS I don't think there are any pre canned solutions. I made one with a Beagle Bone Black and a uBox GPS module but it's not exactly turn key. Or for a server then you would need a fancy (ie $$$$) internal card.
>> The Raspberry Pi does not have an input capture timer, but I believe you can do better with DMA hackery (I haven't tried though).
>
> If a 125 us uncertainty in the PPS is something you can tolerate, so be it. If you are bothering with PPS then presumably you want better accuracy than can be achieved without it.

I think for standard PC timing in a network it is more than adequate.
Using PPS over USB does give you an improvement over just serial traffic so why not use it since it's free.

> No need for DMA hackery. Standard NTP with the Raspberry Pi can handle PPS on a GPIO signal with a couple of edits to allow the PPS support already built into the kernel to be attached to the appropriate GPIO pin. Not out of the box, but very little effort required.
>
> The Raspberry Pi can act as a server for hundreds of clients. If you mean a PC-based Windows server, that's not something I would immediately recommend, but if you must a £20 serial card may be all you need to add.

Sure, but I would think something with an input capture timer will produce a better result again. It is just unfortunate the RPi can't do it.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

<0fi3oi-30m2.ln1@gonzo.specsol.net>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jim...@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 05:46:58 -0700
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <0fi3oi-30m2.ln1@gonzo.specsol.net>
References: <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <t8ff7b$alv$1@dont-email.me> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <t8epif$l1r$1@dont-email.me> <e2euni-bug3.ln1@gonzo.specsol.net> <vk8tni-2ft1.ln1@gonzo.specsol.net> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au>
Injection-Info: reader02.eternal-september.org; posting-host="e559ef464aa817d2c497ade1ab77cf7c";
logging-data="12040"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18AWEAqfFWXA7r5GYJhc0Yn"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-120-lowlatency (x86_64))
Cancel-Lock: sha1:URqo5AeCQDPEHQ8iU74Ry3P37B8=
 by: Jim Pennino - Sun, 19 Jun 2022 12:46 UTC

Daniel O'Connor <darius@dons.net.au> wrote:
>
>
>> On 17 Jun 2022, at 23:31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>>
>> Daniel O'Connor <darius@dons.net.au> wrote:
>>>
>>>> You of course can get the ASCII data over USB, but to get a PPS signal
>>>> you in general have to hack a USB GPS and add a signal wire for PPS then
>>>> hack some interface on the computer to accept PPS.
>>>
>>> This is absolutely not true in any meaningful sense.
>>
>> OK, then to which of the USB connector pins do you connect the PPS
>> signal to get "PPS over USB"?
>
> You can connect them to CTS or RTS, on FreeBSD these can then hook into the kernel PPS API.

Them? There is only one PPS signal line out of a GPS.

CTS/RTS is pin 8 on a RS-232 connector, so how is that "PPS over USB"?

FYI while the Linux PPSAPI says it supports either RTS/CTS or CD, in
reality only CD (pin 1) is supported in the kernel code.

I know this to be true for at least Ubuntu (bug report filed) and likely
many others.

How do I know this?

Because when I got my commercial GNSS receiver with a high prescision,
managed oscillator with a guaranteed PPS accuracy of +/- 1 nanosecond
with PPS on pin 8 on the connector, I had to dig into the kernel code to
figure out why it did not work and had to build a cross over cable.

Also FYI, some of the pps-tools for Linux look directly at the RS-232
port and do not use the kernel PPSAPIi, so they will report a PPS signal
on RTS/CTS.

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<2F042972-2230-4CCE-8606-D789EBF6722C@dons.net.au>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.gal.iecc.com!not-for-mail
From: dar...@dons.net.au (Daniel O'Connor)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 14:03:00 -0000 (UTC)
Organization: Taughannock Networks, Trumansburg NY
Message-ID: <2F042972-2230-4CCE-8606-D789EBF6722C@dons.net.au>
References: <t8ff7b$alv$1@dont-email.me> <t8epif$l1r$1@dont-email.me> <D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au> <a86255a9-295b-cf0c-e959-93a59db1b74a@blueyonder.co.uk> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <t8i1t0$sj2$1@dont-email.me> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
Reply-To: questions@lists.ntp.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 19 Jun 2022 14:03:00 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="gal.iecc.com:64.57.183.53";
logging-data="4802"; mail-complaints-to="abuse@iecc.com"
To: questions@lists.ntp.org
Return-Path: <questions+bounces-85-ntpquestions=iecc.com@lists.ntp.org>
Delivered-To: ntpquestions@iecc.com
Delivered-To: questions@lists.ntp.org
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on gal.iecc.com
X-Spam-Status: No, score=-2.5 required=4.4 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.5
Authentication-Results: iecc.com; spf=pass spf.mailfrom=questions+bounces-85-ntpquestions=iecc.com@lists.ntp.org spf.helo=mail0.chi1.ntfo.org smtp.remote-ip="204.93.207.17"; dkim=fail (bad body hash) header.d=dons.net.au header.s=default header.a=rsa-sha256 header.b="eEfg+qXl"; dmarc=fail header.from=dons.net.au polrec.p=quarantine polrec.pct=100
X-Original-To: questions@lists.ntp.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1655637614; bh=P2ad62LD78B6D9WUkUoqVWfsLrE2V8Dp8ySKfZYiAcg=; h=Subject:From:In-Reply-To:Date:References:To; b=eEfg+qXlCdWLzKbJUhChOTFK/k5OpbPBipiS+ASwckFXtEmy/MbRwnyPEGOYZutLa bu8OpQDyXK+FX/h5v7bx2rN2nfLu5MbVsfWjDDdlm6d3D2YZZ5EdFcmqH/3D2gmXFx ZurO2CcmtqhSXwdozbUXwVez1qDZwNaLxEwJCwFk=
X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403: 5800:5200:4700:3837:1cb7:50d6:d527
List-unsubscribe: mailto: questions+unsubscribe@lists.ntp.org
X-BeenThere: questions@lists.ntp.org
List-Id: questions.lists.ntp.org
Precedence: list
In-Reply-To: <a86255a9-295b-cf0c-e959-93a59db1b74a@blueyonder.co.uk>
X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1
X-DCC-iecc-Metrics: gal.iecc.com 1107; Body=1 Fuz1=1 Fuz2=1
Mail-to-news: iecc.com
 by: Daniel O'Connor - Sun, 19 Jun 2022 14:03 UTC

> On 19 Jun 2022, at 17:43, David Taylor <david-taylor@blueyonder.co..uk> wrote:
>
> On 19/06/2022 07:30, Daniel O'Connor wrote:
>> I think for standard PC timing in a network it is more than adequate.
>> Using PPS over USB does give you an improvement over just serial traffic so why not use it since it's free.
>
>> Sure, but I would think something with an input capture timer will produce a better result again. It is just unfortunate the RPi can't do it.
>
> If PPS over USB is all you have, of course use it. But if you have a local stratum-1 server it's likely to produce much better results, just using a LAN connection.

I am not sure this is true, but the difference if probably negligible.

However.. if you had a local stratum 1 server then using a GPS receiver seems pointless unless you want redundancy..

> Probably on the RPi using an input capture timer wouldn't produce much better results than simply using the GPIO pins and the the built-in kernel PPS support and reference NTP. I tend to think of the RPi alone as "tens of microseconds or better", and capture

Input capture is nice because it means interrupt latency is no longer a problem.

The PPS edge is captured by the clock and so it doesn't matter how long the CPU takes to read it (until the next edge anyway..) there is no loss of accuracy.

> timer (PTP) as sub-microsecond level. Both are quite adequate for "standard PC timing".

Sure, but NMEA (even without PPS) is fine for "standard PC timing".

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

<t8nc46$h80$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dav...@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 15:33:42 +0100
Organization: No affiliation
Lines: 9
Message-ID: <t8nc46$h80$1@dont-email.me>
References: <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<t8ff7b$alv$1@dont-email.me>
<633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au>
<t8epif$l1r$1@dont-email.me> <e2euni-bug3.ln1@gonzo.specsol.net>
<vk8tni-2ft1.ln1@gonzo.specsol.net>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au>
<0fi3oi-30m2.ln1@gonzo.specsol.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 19 Jun 2022 14:33:43 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="36aef9898cfc0962ee427492d93d4d99";
logging-data="17664"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19lVVut7MbxAeUHOlRdQNyeysLtyslbEss="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:B5QXBtOAzygtjhbXihxwfhrrsis=
In-Reply-To: <0fi3oi-30m2.ln1@gonzo.specsol.net>
Content-Language: en-GB
 by: David Woolley - Sun, 19 Jun 2022 14:33 UTC

On 19/06/2022 13:46, Jim Pennino wrote:
> CTS/RTS is pin 8 on a RS-232 connector, so how is that "PPS over USB"?

CTS is on pin 5, and RTS on pin 4, on an RS232 connector, which should
be a DB-25 one.

The DE-9 connector, used on PCs, is a TIA-574 connector, not an RS232
one, and RTS is on pin 7 (although not useful in this context, as it is
output from the PC).

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

<j9r3oi-b563.ln1@gonzo.specsol.net>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jim...@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 08:17:41 -0700
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <j9r3oi-b563.ln1@gonzo.specsol.net>
References: <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <t8ff7b$alv$1@dont-email.me> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <t8epif$l1r$1@dont-email.me> <e2euni-bug3.ln1@gonzo.specsol.net> <vk8tni-2ft1.ln1@gonzo.specsol.net> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au> <0fi3oi-30m2.ln1@gonzo.specsol.net> <t8nc46$h80$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="e559ef464aa817d2c497ade1ab77cf7c";
logging-data="9526"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1846t60XlalAr9rOqIC4sfP"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-120-lowlatency (x86_64))
Cancel-Lock: sha1:+7lYODemKLSAbd2YgY8054e8i9k=
 by: Jim Pennino - Sun, 19 Jun 2022 15:17 UTC

David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 19/06/2022 13:46, Jim Pennino wrote:
>> CTS/RTS is pin 8 on a RS-232 connector, so how is that "PPS over USB"?
>
> CTS is on pin 5, and RTS on pin 4, on an RS232 connector, which should
> be a DB-25 one.

You will be hard pressed to find a serial interface with a DB-25
connector these days but signals don't care about what connector you
use, which is why I would question your "which should be a DB-25".
> The DE-9 connector, used on PCs, is a TIA-574 connector, not an RS232
> one, and RTS is on pin 7 (although not useful in this context, as it is
> output from the PC).

While the 9 pin connector is not formally part of the RS-232 standard,
it has been the defacto standard connector for decades now.

Actually, RTS/CTS is on both pins 7 and 8.

Many commercial GPS boxes output the PPS signal on pin 8.

Which pin that goes to on the computer end depends on the cable used,
but for Linux the PPS signal needs to go to pin 1.

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

<t8nha7$m0o$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dav...@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 17:02:15 +0100
Organization: No affiliation
Lines: 6
Message-ID: <t8nha7$m0o$1@dont-email.me>
References: <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au>
<635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<t8ff7b$alv$1@dont-email.me>
<633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au>
<t8epif$l1r$1@dont-email.me> <e2euni-bug3.ln1@gonzo.specsol.net>
<vk8tni-2ft1.ln1@gonzo.specsol.net>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au>
<0fi3oi-30m2.ln1@gonzo.specsol.net> <t8nc46$h80$1@dont-email.me>
<j9r3oi-b563.ln1@gonzo.specsol.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 19 Jun 2022 16:02:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="36aef9898cfc0962ee427492d93d4d99";
logging-data="22552"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//vT2xG8wAKM1rBhxj74q8WzrNRnQ21kU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:YBR9u0rzl+l4cazfzDiSuTczzxw=
In-Reply-To: <j9r3oi-b563.ln1@gonzo.specsol.net>
Content-Language: en-GB
 by: David Woolley - Sun, 19 Jun 2022 16:02 UTC

On 19/06/2022 16:17, Jim Pennino wrote:
> which is why I would question your "which should be a DB-25".

It's RS232's should be. Actually, Wikipedia seems to say that the D
version says must be. A lot of this thread is about RS232 compliance,
and part of that compliance is using the correct connector.

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

<jrv3oi-s1d3.ln1@gonzo.specsol.net>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jim...@gonzo.specsol.net (Jim Pennino)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Date: Sun, 19 Jun 2022 09:35:33 -0700
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <jrv3oi-s1d3.ln1@gonzo.specsol.net>
References: <459ACBD9-C70B-491C-A84E-7A44EEBFBCF4@dons.net.au> <t8ff7b$alv$1@dont-email.me> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <t8epif$l1r$1@dont-email.me> <e2euni-bug3.ln1@gonzo.specsol.net> <vk8tni-2ft1.ln1@gonzo.specsol.net> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <ABF6BC64-85FC-4D7B-92F5-E57110700FD8@dons.net.au> <0fi3oi-30m2.ln1@gonzo.specsol.net> <t8nc46$h80$1@dont-email.me> <j9r3oi-b563.ln1@gonzo.specsol.net> <t8nha7$m0o$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="e559ef464aa817d2c497ade1ab77cf7c";
logging-data="9192"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/VRlJn/DyHrGn2IgROffnP"
User-Agent: tin/2.4.4-20191224 ("Millburn") (Linux/5.4.0-120-lowlatency (x86_64))
Cancel-Lock: sha1:YcxK7Kct1cq8Gg8Z6mI0NV0Fhwg=
 by: Jim Pennino - Sun, 19 Jun 2022 16:35 UTC

David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 19/06/2022 16:17, Jim Pennino wrote:
>> which is why I would question your "which should be a DB-25".
>
> It's RS232's should be. Actually, Wikipedia seems to say that the D
> version says must be. A lot of this thread is about RS232 compliance,
> and part of that compliance is using the correct connector.

The signals don't care if the connector is DB-9, DB-25 or RJ-45.

The defacto standard for RS-232 has been DB-9 for decades.

As you said, current hardware usually far exceeds the performance
requirements of the 80 year old standard.

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<t8oblr$1dq9$1@gioia.aioe.org>

 copy mid

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

 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-no...@tridac.net (chris)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Mon, 20 Jun 2022 00:32:11 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t8oblr$1dq9$1@gioia.aioe.org>
References: <t8ff7b$alv$1@dont-email.me> <t8epif$l1r$1@dont-email.me> <D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au> <a86255a9-295b-cf0c-e959-93a59db1b74a@blueyonder.co.uk> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <t8i1t0$sj2$1@dont-email.me> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <2F042972-2230-4CCE-8606-D789EBF6722C@dons.net.au>
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="46921"; 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 - Sun, 19 Jun 2022 23:32 UTC

On 06/19/22 15:03, Daniel O'Connor wrote:
>
>
>> On 19 Jun 2022, at 17:43, David Taylor<david-taylor@blueyonder.co.uk> wrote:
>>
>> On 19/06/2022 07:30, Daniel O'Connor wrote:
>>> I think for standard PC timing in a network it is more than adequate.
>>> Using PPS over USB does give you an improvement over just serial traffic so why not use it since it's free.
>>
>>> Sure, but I would think something with an input capture timer will produce a better result again. It is just unfortunate the RPi can't do it.
>>
>> If PPS over USB is all you have, of course use it. But if you have a local stratum-1 server it's likely to produce much better results, just using a LAN connection.
>
> I am not sure this is true, but the difference if probably negligible.
>
> However.. if you had a local stratum 1 server then using a GPS receiver seems pointless unless you want redundancy..
>
>> Probably on the RPi using an input capture timer wouldn't produce much better results than simply using the GPIO pins and the the built-in kernel PPS support and reference NTP. I tend to think of the RPi alone as "tens of microseconds or better", and capture
>
> Input capture is nice because it means interrupt latency is no longer a problem.
>
> The PPS edge is captured by the clock and so it doesn't matter how long the CPU takes to read it (until the next edge anyway..) there is no loss of accuracy.
>
>> timer (PTP) as sub-microsecond level. Both are quite adequate for "standard PC timing".
>
> Sure, but NMEA (even without PPS) is fine for "standard PC timing".
>

The problem with that is that the system granularity can never be better
than one second, since its not known where within that second the timing
is, related to the utc tick.

Might be good enough for some, but properly setup ntp with pps sync can
can have an accuracy in microseconds, that's 6 orders of magnitude
better accuracy. In some cases, that doesn't matter, but some systems
worldwide need precision timing that ntp can provide.

Don't really understand what's meant by "input capture timer" ?. Is
that related to some polling method, or what ?...

Chris

> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
> -- Andrew Tanenbaum

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<t8pipl$n88$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dav...@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Mon, 20 Jun 2022 11:39:48 +0100
Organization: No affiliation
Lines: 12
Message-ID: <t8pipl$n88$1@dont-email.me>
References: <t8ff7b$alv$1@dont-email.me> <t8epif$l1r$1@dont-email.me>
<D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au>
<a86255a9-295b-cf0c-e959-93a59db1b74a@blueyonder.co.uk>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au>
<635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<t8i1t0$sj2$1@dont-email.me>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<2F042972-2230-4CCE-8606-D789EBF6722C@dons.net.au>
<t8oblr$1dq9$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 20 Jun 2022 10:39:49 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="834a49b280c6fda56590a0b0d1902567";
logging-data="23816"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19xPdvIC/cv29goZJQc+KZDDb5IlWU/Hvs="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:lqE/QBt6rhwUY7bf3i9JLBzjfk4=
In-Reply-To: <t8oblr$1dq9$1@gioia.aioe.org>
Content-Language: en-GB
 by: David Woolley - Mon, 20 Jun 2022 10:39 UTC

On 20/06/2022 00:32, chris wrote:
> Don't really understand what's meant by "input capture timer" ?. Is
> that related to some polling method, or what ?...

I believe they mean a hardware clock, that can be read directly by the
software, and is also latched into a register when the PPS signal
arrives. A variation might be to start a hardware timer when the PPS
arrives, again making it directly readable.

Also, whilst NMEA is low priority, I suspect it is not uncommon to have
its generation scheduled at the PPS time, making it much closer to the
last PPS than the next.

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<t8q1mp$196g$1@gioia.aioe.org>

 copy mid

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

 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-no...@tridac.net (chris)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Mon, 20 Jun 2022 15:54:16 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t8q1mp$196g$1@gioia.aioe.org>
References: <t8ff7b$alv$1@dont-email.me> <t8epif$l1r$1@dont-email.me> <D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au> <a86255a9-295b-cf0c-e959-93a59db1b74a@blueyonder.co.uk> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <t8i1t0$sj2$1@dont-email.me> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <2F042972-2230-4CCE-8606-D789EBF6722C@dons.net.au> <t8oblr$1dq9$1@gioia.aioe.org> <t8pipl$n88$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="42192"; 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, 20 Jun 2022 14:54 UTC

On 06/20/22 11:39, David Woolley wrote:
> On 20/06/2022 00:32, chris wrote:
>> Don't really understand what's meant by "input capture timer" ?. Is
>> that related to some polling method, or what ?...
>
> I believe they mean a hardware clock, that can be read directly by the
> software, and is also latched into a register when the PPS signal
> arrives. A variation might be to start a hardware timer when the PPS
> arrives, again making it directly readable.

Still doesn't explain how the pps state change gets into the
system at hardware level. Devil in the detail, as usual.
It sounds like a polled system, not an interrupt driven one,
which can never be as accurate as the latter. Assuming a poll
rate of say, 1mS, not unreasonable for a modern cpu, Then if
the pps state change is not seen at one poll, but is seen at
the next, then the uncertainty can never be better than that
1mS, since it cannot be known when during that 1 mS the state
transition occurred. Best results for ntp really need a true
real time os, but it's far more common to use general purpose
os's because of the out of the box functionality., but not
ideal.

>
> Also, whilst NMEA is low priority, I suspect it is not uncommon to have
> its generation scheduled at the PPS time, making it much closer to the
> last PPS than the next.

Working through the path, would expect the nmea sentence to be
synchronised to the pps, but that's not the end of the story.
GPS engines, ones seen here, typically run at 2400 or 4800 bauds,
or ~200uS per bit. Assume the sentence is 6 bytes, 10 bits per
byte, that's 12.5mS to end of message. The host must then decode
that, say 20mS total processing time. Depending on the host, that
could be fairly deterministic and the delay corrected for, but
the overall system is still limited to a 1 second bounded
uncertainty, not good at all for a public ntp server.

Sorry, but interrupt driven systems are the only way to get it
right...

Chris

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<t8qlh0$i4c$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dav...@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Mon, 20 Jun 2022 21:32:31 +0100
Organization: No affiliation
Lines: 33
Message-ID: <t8qlh0$i4c$1@dont-email.me>
References: <t8ff7b$alv$1@dont-email.me> <t8epif$l1r$1@dont-email.me>
<D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au>
<a86255a9-295b-cf0c-e959-93a59db1b74a@blueyonder.co.uk>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au>
<635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<t8i1t0$sj2$1@dont-email.me>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<2F042972-2230-4CCE-8606-D789EBF6722C@dons.net.au>
<t8oblr$1dq9$1@gioia.aioe.org> <t8pipl$n88$1@dont-email.me>
<t8q1mp$196g$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 20 Jun 2022 20:32:32 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="834a49b280c6fda56590a0b0d1902567";
logging-data="18572"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18LGMFC9UVf/lCPYfRXCDXL5dsOj74zPV8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:+Lej8W7xv7N12c9zZD2cK9IQHmE=
In-Reply-To: <t8q1mp$196g$1@gioia.aioe.org>
Content-Language: en-GB
 by: David Woolley - Mon, 20 Jun 2022 20:32 UTC

On 20/06/2022 15:54, chris wrote:
> Still doesn't explain how the pps state change gets into the
> system at hardware level. Devil in the detail, as usual.
> It sounds like a polled system, not an interrupt driven one,

Interrupt system are I think pretty much always polled at the hardware
level.

> which can never be as accurate as the latter. Assuming a poll
> rate of say, 1mS, not unreasonable for a modern cpu, Then if
> the pps state change is not seen at one poll, but is seen at
> the next, then the uncertainty can never be better than that

The uncertainty is the clock period in the capture hardware, because the
hardware counts and returns the the number of its clock cycles, so you
know very precisely how long it was from the the PPS to when you polled.
Actually I think something like that is pretty standard for most
microcontrollers.

I believe there are Ethernet cards that do this to support, I think,
Precision Time Protocol, which I suspect is what high frequency traders use.

> 1mS, since it cannot be known when during that 1 mS the state
> transition occurred. Best results for ntp really need a true
> real time os, but it's  far more common to use general purpose
> os's because of the out of the box functionality., but not
> ideal.

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<t8qls1$jop$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dav...@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Mon, 20 Jun 2022 21:38:25 +0100
Organization: No affiliation
Lines: 5
Message-ID: <t8qls1$jop$1@dont-email.me>
References: <t8ff7b$alv$1@dont-email.me> <t8epif$l1r$1@dont-email.me>
<D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au>
<a86255a9-295b-cf0c-e959-93a59db1b74a@blueyonder.co.uk>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au>
<635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<t8i1t0$sj2$1@dont-email.me>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<2F042972-2230-4CCE-8606-D789EBF6722C@dons.net.au>
<t8oblr$1dq9$1@gioia.aioe.org> <t8pipl$n88$1@dont-email.me>
<t8q1mp$196g$1@gioia.aioe.org> <t8qlh0$i4c$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 20 Jun 2022 20:38:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="834a49b280c6fda56590a0b0d1902567";
logging-data="20249"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+SlK/iHfHKdCkln5lqFsM+6014ocqB9c0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:UuqwnAN/D0k0icMLkdwd6dVLpMs=
In-Reply-To: <t8qlh0$i4c$1@dont-email.me>
Content-Language: en-GB
 by: David Woolley - Mon, 20 Jun 2022 20:38 UTC

On 20/06/2022 21:32, David Woolley wrote:
> Actually I think something like that is pretty standard for most
> microcontrollers.

E.g. see <https://www.electronicwings.com/pic/pic18f4550-timer-capture>

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<t8r3h9$14s4$1@gioia.aioe.org>

 copy mid

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

 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-no...@tridac.net (chris)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Tue, 21 Jun 2022 01:31:37 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t8r3h9$14s4$1@gioia.aioe.org>
References: <t8ff7b$alv$1@dont-email.me> <t8epif$l1r$1@dont-email.me> <D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au> <a86255a9-295b-cf0c-e959-93a59db1b74a@blueyonder.co.uk> <ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com> <633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au> <635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com> <t8i1t0$sj2$1@dont-email.me> <a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com> <2F042972-2230-4CCE-8606-D789EBF6722C@dons.net.au> <t8oblr$1dq9$1@gioia.aioe.org> <t8pipl$n88$1@dont-email.me> <t8q1mp$196g$1@gioia.aioe.org> <t8qlh0$i4c$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="37764"; 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 - Tue, 21 Jun 2022 00:31 UTC

On 06/20/22 21:32, David Woolley wrote:
> On 20/06/2022 15:54, chris wrote:
>> Still doesn't explain how the pps state change gets into the
>> system at hardware level. Devil in the detail, as usual.
>> It sounds like a polled system, not an interrupt driven one,
>
> Interrupt system are I think pretty much always polled at the hardware
> level.
>
>> which can never be as accurate as the latter. Assuming a poll
>> rate of say, 1mS, not unreasonable for a modern cpu, Then if
>> the pps state change is not seen at one poll, but is seen at
>> the next, then the uncertainty can never be better than that
>
> The uncertainty is the clock period in the capture hardware, because the
> hardware counts and returns the the number of its clock cycles, so you
> know very precisely how long it was from the the PPS to when you polled.
> Actually I think something like that is pretty standard for most
> microcontrollers.

Sorry David, but that is incorrect. If you look at the app note you
posted, input capture section, quite clearly states that:

> When the rising or falling edge is detected at the CCP1 pin,
> the interrupt flag CCP1IF bit is set.

So it is a interrupt driven method, which is the only way
to guarantee synchronisation between an input event and
the system, at micro or even nanosecond accuracy.

In practice, there will be delays in the process between
the pps interrupt and ntpd. If the pps arrival time is
logged within the interrupt handler early and a counter
also started from zero, then the real arrival time can be
determined within ntp, irrespective of delays, by adding
the counter value to the pps event time. Not sure if ntp
does that at present, but it would need driver and kernel
support.

>
> I believe there are Ethernet cards that do this to support, I think,
> Precision Time Protocol, which I suspect is what high frequency traders
> use.

Not sure, but would expect that they use GPS clocks, which
can give nS timing sync anywhere on the planet. Well, just about
anywhere. A commonly used tech by millions with no understanding
needed of haw it works. Even working in tech, i'm still amazed by
what GPS achieves...

Chris

>
>> 1mS, since it cannot be known when during that 1 mS the state
>> transition occurred. Best results for ntp really need a true
>> real time os, but it's far more common to use general purpose
>> os's because of the out of the box functionality., but not
>> ideal.
>
>
>

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?

<t8s87j$95s$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.protocols.time.ntp
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dav...@ex.djwhome.demon.invalid (David Woolley)
Newsgroups: comp.protocols.time.ntp
Subject: Re: [questions] GPS+PPS vs NTP server, why a huge offset ?
Date: Tue, 21 Jun 2022 11:57:55 +0100
Organization: No affiliation
Lines: 30
Message-ID: <t8s87j$95s$1@dont-email.me>
References: <t8ff7b$alv$1@dont-email.me> <t8epif$l1r$1@dont-email.me>
<D4ABA7C3-D641-4A0F-B89A-7CCAFBC41A4C@dons.net.au>
<a86255a9-295b-cf0c-e959-93a59db1b74a@blueyonder.co.uk>
<ee36733a-f1ba-4fe7-8f5d-8ba7e0ef5f7an@googlegroups.com>
<633A7397-0163-4408-BB2C-D639D6C5B92D@dons.net.au>
<635e79a8-586c-4de8-b081-073aaf1b253en@googlegroups.com>
<t8i1t0$sj2$1@dont-email.me>
<a210ebde-c160-415b-84a2-d4a3a50c1ecfn@googlegroups.com>
<2F042972-2230-4CCE-8606-D789EBF6722C@dons.net.au>
<t8oblr$1dq9$1@gioia.aioe.org> <t8pipl$n88$1@dont-email.me>
<t8q1mp$196g$1@gioia.aioe.org> <t8qlh0$i4c$1@dont-email.me>
<t8r3h9$14s4$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 21 Jun 2022 10:57:55 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="1a23a9bf72c824485bda8858c69df988";
logging-data="9404"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/X9qWG/oDRHJthmxnBI7G4jtaddcbdYNs="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:MXf2d9GHY8lxSP5mEfq4gAk94e8=
In-Reply-To: <t8r3h9$14s4$1@gioia.aioe.org>
Content-Language: en-GB
 by: David Woolley - Tue, 21 Jun 2022 10:57 UTC

On 21/06/2022 01:31, chris wrote:
> Sorry David, but that is incorrect. If you look at the app note you
> posted, input capture section, quite clearly states that:
>
> > When the rising or falling edge is detected at the CCP1 pin,
> > the interrupt flag CCP1IF bit is set.
>

If you go to a more primary source
<https://ww1.microchip.com/downloads/en/DeviceDoc/60001122G.pdf>, you
will see, in the diagram on page 15-3, that the logic path for raising
interrupts diverges from that for doing the capture, after the event
detection, so the capture is not dependent on the interrupt occurring.

Also, on page 15-4, that the actual interrupt can be selectively disabled.

In my original response, I did meant to add that there would typically
be an interrupt, but that the interrupt could be handled with low
priority (you will get a good result any time until the timer actually
wraps round. Even then, the use of an interrupt is not a fundamental
requirement.

For a dedicated appliance, interrupts can actually be a liability, as
they can introduce race conditions. Nonetheless, I think all current
microcontrollers support them.

With precision time, over Ethernet, one would expect the normal Ethernet
device driver interrupt handling, but, for example, the device driver
might well service several incoming messages on one interrupt. However
capturing the event time still means that nano-second accuracy is possible.

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor