Thanks to the help I received earlier I am now able to control the Compute Module 4 (CM4) on (White Rabbit) PTP, NTP or GPS. I am trying to understand the meaning of the 9 digits Linux is providing when reading an inode state with "stat -c %y" and how many decimals are actually relevant.
To do this I am connecting an Ettus Research X310 software defined radio to the CM4 and configuring to start collecting data upon detection of the WR 1PPS rising edge. The SDR input is connected to the 1PPS to assess that the record always stays at the same time with respect to the 1PPS and it does. I record a known number of samples in file.bin at a known datarate (5 MS/s) and look at the timestamp of the last file access as the last field of stat -c %y file.bin, and I try and analyze the factional part of this timestamp. I get the attached chart which is a 16 hours long measurement with one measurement every 16 s. I understand that the slope of the sawtooth (inset) is the frequency difference between the oscillator driving the processor and the PTP time as I was able to check by clocking the CM4 with an external synthesizer locked to the WR source (hydrogen maser). What I cannot understand is the sawtooth shape and the relation to the kernel CONFIG_HZ_250 setting, since changing to CONFIG_HZ_300 or CONFIG_HZ_1000 does change the sawtooth amplitude from 4 to 3 ms and then to negligible (~ms but not looking like a sawtooth anymore) amplitude. I have also checked that by clocking the CM4 CPU with a synthesizer locked to the WR GM reference, the sawtooth is gone and I am left with the +/-5 us I attribute to kernel syscall latency fluctuation. Can anyone point me to some literature describing the transfer from PHY PTP time to Linux kernel time and how it affects these timestamps? also where the sawtooth comes from and its relation to the CONFIG_HZ kernel setting? In general I wonder, when I read NTP to be ms accuracy and PTP being nanosecond, how do users actually use such resolution (which I can indeed observe on the PTP 1-PPS output from the PHY) at the operating system level when the kernel itself timestamps with several ms granuarity? With White Rabbit I can access the 10 MHz and 1PPS output that allow me synthesizing any frequency I need in an application, but PTP only provides the timestamp information which I understand to be transferred to the operating system by phc2sys and I see then the impact of the operating system timer granularity it seems. I also cannot understand the long term (7-8 hour period) slow drift visible on the top chart. I have verified that the PHY oscillator frequency does not impact the result, only the CPU oscillator, which might be expected if PTP is not only sharing the time transfer delay but also the time to correct for PHY clock drift. Thank you, Jean-Michel -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France
230721.pdf
Description: Adobe PDF document
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
