> > I wrote something this evening that just busy-loops waiting for a raising > > edge and then writes down the current time to feed that to ntp. > > You are trading interrupt latency for user-kernel crossing delays and > scheduler quirks.
Are you sure about the user-kernel crossings? Because (not 100% sure) I thought wiringpi access the gpio pins directly - iirc they're memory mapped (strace doesn't show any system calls) on ARM processors. > There is probably a way to dedicate a CPU to your polling job. I think I've https://unix.stackexchange.com/questions/530575/how-to-dedicate-a-cpu-to-a-process/530579 Will try that. > What ntpd are you using? The PPS driver may have an option to log every > pulse. It's FLAG4 in ntp classic and ntpsec. That would let you compare > your > two paths. I'm using ntpsec. Unfortunately I don't have any hardware (yet) for comparing pulses so I depend on ntp telling me if it is a false-ticker or not. > You also need to compare the adev type statistics from the interrupt path > when > your polling is/isn't running to see if polling is distorting the interrupt > path. I understand the neccessity for the adev calculation. I don't understand the remark about the interrupt distortion: if I use the poller-program, then I don't enable (via the pps-gpio module) interrupts? _______________________________________________ time-nuts mailing list -- [email protected] -- To unsubscribe send an email to [email protected] To unsubscribe, go to and follow the instructions there.
