[questions] Re: NTP community feels broken
On 21/06/2022 10:48, William Unruh wrote: Who cares if it is no longer RS232, if it works. As has been pointed out virtually no rs232 hardware is RS232 according to the standards. Oddly that is the point I was trying to make. Someone was insisting that you mustn't cut corners, and must use an RS232 driver when interfacing to a nominally RS232 input port. I was analyzing the consequences of actually conforming to RS232. -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
[questions] Re: NTP community feels broken
Jim Pennino wrote: William Unruh wrote: On 2022-06-19, David Woolley wrote: On 19/06/2022 01:06, chris wrote: In practice, that will be small, since the data sheet figures for a typical max232 assume a 2.5nf capacitive load on the output, whereas a few inches of wire into a rs232 line receiver setup might be much faster. As we are talking about compliant RS232, which is the only real world reason for not just connecting TTL directly to the RS232 port, the the 2.5nF condition is the maximum capacitance that can appear across the driver output as the result of what it is driving. That sets a minimum possible slew rate. However a compliant RS232 system also has a maximum permitted slew rate, intended to minimise cross talk, and probably also to ensure that long cables don't ring, as the initial transient reflects backwards and forwards. 30V/µs is the maximum permitted slew rate for a compliant system. If your system exceeds that, even if it is using RS232 drivers, it is not a compliant system. Who cares if it is compliant esp as most real RS232 do better. RS232 standards are about 50 years old. They were still using vacuum tubes:-) Test your system to see what it can do. Hand-wringing over the serial physical characteristics are pointless unless you have a very long cable or are designing your own interface. Commercial hardware is orders of magnitude better at both latency and jitter than most all computer hardware/software combinations unless you are using computer hardware specifically designed for real time systems with a real time OS. The limiting factor for PC's and things like the Pi will be the jitter in processing the interrupt generated by the PPS signal. This tends to be on the order of 1 microsecond at best on every PC and SBC board I have used. FYI the best I've seen so far is about 900 nanoseconds on a Pi4. Back before OoO processors, spread spectrum clocks and variable frequency boosts, i.e. Pentium days around 1994-1997, it was trivially easy to get far below your stated 1 us jitter. It is indeed harder today! A propr GPS clock these days needs to be inverted, i.e. the server asks the clock what time it is _now_, and gets back a timestamp. So, by taking the local system clock, sending off this querey, and then checking the local clock again, you can both measure the latency of this reading and get the official/gps-based time. In order to work this way, the GPS needs a way to use its local osc (typically running at 10 MHz) to count ticks since the last second transition, there has been at least one reference clock that worked this way. Repeat this call maybe 5 times and pick the one with the lowest turnaround time. 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
On 20/06/2022 00:14, chris wrote: Early processors often had just a couple of interrupt pins, irq and nmi, You mean microprocessors. NMI seems to be a concept that was introduced with microprocessors, and multi-priority interrupts existed before even the earliest microprocessors. In terms of software, I don't think typical Linux code really fully supports multi-level interrupts, and, if anything, may effectively invert the priority order. -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
[questions] Re: NTP community feels broken
On 19/06/2022 16:10, William Unruh wrote: So teminate it to get rid of the refections. It's no longer RS232 if you terminate it anything less than, ISTR, 4k, or reverse terminate in anything other than 300 ohms. I think 100 ohm is typical for the characteristic impedance of a wire pair, so given the open source voltage of the driver is 12 volts, by terminating it you have removed all your noise margin, if you accept the transition region is the full +/-3V. If you want to use an EIA standard that uses terminated lines, you should use RS 422, which also uses differential pairs, which also improves noise immunity. Or RS 423, which, although it uses a differential line receiver, is unbalanced, with one of the pair tied to local functional ground at the transmitter. -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
[questions] Re: NTP community feels broken
On 19/06/2022 11:30, chris wrote: Yes, it does have a spec for the slew rate, but i'm not sure that would always be met for modern devices, as such uarts can often be run at data rates of up to 230 Kbytes / second, or about a 4uS bit time. That implies much faster rise and fall times, which relates to slew rate. But those aren't RS232 compliant devices, although the slew rate limit is still low enough to support those data rates, but not with the full cable length. We can theorise about that, but iirc, I bought two ttl to rs232 converters at the time. If I can find the second one, i'll set it up on the bench and measure the propagation delay on a scope from input to output. Also, see what effect the 2.5nF cap has on the waveform and timing... The 2.5nF is mainly intended to represent the capacitance of the cable, which is deliberately operated with both source and load termination impedances well above the characteristic impedances, so behaves like capacitor. With the full length cable, rather than the lumped capacitance, you would expect the voltage to staircase upwards, each time the leading edge reflection returns. The 2.5nF basically allows for the 50 foot maximum cable at 50pF/ft. -- 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
Hi Phillip, Please let me know if you see this. I'll dig thru my Sent folder to find my previous messages. Some of what I want to chat about would be better handled via direct communication. If I see something where others might have an interest, I make public comments. Thanks! On 6/18/2022 11:58 AM, Phillip Hellewell wrote: On Saturday, June 18, 2022 at 1:33:02 AM UTC-6, Harlan Stenn wrote: Phillip, I have send you several emails. Have you received any of them? Unfortunately, no. Maybe they went to my Spam folder? If you want to try again, I'll keep a closer eye on that. Or feel free to just answer here since this seems to be working. I do believe most of my questions are ones that a wider audience could benefit from. I am happy to know that my concerns are not getting ignored. Thank you for that. Phillip -- 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
[questions] Re: NTP community feels broken
On 19/06/2022 01:06, chris wrote: In practice, that will be small, since the data sheet figures for a typical max232 assume a 2.5nf capacitive load on the output, whereas a few inches of wire into a rs232 line receiver setup might be much faster. As we are talking about compliant RS232, which is the only real world reason for not just connecting TTL directly to the RS232 port, the the 2.5nF condition is the maximum capacitance that can appear across the driver output as the result of what it is driving. That sets a minimum possible slew rate. However a compliant RS232 system also has a maximum permitted slew rate, intended to minimise cross talk, and probably also to ensure that long cables don't ring, as the initial transient reflects backwards and forwards. 30V/µs is the maximum permitted slew rate for a compliant system. If your system exceeds that, even if it is using RS232 drivers, it is not a compliant system. -- 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
On Saturday, June 18, 2022 at 1:33:02 AM UTC-6, Harlan Stenn wrote: > Phillip, > > I have send you several emails. Have you received any of them? Unfortunately, no. Maybe they went to my Spam folder? If you want to try again, I'll keep a closer eye on that. Or feel free to just answer here since this seems to be working. I do believe most of my questions are ones that a wider audience could benefit from. I am happy to know that my concerns are not getting ignored. Thank you for that. Phillip -- 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
Phillip, I have send you several emails. Have you received any of them? On 6/17/2022 8:45 PM, Phillip Hellewell wrote: Does anyone have answers to the specific issues I found, like why the github repo isn't Philbeing synced, or why I can't log into bugs.ntp.org, or why emails to webmas...@ntp.org bounce? -- 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
[questions] Re: NTP community feels broken
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
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
[questions] Re: NTP community feels broken
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
[questions] Re: NTP community feels broken
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: NTP community feels broken
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
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
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
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
[questions] Re: NTP community feels broken
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
