[Users] "detached" timer

[Bogdan-Andrei Iancu]

Jerome Martin wrote:
> On Fri, 2007-03-30 at 16:16 +0300, Bogdan-Andrei Iancu wrote:
>> Hi Jerome,
>>
>> right, sometime is good to have thinks as clear as possible :).
>>     
>
> Yep :-)
>
>> as update on the topic, openser 1.2 has a new, improved timer 
>> implementation (core and TM)  - actually done by myself :) - and part of 
>> the performance boost roots from there.
>>     
>
> Which is, BTW, a great job :-)

thanks :)
>
> For people interested in looking at what SER does, this message led me 
> to take a look a SER 2.0 documentation and bits of code, and it is not 
> immediatly evident that they are taking a radically different route 
> ... they also improved timer granularity (down to a resolution of 62.5 
> ms).
openser 1.2 has a granularity of milliseconds - you can adjust it as you 
want, based on your system requirements. Default value is of 100 
milliseconds - the tests showed it is enough for high quality 
retransmissions without any performance penalties.
>
> They changed a bit parameters to configure various timers from config 
> file, and they of course retained the ability to change fr_timer and 
> fr_inv_timer (interesting for controlling max ringing duration) 
> on-the-fly on a per-transaction basis.
>
> They also are currently developping a very interesting module called 
> "timer", which provides the ability to set timers on-the-fly, with 
> callback implemented as routes called when the custom timers fire. 
> This seems pretty simple in their model, the timer module being only 
> 408 lines long (but I can't tell if this works already or not).
I agree with you, there are a lot of thinks you can build, but the 
question is about their importance (as usage). as you know, we want to 
focus more one the hot topics (things really needed) and to avoid 
wasting resources for thinks not needed at that moment.
>
> An other puzzling fact is that SER's implementation of timers in tm 
> module is about half the size as OpenSER's .... I'm not sure we can 
> infer anything from this fact, still it made me curious.
well...size does not matter ;) - also the code structuring may differ. 
and so far I found no relation between size an quality for code :)


regards,
bogdan