On Mon, Jan 15, 2024 at 4:27 PM Miroslav Lichvar <[email protected]> wrote:
> On Mon, Jan 15, 2024 at 01:05:32PM +0700, James Clark wrote: > > I have implemented refclock SOCK for a project I'm working on. In my > case, > > I am getting samples from a PHC, so I have a system time with nanosecond > > precision (from PTP_SYS_OFFSET*). But refclock SOCK uses struct timeval, > > which is in microseconds. I looked at the refclock_sock servo in linuxptp > > 4.x, and that just discards away the fraction of the microsecond. But > > that's not very satisfying and makes chronyc give misleading information > > about the accuracy of the offset. > > The resolution of the timestamp is not very important. Milliseconds > would be still fine. It is not used for calculating the offset. The > offset is provided directly as a floating-point value in the SOCK > message. > Oh, I see. So chrony is using the offset directly? I had misunderstood: I assumed it was computing the true time by adding the offset to the system time, and then using the true time. It all makes sense now. I think my code is doing the right thing already. But let me just describe it, in case I have misunderstood anything else. The information from which I am computing the sample is: - the true time in TAI with nanosecond precision - the date and type of the next announced leap second (from the GNSS receiver) - the Linux system time with nanosecond precision To compute the offset, I convert the system time to a TAI time. But if the system time is in the range [23:59:59, 00:00:00) on the day of a positive leap second, then I don't generate a sample (because it's ambiguous what TAI time that system time corresponds to). I then use as the offset the difference of true TAI time and the TAI time from converting the system time. So the offset is the amount by which the system clock needs to be corrected (rather than the difference between the correct system time and the actual system time). But the offset will be wrong by a small number of seconds if the system clock is so far in the past that leap seconds other than the latest one intervened: I don't think that matters. I compute the leap flags based on the true time: if the true time occurs on a day that ends with a leap second, then I set the leap flags. Or should I be setting them if the true time is some number of hours before the end of the day that ends with a leap second? James
