Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
Backgound:
I have a serial attached black box containing a GNSS receiver and a disciplined, temperature controlled oscillator which has a PPS accuracy
of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
1 ntp server with very good results.
I recently upgraded the OS to 24.04.1 and ntp went insane because it
appears that the latest release no longer supports the ppsapi.
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
The best ntpd server OS have traditionally always been FreeBSD, since
the time when phk was both a FreeBSD kernel hacker and member of the NTP Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a
disciplined, temperature controlled oscillator which has a PPS accuracy
of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
1 ntp server with very good results.
I recently upgraded the OS to 24.04.1 and ntp went insane because it
appears that the latest release no longer supports the ppsapi.
A long time ago, ppsapi was something that could either be part of the kernel, or a loadable module. Is this no longer the case?
Terje
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
The best ntpd server OS have traditionally always been FreeBSD, since
the time when phk was both a FreeBSD kernel hacker and member of the NTP
Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a
disciplined, temperature controlled oscillator which has a PPS accuracy
of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
1 ntp server with very good results.
I recently upgraded the OS to 24.04.1 and ntp went insane because it
appears that the latest release no longer supports the ppsapi.
A long time ago, ppsapi was something that could either be part of the
kernel, or a loadable module. Is this no longer the case?
I'm not sure exactly what is going on other than pps stopped working
after the upgrade. I have filed a bug report.
If it is not resolved quickly, I'm switching distros.
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server? >>>The best ntpd server OS have traditionally always been FreeBSD, since
the time when phk was both a FreeBSD kernel hacker and member of the NTP >>> Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a
disciplined, temperature controlled oscillator which has a PPS accuracy >>>> of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
That is an amazing claim, I have never personally seen any GPS-delivered
PPS signal much better than 10-20 ns RMS, and for that to also have
zero bias, you need to correct for the length and phase delay of the antenna, as well as the length of the PPS signal cable that delivers the time ticks to the kernel/ppsapi.
It is of course mostly moot since any sub-100 ns stratum 1 server is effectively perfect as seen from its clients.
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:That is an amazing claim, I have never personally seen any GPS-delivered
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server? >>>>The best ntpd server OS have traditionally always been FreeBSD, since
the time when phk was both a FreeBSD kernel hacker and member of the NTP >>>> Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a
disciplined, temperature controlled oscillator which has a PPS accuracy >>>>> of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum >>
PPS signal much better than 10-20 ns RMS, and for that to also have
zero bias, you need to correct for the length and phase delay of the
antenna, as well as the length of the PPS signal cable that delivers the
time ticks to the kernel/ppsapi.
It is NOT just a GNSS receiver, it is also a precision, disiplined
oscillator and takes a couple of days to stabilize to 1 ns.
The specs are for the connectors on the box.
The antenna cable length has no effect on the stabilized pps accuracy,
just the location accuracy which is a don't care for ntp.
https://www.ebay.com/itm/265090375590 for an example.
It is of course mostly moot since any sub-100 ns stratum 1 server is
effectively perfect as seen from its clients.
Since ntp really wants to see at least 3 sources, I have 2 of these
things on the local 100 Base-Tx network to keep this server sane.
https://www.ebay.com/itm/255114568844
ntp processing jitter limits the actual accuracy achievable. To get
better performance I could dump UNIX like os's and switch to a real-time operating system, but at this point what I have is good enough for what
I do.
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:That is an amazing claim, I have never personally seen any GPS-delivered >>> PPS signal much better than 10-20 ns RMS, and for that to also have
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server? >>>>>The best ntpd server OS have traditionally always been FreeBSD, since >>>>> the time when phk was both a FreeBSD kernel hacker and member of the NTP >>>>> Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a >>>>>> disciplined, temperature controlled oscillator which has a PPS accuracy >>>>>> of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum >>>
zero bias, you need to correct for the length and phase delay of the
antenna, as well as the length of the PPS signal cable that delivers the >>> time ticks to the kernel/ppsapi.
It is NOT just a GNSS receiver, it is also a precision, disiplined
oscillator and takes a couple of days to stabilize to 1 ns.
The specs are for the connectors on the box.
The antenna cable length has no effect on the stabilized pps accuracy,
just the location accuracy which is a don't care for ntp.
https://www.ebay.com/itm/265090375590 for an example.
That's extremely nice, thanks for the link.
Do you have specs for how close the delivered PPS signal is to the
actual UTC/TAI time? In most os these units with a 10 MHz output, the
PPS signal is delivered at the closest 10 MHz transistion, so giving a
+/- 50 ns skew.
In the Mototola Oncore, the serial stream includes an offset value, specifying how many ns (+/-) the PPS pulse is/was from the true time.
It is of course mostly moot since any sub-100 ns stratum 1 server is
effectively perfect as seen from its clients.
Since ntp really wants to see at least 3 sources, I have 2 of these
In my own setup I had 5 geographically separated S1 servers, 3 of them
using GPS, plus a Meinberg receiver close to the DCF77 transmitter
location in Germany which locked onto the pseudo-random jitter of that transmitter. This provided ~10-20 us accuracy.
Similarly, the S1 server in Tampa, FL used the US cell phone network to
get ~12 us precision.
On top of these S1 servers I had 6 S2 servers with a pair in each of the
3 main datacenters, all of these connected to every S1 server.
Finally, every NTP client machine was configured to use all (6) S2 servers.
things on the local 100 Base-Tx network to keep this server sane.
https://www.ebay.com/itm/255114568844
This is a nice box at an extremely good price, nothing like this was available 20+ years ago, unless you made it yourself.
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:That is an amazing claim, I have never personally seen any GPS-delivered
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server? >>>>The best ntpd server OS have traditionally always been FreeBSD, since
the time when phk was both a FreeBSD kernel hacker and member of the NTP >>>> Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a
disciplined, temperature controlled oscillator which has a PPS accuracy >>>>> of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum >>
PPS signal much better than 10-20 ns RMS, and for that to also have
zero bias, you need to correct for the length and phase delay of the
antenna, as well as the length of the PPS signal cable that delivers the
time ticks to the kernel/ppsapi.
It is NOT just a GNSS receiver, it is also a precision, disiplined
oscillator and takes a couple of days to stabilize to 1 ns.
The specs are for the connectors on the box.
The antenna cable length has no effect on the stabilized pps accuracy,
just the location accuracy which is a don't care for ntp.
https://www.ebay.com/itm/265090375590 for an example.
It is of course mostly moot since any sub-100 ns stratum 1 server is
effectively perfect as seen from its clients.
Since ntp really wants to see at least 3 sources, I have 2 of these
things on the local 100 Base-Tx network to keep this server sane.
https://www.ebay.com/itm/255114568844
ntp processing jitter limits the actual accuracy achievable. To get
better performance I could dump UNIX like os's and switch to a real-time operating system, but at this point what I have is good enough for what
I do.
I have found that the limitation is how the hardware and software
handles interrupts on the serial ports. PCI cards have software
interrupts with LOTS of jitter and are useless for achieving the
accuracy obtainable from this box. You need a legacy serial port
with hardware interrupts and an os with mimimal jitter in handling the interrupts.
If Ubuntu doesn't fix this soon I'll just go to bsd.
On 2024-09-03 22:53, Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:That is an amazing claim, I have never personally seen any GPS-delivered >>> PPS signal much better than 10-20 ns RMS, and for that to also have
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server? >>>>>The best ntpd server OS have traditionally always been FreeBSD, since >>>>> the time when phk was both a FreeBSD kernel hacker and member of the NTP >>>>> Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a >>>>>> disciplined, temperature controlled oscillator which has a PPS accuracy >>>>>> of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum >>>
zero bias, you need to correct for the length and phase delay of the
antenna, as well as the length of the PPS signal cable that delivers the >>> time ticks to the kernel/ppsapi.
It is NOT just a GNSS receiver, it is also a precision, disiplined
oscillator and takes a couple of days to stabilize to 1 ns.
The specs are for the connectors on the box.
The antenna cable length has no effect on the stabilized pps accuracy,
just the location accuracy which is a don't care for ntp.
Actually, the antenna cable will delay all the radio sources of time by
the cable length divided by the speed of light in copper, thus every
20cm of cable would make the time measurements at the other end of that antenna cable late by 1ns more than if the cable length was zero. This
is the kind of problem the offset fudge in ntp.conf is meant to correct.
All current GNSS systems are essentially time stamp broadcasts where the receiver then uses trigonometry to eliminate the speed of light in air
and vacuum delay from transmitters to antenna, however this correction
cannot measure or correct the common delay in the shared antenna cable,
nor the minimum of delays through multiple antenna cables from antennas
with well defined mutual distances.
On 2024-09-04, Jim Pennino <jimp@gonzo.specsol.net> wrote:
I have found that the limitation is how the hardware and software
handles interrupts on the serial ports. PCI cards have software
interrupts with LOTS of jitter and are useless for achieving the
accuracy obtainable from this box. You need a legacy serial port
with hardware interrupts and an os with mimimal jitter in handling the
interrupts.
For sub-microsecond accuracy you need to avoid interrupts in the timing
path completely. That means hardware timestamping. The cheapest way to
do that is connecting the PPS signal to one of the SDPs on the I210
network card.
If Ubuntu doesn't fix this soon I'll just go to bsd.
You will need to build your own kernel if you need the kernel PPS
discipline. No Linux distro that I know of has this feature enabled,
because it conflicts with the tickless mode.
Jakob Bohm <jb-usenet@wisemo.invalid> wrote:
On 2024-09-03 22:53, Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
The best ntpd server OS have traditionally always been FreeBSD, since >>>>>> the time when phk was both a FreeBSD kernel hacker and member of the NTP >>>>>> Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a >>>>>>> disciplined, temperature controlled oscillator which has a PPS accuracy >>>>>>> of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
That is an amazing claim, I have never personally seen any GPS-delivered >>>> PPS signal much better than 10-20 ns RMS, and for that to also have >>>> zero bias, you need to correct for the length and phase delay of the
antenna, as well as the length of the PPS signal cable that delivers the >>>> time ticks to the kernel/ppsapi.
It is NOT just a GNSS receiver, it is also a precision, disiplined
oscillator and takes a couple of days to stabilize to 1 ns.
The specs are for the connectors on the box.
The antenna cable length has no effect on the stabilized pps accuracy,
just the location accuracy which is a don't care for ntp.
Actually, the antenna cable will delay all the radio sources of time by
the cable length divided by the speed of light in copper, thus every
20cm of cable would make the time measurements at the other end of that
antenna cable late by 1ns more than if the cable length was zero. This
is the kind of problem the offset fudge in ntp.conf is meant to correct.
All current GNSS systems are essentially time stamp broadcasts where the
receiver then uses trigonometry to eliminate the speed of light in air
and vacuum delay from transmitters to antenna, however this correction
cannot measure or correct the common delay in the shared antenna cable,
nor the minimum of delays through multiple antenna cables from antennas
with well defined mutual distances.
Which when all is said and done shows up as a constant offset which is
why you need at least two more sources of time and offset fudge.
However it will take heroic efforts to get processing jitter down to fractions of a millisecond, so it is a don't care.
Jim Pennino wrote:
Jakob Bohm <jb-usenet@wisemo.invalid> wrote:
On 2024-09-03 22:53, Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
The best ntpd server OS have traditionally always been FreeBSD, since >>>>>>> the time when phk was both a FreeBSD kernel hacker and member of the NTP
Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a >>>>>>>> disciplined, temperature controlled oscillator which has a PPS accuracy
of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
That is an amazing claim, I have never personally seen any GPS-delivered >>>>> PPS signal much better than 10-20 ns RMS, and for that to also have >>>>> zero bias, you need to correct for the length and phase delay of the >>>>> antenna, as well as the length of the PPS signal cable that delivers the >>>>> time ticks to the kernel/ppsapi.
It is NOT just a GNSS receiver, it is also a precision, disiplined
oscillator and takes a couple of days to stabilize to 1 ns.
The specs are for the connectors on the box.
The antenna cable length has no effect on the stabilized pps accuracy, >>>> just the location accuracy which is a don't care for ntp.
Actually, the antenna cable will delay all the radio sources of time by
the cable length divided by the speed of light in copper, thus every
20cm of cable would make the time measurements at the other end of that
antenna cable late by 1ns more than if the cable length was zero. This
is the kind of problem the offset fudge in ntp.conf is meant to correct. >>>
All current GNSS systems are essentially time stamp broadcasts where the >>> receiver then uses trigonometry to eliminate the speed of light in air
and vacuum delay from transmitters to antenna, however this correction
cannot measure or correct the common delay in the shared antenna cable,
nor the minimum of delays through multiple antenna cables from antennas
with well defined mutual distances.
Which when all is said and done shows up as a constant offset which is
why you need at least two more sources of time and offset fudge.
However it will take heroic efforts to get processing jitter down to
fractions of a millisecond, so it is a don't care.
Rather the opposite: Way back in 1995, in the Pentium days, we had just gotten the RDTSC time stamp counter which allowed close to zero-cost fractional microsecond timestamps, the CPU frequency was constant (no scaling or spread spectrum), and IRQ latency was close to constant.
Under those circumstances it was _easy_ to sync systems within the same
WAN area to the sub-100 us range, with sub-10 typically what we saw.
Way back in 1982 I wrote my first hw interrupt driver, to handle serial
port RS232 traffic on 4.77 MHz 8088 PCs, something I could do reliably
at 19200 baud, i.e. sub-0.5 ms total response time, since otherwise the single-byte receive buffer got overwritten by the next character.
Spool forward 10-15 years to where the CPU frequency had improved by
~20x and cycles per instruction by 4-5x and you see that getting close
to 1 us is doable.
Terje
Miroslav Lichvar <mlichvar@redhat.com> wrote:
You will need to build your own kernel if you need the kernel PPS
discipline. No Linux distro that I know of has this feature enabled,
because it conflicts with the tickless mode.
I was referring to kernal support for the ability to process the PPS
signal at all, as in:
Actually, the antenna cable will delay all the radio sources of time by
the cable length divided by the speed of light in copper,
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Jakob Bohm <jb-usenet@wisemo.invalid> wrote:
On 2024-09-03 22:53, Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
The best ntpd server OS have traditionally always been FreeBSD, since >>>>>>>> the time when phk was both a FreeBSD kernel hacker and member of the NTP
Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a >>>>>>>>> disciplined, temperature controlled oscillator which has a PPS accuracy
of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
That is an amazing claim, I have never personally seen any GPS-delivered >>>>>> PPS signal much better than 10-20 ns RMS, and for that to also have >>>>>> zero bias, you need to correct for the length and phase delay of the >>>>>> antenna, as well as the length of the PPS signal cable that delivers the >>>>>> time ticks to the kernel/ppsapi.
It is NOT just a GNSS receiver, it is also a precision, disiplined
oscillator and takes a couple of days to stabilize to 1 ns.
The specs are for the connectors on the box.
The antenna cable length has no effect on the stabilized pps accuracy, >>>>> just the location accuracy which is a don't care for ntp.
Actually, the antenna cable will delay all the radio sources of time by >>>> the cable length divided by the speed of light in copper, thus every
20cm of cable would make the time measurements at the other end of that >>>> antenna cable late by 1ns more than if the cable length was zero. This >>>> is the kind of problem the offset fudge in ntp.conf is meant to correct. >>>>
All current GNSS systems are essentially time stamp broadcasts where the >>>> receiver then uses trigonometry to eliminate the speed of light in air >>>> and vacuum delay from transmitters to antenna, however this correction >>>> cannot measure or correct the common delay in the shared antenna cable, >>>> nor the minimum of delays through multiple antenna cables from antennas >>>> with well defined mutual distances.
Which when all is said and done shows up as a constant offset which is
why you need at least two more sources of time and offset fudge.
However it will take heroic efforts to get processing jitter down to
fractions of a millisecond, so it is a don't care.
Rather the opposite: Way back in 1995, in the Pentium days, we had just
gotten the RDTSC time stamp counter which allowed close to zero-cost
fractional microsecond timestamps, the CPU frequency was constant (no
scaling or spread spectrum), and IRQ latency was close to constant.
Under those circumstances it was _easy_ to sync systems within the same
WAN area to the sub-100 us range, with sub-10 typically what we saw.
Way back in 1982 I wrote my first hw interrupt driver, to handle serial
port RS232 traffic on 4.77 MHz 8088 PCs, something I could do reliably
at 19200 baud, i.e. sub-0.5 ms total response time, since otherwise the
single-byte receive buffer got overwritten by the next character.
Spool forward 10-15 years to where the CPU frequency had improved by
~20x and cycles per instruction by 4-5x and you see that getting close
to 1 us is doable.
Terje
My experience with today's PC hardware and software says good luck
getting offset jitter to under 1 us.
I have no desire to build either custom hardware or software.
One thing you are missing is software bloat over the years. On the
system where this box is attached, the os is a minimal install and has
at any time ~200 processes running on 4 2.41GHz cores.
I also have a Raspberry Pi 4 with a late GNSS hat running as a stratum 1 server whose statistics I graph. Most of the time the jitter in the
offset is in the ~200 us range, but when it is doing something it goes
to over 1.5 ms.
On 2024-09-05, Jim Pennino <jimp@gonzo.specsol.net> wrote:
Miroslav Lichvar <mlichvar@redhat.com> wrote:
You will need to build your own kernel if you need the kernel PPS
discipline. No Linux distro that I know of has this feature enabled,
because it conflicts with the tickless mode.
I was referring to kernal support for the ability to process the PPS
signal at all, as in:
Did you disable flag3 (kernel PPS discipline) for in your configuration?
By upgrading Ubuntu from 22.04 to 24.04 you switched from ntp to ntpsec.
ntp falls back to non-hardpps mode when the kernel does not support it. ntpsec does not.
On 05/09/2024 04:01, Jakob Bohm wrote:
Actually, the antenna cable will delay all the radio sources of time by
the cable length divided by the speed of light in copper,
The speed of light in polyethylene might be more accurate, as the signal propagates in the dielectric, not in the conductor. It's more
complicated than that, as you are also dealing with a waveguide, so I
think that even an air dielectric cable has a velocity factor less than
1 (.93 for one example, in Wikipedia.)
Velocity factor is also frequency dependent, so we are really talking
about the velocity factor in the low GHz range.
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
Backgound:
I have a serial attached black box containing a GNSS receiver and a disciplined, temperature controlled oscillator which has a PPS accuracy
of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
1 ntp server with very good results.
I recently upgraded the OS to 24.04.1 and ntp went insane because it
appears that the latest release no longer supports the ppsapi.
Now ntpq shows:I may be wrong, but PPS won't be supported until at least one other server has been locked (has a good enough reach), so here as the NMEA has zero reach the PPS won't be used (status is "x").
NMEA(0) .GPS. 0 l - 16 0 0.0000 0.0000 1.9531
xPPS(0) .PPS. 0 l 26 64 377 0.0000 -0.2407 0.1137
Yes, there is NMEA data at 9600 baud.
On 14/09/2024 00:08, Jim Pennino wrote:
Now ntpq shows:
NMEA(0) .GPS. 0 l - 16 0 0.0000 0.0000 1.9531
xPPS(0) .PPS. 0 l 26 64 377 0.0000 -0.2407 0.1137
Yes, there is NMEA data at 9600 baud.
I may be wrong, but PPS won't be supported until at least one other server has
been locked (has a good enough reach), so here as the NMEA has zero reach the PPS won't be used (status is "x").
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
The best ntpd server OS have traditionally always been FreeBSD, since
the time when phk was both a FreeBSD kernel hacker and member of the NTP Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a
disciplined, temperature controlled oscillator which has a PPS accuracy
of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
1 ntp server with very good results.
I recently upgraded the OS to 24.04.1 and ntp went insane because it
appears that the latest release no longer supports the ppsapi.
A long time ago, ppsapi was something that could either be part of the kernel, or a loadable module. Is this no longer the case?
Terje
[-- text/plain, encoding base64, charset: UTF-8, 12 lines --]
This thread triggered a question that may, or may not be related and relevant:
Ubuntu offers a 'lowlatency'-kernel and I have always wondered if that
would make sense for improving the precision of an NTP server.
Opinions?
wrote:
"\"Marco Davids (SIDN)\" via questions Mailing List" < questions@lists.ntp.org> wrote:
[-- text/plain, encoding base64, charset: UTF-8, 12 lines --]
This thread triggered a question that may, or may not be related and relevant:
Ubuntu offers a 'lowlatency'-kernel and I have always wondered if that would make sense for improving the precision of an NTP server.
Opinions?
I have been using the lowlatency kernel for a year or two now. It did
reduce jitter noticeably when I made the switch, but I do not remember
what the numbers were.
From the plot of the clock offset, the amplitude of the jitter is about
3 microseconds.
This is for a source that has a temperature controlled and disciplined oscillator with a PPS specificaion of +/- 1 nanosecond.
From the plot of the clock offset, the amplitude of the jitter is about<br>3 microseconds.<br>
[-- text/plain, encoding quoted-printable, charset: UTF-8, 38 lines --]
I have been using the Standard Raspberry Pi distro along with the Adafruit GPS hat and it works great. If you want, I could send you instructions on how to set this up
Chip
On Thu, Sep 26, 2024 at 11:06 AM Jim Pennino <jimp@gonzo.specsol.net> wrote:
"\"Marco Davids (SIDN)\" via questions Mailing List" <
questions@lists.ntp.org> wrote:
[-- text/plain, encoding base64, charset: UTF-8, 12 lines --]
This thread triggered a question that may, or may not be related and
relevant:
Ubuntu offers a 'lowlatency'-kernel and I have always wondered if that
would make sense for improving the precision of an NTP server.
Opinions?
I have been using the lowlatency kernel for a year or two now. It did
reduce jitter noticeably when I made the switch, but I do not remember
what the numbers were.
From the plot of the clock offset, the amplitude of the jitter is about
3 microseconds.
This is for a source that has a temperature controlled and disciplined
oscillator with a PPS specificaion of +/- 1 nanosecond.
However it will take heroic efforts to get processing jitter down to fractions of a millisecond, so it is a don't care.
On 9/5/24 14:07, Jim Pennino wrote:
However it will take heroic efforts to get processing jitter down to
fractions of a millisecond, so it is a don't care.
Don't find that to be the case at all. Not a particularly complex
setup here, Freebsd os, 1pps into the dcd line on the serial port,
and consistently get offsets in the 1-2 microsecond range and jitter
of the same, 1-2 microseconds. Need to make sure the dcd pulse
polarity is set correctly in ntp setup, positive or negative going
edge.
Don't worry too much about antenna cable delay either, which is
in the low nanosecond range, irrelevant to the 1-2 microsecond
offset ntp values. Several orders of magnitiude difference.
Perhaps you are using the wrong os for the job, or perhaps real
time preemptive mode is not enabled, or even available ?.
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Jakob Bohm <jb-usenet@wisemo.invalid> wrote:
On 2024-09-03 22:53, Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
The best ntpd server OS have traditionally always been FreeBSD, since >>>>>>>> the time when phk was both a FreeBSD kernel hacker and member of the NTP
Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a >>>>>>>>> disciplined, temperature controlled oscillator which has a PPS accuracy
of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
That is an amazing claim, I have never personally seen any GPS-delivered >>>>>> PPS signal much better than 10-20 ns RMS, and for that to also have >>>>>> zero bias, you need to correct for the length and phase delay of the >>>>>> antenna, as well as the length of the PPS signal cable that delivers the >>>>>> time ticks to the kernel/ppsapi.
It is NOT just a GNSS receiver, it is also a precision, disiplined
oscillator and takes a couple of days to stabilize to 1 ns.
The specs are for the connectors on the box.
The antenna cable length has no effect on the stabilized pps accuracy, >>>>> just the location accuracy which is a don't care for ntp.
Actually, the antenna cable will delay all the radio sources of time by >>>> the cable length divided by the speed of light in copper, thus every
20cm of cable would make the time measurements at the other end of that >>>> antenna cable late by 1ns more than if the cable length was zero. This >>>> is the kind of problem the offset fudge in ntp.conf is meant to correct. >>>>
All current GNSS systems are essentially time stamp broadcasts where the >>>> receiver then uses trigonometry to eliminate the speed of light in air >>>> and vacuum delay from transmitters to antenna, however this correction >>>> cannot measure or correct the common delay in the shared antenna cable, >>>> nor the minimum of delays through multiple antenna cables from antennas >>>> with well defined mutual distances.
Which when all is said and done shows up as a constant offset which is
why you need at least two more sources of time and offset fudge.
However it will take heroic efforts to get processing jitter down to
fractions of a millisecond, so it is a don't care.
Rather the opposite: Way back in 1995, in the Pentium days, we had just
gotten the RDTSC time stamp counter which allowed close to zero-cost
fractional microsecond timestamps, the CPU frequency was constant (no
scaling or spread spectrum), and IRQ latency was close to constant.
Under those circumstances it was _easy_ to sync systems within the same
WAN area to the sub-100 us range, with sub-10 typically what we saw.
Way back in 1982 I wrote my first hw interrupt driver, to handle serial
port RS232 traffic on 4.77 MHz 8088 PCs, something I could do reliably
at 19200 baud, i.e. sub-0.5 ms total response time, since otherwise the
single-byte receive buffer got overwritten by the next character.
Spool forward 10-15 years to where the CPU frequency had improved by
~20x and cycles per instruction by 4-5x and you see that getting close
to 1 us is doable.
Terje
My experience with today's PC hardware and software says good luck
getting offset jitter to under 1 us.
I have no desire to build either custom hardware or software.
One thing you are missing is software bloat over the years. On the
system where this box is attached, the os is a minimal install and has
at any time ~200 processes running on 4 2.41GHz cores.
I also have a Raspberry Pi 4 with a late GNSS hat running as a stratum 1 server whose statistics I graph. Most of the time the jitter in the
offset is in the ~200 us range, but when it is doing something it goes
to over 1.5 ms.
On 9/5/2024 8:28 PM, Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Jakob Bohm <jb-usenet@wisemo.invalid> wrote:
On 2024-09-03 22:53, Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
Jim Pennino wrote:
Anyone have a suggestion for a GOOD linux distro for a stratum 1 server?
The best ntpd server OS have traditionally always been FreeBSD, since >>>>>>>>> the time when phk was both a FreeBSD kernel hacker and member of the NTP
Hackers group.
Backgound:
I have a serial attached black box containing a GNSS receiver and a >>>>>>>>>> disciplined, temperature controlled oscillator which has a PPS accuracy
of +/- 1 nanosecond I have been using for years with Ubuntu as a stratum
That is an amazing claim, I have never personally seen any GPS-delivered
PPS signal much better than 10-20 ns RMS, and for that to also have >>>>>>> zero bias, you need to correct for the length and phase delay of the >>>>>>> antenna, as well as the length of the PPS signal cable that delivers the
time ticks to the kernel/ppsapi.
It is NOT just a GNSS receiver, it is also a precision, disiplined >>>>>> oscillator and takes a couple of days to stabilize to 1 ns.
The specs are for the connectors on the box.
The antenna cable length has no effect on the stabilized pps accuracy, >>>>>> just the location accuracy which is a don't care for ntp.
Actually, the antenna cable will delay all the radio sources of time by >>>>> the cable length divided by the speed of light in copper, thus every >>>>> 20cm of cable would make the time measurements at the other end of that >>>>> antenna cable late by 1ns more than if the cable length was zero. This >>>>> is the kind of problem the offset fudge in ntp.conf is meant to correct. >>>>>
All current GNSS systems are essentially time stamp broadcasts where the >>>>> receiver then uses trigonometry to eliminate the speed of light in air >>>>> and vacuum delay from transmitters to antenna, however this correction >>>>> cannot measure or correct the common delay in the shared antenna cable, >>>>> nor the minimum of delays through multiple antenna cables from antennas >>>>> with well defined mutual distances.
Which when all is said and done shows up as a constant offset which is >>>> why you need at least two more sources of time and offset fudge.
However it will take heroic efforts to get processing jitter down to
fractions of a millisecond, so it is a don't care.
Rather the opposite: Way back in 1995, in the Pentium days, we had just
gotten the RDTSC time stamp counter which allowed close to zero-cost
fractional microsecond timestamps, the CPU frequency was constant (no
scaling or spread spectrum), and IRQ latency was close to constant.
Under those circumstances it was _easy_ to sync systems within the same
WAN area to the sub-100 us range, with sub-10 typically what we saw.
Way back in 1982 I wrote my first hw interrupt driver, to handle serial
port RS232 traffic on 4.77 MHz 8088 PCs, something I could do reliably
at 19200 baud, i.e. sub-0.5 ms total response time, since otherwise the
single-byte receive buffer got overwritten by the next character.
Spool forward 10-15 years to where the CPU frequency had improved by
~20x and cycles per instruction by 4-5x and you see that getting close
to 1 us is doable.
Terje
My experience with today's PC hardware and software says good luck
getting offset jitter to under 1 us.
The approach I have been looking at for such tasks is to use a hardware
time counter running at around 1 GHz with a hardware mechanism to
capture the counter value (undisciplined timestamp) when the PPS signal arrives. Such hardware is included in some Texas Instruments SoCs, such
as the AM3358B used on the open hardware BeagleBone cards . On this particular hardware, config data tells the SoC to use a particular GPIO
pin in this way . Same SoC (but not the BeagleBone card) supports
syncing this to the Ethernet hardware time stamping / sync mechanism on
one of the Gigabit ports .
One needs simply adjust kernel defines and drivers such that the chosen hardware counter register plus a disciplined factor and offset becomes
the definition of the kernel realtime clock, the PPS interrupt handler
then just needs to read back the hardware captured timestamp before it
wraps after 4 seconds, then apply the factor and offset active at the captured time to produce a time value returned via the PPS ioctl
to ntpd, which will then issue syscalls to adjust the kernel clock speed
and time (by changing the factor and offset effective at the time of the adjustment call).
If (as on that SoC), the hardware counter is only 32 bits, one also
needs to chain an overflow counter to the hardware nanosecond counter, possibly via a small bit of code that checks for timer wrap every about
2 seconds and whenever something reads the time for actual use. Some of
that logic may already be in OS kernels as part of a generic mechanism
for using such a hardware time register .
Using the above idea, ntpd should be able to discipline the kernel timer
(aka the adjusted scale/offset) to get closer to the jitter of the the
used 1GHz system clock, limited by PPS pin I/O buffering granularity
inside the chip .
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 997 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 220:13:09 |
| Calls: | 13,045 |
| Files: | 186,574 |
| Messages: | 3,292,560 |