[ntp:questions] Time server question
xxx.syseng.yyy at gfsys.co.uk
Tue Jun 25 00:33:43 UTC 2019
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 at 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
>>> 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).
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
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...
More information about the questions