[Serusers] Re: Fw: [Users] TM : retransmission timers

Klaus Darilion klaus.mailinglists at pernau.at
Mon Nov 27 17:17:52 CET 2006


Jiri Kuthan wrote:
> I think it can be quite many SER improvements actually. Timers, tm, some core
> changes too may collectively affect the performance. -jiri

I thought there will be only fixes to the 0.9. branch

regards
klaus


> 
> At 14:34 27/11/2006, Vaclav Kubart wrote:
>> I guess that it is an old improvement in ser, but running this test
>> against older ser versions could show which version was it...
>>
>>        Vaclav
>>
>> On Mon, Nov 27, 2006 at 01:25:06PM +0100, Klaus Darilion wrote:
>>> This leads to one question:
>>>
>>> Are there improvements to ser's stable branch since the fork, or is it 
>>> degradation in openser?
>>>
>>> regards
>>> klaus
>>>
>>> Vaclav Kubart wrote:
>>>> I'm sorry to nip in, but I tried to rerun the tests again and add more
>>>> info into output as requested and add stable ser and CVS openser.
>>>>
>>>> I know that this test doesn't conform much to real life (for example
>>>> generated callid/branch/tags differs only in a number, etc) but it can
>>>> give at least an image about simple stateful forward.
>>>>
>>>> So, if anybody is interested:
>>>>
>>>> http://www.iptel.org/~vku/performance/tm.serXopenser.correct/
>>>>
>>>> I tried the same once more with less iterations because there were some
>>>> errors in log from openser speaking about low memory (I used -m to
>>>> specify shared mem size but with 768M it still said errors, might be a
>>>> memleak or did I anything wrong?). With 1M iterations it was without
>>>> errors:
>>>>
>>>> http://www.iptel.org/~vku/performance/tm.serXopenser.1M/
>>>>
>>>>     Vaclav
>>>>
>>>> P.S. I have forgotten - SIPP was "Sipp v1.1, version 20060829, built Sep
>>>> 5 2006, 15:07:25", I'm attaching simple patch which I have used.
>>>>
>>>> On Wed, Nov 22, 2006 at 12:48:12AM +0200, Daniel-Constantin Mierla wrote:
>>>>> I love such "independent" and "very very useful" tests ... one selected 
>>>>> the versions he liked, latest development of ser with latest stable 
>>>>> version of openser, the details about testing scenarios are pretty 
>>>>> limited. However these details are very very insignificant, really.
>>>>>
>>>>> What matters is this particular case: what you tested is useless and 
>>>>> someone can better implement a tiny kernel module to perform same job 
>>>>> much faster that will make openser/ser trashed instantly if that is 
>>>>> their only usage. More important are the performances in real world 
>>>>> cases. I am not going to do comparison tests and reveal numbers, I will 
>>>>> let you do and hope make the results available.
>>>>>
>>>>> I will exemplify with just two common use cases:
>>>>> A) ITSP where usrloc is required - to get the throughput from your tests 
>>>>> one needs to have over million of online users. Let me know how SER is 
>>>>> doing with loading them, I can bet that it takes several minutes to 
>>>>> start (so service down for a significat time) and lot to lookup a record 
>>>>> afterwards, do not forget to mention required memory. Then we will see 
>>>>> if the forwarding throughput is the bottleneck.
>>>>> B) carrier - heavy accounting needed - take the latest cvs snapshots and 
>>>>> test it, look at flexibility in same time and see if the balance of 
>>>>> throughput and features is satisfactory. Do not forget that behind 
>>>>> database should be redundant for a reliable accounting storage.
>>>>>
>>>>> My conclusion and the point I wanted to underline is that forwarding is 
>>>>> not the bottleneck by far and so far in real-world deployments -- or at 
>>>>> least nobody reported in openser mailing lists. Once it will be, for 
>>>>> sure there will be effort and focus to optimize it. I don't even bother 
>>>>> to check the scenarios, environment and test results you had, because 
>>>>> makes no sense today.
>>>>>
>>>>> It is more important to look at the results gave, for example, here by 
>>>>> an independent party:
>>>>> http://openser.org/pipermail/users/2006-November/007777.html
>>>>>
>>>>> With a real config and clustering system the performance of a box was 
>>>>> 300calls per second -- having at least 5 database accesses!!!. If you 
>>>>> need double you can add one more hardware, without extra configuration 
>>>>> overhead, just plug and play. And that is stable version of OpenSER 
>>>>> since July this year (btw, for those who keep saying that OpenSER does 
>>>>> not focus on stability, just check the CVS and see the number of bugs 
>>>>> encountered with this release, maybe you can change your opinion), and 
>>>>> you can have a safe environment distributed geographically where each 
>>>>> hardware can undertake the traffic from the others on the fly. With 
>>>>> single box crashing because of different independent reasons (hardware 
>>>>> failure, power outages ...) you get no service ... with three boxes you 
>>>>> can serve huge number of active subscribers in peak hours and have 
>>>>> failover support, so service availability 100%. I am sure most of the 
>>>>> people look now how to build reliable platforms that scale very easy and 
>>>>> can be distributed around the world, with a bunch of useful features -- 
>>>>> simple first line replacement is not the business case for VoIP anymore.
>>>>>
>>>>> We didn't try at OpenSER to get a airplane when we have to drive city 
>>>>> streets, we looked to get feature rich and reliable application for its 
>>>>> use cases. I would propose to have focus on making own applications 
>>>>> better than trying to show the other one is worse.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>> PS. You can use stateless forwarding to get even better results, the 
>>>>> usefulness will be the same.
>>>>>
>>>>> On 11/21/06 12:30, Jiri Kuthan wrote:
>>>>>> Regarding the technical discussion, here are some hard numbers which show
>>>>>> how SER stack outperforms derivative work. Forwarding throughput is 
>>>>>> clearly
>>>>>> several times better under stress and consequently, variation of response
>>>>>> delay is rather stable.
>>>>>>
>>>>>>
>>>>>>> http://www.iptel.org/~vku/performance/tm.serXopenser.pulpuk/
>>>>>>>   
>>>>>> -jiri
>>>>>>
>>>>>>
>>>>>> At 21:16 09/11/2006, Rao Ramaratnamma wrote:
>>>>>>
>>>>>>> Hi Weiter,
>>>>>>>
>>>>>>> Yeah, I have been trying to limit myself to technical observations too, 
>>>>>>> but the governance aspect is somewhat interesting too as a hint for 
>>>>>>> future development, even though I guess even this is much more 
>>>>>>> confusing than the technical ones. I have investigated, both projects 
>>>>>>> have their firms with them that pursue their commercial interests which 
>>>>>>> creates a risk of possibly departing from the public interest, like 
>>>>>>> with redhat. 
>>>>>> >From this angle they look quite similar. But if any worries me just a 
>>>>>>> little bit more than openser.  Appearance at commercial shows on the 
>>>>>>> "open" side versus technical event on the "net" side if I take your BSD 
>>>>>>> parallel, marketing "open" webpage accusing "net" version bad, hiding 
>>>>>>> root commerical sponsors on the "open" webpage, this could be signs for 
>>>>>>> a redhat-like doubleedged sword.  Hopefully I am oversensing because I 
>>>>>>> mean it is natural that everybody has SOME interest, but indisputably 
>>>>>>> folks on both sides have done good work, but same indisputably more 
>>>>>>> TRANSPARENCY would be helpful for both projects so that users can be 
>>>>>>> less investigative.
>>>>>>>
>>>>>>> But I agree the technical comparison you suggest will be very useful if 
>>>>>>> not most useful. This is what I am eventually upto. Anything folks have 
>>>>>>> to tell in this topic is most welcome like the retransmission timers in 
>>>>>>> subject or user loading.
>>>>>>>
>>>>>>> rr
>>>>>>>
>>>>>>> disconcerted by the fact that the more I know the more I am confused 
>>>>>>> and determined to get over the learning curve quickly. also excuse the 
>>>>>>> abuse I crossposted again but I think cross interrogation is a bit 
>>>>>>> painful but the more effective :-)
>>>>>>>
>>>>>>> ----- Original Message ----
>>>>>>> From: Weiter Leiter <bp4mls at googlemail.com>
>>>>>>> To: Kim Il <kim_il_s at yahoo.com>
>>>>>>> Cc: users at openser.org
>>>>>>> Sent: Thursday, November 9, 2006 1:42:29 PM
>>>>>>> Subject: Re: Fw: [Users] TM : retransmission timers
>>>>>>>
>>>>>>> Common user barely has time to meet his boss requirements, rather than 
>>>>>>> playing around with different scenarios, platforms, environments. 
>>>>>>> I only read one email where Daniel stated that OpenSER now performs a 
>>>>>>> whole much better while loading users from database. SER guys put no 
>>>>>>> figure out yet, neither bare numbers nor comparisons. I'm just really 
>>>>>>> curious to see how both servers perform, that's all. 
>>>>>>> Even though I must maintain my SER, I kinda like OpenSER's faster 
>>>>>>> releases and developers' responsiveness (that I shamelessly exploit for 
>>>>>>> the common code left there :-), which is pretty much nonexistent with 
>>>>>>> iptel (at least this is the general belief here at OpenSER). But about 
>>>>>>> this I'll probably have to fight on SER's mailing list. I still wish 
>>>>>>> that one day I won't have to compare features; heck, NetSER and FreeSER 
>>>>>>> are still available ;-). 
>>>>>>> WL.
>>>>>>>
>>>>>>> PS. Maybe regretfully, I haven't seen any iptel booth at von this year, 
>>>>>>> while OpenSER guys put up a nice show. My congrats.
>>>>>>>
>>>>>>> On 11/9/06, Kim Il <<mailto:kim_il_s at yahoo.com>kim_il_s at yahoo.com> 
>>>>>>> wrote: I can see what you are hinting at, but I guess that the users 
>>>>>>> are the unbiased party that should do the judgment and not the parties 
>>>>>>> who have something to gain.
>>>>>>> cheers
>>>>>>>
>>>>>>> Weiter Leiter <<mailto:bp4mls at googlemail.com>bp4mls at googlemail.com> 
>>>>>>> wrote:  This features comparisons are not to last for too long, some 
>>>>>>> performance comparisons would also be nice. After all, there are plenty 
>>>>>>> of UA-level stacks out there. At least now that both projects get to 
>>>>>>> have stable releases after forking and some core functionality remained 
>>>>>>> shared. I wonder what "unbiased" organization will take up the 
>>>>>>> challenge. :-)
>>>>>>> On 11/8/06, Kim Il <<mailto:kim_il_s at yahoo.com> kim_il_s at yahoo.com > 
>>>>>>> wrote:  Mike,
>>>>>>> this is a really good start and we should collect these things  so as 
>>>>>>> to help the  community to take the right choice. I would also suggest 
>>>>>>> that what ever ground breaking issues we list we stay at the functional 
>>>>>>> level (I do not think anyone is helped by using a description 
>>>>>>> containing "allowing carrier grade platforms" and similar marketing 
>>>>>>> phrases). cheers
>>>>>>>
>>>>>>>
>>>>>>> {truncated because too large}
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sponsored Link 
>>>>>>> Talk more and pay less. Vonage can save you up to $300 a year on your 
>>>>>>> phone bill. 
>>>>>>> <http://clk.atdmt.com/VON/go/yhxxxvon1080000017von/direct/01/>Sign up 
>>>>>>> now. 
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users at openser.org
>>>>>>> <http://openser.org/cgi-bin/mailman/listinfo/users>http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Serusers mailing list
>>>>>>> Serusers at lists.iptel.org
>>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>>   
>>>>>> --
>>>>>> Jiri Kuthan            http://iptel.org/~jiri/  
>>>>>>
>>>>>> _______________________________________________
>>>>>> Serusers mailing list
>>>>>> Serusers at lists.iptel.org
>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> Serusers at lists.iptel.org
>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> Serusers at lists.iptel.org
>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>> -- 
>>> Klaus Darilion
>>> nic.at
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
> 
> --
> Jiri Kuthan            http://iptel.org/~jiri/ 
> 


-- 
Klaus Darilion
nic.at




More information about the sr-users mailing list