<div dir="ltr">Hi there,<div><br></div><div>I am trying to profile the latency of the testptp.c self-test in the linux kernel (linux/tools/testing/selftests/ptp/testptp.c). (This will become more clear later on)</div><div><br></div><div>I have compiled it separately, and am using the following commands to enable PPS on my Intel I210 NICs:</div><div><br></div><div>./testptp -d /dev/ptp0 -L 0,2</div><div>./testptp -d /dev/ptp0 -p 1000000000</div><div><br></div><div>Using an oscilloscope, I can see the PPS signal being asserted on my NIC at 1PPS, and I can see the "assert" timestamp by using:</div><div><br></div><div>cat /sys/class/pps/pps0/assert</div><div><br></div><div>It's not clear to me what timestamp is showing under the assert file. I'm assuming that an interrupt is generated after a certain amount of clock ticks assert the PPS signal on the pin. Presumably, there is a latency between when the interrupt is generated, and when the PPS pin is actually asserted. I understand this latency will be very small, but I'd still like to profile it. Is the timestamp in "assert" the time that the IRQ was generated, or the time that the PPS pin was actually asserted?</div><div><br></div><div>I was going to use cyclictest to profile the latency between the call for PPS to be asserted, and when it's actually asserted, but I don't think I can do that since there isn't a process that actively does this. Any ideas?</div><div><br></div><div>Regards,</div></div>