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

Wed Nov 22 12:53:52 CET 2006

While trying to remain equidistant:

On 11/22/06, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
>
> Jiri Kuthan wrote:
> > 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.
>
> 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.

 You are right, but these bottle necks affect both projects. I wouldn't
count it as a discriminator. Or do you see improvements in either project in
the way they access the DB at runtime? I know that OpenSER loads (only?)
faster.

Let me compare with cars. ser is the much more fast car then openser,
> but with openser I can drive the shortest route whereas with ser I had
> to drive weird routes because of missing functions.

I believe that naming such functionality would help in this kind of
sessions. (I have my wish list for both, as well.)
But I'm still not sure whether there got to be an open feature list and a
roadmap for SER.

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

I find it pretty easy to use, but I join you in denouncing that the
documentation is lagging behind, something that becomes chronic for SER; the
only thing I found is the mentioning under "Attribute-value pairs and
selects" and I know for sure there is more to be said, not so intuitive.

WL.

regards
> Klaus
>
> > 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
> 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 m
> ore 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
> >>>
> >>>
> >> --
> >> Jiri Kuthan            http://iptel.org/~jiri/
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20061122/9e9fefeb/attachment.htm 