On Mon, Sep 11, 2023 at 10:29:30 +0200, Miroslav Lichvar wrote: > On Fri, Sep 08, 2023 at 11:21:08AM -0400, Josef 'Jeff' Sipek wrote: > > I'm playing with feeding data to the SOCK refclock with GPS time myself > > (without using gpsd, etc.). I saw that the samples contain the host/system > > timestamp as a struct timeval. I changed it to allow nanosecond time of > > measurements but before I try to polish it and send it for inclusion, I > > wanted to check if there would there be interest in that? The current diff > > is below, but it needs a bit more cleanup and testing. > > That timestamp doesn't need much resolution. It just says when the > offset (in double format) was captured. Milliseconds would be fine.
Ok. I just saw that the code uses that the timestamp and the offset to calculate the time (for non-PPS sources) and it seemed desirable to get more than microsecond resolution for that before it gets fed into RCL_AddSample. In other words, this timestamp indirectly affects the resolution of the sample fed in. > The code was written when chrony was still internally using timeval. > If it was written today, timespec would be the obvious choice, Makes sense. > but > switching now I think would just create unnecessary work for the > applications and more code to maintain. The way I changed the code, it handles 3 variants: 32-bit timeval, 64-bit timeval, and timespec (fixed at 2*64 bits). So, no application changes are required and the extra code is in chrony. Jeff. -- 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.
