Re: [chrony-dev] Runtime refclock management

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Wed, Oct 04, 2017 at 03:10:15PM -0400, Will Miles wrote:
> On 2017-10-04 6:15 AM, Miroslav Lichvar wrote:
> > On Tue, Oct 03, 2017 at 02:30:09PM -0400, Will Miles wrote:
> > > What is the best way to submit a patch sequence?   Currently I've got it up
> > > on github at
> > > https://github.com/willmmiles/chrony/commits/client-refclock-add , but I can
> > > do something like git format-patch/git send-email if that's more practical.
> > Sending patches to the list is prefered.
> 
> OK, I will do that in the future.   For a commit chain of several patches,
> do you prefer one email per patch, or a single message with each patch as an
> attachment?   I looked through a few months of mailing list history but
> couldn't find any examples.

I have a slight preference for the former, but the later works too as
long as the attachments have text/plain type so they are automatically
included in email reply.

I should write a document on contributing :).

> Ah, figures I'd miss a style cleanup somewhere.   Re memory leaks, I didn't
> thoroughly audit the refclock drivers to ensure everything was freed, but is
> there something specific you spotted?

I think I saw a missing Free() for the driver name and parameter when
adding refclock failed.

> -> Ensure that the tracking state was preserved across restarts so that
> esterror and maxerror aren't disturbed -- my application depends not just on
> accurate time, but also uses the esterror and maxerror values to indicate
> how much we can trust it; adding a new source shouldn't degrade the existing
> estimates.   This may already be solved, but I haven't tested it.

No, this would need to be fixed. If it was necessary to avoid the race
between chronyd setting the timex fields on start and applications
completely, it might require significant changes in the code.

> From here it seemed to be a lot more straightforward to try and use the
> existing client message handling framework rather than have to solve
> parallelism issues via the filesystem, write an additional config file
> management daemon, and/or fix up any tracking state continuity issues.

Makes perfect sense.

I guess a completely different approach would be to allow multiplexing
with the SOCK driver. Multiple clients could connect to the socket and
each one would have a separate refclock. This could be tricky.

> In that vein, I also have a patch stream that adds TAI offset tracking for
> sources, and implements
> https://tools.ietf.org/html/draft-stenn-ntp-extended-information-00 to
> communicate TAI offset information between nodes.   I definitely wouldn't
> recommend it for use on the public internet, but the foundational patches to
> transmit and receive NTPv4 extensions might be useful at some future date.  
> Would it be of any use to post them up here for posterity, even though
> there's not really much point in merging anything like it now?

I'd like to see the patches. We will need to work with extension
fields when NTS is implemented. There is still an ongoing debate in
the NTP working group about parsing of extension fields, their types,
etc.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.