On Mon, 24 Jul 2023 09:17:10 +0200 Miroslav Lichvar <mlich...@redhat.com> wrote:
> On Sat, Jul 22, 2023 at 04:12:32PM +0200, jmfriedt wrote: > > 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. > > How exactly you are writing to that file? Any buffering or fsync()? > > I think the modified timestamp of a file is captured by the kernel > when it's updating the inode. The system clock might be precise to few > tens of nanoseconds, but that update of the inode certainly cannot be > timed to such precision. This is exactly what I am interested in learning: the impact of the operating system and the filesystem on the timestamping capability at the userspace level. The file storage is handled at a very high level by a Python script generated by GNU Radio Companion using a File Sink with unbuffered(False) so indeed there is buffering occuring, thank you for pointing that out. Attached is the result whan the CPU clock is generated by a synthesizer controlled by the GM reference. In tihs case the system clock v.s PHC clock offset is cancelled and I am only left with what I believe to be system jitter, which I calculate as about 3 us after removing outliers. So I would now like to try and synchonize the CPU clock on the PHC information. However I fail to identify the time (frequency) offset without the external truth of the SDR records. I don't understand the "freq" field of ptp4l but I believe this is related to the PHY oscillator, not the CPU oscillator as this field is not changing significantly when I change the CPU frequency. Also I try to read testptp -k 10 but that too I cannot understand: since phc2sys is constantly updating sys with phc I believe, how come that testptp -k tells me system/phc clock time offset is 37 s? Furthermore this quantity also does not represent the frequency offset of the CPU driving oscillator wrt its nominal frequency. I tried reading the various outputs of pmc but since this is the PTP management part, probably it will not relate to system time. So I fail to identify an indicator of system frequency vs PHC frequency difference that would allow me to steer the CPU clock to its nominal frequency. Thank you, Jean-Michel -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France
res25_PTPExtclk_250Hz.pdf
Description: Adobe PDF document
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
