[Devel] Re: [Serusers] Re: Fw: [Users] TM : retransmission timers
andrei at iptel.org
Mon Nov 27 23:14:38 CET 2006
On Nov 27, 2006 at 19:02, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
> small typo below...
> Bogdan-Andrei Iancu wrote:
> >Hi Klaus,
> >as the discussion about ser's improvements bounces again to openser, I
> >had to do a bit of digging to provide a correct answer to openser's
> >yes, there were some improvements did by Andrei to TM, mainly in timer
> >implementation. As you were wondering, the 0.9.6 SER should be
> >relatively close to openser 0.9.4 as TM performance and merging the
> >results from Vaclav with Andrei tests before the timer improvement in
> >SER 0.9.6, seams to be correct. See:
> > http://lists.iptel.org/pipermail/serdev/2005-December/006583.html
> >After this improvement, SER's 0.9.6 performances dramatically
> >increased, but unfortunately, according to our tests it is also
> >dramatically wrong. TM timers are not working correctly when variable
> >timeouts are used in SER.
> >With the improvement, the following scenario gets broken - 3 calls
> >only, no load, default cfg:
> >CALL 1: has 60 secs timeout for Final_response_timeout - nobody
> >answers, still ringing
> >in less than 2 secs ->
> >CALL 2: has 70 secs timeout - it is immediately answered.
> >in less than 2 secs ->
> >CALL 3: has 10 secs timeout for Final_response_timeout - nobody
> >answers, ringing.
> >Of course, everybody expects that CALL3 will timeout before CALL1
> >(with more than 40 secs), but in SER 0.9.6 (latest stable for the last
> >2 years), this will not happened - both CALL3 and CALL1 will timeout
> >simultaneously when the CALL3 timer hits.
Thanks a lot for the bug report.
> ^^ it is CALL1
> >It is a simple test that anybody can easily reproduce.
> >A lot of people are saying that OpenSER is a less stable, but dynamic
> >version of SER. Results say something else here.
> >"performance" should have no penalty over "stability", I would say.
> >This bug was not in the devel tree, but it is in the current SER
> >0.9.6 stable version for ~ 1 year.
> >In this case I would say it is not relevant how many CPS you have if
> >you cannot handle them correctly.
This get funny... :-)
Well this is a bug that appears _only_ when _variable_ timers are used
(which should not be used with the old tm code anyway) and only if you
catch a race (rather large, ~ 2 sec) and the worst that will happen is
that you'll have a timer extended to another value (last variable timer
used). Very dangerous :-)
More information about the Devel