On 06/25/19 11:34, William Unruh wrote:
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
Hi,
Thanks again for the replies. Did a bit of digging this morning and
find that the 1pps sync stuff has been done before. Well, many
years ago in fact and more or less how I had visualised it - ntp
data augmented by the 1 pps signal. Several pointers to the way
forward and it's also supported in the FreeBSD kernel, using either a
pin on a serial or parallel port for the 1 pps. Probably go for
the parallel port, as that avoids the hardware to convert 1 pps
ttl to rs232 levels.
Have a Minix mini-itx box with two network ports which only draws
about 12 watts. It has headers for the parallel and serial ports,
so looks ideal to experiment with. Already has FreeBSD 11.2, but
will reinstall 12 at minimum level to get the job done. Not after
perfection, but engineers always want the best result at minimum
cost and timescales :-). A few uS should be more than good enough to
maintain stratum 1 accuracy afaics, as network variables are
orders of magnitude greater than that. Fun project anyway and
will document once it's working...
Chris
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
