charts: try compute a real desired_delay_us

This introduces a concept of a "close enough" epsilon value.
Where if the attempted update's current time is within very small
temporal distance from the precisely scheduled time dictated by
the interval, the update will still take a sample, rather than
try introduce a tiny dely the host/kernel/ppoll will likely fail
to adhere to without being tardy.

Previously the desired delay was just a third of the interval,
with no consideration for how long sampling took.  This was dead
simple, but made no attempt to schedule the poll timeout to align
with the next sampling deadline, and would either cause excessive
wakeups, or excessive tardiness, depending on the host's speed.

I think this technically also fixed a bug where this_delta
wouldn't get assigned if one of the earlier conditions
short-circuited the later condition where it was being assigned.

0 files changed, 0 insertions, 0 deletions