Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
On Mon, Oct 19, 2020 at 12:43:47PM +0200, Vitezslav Samel wrote: > On Mon, Oct 19, 2020 at 09:49:36AM +0200, Miroslav Lichvar wrote: > > Not an FPGA, but the Intel I210 costs about $50 and it has a nice > > hardware clock with PPS input/output, which is well supported in > > Linux. It's a NIC, so you can use the same clock for timestamping PPS > > and NTP packets, avoiding any asymmetries on the PCIe bus between the > > PPS-timestamping hardware, CPU, and the NIC, which allows you to make > > an NTP server accurate to few tens of nanoseconds. > > Any pointers/info how to use this in Linux? In the Linux kernel source there is a testptp utility in the tools/testing/selftests/ptp directory, which can enable the PPS input and/or output and print the captured timestamps. For configuring NTP (chrony), see this blog post from Dan Drown: https://blog.dan.drown.org/apu2-ntp-server-2/ Note that he uses an onboard variant of the NIC, which doesn't have a pin header for the SDP and requires some soldering, but that's not an issue with the I210: http://linuxptp.sourceforge.net/i210/i210-SDPs.jpg With the described configuration there is some extra jitter in NTP timestamps due to the system clock being used as the main clock. If you wanted to avoid that to improve stability, you would need to patch chronyd to serve time directly from the hardware clock. Let me know if you want more details. If you just want to synchronize the hardware clock to its PPS input, or you want to provide a PTP service with ptp4l, in the linuxptp package there is a ts2phc program for that. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
done by David Taylor at www.satsignal.eu <http://www.satsignal.eu> and appears here: https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html <https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html> and elsewhere on the satsignal.eu website. David has found one GPS chip that appears to produce really remarkable results. M = Misra, P. and P. Enge (2012). Global Positioning System: Signals, Measurements and Performance. Lincoln, Massachusetts, USA, Ganga-Jamuna Press. Charles Elliott Original Message questions [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of Miroslav Lichvar Sent: Monday, October 19, 2020 3:50 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter On Thu, Oct 15, 2020 at 07:52:06AM +0200, Juergen Perlinger wrote: Another thing that gets into the way are the energy saving strategies modern CPUs employ, like reducing the clock speed and distribute load over cores. So unless you nail down the IRQ to a certain core and prevent cores from going to full sleep, the interrupt rescheduling can add another few usecs. IRQ processing was never a high speed thing on x86 platforms to start with, and it never kept up with speed boost all other parts of the architecture got, AFAIK. Setting the CPU to a fixed frequency (e.g. using the userspace governor) can help a lot with the stability of timestamping, not just of the PPS signal, but also received NTP packets. In short, your numbers look familiar, and I don't know how to improve the much without dedicated hardware. I'm dreaming of some FPGA hardware on a PCIe board at an affordable price... Not an FPGA, but the Intel I210 costs about $50 and it has a nice hardware clock with PPS input/output, which is well supported in Linux. It's a NIC, so you can use the same clock for timestamping PPS and NTP packets, avoiding any asymmetries on the PCIe bus between the PPS-timestamping hardware, CPU, and the NIC, which allows you to make an NTP server accurate to few tens of nanoseconds. -- Miroslav Lichvar ___ questions mailing list <mailto:questions@lists.ntp.org> questions@lists.ntp.org <http://lists.ntp.org/listinfo/questions> http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
On Mon, Oct 19, 2020 at 09:49:36AM +0200, Miroslav Lichvar wrote: > On Thu, Oct 15, 2020 at 07:52:06AM +0200, Juergen Perlinger wrote: > > Another thing that gets into the way are the energy saving strategies > > modern CPUs employ, like reducing the clock speed and distribute load > > over cores. So unless you nail down the IRQ to a certain core and > > prevent cores from going to full sleep, the interrupt rescheduling can > > add another few usecs. IRQ processing was never a high speed thing on > > x86 platforms to start with, and it never kept up with speed boost all > > other parts of the architecture got, AFAIK. > > Setting the CPU to a fixed frequency (e.g. using the userspace > governor) can help a lot with the stability of timestamping, not just > of the PPS signal, but also received NTP packets. > > > In short, your numbers look familiar, and I don't know how to improve > > the much without dedicated hardware. I'm dreaming of some FPGA hardware > > on a PCIe board at an affordable price... > > Not an FPGA, but the Intel I210 costs about $50 and it has a nice > hardware clock with PPS input/output, which is well supported in > Linux. It's a NIC, so you can use the same clock for timestamping PPS > and NTP packets, avoiding any asymmetries on the PCIe bus between the > PPS-timestamping hardware, CPU, and the NIC, which allows you to make > an NTP server accurate to few tens of nanoseconds. Any pointers/info how to use this in Linux? Thanks, Vita ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
Hello: The original question was what realistic performance can one expect from GPS PPS. Based on some reading I did over the weekend here is a definitive answer: The 2001 SPS (standard, civilian signal, GPS in the United States) timing standard was 40 ns with 30 ns accuracy commonly observed. (M & E, p. 49). Time and distance are related with GPS (see M, p. 23), and good differential GPS (DGPS) is supposed to yield approximately 10 times the distance accuracy of the above specification, which implies one should be able to achieve 3-4 ns accuracy with GPS timing. The FAA's Wide Area Augmentation System (WAAS) is supposed to produce 2 m accuracy throughout the United States. This would imply approximately 8 ns to 6 ns time accuracy. Of course, you need a recently manufactured chip to pick up DGPS and WAAS. In addition, most GPS chips require that commands be sent to them to activate the GPS and WAAS. These commands are available in recent NMEA manuals published by chip manufacturers that you can find by googling for them. The 15-year-old GPS chip that I own constantly slips into an out of DGPS mode, which implies that the command to activate DGPS must be resent to the GPS chip periodically. The equation that the GPS chip solves every second has four unknowns: the receiver position in three dimensions and time. This implies that to solve this equation definitively four satellites must be in view. However if more than four satellites are in view the equation is over-determined and the fix is obtained by least-squares regression, which yields maximum likelihood predictors for the four variables. These predictors are much, much more accurate than the simple solution of the equation. A recent chip that picks up American GPS satellites, the Russian GLONASS satellites, and the European Galileo satellites should produce far better results than an older chip. My $40 Alcatel model A503DL Android phone commonly claims to have 19 or more satellites in view. The GPS fix changes as satellites slip into, or out of, view. Consequently one can observe jumps in time either forward or backward. Not to belabor the obvious, but time is monotonically increasing. So any jumps in time of more or less than about a positive second should be ignored. The American GPS system has two new signals (L2C and L5) which will greatly improve accuracy when they are fully operational. They are being phased in as older satellites are replenished with new models. L2C first began to appear in 2005 and L5 in 2010. Both are available now, but in a pre-operational stage so that one uses them at their own risk. A summary of the signals and their availability appears here: https://www.gps.gov/systems/gps/modernization/civilsignals/. The best published work on GPS accuracy and NTPD was done by David Taylor at www.satsignal.eu <http://www.satsignal.eu> and appears here: https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html <https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html> and elsewhere on the satsignal.eu website. David has found one GPS chip that appears to produce really remarkable results. M = Misra, P. and P. Enge (2012). Global Positioning System: Signals, Measurements and Performance. Lincoln, Massachusetts, USA, Ganga-Jamuna Press. Charles Elliott Original Message questions [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of Miroslav Lichvar Sent: Monday, October 19, 2020 3:50 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter On Thu, Oct 15, 2020 at 07:52:06AM +0200, Juergen Perlinger wrote: > Another thing that gets into the way are the energy saving strategies > modern CPUs employ, like reducing the clock speed and distribute load > over cores. So unless you nail down the IRQ to a certain core and > prevent cores from going to full sleep, the interrupt rescheduling can > add another few usecs. IRQ processing was never a high speed thing on > x86 platforms to start with, and it never kept up with speed boost all > other parts of the architecture got, AFAIK. Setting the CPU to a fixed frequency (e.g. using the userspace governor) can help a lot with the stability of timestamping, not just of the PPS signal, but also received NTP packets. > In short, your numbers look familiar, and I don't know how to improve > the much without dedicated hardware. I'm dreaming of some FPGA > hardware on a PCIe board at an affordable price... Not an FPGA, but the Intel I210 costs about $50 and it has a nice hardware clock with PPS input/output, which is well supported in Linux. It's a NIC, so you can use the same clock for timestamping PPS and NTP packets, avoiding any asymmetries on the PCIe bus between t
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
On Thu, Oct 15, 2020 at 07:52:06AM +0200, Juergen Perlinger wrote: > Another thing that gets into the way are the energy saving strategies > modern CPUs employ, like reducing the clock speed and distribute load > over cores. So unless you nail down the IRQ to a certain core and > prevent cores from going to full sleep, the interrupt rescheduling can > add another few usecs. IRQ processing was never a high speed thing on > x86 platforms to start with, and it never kept up with speed boost all > other parts of the architecture got, AFAIK. Setting the CPU to a fixed frequency (e.g. using the userspace governor) can help a lot with the stability of timestamping, not just of the PPS signal, but also received NTP packets. > In short, your numbers look familiar, and I don't know how to improve > the much without dedicated hardware. I'm dreaming of some FPGA hardware > on a PCIe board at an affordable price... Not an FPGA, but the Intel I210 costs about $50 and it has a nice hardware clock with PPS input/output, which is well supported in Linux. It's a NIC, so you can use the same clock for timestamping PPS and NTP packets, avoiding any asymmetries on the PCIe bus between the PPS-timestamping hardware, CPU, and the NIC, which allows you to make an NTP server accurate to few tens of nanoseconds. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
Hello Matt, On 10/15/20 7:24 PM, Matt Corallo wrote: > I was wondering about this too, so sat down and patched kernel to pull > timestamps right after the interrupt fires and then decide later if it > was because of DCD change (passing the timestamp through the dcd_change > callback, its a pretty trivial patch). It cut the jitter down some (a > few us, maybe) and killed some peaks, but clearly wasn't the source of > most of the jitter here, at least on an embedded AMD box with other > things to do between interrupts and a relatively poor system clock. I do > already get better than 10us jitter, however, closer to maybe 5. IMHO you won't get much better on a PC. 5µs is probably very close to the IRQ response jitter. And an ordinary rs232 level shifter for the PPS signal adds probably another µsec or two to the jitter -- high-quality PPS signal distribution/transmission needs coax cable and analog line drivers with impedance matching. I'm not nerdy enough to attempt this :) But then, even a very good PPS line does not help without a hardware counter capture register, because the IRQ response delay will be the major contribution to the jitter. But if you could share your UART code mods, that would make an interesting reading. If I only had more time... Pearly > Matt > > On 10/15/20 1:52 AM, Juergen Perlinger wrote: >> On 10/7/20 8:45 PM, Andreas Mattheiss wrote: >>> Hello, >>> >>> I wonder what's a realistic ballpark for the jitter I can expect when >>> feeding a GPS PPS into ntpd? >>> >>> My setup is: a cheap u-blox NEO6M has its PPS output connected to a >>> MAX232 >>> level shifter, connected to a true serial port on my desktop PC. I >>> use it >>> at the same time for daily work, so no designated ntp server. The GPS >>> antenna is sitting inside, close to the window, with a building >>> opposite - >>> suboptimal view of the sky. I do feed RTMS corrections to the GPS though >>> (ionospheric corrections etc.). The GPS is set to "stationary" mode, so >>> it's probably set up as good as it gets. >>> >>> The jitter values I get do, sorry, jitter. I guess it's a lot to do with >>> the poor view to the sky, mainly. PPS from GPS is claimed to be accurate >>> to say 10's of ns; my jiitter values are around 10 micro s >>> approximately, >>> on avarege, for a well settled system set up as described. They do zoom >>> up, occasionally, to 60 micro s though. I would assume that it's >>> unrealistic to expect ns accuracy from ntpd on a non-designated system. >>> >>> What do you think, is my 10 micro jitter within experience? While I am >>> writing this I just realised a post from David Taylor >>> () showing >>> >>> remote refid st t when poll reach delay offset >>> jitter >>> == >>> >>> o127.127.22.1 .uPPS. 0 l - 16 377 0.000 0.026 >>> 0.013 >>> >> >> That's quite close to what I get -- either with a GPS18xLVC, or a >> NEO-M8T (also homegrown, with a MAX-3232 TTL<->RS232 shifter) >> >> I had better numbers (half the jitter) with my old Phenom-II box, but >> with the XEON board I'm running now I see jitter in the 10usec range. >> With both receivers active at the same time, I have a higher jitter -- >> clearly interrupt collision, and the jitter occasionally bumps up to >> 20..30 usec, and the offset between the receivers (which is ~20usec) >> reverses then. >> >> I looked into the UART code of the Linux kernel (not _too_ deep) but >> it's clear that the handling of the DCD signal change and the assigning >> of time stamps to a change event is not optimal. The time stamp is not >> assigned ASAP (as it is done in the line discipline), and thanks to the >> IRQ sharing and status register poll loop there _has_ to be some delay. >> >> Funny enough, with an Arduino I can create time stamps much more >> reliable -- when I use a hardware counter with a latch-strobe signal. >> (Here the IRQ is created _after_ the counter was value was stored in a >> capture register!) Unfortunately, such a stratagem is not an option with >> a PC... >> >> Another thing that gets into the way are the energy saving strategies >> modern CPUs employ, like reducing the clock speed and distribute load >> over cores. So unless you nail down the IRQ to a certain core and >> prevent cores from going to full sleep, the interrupt rescheduling can >> add another few usecs. IRQ processing was never a high speed thing on >> x86 platforms to start with, and it never kept up with speed boost all >> other parts of the architecture got, AFAIK. >> >> In short, your numbers look familiar, and I don't know how to improve >> the much without dedicated hardware. I'm dreaming of some FPGA hardware >> on a PCIe board at an affordable price... >> >> Cheers, >> Pearly >> ___ >> questions mailing list >> questions@lists.ntp.org >> http://lists.ntp.org/listinfo/questions >> >
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
I didn't say my setup was optimal, only that the IRQ processing and UART poll time is likely not your issue, as you note
the IRQ jitter is more likely to be the culprit (though in my case there is no level shifting going on).
Patch below against 5.7.10, though I was lazy and only intended to make sure it works for the 8250-based UART in my box,
YMMV, apologies in advance that email will almost certainly break lines in it. Its really much more trivial than you
were thinking :)
Matt
commit 85aa50c40dae86b2d5051902e72fc1b18c1c8563
Author: Matt Corallo
Date: Sun Sep 27 23:02:24 2020 -0400
pass interrupt timestamp through to pps-ldisc
diff --git a/drivers/pps/clients/pps-ldisc.c b/drivers/pps/clients/pps-ldisc.c
index 4fd0cbf7f931..0f4f55fd6d4c 100644
--- a/drivers/pps/clients/pps-ldisc.c
+++ b/drivers/pps/clients/pps-ldisc.c
@@ -15,12 +15,15 @@
#define PPS_TTY_MAGIC 0x0001
-static void pps_tty_dcd_change(struct tty_struct *tty, unsigned int status)
+static void pps_tty_dcd_change(struct tty_struct *tty, unsigned int status,
struct system_time_snapshot *irq_ts)
{
struct pps_device *pps;
struct pps_event_time ts;
- pps_get_ts();
+ if (irq_ts == NULL)
+ pps_get_ts();
+ else
+ sys_snap_to_pps_ev(irq_ts, );
pps = pps_lookup_dev(tty);
/*
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 9548d3f8fc8e..54c92902c960 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -111,6 +111,9 @@ static irqreturn_t serial8250_interrupt(int irq, void
*dev_id)
struct list_head *l, *end = NULL;
int pass_counter = 0, handled = 0;
+ struct system_time_snapshot ts;
+ ktime_get_snapshot();
+
pr_debug("%s(%d): start\n", __func__, irq);
spin_lock(>lock);
@@ -123,7 +126,7 @@ static irqreturn_t serial8250_interrupt(int irq, void
*dev_id)
up = list_entry(l, struct uart_8250_port, list);
port = >port;
- if (port->handle_irq(port)) {
+ if (port->handle_irq(port, )) {
handled = 1;
end = NULL;
} else if (end == NULL)
@@ -258,7 +261,7 @@ static void serial8250_timeout(struct timer_list *t)
{
struct uart_8250_port *up = from_timer(up, t, timer);
- up->port.handle_irq(>port);
+ up->port.handle_irq(>port, NULL);
mod_timer(>timer, jiffies + uart_poll_timeout(>port));
}
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index aab36789..d9d67fc275d4 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -219,7 +219,7 @@ static unsigned int dw8250_serial_in32be(struct uart_port
*p, int offset)
}
-static int dw8250_handle_irq(struct uart_port *p)
+static int dw8250_handle_irq(struct uart_port *p, struct system_time_snapshot
*ts)
{
struct uart_8250_port *up = up_to_u8250p(p);
struct dw8250_data *d = to_dw8250_data(p->private_data);
@@ -247,7 +247,7 @@ static int dw8250_handle_irq(struct uart_port *p)
spin_unlock_irqrestore(>lock, flags);
}
- if (serial8250_handle_irq(p, iir))
+ if (serial8250_handle_irq(p, iir, ts))
return 1;
if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY) {
diff --git a/drivers/tty/serial/8250/8250_mid.c
b/drivers/tty/serial/8250/8250_mid.c
index efa0515139f8..78dab30a9c33 100644
--- a/drivers/tty/serial/8250/8250_mid.c
+++ b/drivers/tty/serial/8250/8250_mid.c
@@ -73,7 +73,7 @@ static int pnw_setup(struct mid8250 *mid, struct uart_port *p)
return 0;
}
-static int tng_handle_irq(struct uart_port *p)
+static int tng_handle_irq(struct uart_port *p, struct system_time_snapshot *ts)
{
struct mid8250 *mid = p->private_data;
struct uart_8250_port *up = up_to_u8250p(p);
@@ -100,7 +100,7 @@ static int tng_handle_irq(struct uart_port *p)
ret |= hsu_dma_do_irq(chip, mid->dma_index * 2, status);
/* UART */
- ret |= serial8250_handle_irq(p, serial_port_in(p, UART_IIR));
+ ret |= serial8250_handle_irq(p, serial_port_in(p, UART_IIR), ts);
return IRQ_RETVAL(ret);
}
@@ -124,7 +124,7 @@ static int tng_setup(struct mid8250 *mid, struct uart_port
*p)
return 0;
}
-static int dnv_handle_irq(struct uart_port *p)
+static int dnv_handle_irq(struct uart_port *p, struct system_time_snapshot *ts)
{
struct mid8250 *mid = p->private_data;
struct uart_8250_port *up = up_to_u8250p(p);
@@ -149,7 +149,7 @@ static int dnv_handle_irq(struct uart_port *p)
ret |= hsu_dma_do_irq(>dma_chip, 0, status);
}
if (fisr & BIT(0))
- ret |= serial8250_handle_irq(p, serial_port_in(p, UART_IIR));
+ ret |= serial8250_handle_irq(p, serial_port_in(p, UART_IIR),
ts);
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
Hello: > I'm dreaming of some FPGA hardware on a PCIe board at an affordable price... Have you seen these? None are on a PCIe board, but they do have GPS, a timing crystal, and a PPS signal. LeoNTP Networked Time NTP Server; Price: 300.00GBP http://www.leobodnar.com/shop/index.php?main_page=product_info <http://www.leobodnar.com/shop/index.php?main_page=product_info=120 oducts_id=272> =120_id=272 GPSDO GPS Disciplined Oscillator Clock NTP Time Server https://www.ebay.com/itm/GPSDO-GPS-Disciplined-Oscillator-Clock-NTP-Time-Ser ver-without-IRIG-B-AC-Code/124253295400?_trkparms=aid%3D1110012%26algo%3DSPL ICE.SOIPOST%26ao%3D1%26asc%3D225074%26meid%3D65bb838564cd4d1f841f71471cd16c9 3%26pid%3D18%26rk%3D1%26rkt%3D12%26sd%3D124133795048%26itm%3D12425329540 0%26pmt%3D1%26noa%3D0%26pg%3D2047675%26algv%3DPromotedSellersOtherItemsV2%26 brand%3DUnbranded <https://www.ebay.com/itm/GPSDO-GPS-Disciplined-Oscillator-Clock-NTP-Time-Se rver-without-IRIG-B-AC-Code/124253295400?_trkparms=aid%3D1110012%26algo%3DSP LICE.SOIPOST%26ao%3D1%26asc%3D225074%26meid%3D65bb838564cd4d1f841f71471cd16c 93%26pid%3D18%26rk%3D1%26rkt%3D12%26sd%3D124133795048%26itm%3D1242532954 00%26pmt%3D1%26noa%3D0%26pg%3D2047675%26algv%3DPromotedSellersOtherItemsV2%2 6brand%3DUnbranded&_trksid=p2047675.c18.m2219> &_trksid=p2047675.c18.m2219 There are several on this page that range in price from $155 to $219 USD. Right now I am seeing 1-4 usec jitter from a combination of a PPS signal from an American-made GPS device by Time Machines and a Chinese device from JinnUSR advertised as "Network Time Server NTP Server for GPS Beidou GLONASS Galileo QZSS Desktop tpUS," that serves as the system clock and gives the second. All this is with the serial PPS DLL supplied by Meinberg. I do have the GPS antennas at the end of a ladder that stretches 1/2 way to the second floor roof of the house. It is common to have 7-9 satellites in a fix at one time, which hugely improves position and perhaps time accuracy. Any success I have had with the GPS is due to Misra, P. and P. Enge (2012). Global Positioning System: Signals, Measurements and Performance. Lincoln, Massachusetts, USA, Ganga-Jamuna Press. Read a little bit, make a few changes, and better performance results. You might note that with the above GPS devices requiring 3-4 Watts, there is no way that a PC is an economical time server over the long run. Charles Elliott -Original Message- From: questions [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of Juergen Perlinger Sent: Thursday, October 15, 2020 1:52 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter On 10/7/20 8:45 PM, Andreas Mattheiss wrote: > Hello, > > I wonder what's a realistic ballpark for the jitter I can expect when > feeding a GPS PPS into ntpd? > > My setup is: a cheap u-blox NEO6M has its PPS output connected to a > MAX232 level shifter, connected to a true serial port on my desktop > PC. I use it at the same time for daily work, so no designated ntp > server. The GPS antenna is sitting inside, close to the window, with a > building opposite - suboptimal view of the sky. I do feed RTMS > corrections to the GPS though (ionospheric corrections etc.). The GPS > is set to "stationary" mode, so it's probably set up as good as it gets. > > The jitter values I get do, sorry, jitter. I guess it's a lot to do > with the poor view to the sky, mainly. PPS from GPS is claimed to be > accurate to say 10's of ns; my jiitter values are around 10 micro s > approximately, on avarege, for a well settled system set up as > described. They do zoom up, occasionally, to 60 micro s though. I > would assume that it's unrealistic to expect ns accuracy from ntpd on a non-designated system. > > What do you think, is my 10 micro jitter within experience? While I am > writing this I just realised a post from David Taylor > (< <mailto:qgmgcu$2ad$1...@dont-email.me> qgmgcu$2ad$1...@dont-email.me>) showing > > remote refid st t when poll reach delay offset > jitter > == > o127.127.22.1.uPPS. 0 l- 16 3770.0000.026 > 0.013 > That's quite close to what I get -- either with a GPS18xLVC, or a NEO-M8T (also homegrown, with a MAX-3232 TTL<->RS232 shifter) I had better numbers (half the jitter) with my old Phenom-II box, but with the XEON board I'm running now I see jitter in the 10usec range. With both receivers active at the same time, I have a higher jitter -- clearly interrupt collision, and the jitter occasionally bumps up to 20..30 usec, and
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
I was wondering about this too, so sat down and patched kernel to pull timestamps right after the interrupt fires and then decide later if it was because of DCD change (passing the timestamp through the dcd_change callback, its a pretty trivial patch). It cut the jitter down some (a few us, maybe) and killed some peaks, but clearly wasn't the source of most of the jitter here, at least on an embedded AMD box with other things to do between interrupts and a relatively poor system clock. I do already get better than 10us jitter, however, closer to maybe 5. Matt On 10/15/20 1:52 AM, Juergen Perlinger wrote: On 10/7/20 8:45 PM, Andreas Mattheiss wrote: Hello, I wonder what's a realistic ballpark for the jitter I can expect when feeding a GPS PPS into ntpd? My setup is: a cheap u-blox NEO6M has its PPS output connected to a MAX232 level shifter, connected to a true serial port on my desktop PC. I use it at the same time for daily work, so no designated ntp server. The GPS antenna is sitting inside, close to the window, with a building opposite - suboptimal view of the sky. I do feed RTMS corrections to the GPS though (ionospheric corrections etc.). The GPS is set to "stationary" mode, so it's probably set up as good as it gets. The jitter values I get do, sorry, jitter. I guess it's a lot to do with the poor view to the sky, mainly. PPS from GPS is claimed to be accurate to say 10's of ns; my jiitter values are around 10 micro s approximately, on avarege, for a well settled system set up as described. They do zoom up, occasionally, to 60 micro s though. I would assume that it's unrealistic to expect ns accuracy from ntpd on a non-designated system. What do you think, is my 10 micro jitter within experience? While I am writing this I just realised a post from David Taylor () showing remote refid st t when poll reach delay offset jitter == o127.127.22.1.uPPS. 0 l- 16 3770.0000.026 0.013 That's quite close to what I get -- either with a GPS18xLVC, or a NEO-M8T (also homegrown, with a MAX-3232 TTL<->RS232 shifter) I had better numbers (half the jitter) with my old Phenom-II box, but with the XEON board I'm running now I see jitter in the 10usec range. With both receivers active at the same time, I have a higher jitter -- clearly interrupt collision, and the jitter occasionally bumps up to 20..30 usec, and the offset between the receivers (which is ~20usec) reverses then. I looked into the UART code of the Linux kernel (not _too_ deep) but it's clear that the handling of the DCD signal change and the assigning of time stamps to a change event is not optimal. The time stamp is not assigned ASAP (as it is done in the line discipline), and thanks to the IRQ sharing and status register poll loop there _has_ to be some delay. Funny enough, with an Arduino I can create time stamps much more reliable -- when I use a hardware counter with a latch-strobe signal. (Here the IRQ is created _after_ the counter was value was stored in a capture register!) Unfortunately, such a stratagem is not an option with a PC... Another thing that gets into the way are the energy saving strategies modern CPUs employ, like reducing the clock speed and distribute load over cores. So unless you nail down the IRQ to a certain core and prevent cores from going to full sleep, the interrupt rescheduling can add another few usecs. IRQ processing was never a high speed thing on x86 platforms to start with, and it never kept up with speed boost all other parts of the architecture got, AFAIK. In short, your numbers look familiar, and I don't know how to improve the much without dedicated hardware. I'm dreaming of some FPGA hardware on a PCIe board at an affordable price... Cheers, Pearly ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
On 10/7/20 8:45 PM, Andreas Mattheiss wrote: > Hello, > > I wonder what's a realistic ballpark for the jitter I can expect when > feeding a GPS PPS into ntpd? > > My setup is: a cheap u-blox NEO6M has its PPS output connected to a MAX232 > level shifter, connected to a true serial port on my desktop PC. I use it > at the same time for daily work, so no designated ntp server. The GPS > antenna is sitting inside, close to the window, with a building opposite - > suboptimal view of the sky. I do feed RTMS corrections to the GPS though > (ionospheric corrections etc.). The GPS is set to "stationary" mode, so > it's probably set up as good as it gets. > > The jitter values I get do, sorry, jitter. I guess it's a lot to do with > the poor view to the sky, mainly. PPS from GPS is claimed to be accurate > to say 10's of ns; my jiitter values are around 10 micro s approximately, > on avarege, for a well settled system set up as described. They do zoom > up, occasionally, to 60 micro s though. I would assume that it's > unrealistic to expect ns accuracy from ntpd on a non-designated system. > > What do you think, is my 10 micro jitter within experience? While I am > writing this I just realised a post from David Taylor > () showing > > remote refid st t when poll reach delay offset > jitter > == > o127.127.22.1.uPPS. 0 l- 16 3770.0000.026 > 0.013 > That's quite close to what I get -- either with a GPS18xLVC, or a NEO-M8T (also homegrown, with a MAX-3232 TTL<->RS232 shifter) I had better numbers (half the jitter) with my old Phenom-II box, but with the XEON board I'm running now I see jitter in the 10usec range. With both receivers active at the same time, I have a higher jitter -- clearly interrupt collision, and the jitter occasionally bumps up to 20..30 usec, and the offset between the receivers (which is ~20usec) reverses then. I looked into the UART code of the Linux kernel (not _too_ deep) but it's clear that the handling of the DCD signal change and the assigning of time stamps to a change event is not optimal. The time stamp is not assigned ASAP (as it is done in the line discipline), and thanks to the IRQ sharing and status register poll loop there _has_ to be some delay. Funny enough, with an Arduino I can create time stamps much more reliable -- when I use a hardware counter with a latch-strobe signal. (Here the IRQ is created _after_ the counter was value was stored in a capture register!) Unfortunately, such a stratagem is not an option with a PC... Another thing that gets into the way are the energy saving strategies modern CPUs employ, like reducing the clock speed and distribute load over cores. So unless you nail down the IRQ to a certain core and prevent cores from going to full sleep, the interrupt rescheduling can add another few usecs. IRQ processing was never a high speed thing on x86 platforms to start with, and it never kept up with speed boost all other parts of the architecture got, AFAIK. In short, your numbers look familiar, and I don't know how to improve the much without dedicated hardware. I'm dreaming of some FPGA hardware on a PCIe board at an affordable price... Cheers, Pearly ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
Hello, I wonder what's a realistic ballpark for the jitter I can expect when feeding a GPS PPS into ntpd? [] Thanks, regards Andreas === Andreas, I have some offset plots here: https://www.satsignal.eu/mrtg/performance_ntp.php and a few experimental clock and system jitter plots here: https://www.satsignal.eu/mrtg/performance_ntp_jitter.php For an unloaded Raspberry Pi, 1-4 us, for an RPi carrying out another task perhaps as high as 5-7 us for an RPi zero. For a Windows-10 PC 4-50 us depending on load and CPU speed and age. All given a reasonably clear satellite view, and no GPS jammer truck parked outside! [us => microsecond] Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
On 2020-10-07, Andreas Mattheiss wrote: > Hello, > > I wonder what's a realistic ballpark for the jitter I can expect when > feeding a GPS PPS into ntpd? around a microsecond or less. > > My setup is: a cheap u-blox NEO6M has its PPS output connected to a MAX232 > level shifter, connected to a true serial port on my desktop PC. I use it Not really needed since almost all serial cards will handle TTL level with not problem. > at the same time for daily work, so no designated ntp server. The GPS You need to set the seconds somehow. Are you doing that via nmea from the GPS? > antenna is sitting inside, close to the window, with a building opposite - > suboptimal view of the sky. I do feed RTMS corrections to the GPS though > (ionospheric corrections etc.). The GPS is set to "stationary" mode, so > it's probably set up as good as it gets. > > The jitter values I get do, sorry, jitter. I guess it's a lot to do with > the poor view to the sky, mainly. PPS from GPS is claimed to be accurate > to say 10's of ns; my jiitter values are around 10 micro s approximately, > on avarege, for a well settled system set up as described. They do zoom > up, occasionally, to 60 micro s though. I would assume that it's > unrealistic to expect ns accuracy from ntpd on a non-designated system. It sounds to me like you are running from the wrong edge of the signal. Is your level shifter also and inverter? > > What do you think, is my 10 micro jitter within experience? While I am No. I get using chronyd (report from chronyc) sources MS Name/IP address Stratum Poll Reach LastRx Last sample #* PPS0 0 4 37724 +2035ns[+2458ns] +/- 776ns sourcestats Name/IP AddressNP NR Span Frequency Freq Skew Offset Std Dev PPS0 24 11 367 +0.000 0.016 +1ns 1972ns Of course chrony has long been know to give much better control of the clock than does ntpd > writing this I just realised a post from David Taylor > () showing > > remote refid st t when poll reach delay offset > jitter >== > o127.127.22.1.uPPS. 0 l- 16 3770.0000.026 > 0.013 > > Pretty much what I get. > > Thanks, regards > Andreas > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
Quoting Andreas Mattheiss : I wonder what's a realistic ballpark for the jitter I can expect when feeding a GPS PPS into ntpd? Assuming Linux, and using pps-ldisc or pps-gpio, I'd expect reported jitter to be around 1us : The jitter values I get do, sorry, jitter. I guess it's a lot to do with the poor view to the sky, mainly. PPS from GPS is claimed to be accurate to say 10's of ns; my jiitter values are around 10 micro s approximately, on avarege, for a well settled system set up as described. They do zoom up, occasionally, to 60 micro s though. I would assume that it's unrealistic to expect ns accuracy from ntpd on a non-designated system. What do you think, is my 10 micro jitter within experience? What are your GPS signal levels during these times? Does your module lose lock? What are your minpoll/maxpoll settings on your refclock? You can try changing your timesource. Many Linux systems will default to the TSC timesource, which is much quicker to read but is less stable in frequency compared to HPET. The timesource settings are here: /sys/devices/system/clocksource/clocksource0/available_clocksource /sys/devices/system/clocksource/clocksource0/current_clocksource ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
