On 2019-06-25, Chris <xxx.syseng....@gfsys.co.uk> wrote: > On 06/21/19 15:48, Jakob Bohm wrote: >> On 21/06/2019 15:14, Thomas Laus wrote: >>> On 2019-06-21, David Woolley <david@ex.djwhome.demon.invalid> wrote: >>>> On 21/06/2019 12:26, Thomas Laus wrote: >>>>> Will either isolation solution have direct access to the computer >>>>> CPU? The GPS clock will need the ability to directly adjust the >>>>> frequency of the CPU to achieve expected results for a Stratum 1 >>>>> serve >>>> >>>> I'm not aware of anything in ntpd that directly adjusts the CPU >>>> frequency and there generally isn't any fine grained way of doing that. >>>> ntpd normally works by adjusting how many cycles of a fixed frequency >>>> represent a certain time period, and that is a software operation. >>>> >>> I guess that I should have stated this reply a little differently. I >>> meant to say that ntpd will need direct access to the hardware that >>> it runs on. That means a hardware serial port for pulse per second >>> and the running system clock frequency. The ntpd program does not >>> perform well when running on a virtual machine nor in a isolated >>> security environment similar to a freebsd jail. My advice to the >>> original poster is to get ntpd running as a stratum 1 source and >>> then connect it to the internet with the fewest number of inter- >>> mediate hops in between. I doubt that this is possible if the >>> Stratum 1 time source can be connected through any buffer device >>> to the internet and still serve Stratum 1 time. >>> >>> >> >> The deeper problem here is that the NTP protocol doesn't clearly >> distinguish between a stratum 2 server running dozens of low quality >> hops from it's time sources and a stratum 2 server that sits a single >> hop from a solid stratum 1 source. >> >> On the other hand, a GPS, WWVB or other radio clock isn't really a >> stratum 1, as it receives remote time over a non-NTP protocol, so that >> sort of cancels out the stratum 2 reported due to the stacking. >> >> Running the Internet-exposed ntp server in a bastion host separate >> from the difficult-to-upgrade old hardware makes perfect sense, and >> an ntpd server without same machine precision time sources only needs >> the permissions to use port 123 and to adjust the local clock (including >> it's speed) via the various privileged system calls. Running the >> computer clocks in such a bastion host from a quality crystal rather >> than a cheap ceramic oscillator would also help reduce time errors, but >> this is in the hardware buying phase and not a detail typically provided >> by computer vendors. >> >> I suspect the ntp servers run by national time services and synced to >> their reference Cs and maser clocks are also receiving the time via >> some kind of internal network, either ntp with stratum fudge, PTP low >> latency Ethernet distribution or an amplified low latency coax >> distribution of the 1Hz or 10MHz reference (the latter would be most >> precise and offer no data channel for a compromised server to attack the >> actual clock). >> >> >> Enjoy >> >> Jakob > > Thanks for all the replies. I guess the next thing to do is to build > a working system, then evaluate to see how it can be improved. All > the kit is in the same rack and with dedicated hardware interfaces, > network latency shouldn't be a problem. This is effectively a real > time requirement, so any code running needs to be consistent in terms > of response time to minimise jitter on the timing. Need to get > a feel for acceptable delay and response times, so will look to see > what others have done in the past. > > I like the idea of using a 1 pps signal from the gps for fine tuning. > Rough time and date via the network ntp and the 1pps to fine tune it. > That could maintain the stratum 1 timing quality, as the 1pps is > generally within 10's of nS of UTC, but need to look into how ntpd
Well, yes and no. That may be when a certain point inthe transition of the pps signal occurs (although youwoillo have to be really careful about the line from the gps to the computer, and the terminations of the lines. Also that tends to be the corrected time (for the sawtooth running). Also it is really hard to get your computer to process the signal to 0ns. A more resonable estimate is 1microsecond Taking intoaccunt the computer's interrupt latency, time to read system time, etc. To do better is going to take a lot of work. Note the gps ALSO delivers the seconds information in the gps time signal. (Ie labelling the seconds). > would handle that and also how to introduce that into the system. > Already use an ex telco gps for a lab frequency standard, but of > course, frequency != time of day. A dedicated embedded solution might > be the best bet, but other options might include a cheap netgear > router to provide the isolation, as it would only be handling ntp > packets at low and consistent system and network load. > > Nothing is ever as easy as it seems, as usual... Depends on what you want out of the system, or rather what you need. No point is spending months and tens of thousands of dollars when all you really need is resultion to the second. > > Chris > > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
