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

Jiri Kuthan wrote: enthusiasm, to way. The data stack, overall (unless the Yes - tm performance is fine, but from my practical experience external applications (database lookups, DNS lookups ...) are the real limitations. Maybe DNS lookups are not a bottleneck anymore in ser (due to caching), but this also only works for already cached results.

but with openser I can drive the shortest route whereas with ser I had to drive weird routes because of missing functions.

getting better with the select framework in Ottendorf - if only I could understand it.

Klaus off-topic for hide 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. 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. 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. 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. 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. an independent party: 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. 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. usefulness will be the same. show clearly response 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 ore TRANSPARENCY would be helpful for both projects so that users can be less investigative. 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. 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 :-) than playing around with different scenarios, platforms, environments. 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. 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 ;-). year, while OpenSER guys put up a nice show. My congrats. wrote: unbiased party that should do the judgment and not the parties who have something to gain. wrote: 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. :-) wrote: 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 a year on your phone bill. < http://clk.atdmt.com/VON/go/yhxxxvon1080000017von/direct/01/>Sign up now. http://openser.org/cgi-bin/mailman/listinfo/users -- Klaus Darilion nic.at _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers