Hello, I am Orlinum. Nice to meet you !
I have been operating NTP servers for many years. Currently, I run a Stratum 1 node powered by a Raspberry Pi 5 with a GPS/PPS reference clock (u-blox NEO-M9N). Real-time operational metrics are available on my public statistics page: https://time.orlinum.fr. I appreciate any feedback regarding this NTP server.
Have a good day.
Orlinum
The monitoring data looks good!
It might be interesting for you to fetch the monitoring data through the API (CSV or JSON data currently) and graph that against some of your other charts. It might be that your system is too accurate for the monitoring system to show anything interesting though.
Excellent server metrics! I hope I could have similar metrics but I am too lazy to set up a monitoring server to collect NTP activity data from my router which my LeoNTP server connects to. LeoNTP is an excellent high-volume server but it lacks reporting function.
Welcome to the club! Nice page you have. 
Hi,
Thank you for the feedback.
The proposition to fetch CSV/JSON data to compare internal hardware precision against external network latency is logically sound. I have not implemented it yet. I will test an asynchronous data collection method in the upcoming weeks.
Orlinum.
websdr.heppen.be nice too 
Wow you have a lot of extra lines to other servers.
You should not do this when having your own GPS+PPS (like you do) for 3 reasons:
You no not need more then 3-5 lines to verify
It’s considered abuse of servers by some operators
It uses needless CPU-cycles, not improving your accuracy.
Far away servers do not give you very accurate time because of path latency becoming less and less stable.
If you see then change a lot, means unstable path, ergo pretty useless line for you anyway.
Thank you for the feedback.
The excessive polling was a temporary telemetry phase designed to profile path latency and isolate the most reliable network sources for this location.
This metric collection is complete (for some time :-/). The configuration has been corrected and limited to most optimal servers.
Thank you.
Nicely done.
But your GPS is off too much, as such it won’t lock to the PPS signal, according to the manuals it should be less then 40ms.
Settings i use, and yes I added YOU to it 
refclock SHM 0 refid GPS poll 4 offset 0.083 delay 0.2
refclock SHM 1 refid PPS poll 4 precision 1e-10 maxlockage 64 lock GPS prefer
#You do need to talk to an NTP server or two (or three).
server time.fu-berlin.de minpoll 5 maxpoll 8
server time.antwerpspace.be minpoll 5 maxpoll 8
server ntp1.economie.fgov.be minpoll 5 maxpoll 8
server time1.esa.int minpoll 5 maxpoll 8
server time.orlinum.fr minpoll 5 maxpoll 8
giving me this:
root@server:~# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
GPS 15 8 224 +117.154 90.944 +16ms 6491us
PPS 16 7 239 -0.000 0.029 -1ns 1748ns
time.fu-berlin.de 14 10 56m +0.059 0.136 -1687us 112us
d54c70bd3.static.telenet> 21 10 86m +0.104 0.224 +397us 437us
mineco.fgov.be 15 8 60m +0.073 0.138 -1736us 141us
time1.esa.int 14 8 81m +0.151 0.106 -1527us 121us
82-64-42-185.subs.proxad> 17 14 68m +0.023 0.191 -1301us 199us
If you want to monitor my server, use ntp1.heppen.be it returns heppen.be in your list, as I have a PTR.
I learned before, do not poll the GPS/PPS too often as it has a buffer with many samples, if you poll too much, often the buffer can be empty as far as I understand it. So I stopped polling too much. GPS’ses have buffers and they can store a lot.
BTW, my stats are here: http://ntp1.heppen.be:90/
Thank you for the review and for adding my server to your peering list.
If you wish, I can provide a symmetric key for authenticated synchronization.
Accordig to the FAQ, the limit for PPS association in chrony is technically 200ms ( chronyd version < 4.1) or 400ms (chrony – Frequently Asked Questions), not 40ms. My configuration successfully locks the PPS with >50ms offset.
But, observing a higher value in the telemetry, I adjusted the offset …
For information, a part of chrony configuration :
refclock PPS /dev/pps0 lock GPS poll 2 filter 16 precision 1e-9 rate 1 width 0.5 maxlockage 10 prefer
## refclock SHM 0 refid GPS offset 0.075 noselect poll 3
refclock SHM 0 refid GPS offset 0.125 noselect poll 4
## FR - [UTC(OP)]
server ntp-p1.obspm.fr minpoll 6 iburst xleave
## DE - [UTC(PTB)]
server ptbtime4.ptb.de minpoll 6 iburst xleave
## UK - [UTC(NPL)]
server ntp1.npl.co.uk minpoll 6 iburst xleave
## USA - [UTC(NIST)]
server time.nist.gov minpoll 6 iburst xleave
## Bas Time server
server ntp1.heppen.be minpoll 6 iburst xleave
I have noted ntp1.heppen.be. i use your server now ! ( as the 6th source
For the pooling, my hardware architecture uses unidirectional serial transmission with only the TX GPS pin connected to the RX GPIO pin. The GNSS module broadcasts blindly per second. The system only reads the local buffer and cannot physically query the receiver. Therefore, buffer depletion from over-polling seems to be impossible in this setup. It is probably that your observation applies to USB-based GNSS receivers, where the USB bus layer and internal buffers can introduce such artifacts ?
Regarding the polling frequency and the buffer, I have empirically tested various polling intervals for the GPS via SHM and observed no adverse effects or buffer depletion issues.
For the PPS synchronization, empirical data proves that my current configuration yields the highest precision. Specifically, explicitly defining the pulse duration (width 0.5) in chrony, combined with a correctly configured 50% duty cycle on the GNSS receiver’s hardware output. This significantly increases the overall accuracy of the time measurement.
I have reviewed the telemetry link you provided. The operational metrics of your NTP is nice too !
A technical documentation detailing the engineering of this node, including CPU core isolation, strict interrupt affinity … is currently being written to document these architectural choices. it make some time …
Someone told me it was 40ms, looks like that person made a typo, as I never bothered to look it up, I assumed it was correct.
Ah ok, that’s sort of the same as with USB-ports.
That explains it, as I’m using native RS-232 port to get the data, it can tell the GPS to empty it’s buffers when needed.
Therefor it can store many samples and be read in one big stream rather then triggering-irq’s to the CPU constantly.
I seen you added my server, I like that