Andreas, Okay, that’s damn creative. A very interesting alternative to disabling power management. :)
Kinda cool. One thing however... Comments from the code: * When using unidled, assert that all of gpsd, chronyd and unidled are set * to run on the same core and with realtime privilege (unidled highest, * followed by gpsd and then chronyd whith lowest privilege). Make sure that * the pps serial interrupt is served by the same core, use a script to * irqbalance to assert this, if required. Setting real-time priority for gpsd and chronyd will be counterproductive, particularly when you have them bound to the processor that is handling the IRQ for the serial port. When using kernel PPS (KPPS), the PPS timestamp is set by the kernel IRQ handler relative to the system clock at that point. Gpsd is not involved in this process. When gpsd subsequently runs, it uses the kernel’s PPS timestamp as the basis for what it delivers to chronyd. Yes, without KPPS, gpsd would be the generator of the timestamp and process priority could certainly have an impact, but with KPPS it should not offer benefit. Likewise, while chronyd previously benefited from real-time priority before support for kernel/hardware packet timestamping was introduced, it doesn’t really offer benefit anymore. Running processes at real-time priority unnecessarily, particularly if you are not using a preempt-able kernel, will have an adverse effect on the jitter of the IRQ timestamp. It makes sense to keep a high process priority for unidled, but you should see comparable or better results if you run gpsd and chronyd at normal priority. Note that IRQ jitter is heavily masked by the larger polling interval and median filter. If you want to get a good view of the actual PPS jitter you can pull the raw clock data out of refclocks.log and do calculations based on that. Or use ppswatch. FWIW, the best result I see is with a pre-emptable kernel @ 1000HZ, power management disabled, and a single core servicing the serial IRQ (and no other IRQs). I test with on a C2558 based system with a serial driver that doesn’t support MSI. With a poll interval of 3 and a median filter length of 8, I see an average offset in chrony of ~7us (IRQ response time), with an average standard deviation of ~200ns. However if I look at the underlying PPS signal, the actual standard deviation is ~700ns. Your mileage may vary. Denny -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
