The timer interval for the ratelimit is configurable (called every
second in my case).
I'm using it to control inbound/outbound cps over several SIP trunks.
Before having a separate timer for ratelimit, I wasn't able to
properly control the cps due to timer jitter.
If the slow timer doesn't introduce jitter, then I have no objections
in using it. But if the slow timer is exposed to jitter due to other
timers that can block and introduce jitter, then the slow timer is not
a viable option here.
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 3:29 AM, Andrei Pelinescu-Onciul
<andrei(a)iptel.org> wrote:
On Mar 09, 2009 at 22:14, Ovidiu Sas
<osas(a)voipembedded.com> wrote:
Should I understand that in ser there are two
timer processes:
- fast timer
- slow timer
If this is correct, I would like to have the ability to register an
extra process for particular timer.
On a multicore platform, several timers can be processed in parallel.
Under heavy load, I experienced issues while using the standard timer
process for the ratelimit module and therefore I registered the
ratelimit timer with it's own process.
Could you describe what is the ratelimit timer doing and how
often is it called?
(there are huge differences between the timer in k and sr, the timer in
k is very inefficient and that's what you might have seen).
Anyway so far I've seen register_timer_process used only in 5 modules
and I suspect in the worst case it can be replaced by fork_process();
while() { sleep(1); call_timer())} (which is basically what
register_timer_process does). For this I wouldn't create a special
function.
If the needs arrives for more complex timers (ones that handle several
different timeouts or need dynamically adding and removing), I will add
something similar (based on local_timer.h), but that would return a
timer_proc_handle so that more timers can be added to it at runtime
(even from different processes if proper locking is used).
Andrei