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

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 &lt;bp4mls(a)googlemail.com&gt; >>> To: Kim Il &lt;kim_il_s(a)yahoo.com&gt; >>> Cc: users(a)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@yahoo.com>kim_il_s@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@googlemail.com>bp4mls@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@yahoo.com> kim_il_s(a)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(a)openser.org >>> <http://openser.org/cgi-bin/mailman/listinfo/users>http://openser.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Serusers mailing list >>> Serusers(a)lists.iptel.org >>> http://lists.iptel.org/mailman/listinfo/serusers >>> >> -- >> Jiri Kuthan http://iptel.org/~jiri/ >> _______________________________________________ >> Serusers mailing list >> Serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> >> >> > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > ------------------------------------------------------------------------ > > > Index: call.cpp > =================================================================== > --- call.cpp (revision 32) > +++ call.cpp (working copy) > @@ -1812,6 +1812,8 @@ > dest += sprintf(dest, "%s", (media_ip_is_ipv6 ? "6" : "4")); > } else if(!strcmp(keyword, "call_number")) { > dest += sprintf(dest, "%lu", number); > + } else if(!strcmp(keyword, "call_number_6")) { > + dest += sprintf(dest, "%06lu", number); > } else if(!strcmp(keyword, "call_id")) { > dest += sprintf(dest, "%s", id); > } else if(!strcmp(keyword, "cseq")) { > @@ -2246,6 +2248,19 @@ > return; > } > > + /* quick hack for UAS and loose router - needed to use routes + > * in the same order as Record-Routes */ > + if (bRequestIncoming) { > + dialog_route_set = (char *)calloc(1, strlen(rr) + 2); > + sprintf(dialog_route_set, "%s", rr); > + > + if (strlen (contact)) { > + strcpy (next_req_url, contact); > + formatNextReqUrl (next_req_url); > + } > + return; > + } > + char actual_rr[MAX_HEADER_LEN]; > char targetURI[MAX_HEADER_LEN]; > memset(actual_rr, 0, sizeof(actual_rr)); >