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

Hi Daniel, thank you for your speech. I do not wish to discourage you in your enthusiasm, but at the same moment I prefer to rely on accurate measurements and not to spend time on undermining their results or relevance in a derogative way. The data shows quite clearly the performance of the underlying "engine", the stack, which is part of every server's doing and has *inherent* impact on the overall performance and consequently scalability in whatever setup you have (unless the setup relies on some underperforming techniques). That's what it is.

Other than that, I have not really seen enough *facts* in your later off-topic paragraphs (regarding reliability, stability, airplanes, misleading and non-applicable suggestions for stateles forwarding) to provide grounds for a debate with some tangible result -- hope you don't mind I don't join. You really cannot compare oranges to apples without loss of substance. I mean doing arbitrarily underperforming network design can perfectly hide underperforming software but that's not excuse for the latter. -jiri At 23:48 21/11/2006, 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

> > 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 m

_______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers