The sole purpose of the *"time_keeper"* process is to loop infinitely while
counting seconds and microseconds. Doing anything else besides that was avoided
because it would cause his time keeping duties to gradually offset, thus losing
track of time.
But simply looping (not to mention also incrementing a few integers) is a job
itself, and that takes time! This causes the *"time_keeper"* to occasionally
lose some (micro)second increments, although it is designed to be work-free!
This bug affects scheduled operations in OpenSIPS. The further away in the
future they are, the bigger the gap between when they **should run**, and when
they're **actually run**, some time later.
The concerned time keeping routine is `run_timer_process_jif()`. Solution
should involve occasionally synchronizing with the system. We cannot use CPU
time since there's some I/O going on (notice the `select()` syscall for
`ITIMER_TICK` μs), so `gettimeofday()` along with a defensive mechanism should
suffice (protection against sudden system time changes).
Reported by Grygoriy Dobrovolskyy
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/745
_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
