---==========

I'm going to say something that may seem heretical but probably
shouldn't be...

On 12/16/21 18:37, giuseppe@marullo.it wrote:

For log purposes, if you're down at the 2ms level you're probably
utterly fine.

I'm sure many people here will tell you what you would need to get
better performance, and there are certainly situations where such
performance is necessary and important. I've worked on such applications
myself, in which microsecond accuracy timestamping of network events was
actually useful.

For ordinary system logs, you will never notice the difference if your
clocks are off by a marginal 1ms. Your logs probably don't even record
milliseconds, and if you're trying to debug a problem in your systems,
your logging subsystem probably doesn't have good guarantees that it's
going to timestamp events within a ms of them occurring. I'd consider
your situation pretty good already and call it a day unless, as with
many of us, you find the idea of getting your machines better
synchronized for its own sake personally satisfying.

Note that there really isn't anything wrong with wanting to do better
for its own sake, but from an engineering requirements point of view,
you've already succeeded.

Perry

On 16/12/2021 23:37, giuseppe@marullo.it wrote:

You can see the offsets reported by a number of Raspberry Pi NTP servers here:

https://www.satsignal.eu/mrtg/performance_ntp.php

As a very rough guide I would expect a PPS-based RPi to be within 100 us
easily, and perhaps considerably better (~10 us) in a constant temperature
environment, and with no other load.  I don't know about load capacity as I've
not tested that, but here it's serving perhaps 50 devices.  With classic NTP
which is what I use there will be a period before the offset becomes near-zero
so 24 x 7 is the way to operate.

Although there are some devices on that page with LAN, 2.4 GHz or 5 GHz
connections, for beat accuracy you must use the PPS signal from the GPS as you
know.  The "o" tally code suggests that's OK.

I suggest using the "pool" directive rather than multiple pool servers:

https://www.satsignal.eu/ntp/setup.html#pool

Cheers,
David

SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv

A couple of Meinberg SyncMon plots for the past month are attached of a Raspberry Pi 4B with a TimeHat (https://millerjs.org/timehat https://millerjs.org/timehat) against a Meinberg M1000 (midrange OXCO), both close to original configuration. The plot with the 1ms scale is for unloaded NTP (meaning Chrony for the Debian variant running on the Pi) with both remaining within about a 0.1 ms envelope.

The plot with the 100ns scale has zoomed in on the 1PPS signals, both likely direct from their u-blox chips. (At least, I think this particular Meinberg relies on u-blox. I’m not at the office to pull the card.) SyncMon can track all sorts of other information, not just offsets, which would allow analyzing the behavior with different numbers of NTP clients, etc.

Our interest is in TTL time capture, and u-blox supports these directly (their TimeMark feature), though this is not implemented for the TimeHats. Both our Meinberg reference clocks and our Meinberg PCIe IRIG-B cards (no u-blox) implement time capture, described here: https://arxiv.org/abs/1807.01370 https://arxiv.org/abs/1807.01370

The Raspberry Pi Compute Module 4 has a hardware timestamping NIC, though it appears no kernel support yet. There are CM4 carrier boards that support multiple gigabyte ethernet connections that could serve as PTP master clocks or boundary clocks (if somebody implements kernel support). There are a lot of variations of Raspberry Pi at this point and the 4Bs and CM4s are significantly more performant than earlier versions.

One could imagine designing a purpose-built CM4 carrier board that would incorporate various features from the OCP TAP design (https://www.opencompute.org/wiki/Time_Appliances_Project https://www.opencompute.org/wiki/Time_Appliances_Project).

Which is to say that the Raspberry Pi itself is not the limiting factor here, and indeed such an affordable single board computer is required to provide inexpensive ubiquitous precision timekeeping.

Rob Seaman
Lunar and Planetary Laboratory
University of Arizona

—

Hi

Any time you run an “open loop” ( = delay asymmetry is not measured)  setup
like NTP, you have multiple sources of error. If you have a requirement for always
being in the microseconds rather than milliseconds, PTP is a better approach.

Even with PTP, there are limits. As your network structure grows, it may struggle
as well. It will be struggling with microseconds rather than milliseconds, but it
can indeed have problems.

Bob

Hi Bob,

I just need it for logs and computer time sync, PTP seems overkill for my requirements.
It is a small lab, then maybe I could offer NTP (SecureNTP) service for the rest of the company, if I will add other NTP/SecureNTP servers depending on the load.

Giuseppe Marullo
IW2JWW - JN45RQ

On 18/12/2021 21:13, giuseppe@marullo.it wrote:

Giuseppe,

If you are considering something for "the rest of the company" you could save
yourself a lot of bother by getting something like the LeoNTP box:

http://www.leobodnar.com/shop/index.php?main_page=product_info&products_id=272

https://store.uputronics.com/index.php?route=product/category&path=70

It just sits there and works, and can serve many thousands of NTP clients.
Good luck in finding one, though, due to the current component shortage.

73,
David GM8ARV

SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv

Hi Perry,

fine.
Sure, 2ms still good IF it is 2ms.

Provided I was expecting way less than 1ms, if ntpstat is reliable I could
stop here.

One example, ms logs have 1ms "resolution" (short version, please bear with
me), not sure about accuracy and events may be logged out of order so no big
deal, 2ms is still plenty of precision.

its own sake, but from an engineering requirements point of view, you've
already succeeded.
Thanks, of course asking here is to improve but what is puzzling me is the
2ms value. Is it the actual accuracy?
Here it is another command output(ntptime):

ntp_gettime() returns code 0 (OK)
time e56974e6.38dfefc0  Sun, Dec 19 2021 10:07:50.222, (.222167714),
maximum error 6000 us, estimated error 0 us, TAI offset 37
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 0.347 us, frequency -12.253 ppm, interval 1 s,
maximum error 6000 us, estimated error 0 us,
status 0x2001 (PLL,NANO),
time constant 3, precision 0.001 us, tolerance 500 ppm,

I don't see 2ms accuracy, it seems better(0.347 us?).

time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an
email to time-nuts-leave@lists.febo.com To unsubscribe, go to and follow the
instructions there.

Hi David,

save yourself a lot of bother by getting something like the LeoNTP box:
I know Leobodnar stuff, mostly encoders for flight simulator's Garmin
navigator(https://www.thingiverse.com/thing:4019943).
Their GPSDO is well known option for O100 sat comms, it comes handy when you
need also  that 25MHz reference for improving stability of the LNB for
OSCAR100 ham sat transceivers.

Made of Unoubtanium, as almost any kind of item at the moment in Italy. From
bricks to cars, wait time is up to two years.

Anyway, given that I fear we don't have any NTP server at the moment(not to
mention no Stratum 1), I would end up to be responsible for its operation,
so a COTS solution is absolutely a good idea.

COTS
I would like something like one, for example (on backorder as everything):
https://www.netburner.com/products/network-time-server/pk70-ex-ntp-network-t
ime-server/

Probably we should implement NTPSec for a somewhat serious usage though.

I will fiddle in my lab with Raspberrys, leaving to ops the joy of being
responsible of the NTP infrastructure of the company.

We are aiming for ISO17025 accreditation, but we are involved in
cybersecurity, nominally for IoT, not for metrology or material testing.
Time accuracy is for records, documents and so on.

Of course, we need a small electronic bench with the usual stuff, like DSO,
DMM and the like, a good GPSDO is a must today, but we don't need periodic
calibration.
Hopefully any chinesium re-encased trimble should work for this.

Giuseppe Marullo
IW2JWW - JN45RQ

-----Original Message-----
From: David Taylor via time-nuts time-nuts@lists.febo.com
Sent: Sunday, December 19, 2021 6:40 AM
To: time-nuts@lists.febo.com
Cc: David Taylor david-taylor@blueyonder.co.uk
Subject: [time-nuts] Re: Poor's man NTP

On 18/12/2021 21:13, giuseppe@marullo.it wrote:

than milliseconds, PTP is a better approach.

requirements.

the rest of the company, if I will add other NTP/SecureNTP servers depending
on the load.

Giuseppe,

If you are considering something for "the rest of the company" you could
save yourself a lot of bother by getting something like the LeoNTP box:

http://www.leobodnar.com/shop/index.php?main_page=product_info&products_id=2
72

https://store.uputronics.com/index.php?route=product/category&path=70

It just sits there and works, and can serve many thousands of NTP clients.
Good luck in finding one, though, due to the current component shortage.

73,
David GM8ARV

SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv

time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an
email to time-nuts-leave@lists.febo.com To unsubscribe, go to and follow the
instructions there.

Hi

If you are talking about a “rest of the company” sort of thing,
it probably needs to be looked at carefully. Far better to not do
it than to do it and get in a tangle.

The NTP “server” is only one part of the error equation, even on
a local network. It may not be the largest contributor to the total
error “as delivered”. If you really are after 1 ms “for sure / all the
time" to a bunch of clients …. look at PTP.

A proper NTP setup will include at least three independent, accurate,
stable, reliable local servers.Since even numbers get voting processes
confused and even reliable stuff does break from time to time, five
independent servers is a good target to aim for.

Again, better to not do it than to get started and find it’s a project
that can’t be properly implemented.

Bob