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
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 reduci
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.
nday, 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
&
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
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
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
: 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?
&g
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,
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
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
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
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
13 matches
Mail list logo
