Quoting Achim Gratz via devel <devel@ntpsec.org>:
:
I tend to organize timer triggered code in a way that any computations
that take a long or indeterminate time happen after the time-critical
section that uses either very short computations or precomputed values
from the last period. That assumes that the resulting lag until the
next timer invocation can be taken into account (which should usually be
possible). So if things get organized like that, as long as whatever GC
does is done until the next trigger would not matter at all.
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 to correct any mistakes or omissions.
Time critical code:
1. packet tx happening right after tx timestamp for server response
2. serial NMEA data timestamps
Non time critical code:
1. packet rx timestamp (assumption: SO_TIMESTAMPNS or alike is being used)
2. packet tx happening right after tx timestamp for client request
(assumption: SO_TIMESTAMPNS or alike is being used)
3. receiving SHM data
4. receiving PPS data
5. calculating/updating local clock offset/frequency
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
schedule GC, we can avoid scheduling it during those times.
The non timing critical code can be delayed tens of milliseconds
without an impact to timing quality.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
