Dan Drown via devel :
> Let's talk a bit about what time critical sections are currently in the
> code. I think that will help drive the decision about the impact of garbage
> collection.
>
> I haven't looked at ntpsec's codebase lately, so some of this might be out
> of date. Please feel free t
Hal Murray :
>
> Eric said:
> > Talk to me about what you think the effect of very occasional stop-the-world
> > pauses of 600 microseconds or less would be on sync accuracy. By "very
> > occasionally" let's say once every ten minutes or so, that being what I
> > think
> > is a *very* pessimistic
Dan Drown via devel writes:
> Time critical code:
>
> 1. packet tx happening right after tx timestamp for server response
Yes, and that really should be handled in the kernel, maybe implemented
via BPF.
> 2. serial NMEA data timestamps
Arguably that should also (ideally) be the responsibility of
Dan said:
> The time critical code can tolerate some level of delay (~hundreds of
> microseconds), as things like packet tx can be delayed for a multitude of
> kernel and hardware reasons. The good news is both of the time critical
> code paths are somewhat predictable and if we can manually
