On Nov 27, 2006 at 19:02, Bogdan-Andrei Iancu <[EMAIL PROTECTED]> 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 > >users. > > > >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 :-) Andrei _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
