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] PPS not working on newer kernel/distros
Hi! On Sun, Oct 14, 2018 at 05:59:49PM -0400, Brandon Applegate wrote: > On Oct 14, 2018, at 4:22 PM, Brandon Applegate wrote: > > What I’m experiencing is that it will run with flag3 set to 1 - but > > it never seems to ‘lock on’ to PPS. I’m wondering / asking if this > > could be a kernel issue. I know I’m not giving kernel versions etc. > > and I’m speaking in terms of linux distro version. I suppose I > > could nail down versions and try to dig to see if there’s PPS > > changes that have been made (for the worse) over the years. I was > > just hoping perhaps someone on this list would know offhand of a > > ’smoking gun’ WRT linux kernel version / changes that has > > (adversely) affected kernel PPS. > > Well it might seem that I was a bit hasty - and didn’t give ntpd time > enough to sync on PPS. In the past this was a very rapid process. > Since I’ve reinstalled and rebuilt it certainly takes longer. I’ve > set flag 3 to 1 and it did sync on PPS (‘o’ in billboard). It seems > to be settling down now. To see if you are using kernel PPS use 'ntpq -c kerninfo' and search for line starting with 'kernel status:' in case of userspace PPS: kernel status: pll nano in case of kernel PPS: kernel status: pll ppsfreq ppstime ppssignal nano Vita ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS not working on newer kernel/distros
Hi! On Tue, Oct 09, 2018 at 01:04:05PM -0400, Brandon Applegate wrote: > > > On Oct 9, 2018, at 5:43 AM, Joachim Fabini > > wrote: > > > > Hello Brandon, > > > > Which version of ntp is deployed on your system? > > Any relevant/suspect output in syslog when restarting ntpd? > > What does ntpq report? > > > > First guess: please remember http://bugs.ntp.org/show_bug.cgi?id=3367 - > > this was staged (only) for ntp-4.2.8p11. Make sure that either your ntp > > has the patch already or patch your sources manually. IMHO this patch is completely wrong! If we want kernel PPS (flag3 1) and time_pps_kcbind() fails with EOPNOTSUPP we should fail the same way as with outher errors because we get no kernel PPS! With this patch we don't have any message and we don't fail and we have no kernel PPS. Without this patch we fail correctly when time_pps_kcbind() fails with EOPNOTSUPP. > > br Joachim > > > > Hey Joachim, > > Actually I think you helped me out a few years ago when I first found > this issue. You gave me a patch which I put against 4.2.8p6 I believe > at the time. I was getting the kcbind error on Ubuntu 14.04. > > So yes, now that I’ve installed 4.2.8p12 (that includes the patch) - I > no longer get this error. The bad news though is that it seems like I > never lock on to PPS. I never get an ‘o’ in my billboard. If I put > fudge flag3 back to 0, I seem to be in business (I get ‘o’ quickly and > my offset settles down to near 0). But (and I don’t have actual > before/after graphs or hard data to confirm this) but it seems like it > wavers a bit more now than it did previously on Ubuntu 14.04 with > fudge flag 3 set to 1. In case of 'flag3 0' you are using userlevel PPS handling, in case of 'flag3 1' and proper kernel support (and proper timepps.h header file and properly compiled ntpd sources) you are using kernel PPS. To have proper kernel PPS support you need to have timepps.h header file from git://github.com/ago/pps-tools.git installed in the right place and then ntpd sources recompiled. timepps.h file from this repository has properly implemented the time_pps_kcbind() function. Cheers, Vita ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
