[questions] Re: NTP community feels broken

[Phillip Hellewell]

Does anyone have answers to the specific issues I found, like why the github 
repo isn't being synced, or why I can't log into bugs.ntp.org, or why emails to 
webmas...@ntp.org bounce?
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

Re: [questions] Re: NTP community feels broken

[Harlan Stenn]

On 6/17/2022 11:33 AM, David Woolley wrote:

On 17/06/2022 19:14, Paul G wrote:
Where is it in this 
tarball:http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p15.tar.gz 



If it's not there then you're probably in the wrong list/group.


This group is about the NTP protocol, not just the version 4 reference 
implementation.  chrony, the SNTP client that Debian use, etc., are also 
on topic.  I would say that the management of the pool servers was 
definitely on topic.


If you're talking about questions@ and maybe even c.p.t.n, I think "this 
group" is about things related to the NTP Project, originally considered 
to be at UDel (from the 80s until 2011), and (since 2011) now at Network 
Time Foundation.


--
Harlan Stenn 
http://networktimefoundation.org - be a member!
--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

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

[David Woolley]

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.

--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

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

[David Woolley]

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.


 quotes ≤30 
nanoseconds, 95% of the time.  That probably includes uplink allowances. 
 Also, I'm not sure if UTC() 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.

--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

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

[Ralph Blach]

I like the adafruit gps hat

Chip Blach

On Fri, Jun 17, 2022, 1:16 PM Terje Mathisen  wrote:

> 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
>
> --
> - 
> "almost all programming can be viewed as an exercise in caching"
> --
> This is questions@lists.ntp.org
> Subscribe: questions+subscr...@lists.ntp.org
> Unsubscribe: questions+unsubscr...@lists.ntp.org
>
>
>
>
>

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

[Terje Mathisen]

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

--
- 
"almost all programming can be viewed as an exercise in caching"
--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 2:24:05 PM UTC-4, chris wrote:
> That's correct, but the various issues with the system have been 
> discussed for years, yet nothing ever gets done about it. That's the 
> point that Philip above was making... 

Of course working with Harlan is difficult. Coming here to advise us of that 
won't result in any changes. Fortunately there are alternatives so there's no 
need to fret about the "reference" implementation.

The issue with your posts is that they were confusing. Or wrong.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

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

[David Woolley]

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.

--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 2:33:35 PM UTC-4, David Woolley wrote:
> On 17/06/2022 19:14, Paul G wrote: 
> > Where is it in this 
> > tarball:http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p15.tar.gz
> >  
> > 
> > If it's not there then you're probably in the wrong list/group.
> This group is about the NTP protocol

I said probably because other major projects have (or should have) their own 
discussion channels.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

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

[David Woolley]

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.

--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[David Woolley]

On 17/06/2022 19:14, Paul G wrote:

Where is it in this 
tarball:http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p15.tar.gz

If it's not there then you're probably in the wrong list/group.


This group is about the NTP protocol, not just the version 4 reference 
implementation.  chrony, the SNTP client that Debian use, etc., are also 
on topic.  I would say that the management of the pool servers was 
definitely on topic.

--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 2:12:52 PM UTC-4, chris wrote:

> Nothing to do with products. ntp.org has a monitoring system that polls 
> every server in its database to verify that it's reachable.

Perhaps you mean pool.ntp.org. It's in the ntp.org namespace but it's a 
separate project run by Ask Bjørn Hansen.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 11:24:31 AM UTC-4, chris wrote:
> It's the code that polls ntp servers to verify that they are up.

Where is it in this tarball: 
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p15.tar.gz

If it's not there then you're probably in the wrong list/group.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 9:37:15 AM UTC-4, chris wrote:
> The problem is the monitoring software

What software product/program do you mean?
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

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

[Jim Pennino]

Daniel O'Connor  wrote:
> 
> 
>> On 17 Jun 2022, at 12:52, Jim Pennino  wrote:
>> Daniel O'Connor  wrote:
>>> 
>>> 
 On 17 Jun 2022, at 00:07, David Taylor 
  wrote:
 
 On 16/06/2022 10:00, Thiebaud HUMBERT wrote:
> To do the inversion, I just changed the "Pulse Mode" parameter to 
> "Falling edge" from "Rising edge".
> The offset induced by the "pulse length" has disappeared.
> But there is still an offset of around 10.3ms, which I think is induced 
> by USB as explained in this article about other chipsets 
> (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html)
 
 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).
>> 
>> As USB is a two wire interface, there is no such thing as PPS over USB.
> 
> The fact USB only has 2 data lines is irrelevant to wether you can send PPS 
> over USB.
> 
>> 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"?
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

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

[Ralph Blach]

I have complete instructions on how to use a raspberry pi as an NTP server.

Ping me if you want them

Chip Blach

On Fri, Jun 17, 2022, 8:08 AM David Taylor
 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.
>
> 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.
>
> --
> Cheers,
> David
> Web: http://www.satsignal.eu
> --
> This is questions@lists.ntp.org
> Subscribe: questions+subscr...@lists.ntp.org
> Unsubscribe: questions+unsubscr...@lists.ntp.org
>
>
>
>
>

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

[David Taylor]

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.


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.


--
Cheers,
David
Web: http://www.satsignal.eu
--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

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

[David Woolley]

On 17/06/2022 00:55, chris wrote:

No argument with that, but some have tried to bypass a converter,
feeding the ttl pps into the rs232 port, which may work in some
cases. TLL pps low level, in particular, won't guarantee the rs232
input line to switch, whereas, of course, the ttl high will switch.
The rs232 ip needs zero or a minus level to properly work and avoid
jitter...



In practice, RS232 line receivers will emulate the characteristics of 
the 1489 or 1489A ICs (which are still available).  In the simplest 
configuration for those, the input low threshold voltage is no less than 
+0.75 volts and the input high threshold voltage is no more than +2.25 
volts, which makes nearly all real life true RS232 line receivers TTL 
compatible.  (The A variant has a larger hysteresis, and results in a 
higher high threshold.)


The main reason for not using TTL are that is isn't designed for driving 
more than a few inches of wire, and it doesn't have the huge noise 
margins of true RS232 drivers.


In terms of level converting to TTL, the decades old 1488 line drivers 
are also still available, although they need +/- 12V supplies, as are 
the newer, but still decades old, MAX232 devices, that have charge pumps 
to derive the 12 volts from a 5 volt supply.  As such, there is no 
really sensible reason to re-purpose device intended for shifting 
between 3.3 an 5 volt CMOS levels.

--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[David Woolley]

On 17/06/2022 00:30, chris wrote:

lack of full disclosure, documented


I'm having trouble understanding what this means.  If you mean that the 
documentation is poor, that is a common problem with open source 
software, as it relies  on volunteer effort, and programmers don't like 
writing documentation.


Actually, in terms of end user documentation, I find most technology 
poor.  Businesses tend to document the small number of marketing claims, 
in marketing language, and don't provide detailed functional descriptions.


For software, the only really good documentation is often the test plan, 
but that is considered highly confidential for commercial software. 
Open source coders are less likely to write formal test suites.


The original author of ntpd saw it as a maths problem, and was 
frustrated by the inability of the RFC system to cope with mathematical 
notation.  The primary documentation, the version 4 RFC, is written as a 
maths paper, but with the Greek letters spelled out.


ntpd will have been documented to the same sort of detail as an 
experimental rig in an academic paper.  The main detail would have gone 
into the particualr property of the core algorithm that the paper was 
trying to investigate.


It may also be significant that its primary developer is now 84.

Although I say lack of documentation is a problem for all technology, 
what I sometimes find out with hardware is that it is all based on a 
small number of special purpose ICs, and if you can establish what is 
being used you can get a long way towards a real specification, rather 
than the half page marketing hype on Amazon, by looking at the 100 page 
data sheet for the ICs.  Semiconductors seem to be an area where 
detailed end user documentation is still available in the public domain.


It is common for the consumer products to be more or less direct 
implementations of the typical application circuits, from the IC data 
sheet.  This doesn't work so well with software, as every user can end 
up customising its use to a level that only the final manufacturer would 
do for hardware, and they are more prepared to do so than the people who 
sell products on Amazon.

--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org