[Serdev] Re: was [Serusers] Timers

[Andrei Pelinescu-Onciul]

On May 25, 2004 at 01:23, Richard <mypop3mail at yahoo.com> wrote:
> Hi Jiri,
> 
> More thoughts on the timer issue.
> 
> The main issue to have multiple timer is the overhead
> to insert the element into the timer list. If only
> fixed timer is used, the event can be added at the end
> of the list and incur little cost. If we maintain a
> fixed timer list and use a flexible timeout value for
> an element, we can still add the element to the end of
> the list. When the element is called, the timeout
> value is reduced by fixed time amount and put back
> into the end of the list. The repeats until the
> timeout value becomes 0 or negative. Then the real
> processing is called.

Yes this will work, but it would still incure a performance penalty. You
will have to use "shorter" fixed timers, so that if you want a
fr_invite_timeout of 20s for a call, it would work. 
But if you make the standard fr_inv_timer tick at 20s, then normal calls
which use the default 120s value, would produce 6 extra timer operations
 (wake-up, substract 20s, re-insert).

We do have a complete timer rewrite on our TODO list (this involves the
whole ser timers and not only tm). In fact we do have a test version of
the new timer code. It uses arrays of timers with same expirations time.
It keeps an crt_time+3600 circular array. Cell n in this array contains
timers that expire at crt_time+n. All higher timeouts are kept in a
sorted list (we generally have very few things that will use timeouts >
1h in ser). 
We are still having a debate on timer granularity (1s, 0.5, 0.1 s) and
on whether or not to use completely separate timers for "fast" users and
"slow" users (a "slow user would be a callback which does a lot of work
on timer, like dns lookups, opens tcp connections a.s.o).

The code status is: it works ok in our tests, but right now does not
include any multiple process support (locking & shared mem. structures).
After this it would need to be integrated in ser, all the timer users
 would need to be  updated with the new timer api (if it would change)
 and finally tm must be switched to the new timer (which would make
 current tm timers obsolete).
 The problem is we don't have currently enough time. I wrote the test
 timer code almost 3 month ago, but other priorities have taken over.

So expect a timer update in the near future (3 month?). Other pending
stuff: config parser change (first step to variables), *_malloc memory
defragmentation, various tcp fixes, performance optimization (select
replaced with poll,epoll,kqueue,/dev/poll depending on system) a.s.o.



Andrei