Introduce sippy.Time.MonoTime, a way to do more accurate time interval accounting and scheduling that is not affected by any realtime clock corrections due to NTP and other sources of corrections (i.e. time change using settimeofday, leap seconds etc).
Introduce sippy.Time.MonoTime, a way to do more accurate time
interval accounting and scheduling that is not affected by any
realtime clock corrections due to NTP and other sources of
corrections (i.e. time change using settimeofday, leap seconds
etc).

The basic idea is that we combine both CLOCK_REALTIME and
CLOCK_MONOTONIC in one single package, so we can always use the
latter when we need to calculate the difference between time
point A and point B, plus we can also get proper wall-clock of
either A or B precise to the best information the system had
at the time when either A or B has been instantiated.

Plus it is also possible to re-expres wall-clock of event A
or event B to be compatible to each other, even if some kind of
time correction has happened between them.

Since there is no way to synchronously obtain both values in
single system call, there is always some uncertainty as to possible
extra scheduling delay between two clock_gettime() calls necessary
to read both clocks. Get rid of most of this jitter-like error by
filtering out semi-constant offset between those two readings via
low-pass filter and taking the filtered value as a real offset.

In practice, this works quite well, the accuracy and stability of
that offset between multiple instantiations is down to few
microseconds (i.e. 10e-6), while the jitter due to scheduling
interventions can be on the order of few milliseconds or more
under heavy load.

That works quite well, since most of the time we are interested
in the CLOCK_MONOTONIC part of the class, which is not affected
by the filtering.

We will push this new object to be used as a primary time keeper
to replace time.time() calls pretty much everywhere in the code.

sippy/b2bua,AVOXI/b2bua,AVOXI/b2bua,sippy/b2bua