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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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 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 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 <
kim_il_s@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.
Sign up now.
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Rao, Thanks for keeping this discussion going. I agree that more transparency is needed, and we are working on that.
Let me help you out with some facts: - iptel.org is an open-source community open to anybody who wants to contribute, on development, documentation, or community - iptel.org is not only focused on SER, but also on SERWeb, SEMS, rtpproxy, as well as advancing SIP in general (the free SIP service, SIP information, the product database...) - Many of the current developers of current SER are employed by what was formerly known as iptelorg.com, now Tekelec, while many others (including me) have no affiliation at all with iptelorg.com/Tekelec - Anyone participating in iptel.org work can get an iptel.org email address (and anyone using the free SIP service will have an iptel.org SIP account) - Commercial iptelorg.com/Tekelec is focused on large-scale SIP server deployments for telecom companies, both IETF SIP and IMS - Open-source SER has a life and purpose on its own founded on a handful of resourceful individuals who, though employed by iptelorg.com/Tekelec, also spend personal time on the project due to their interest in SIP (and would do so even if they changed jobs) - The features developed by SER developers at iptelorg.com/Tekelec are partly influenced by what they do in their day job and partly what they feel is important to SER as an open-source SIP server - Other developers/contributors are influenced by *their* projects/dayjobs/visions for SER - Anybody can contribute ideas and try to get a "sponsor" (developer) for that functionality on serdev (or contribute code themselves) - The iptel.org website, the SER - Getting Started document and much other documentation is focused on the advancement of SIP, and we don't really worry too much about whether people use ser or openser (in fact, an effort to write an openser Getting Started document is in progress, and we'll try to coordinate as much as possible on what is common) - SER is an open-source project that has much to improve when it comes to documentation and transparency in processes, but we are making good progress - SER open-source project is about quality, reliability and large-scale setups with longer turn-around time on new releases and longer support for older versions than what is normal for open-source projects. However, we have discussed introducing a new development track making new features more easily accessible for those who want "bleeding edge" - Documentation improvements for SER will be in areas important for SIP professionals, including release predictability, migration documentation, scripting, quality improvements in best practices for ser.cfg etc - SER's development will not be better than the people contributing and everybody can make an effort
I don't want to say anything bad about OpenSER. Most "old-timers" on serusers know that I didn't like the fork, I think it would have been possible to do things within (a better governed) shared open-source project, but the community was never allowed to say its meaning and personal differences probably made it impossible. OpenSER have done good things and some good people contribute code to the project.
As for VON, I'm not sure if Tekelec was there, probably not, but the absence of a booth for iptel.org is more due to the fact that iptel.org is a loose collection of individuals with sponsorship from FOKUS Fraunhofer and iptelorg.com/Tekelec and not an entity that has resources (or inclinations) to do commercial efforts.
g-)
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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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* <kim_il_s@yahoo.com mailto: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 <bp4mls@googlemail.com <mailto: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* < kim_il_s@yahoo.com <mailto:kim_il_s@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. Sign up now. <http://clk.atdmt.com/VON/go/yhxxxvon1080000017von/direct/01/>
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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 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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
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.
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. Probably this is getting better with the select framework in Ottendorf - if only I could understand it.
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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Klaus Darilion wrote:
to drive weird routes because of missing functions. Probably this is getting better with the select framework in Ottendorf - if only I could understand it.
I posted the description of the framework to serdev some time ago. The idea is very simple, selects are denoted by @ in the configuration file. The name of the select will be translated into a function which returns the relevant part of the SIP message/transport information.
For example @ruri.user will call function select_uri_user which will be given the Request-URI as the parameter and the function will return the username part of the URI.
Select identifiers are translated into function calls using translation trees stored in form of select_row_t tables. This is similar to how SER looks up module functions.
See also: http://www.iptel.org/attribute_value_pairs_and_selects
Jan.
While trying to remain equidistant:
On 11/22/06, Klaus Darilion klaus.mailinglists@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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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/%3ESign up now.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
http://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Weiter Leiter wrote:
While trying to remain equidistant:
On 11/22/06, Klaus Darilion klaus.mailinglists@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.
Nothing that I am aware. But using openser instead of ser (0.9) I could get rid of some external scipts and overall performance was better - but as I said this was with old ser - Ottendorf probably also allows better more flexible routing.
Maybe Ottendorf is better (faster, more flexible) than current openser - but some months ago IMO openser was the only reasonable choice. But I think Ottendorf wont be that fast/flexible when it is about adding new features (applying patches ...)
Thus, when choosing a SIP proxy, there are more attributes which have to be considered except performance.
regards Klaus
At 12:53 22/11/2006, Weiter Leiter wrote: ...
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.)
Just curious what your "wish list" is?
But I'm still not sure whether there got to be an open feature list and a roadmap for SER.
Actually a roadmap suggestion is in the ottendorf release announcement http://www.iptel.org/new_major_ser_pre_release_ottendorf_is_out_for_testing It is kind of testing balloon -- wondering if people would like to comment on it.
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;
badly, I have to join you too :-) anyhow, if you occur to have some examples or text to share, that would be just fantastic.
Also I recall you once mentioned some fast-usrloc-loading feature in an email I can't find -- could you share with me what this actually is?
thanks!
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
At 12:53 22/11/2006, Weiter Leiter wrote:
I know that OpenSER loads (only?) faster.
Can folks share with me what the fast-usrloc-loading feature is about? I was not successful finding it out.
Thanks!
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Maybe you are looking for this one: http://www.openser.org/index.php?option=com_content&task=view&id=48&...
Regards, Ovidiu Sas
On 11/30/06, Jiri Kuthan jiri@iptel.org wrote:
At 12:53 22/11/2006, Weiter Leiter wrote:
I know that OpenSER loads (only?) faster.
Can folks share with me what the fast-usrloc-loading feature is about? I was not successful finding it out.
Thanks!
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
At 23:48 21/11/2006, Daniel-Constantin Mierla wrote:
I would propose to have focus on making own applications better than trying to show the other one is worse.
Hi Daniel,
I actually think that providing undisputable measurements is a good thing to do for knowledge. Knowledge is never too dear :-) (Sir Welsingham) Something is rotten in the state of Denmark (W.S.), though....
What surprises me is that with this strong opinion of yours, your own company actually displays comparisons with outdated software on its website: http://www.openser.org/index.php?option=com_content&task=view&id=44
There is another webpage which really makes me puzzled. It is called "OpenSER History" http://openser.org/index.php?option=com_content&task=view&id=40&.... The owner of the website, Voice Sistem SRL, which I believe you are affiliated with, suggests in a twisted language that SER has been purposely discontinued. I'm being told that some other personal affiliated with the same company more or less copied-n-pasted TCP code from the allegibly discontinued SER to OpenSER.
So can you confirm for me that Voice Sistem SRL takes NEW code from SER of it which it says it is NOT being continued on its webpage?
This is really not a most pleasant conversation I can think of, but I am really *very* interested in your answers.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri Kuthan wrote:
At 23:48 21/11/2006, Daniel-Constantin Mierla wrote:
I would propose to have focus on making own applications better than trying to show the other one is worse.
Hi Daniel,
I actually think that providing undisputable measurements is a good thing to do for knowledge. Knowledge is never too dear :-) (Sir Welsingham) Something is rotten in the state of Denmark (W.S.), though....
What surprises me is that with this strong opinion of yours, your own company actually displays comparisons with outdated software on its website: http://www.openser.org/index.php?option=com_content&task=view&id=44
Openser users know that this is an rather old comparison. Nevertheless, to avoid confusing newbies I would suggest adding a timestamp of the comparison and detailed version information.
There is another webpage which really makes me puzzled. It is called "OpenSER History" http://openser.org/index.php?option=com_content&task=view&id=40&.... The owner of the website, Voice Sistem SRL, which I believe you are affiliated with, suggests in a twisted language that SER has been purposely discontinued.
Apperently Ottendorf proves this to be wrong. Although I ever wondered if there will come a new ser release (no roadmap). This site needs an update ...
I'm being told that some other personal affiliated with the same company more or less copied-n-pasted TCP code from the allegibly discontinued SER to OpenSER.
That's how open source works. I also copied lots of TLS extensions from ser to openser, and even extended it. You can also copy my extensions back to ser ... I would love to see it there :-)
regards Klaus
So can you confirm for me that Voice Sistem SRL takes NEW code from SER of it which it says it is NOT being continued on its webpage?
This is really not a most pleasant conversation I can think of, but I am really *very* interested in your answers.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Nov 22, 2006 at 12:39, Klaus Darilion klaus.mailinglists@pernau.at wrote: [...]
I'm being told that some other personal affiliated with the same company more or less copied-n-pasted TCP code from the allegibly discontinued SER to OpenSER.
That's how open source works. I also copied lots of TLS extensions from ser to openser, and even extended it. You can also copy my extensions back to ser ... I would love to see it there :-)
I'm sure Jiri has no problem with copying code from ser to openser. We will do the same with some openser modules and we already did with some fixes. The problem here was that it was claimed that ser was dead but in the same time new code commited in ser was added in openser (so the openser history writer was not very well intended).
Speaking of copying/porting ser between ser and openser I have a few requests:
1. If someone sends a fix for code taken from ser, which was not modified in openser, please could you also bounce the message to the ser maintainer of that piece of code? If you don't to whom, just send it to me and I will make sure it reaches the right person. I'm asking this because my favourite pass-time is not to scan openser commitlogs for possible fixes to my code (e.g.:http://openser.cvs.sourceforge.net/openser/sip-server/fastlock.h?r1=1.2&...) and this will help me at a minimum effort for the openser developer part. Of course I think this is true not only for me, but also for other ser and openser developers and I (and I'm sure anybody else on the ser team) will return the favour.
2. Please give proper credits for the code you port from ser. I've saw several times things like: Foo sees something was fixed in ser or a new small feature was added and sends an email to the openser list (specifying that the change/patch comes form ser). The openser developers take the change, but the commit message says something like: fix for XyZ, credits go to Foo (ser is not mentioned at all). It would not only be polite, but it will also help us to filter more easily through the openser fixes.
Comming back to the openser - ser performance / features discussion, I think the important part here is how we can improve both sers (and you should take the test results as a bug report and maybe ask yourself how did this go through testing, even old sers were faster then 4000 cps). If you think only of the users, then a combination of ser & openser will be the best version. While we disagree (probably) in many respects, I think there are at least a few clear advantages each version has. For example openser has very impressive documentation (at this time ser is very far away from this point of view) and lots of new modules. ser has also its share of new modules (though I think not so many) and a better/improved "infrastructure" (core, tm and lots of the "base" modules - we are actively improving them). ser code tends to also be more tested and stable (our release policies differ wildly). I've tried looking at openser core & tm commits and I haven't seen any significant changes (and this is not a flamewar attempt). Now the question is why doesn't openser take the core, tm and a big part of the modules from ser completely and concentrate then in adding new modules (which you seem to do anyway)? Does it make sense to re-invent the wheel ? Everybody (me too) suffers at least a little from the not-invented-here syndrome, but if you think of the users and at how much of your time it will save, it will make a lot of sense, even if some compromises would be necessary. I think the advantages will far outweigh the problems. Just think about it, we can concentrate each other on our favourite stuff and we can benefit much more easily from each other's work.
Andrei
Hi Andrei!
Andrei Pelinescu-Onciul wrote:
On Nov 22, 2006 at 12:39, Klaus Darilion klaus.mailinglists@pernau.at wrote: [...]
I'm being told that some other personal affiliated with the same company more or less copied-n-pasted TCP code from the allegibly discontinued SER to OpenSER.
That's how open source works. I also copied lots of TLS extensions from ser to openser, and even extended it. You can also copy my extensions back to ser ... I would love to see it there :-)
I'm sure Jiri has no problem with copying code from ser to openser. We will do the same with some openser modules and we already did with some fixes. The problem here was that it was claimed that ser was dead but in the same time new code commited in ser was added in openser (so the openser history writer was not very well intended).
As I already said (maybe to less explicit) this is obviously false and should be fixed.
Speaking of copying/porting ser between ser and openser I have a few requests:
- If someone sends a fix for code taken from ser, which was not
modified in openser, please could you also bounce the message to the ser maintainer of that piece of code? If you don't to whom, just send it to me and I will make sure it reaches the right person. I'm asking this because my favourite pass-time is not to scan openser commitlogs for possible fixes to my code (e.g.:http://openser.cvs.sourceforge.net/openser/sip-server/fastlock.h?r1=1.2&...) and this will help me at a minimum effort for the openser developer part. Of course I think this is true not only for me, but also for other ser and openser developers and I (and I'm sure anybody else on the ser team) will return the favour.
This is a practice which must be done by the core developers. I often see bug fixes, but for me it is impossible to know if the fixes are for original ser code or for new code. In the beginning I watched the ser's CVS commits and forwarded fixes to the openser list. Some of them were applied to openser too, but not all of them.
I agree it would be nice if the core developers exchange fixes for common code - maybe a common mailing list would help for this?
- Please give proper credits for the code you port from ser.
I've saw several times things like: Foo sees something was fixed in ser or a new small feature was added and sends an email to the openser list (specifying that the change/patch comes form ser). The openser developers take the change, but the commit message says something like: fix for XyZ, credits go to Foo (ser is not mentioned at all). It would not only be polite, but it will also help us to filter more easily through the openser fixes.
I agree - it should be explicitly mentioned when a patch comes from ser.
Comming back to the openser - ser performance / features discussion, I think the important part here is how we can improve both sers (and you should take the test results as a bug report and maybe ask yourself how did this go through testing, even old sers were faster then 4000 cps).
You think the current openser has a bug because of the low performance? In this case it would be interesting to see how stable ser (0.9.x) compares to openser - if there is really a loss of speed in openser's tm module compared to its roots (ser 0.9)
If you think only of the users, then a combination of ser & openser will be the best version.
Of course - I was not happy about the split because it was clear that some features will be only in one of the two branches.
While we disagree (probably) in many respects, I think there are at least a few clear advantages each version has. For example openser has very impressive documentation (at this time ser is very far away from this point of view) and lots of new modules.
I agree - that's one of the reasons I prefer using openser also in new installations.
I still wonder why you do not the same. Autogenerate the README files from the xml files and put them on the webpage - this is what openser did (and some improving of the README).
You started a wiki which must be filled - thus you are starting from ground although there is already lots of documentation in the READMEs.
Further, I often see commits in ser with new features but without documentation. In openser it is not allowed to introduce new features without writing a documentation patch. Why isn't there the same rule in ser?
ser has also its share of new modules (though I think not so many) and a better/improved "infrastructure" (core, tm and lots of the "base" modules - we are actively improving them). ser code tends to also be more tested and stable (our release policies differ wildly).
Probably faster release cycles does not allow such heavy testing as you do - nevertheless openser1.0 was real heavy tested (by me).
I've tried looking at openser core & tm commits and I haven't seen any significant changes (and this is not a flamewar attempt).
Aren't the pseudo variables vs. select framework significant changes? Also TLS in core vs. TLS as module?
Now the question is why doesn't openser take the core, tm and a big part of the modules from ser completely and concentrate then in adding new modules (which you seem to do anyway)? Does it make sense to re-invent the wheel ?
I would like to see that too - although I sometimes commit code I am rather a user than a developer and of course I would like to benefit from all the new features in ser and openser.
Probably it is a matter of time. Replacing openser's core is sure lot of work. And maybe it is done if openser's core/tm will become a bottleneck.
Everybody (me too) suffers at least a little from the not-invented-here syndrome, but if you think of the users and at how much of your time it will save, it will make a lot of sense, even if some compromises would be necessary. I think the advantages will far outweigh the problems. Just think about it, we can concentrate each other on our favourite stuff and we can benefit much more easily from each other's work.
I'm completely with you - but this is something the developers have to agree - not the users (me).
regards klaus
On Nov 23, 2006 at 11:43, Klaus Darilion klaus.mailinglists@pernau.at wrote:
[...]
I've tried looking at openser core & tm commits and I haven't seen any significant changes (and this is not a flamewar attempt).
Aren't the pseudo variables vs. select framework significant changes? Also TLS in core vs. TLS as module?
Ok. I've meant openser core vs ser 0.9.4, or if you want what openser core has extra compared to ser 0.10.99 (speaking of bigger features, probably only the statistics part and the new MI, which seems to correspond to ser's RPC, so I wouldn't call it an extra, but re-inventing the wheel). If we are talking the other way arround, ser core has evolved much more (avps in script, select, timers, dns, blacklist a.s.o). That's one of the reason I'm suggesting that it would be a good ideea to switch to it (and at least tm), besides performance tunning and extra-testing.
[...]
Andrei
Andrei Pelinescu-Onciul wrote:
On Nov 23, 2006 at 11:43, Klaus Darilion klaus.mailinglists@pernau.at wrote:
[...]
I've tried looking at openser core & tm commits and I haven't seen any significant changes (and this is not a flamewar attempt).
Aren't the pseudo variables vs. select framework significant changes? Also TLS in core vs. TLS as module?
Ok. I've meant openser core vs ser 0.9.4, or if you want what openser core has extra compared to ser 0.10.99 (speaking of bigger features, probably only the statistics part and the new MI, which seems to correspond to ser's RPC, so I wouldn't call it an extra, but re-inventing the wheel). If we are talking the other way arround, ser core has evolved much more (avps in script, select, timers, dns, blacklist a.s.o). That's one of the reason I'm suggesting that it would be a good ideea to switch to it (and at least tm), besides performance tunning and extra-testing.
I would be happy if openser would switch to Ottendorf's core. But seeing all the changes in Ottendorf I think it will be quite complex to use Ottendorf's core inside openser.
regards klaus
Andrei,
just *one* reply from my side, as I really do not like to get into this discussion.
First of all I say all your opinions and statements about openser are based on a glimpse over the project and they reflect neither that you really understand it, nor you followed all the changes and improvements we had.
So, please excuse me, but I cannot find as valid statements your sayings like : ser is faster, ser has more in core, ser has these and these..... Of course, in your quest, you forgot to take into account all the clean-up and speed-ups in acc, usrloc, register, tm , etc module -core also-, the new feature and modules, that openser had PV from the beginning or the fact that most ser's adds-on actually followed the original roadmap of openser (posted on the web site). But I do not accuse you, because it is not your job to follow openser's evolution, so things may escape you.
So, let us talk about things we really know. And do not think that the difference between ser and openser it's only about code....a project is not only the code..it is policy and attitude and respect regarding the community.
Definitely we will try to consider the things you found unjust (like mentioning the project along the contributor's name). We do not want to bother anybody - in fact you probably notice that from openser side there was no negative posts (about ser) on the mailing list or web - just the truth with your own words. I really do not understand your attitude :(.
I just wanted to express my opinion about this discussion which hopefully goes to an end.
All the best regards, Bogdan
Andrei Pelinescu-Onciul wrote:
On Nov 23, 2006 at 11:43, Klaus Darilion klaus.mailinglists@pernau.at wrote:
[...]
I've tried looking at openser core & tm commits and I haven't seen any significant changes (and this is not a flamewar attempt).
Aren't the pseudo variables vs. select framework significant changes? Also TLS in core vs. TLS as module?
Ok. I've meant openser core vs ser 0.9.4, or if you want what openser core has extra compared to ser 0.10.99 (speaking of bigger features, probably only the statistics part and the new MI, which seems to correspond to ser's RPC, so I wouldn't call it an extra, but re-inventing the wheel). If we are talking the other way arround, ser core has evolved much more (avps in script, select, timers, dns, blacklist a.s.o). That's one of the reason I'm suggesting that it would be a good ideea to switch to it (and at least tm), besides performance tunning and extra-testing.
[...]
Andrei
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan,
This seems similar to the same message I wrote about this earlier. New users don't seem to be able to see all of the great work that has been done since OpenSER forked, or any of the original reasons why OpenSER was forked, especially now that SER seems to have learned from OpenSER how to better treat the users community.
In response to this, I think someone needs to start a wiki page about the differences, and I think another page needs to be dedicated to the progress OpenSER has made since the fork. This would highlight true advantages and disadvantages of using OpenSER over SER, and would also show the real amount of work that the OpenSER team has done.
I'll try to get something started over this weekend, if I have time.
Mike Williams
On Thursday 23 November 2006 07:36, Bogdan-Andrei Iancu wrote:
Andrei,
just *one* reply from my side, as I really do not like to get into this discussion.
First of all I say all your opinions and statements about openser are based on a glimpse over the project and they reflect neither that you really understand it, nor you followed all the changes and improvements we had.
So, please excuse me, but I cannot find as valid statements your sayings like : ser is faster, ser has more in core, ser has these and these..... Of course, in your quest, you forgot to take into account all the clean-up and speed-ups in acc, usrloc, register, tm , etc module -core also-, the new feature and modules, that openser had PV from the beginning or the fact that most ser's adds-on actually followed the original roadmap of openser (posted on the web site). But I do not accuse you, because it is not your job to follow openser's evolution, so things may escape you.
So, let us talk about things we really know. And do not think that the difference between ser and openser it's only about code....a project is not only the code..it is policy and attitude and respect regarding the community.
Definitely we will try to consider the things you found unjust (like mentioning the project along the contributor's name). We do not want to bother anybody - in fact you probably notice that from openser side there was no negative posts (about ser) on the mailing list or web - just the truth with your own words. I really do not understand your attitude :(.
I just wanted to express my opinion about this discussion which hopefully goes to an end.
All the best regards, Bogdan
Andrei Pelinescu-Onciul wrote:
On Nov 23, 2006 at 11:43, Klaus Darilion klaus.mailinglists@pernau.at wrote:
[...]
I've tried looking at openser core & tm commits and I haven't seen any significant changes (and this is not a flamewar attempt).
Aren't the pseudo variables vs. select framework significant changes? Also TLS in core vs. TLS as module?
Ok. I've meant openser core vs ser 0.9.4, or if you want what openser core has extra compared to ser 0.10.99 (speaking of bigger features, probably only the statistics part and the new MI, which seems to correspond to ser's RPC, so I wouldn't call it an extra, but re-inventing the wheel). If we are talking the other way arround, ser core has evolved much more (avps in script, select, timers, dns, blacklist a.s.o). That's one of the reason I'm suggesting that it would be a good ideea to switch to it (and at least tm), besides performance tunning and extra-testing.
[...]
Andrei
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
At 13:36 23/11/2006, Bogdan-Andrei Iancu wrote:
Hi Bogdan,
/* still largely catching on emails */ ....
fact that most ser's adds-on actually followed the original roadmap of openser (posted on the web site).
Can you please make me a favor and show me evidence of what specific features have been actually followed by SER?
But I do not accuse you, because it is not your job to follow openser's evolution, so things may escape you.
So, let us talk about things we really know. And do not think that the difference between ser and openser it's only about code....a project is not only the code..it is policy and attitude and respect regarding the community.
I violently agree. I fear we may be understanding something else under that, but I hope the email I posted recently hopefuly makes a fair and understandable point: http://openser.org/pipermail/users/2006-November/007875.html
In this spirit I suggest folks really begin to be serious about what they post. I think marvellous achievements like openser doc or ottendorf overhaul should not be dragged by discussions which are just not worth it.
Definitely we will try to consider the things you found unjust (like mentioning the project along the contributor's name). We do not want to bother anybody - in fact you probably notice that from openser side there was no negative posts (about ser) on the mailing list or web - just the truth with your own words. I really do not understand your attitude :(.
I think the questions are coming from my Nov-22 email (http://lists.iptel.org/pipermail/serusers/2006-November/031423.html) --you might have possibly missed that, because my emails didn't quite make it to openser archives.
Looking forward to your consideration results,
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Vaclav!
Thanks for the tests. Interesting that openser's tm is much slower than ser 0.9.6. Hmm.
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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Klaus, you are welcome. ;-)
Yes, it is interesting. I didn't explore it deeply because of not much time.
I'm interested if somebody could repeat this test or something similar (may be better than the same) if I didn't a mistake somewhere...
Vaclav
On Mon, Nov 27, 2006 at 12:46:58PM +0100, Klaus Darilion wrote:
Hi Vaclav!
Thanks for the tests. Interesting that openser's tm is much slower than ser 0.9.6. Hmm.
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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Hi All!
I've been trying to enable to blind forward functinality I did everything as it is writen in the getting started manual.
I have the following record in the database: mysql> select * from ser.usr_preferences where attribute = 'callfwd'; +------+----------+-------------------+-----------+---------------------------+------+---------------------+ | uuid | username | domain | attribute | value | type | modified | +------+----------+-------------------+-----------+---------------------------+------+---------------------+ | | test | scscf.ims.touk.pl | callfwd | sip:tzl@scscf.ims.touk.pl | 0 | 2006-11-27 11:57:55 | +------+----------+-------------------+-----------+---------------------------+------+---------------------+ 1 row in set (0.00 sec)
Whenever i try to call the test@scsct.im.touk.pl i receive the following reply from ser: SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.0.106:7000;rport=7000;branch=z9hG4bK7F6EAC5A9DD87C21CC2797D4722BBA05
From: tzl sip:tzl@scscf.ims.touk.pl:7000;tag=1499009376
To: sip:test@scscf.ims.touk.pl;tag=9463a2e9cf4445c72e97ac31aeb7f1ed.303b
Call-ID: 4833F4EA-84DA-95F7-5728-DB7036530039@192.168.0.106
CSeq: 111 INVITE
Proxy-Authenticate: Digest realm="scscf.ims.touk.pl", nonce="456aed756ad518cbd0b2e3a59239eaf72552cee2"
Server: Sip EXpress router (0.9.7-pre1 (x86_64/linux))
Content-Length: 0
Warning: 392 scscf.ims.touk.pl:5060 "Noisy feedback tells: pid=20052 req_src_ip=192.168.0.74 req_src_port=5060 in_uri=sip:tzl@scscf.ims.touk.pl out_uri=sip:tzl@scscf.ims.touk.pl via_cnt==2"
In the attachment i placed my ser.cfg file I kindly ask for your help. Bests Tomek
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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
I think it can be quite many SER improvements actually. Timers, tm, some core changes too may collectively affect the performance. -jiri
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...
VaclavOn 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/
VaclavP.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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
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...
VaclavOn 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/
VaclavP.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@googlemail.com > To: Kim Il kim_il_s@yahoo.com > Cc: users@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.comkim_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.combp4mls@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@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@openser.org > http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Serusers mailing list > Serusers@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers
>
Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Hi Klaus,
as the discussion about ser's improvements bounces again to openser, I had to do a bit of digging to provide a correct answer to openser's users.
yes, there were some improvements did by Andrei to TM, mainly in timer implementation. As you were wondering, the 0.9.6 SER should be relatively close to openser 0.9.4 as TM performance and merging the results from Vaclav with Andrei tests before the timer improvement in SER 0.9.6, seams to be correct. See: http://lists.iptel.org/pipermail/serdev/2005-December/006583.html
After this improvement, SER's 0.9.6 performances dramatically increased, but unfortunately, according to our tests it is also dramatically wrong. TM timers are not working correctly when variable timeouts are used in SER.
With the improvement, the following scenario gets broken - 3 calls only, no load, default cfg:
CALL 1: has 60 secs timeout for Final_response_timeout - nobody answers, still ringing in less than 2 secs -> CALL 2: has 70 secs timeout - it is immediately answered. in less than 2 secs -> CALL 3: has 10 secs timeout for Final_response_timeout - nobody answers, ringing.
Of course, everybody expects that CALL3 will timeout before CALL1 (with more than 40 secs), but in SER 0.9.6 (latest stable for the last 2 years), this will not happened - both CALL3 and CALL1 will timeout simultaneously when the CALL3 timer hits.
It is a simple test that anybody can easily reproduce.
A lot of people are saying that OpenSER is a less stable, but dynamic version of SER. Results say something else here.
"performance" should have no penalty over "stability", I would say.
This bug was not in the devel tree, but it is in the current SER 0.9.6 stable version for ~ 1 year.
In this case I would say it is not relevant how many CPS you have if you cannot handle them correctly.
regards, Bogdan
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/
VaclavP.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.
small typo below...
Bogdan-Andrei Iancu wrote:
Hi Klaus,
as the discussion about ser's improvements bounces again to openser, I had to do a bit of digging to provide a correct answer to openser's users.
yes, there were some improvements did by Andrei to TM, mainly in timer implementation. As you were wondering, the 0.9.6 SER should be relatively close to openser 0.9.4 as TM performance and merging the results from Vaclav with Andrei tests before the timer improvement in SER 0.9.6, seams to be correct. See: http://lists.iptel.org/pipermail/serdev/2005-December/006583.html
After this improvement, SER's 0.9.6 performances dramatically increased, but unfortunately, according to our tests it is also dramatically wrong. TM timers are not working correctly when variable timeouts are used in SER.
With the improvement, the following scenario gets broken - 3 calls only, no load, default cfg:
CALL 1: has 60 secs timeout for Final_response_timeout - nobody answers, still ringing in less than 2 secs -> CALL 2: has 70 secs timeout - it is immediately answered. in less than 2 secs -> CALL 3: has 10 secs timeout for Final_response_timeout - nobody answers, ringing.
Of course, everybody expects that CALL3 will timeout before CALL1 (with more than 40 secs), but in SER 0.9.6 (latest stable for the last 2 years), this will not happened - both CALL3 and CALL1 will timeout simultaneously when the CALL3 timer hits.
^^ it is CALL1
It is a simple test that anybody can easily reproduce.
A lot of people are saying that OpenSER is a less stable, but dynamic version of SER. Results say something else here.
"performance" should have no penalty over "stability", I would say.
This bug was not in the devel tree, but it is in the current SER 0.9.6 stable version for ~ 1 year.
In this case I would say it is not relevant how many CPS you have if you cannot handle them correctly.
regards, Bogdan
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/
VaclavP.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.
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
On Nov 27, 2006 at 19:02, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
small typo below...
Bogdan-Andrei Iancu wrote:
Hi Klaus,
as the discussion about ser's improvements bounces again to openser, I had to do a bit of digging to provide a correct answer to openser's users.
yes, there were some improvements did by Andrei to TM, mainly in timer implementation. As you were wondering, the 0.9.6 SER should be relatively close to openser 0.9.4 as TM performance and merging the results from Vaclav with Andrei tests before the timer improvement in SER 0.9.6, seams to be correct. See: http://lists.iptel.org/pipermail/serdev/2005-December/006583.html
After this improvement, SER's 0.9.6 performances dramatically increased, but unfortunately, according to our tests it is also dramatically wrong. TM timers are not working correctly when variable timeouts are used in SER.
With the improvement, the following scenario gets broken - 3 calls only, no load, default cfg:
CALL 1: has 60 secs timeout for Final_response_timeout - nobody answers, still ringing in less than 2 secs -> CALL 2: has 70 secs timeout - it is immediately answered. in less than 2 secs -> CALL 3: has 10 secs timeout for Final_response_timeout - nobody answers, ringing.
Of course, everybody expects that CALL3 will timeout before CALL1 (with more than 40 secs), but in SER 0.9.6 (latest stable for the last 2 years), this will not happened - both CALL3 and CALL1 will timeout simultaneously when the CALL3 timer hits.
Thanks a lot for the bug report.
^^ it is CALL1It is a simple test that anybody can easily reproduce.
A lot of people are saying that OpenSER is a less stable, but dynamic version of SER. Results say something else here.
"performance" should have no penalty over "stability", I would say.
This bug was not in the devel tree, but it is in the current SER 0.9.6 stable version for ~ 1 year.
In this case I would say it is not relevant how many CPS you have if you cannot handle them correctly.
This get funny... :-) Well this is a bug that appears _only_ when _variable_ timers are used (which should not be used with the old tm code anyway) and only if you catch a race (rather large, ~ 2 sec) and the worst that will happen is that you'll have a timer extended to another value (last variable timer used). Very dangerous :-)
Andrei
On Nov 27, 2006 at 23:14, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Nov 27, 2006 at 19:02, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
small typo below...
Bogdan-Andrei Iancu wrote:
Hi Klaus,
as the discussion about ser's improvements bounces again to openser, I had to do a bit of digging to provide a correct answer to openser's users.
yes, there were some improvements did by Andrei to TM, mainly in timer implementation. As you were wondering, the 0.9.6 SER should be relatively close to openser 0.9.4 as TM performance and merging the results from Vaclav with Andrei tests before the timer improvement in SER 0.9.6, seams to be correct. See: http://lists.iptel.org/pipermail/serdev/2005-December/006583.html
After this improvement, SER's 0.9.6 performances dramatically increased, but unfortunately, according to our tests it is also dramatically wrong. TM timers are not working correctly when variable timeouts are used in SER.
With the improvement, the following scenario gets broken - 3 calls only, no load, default cfg:
CALL 1: has 60 secs timeout for Final_response_timeout - nobody answers, still ringing in less than 2 secs -> CALL 2: has 70 secs timeout - it is immediately answered. in less than 2 secs -> CALL 3: has 10 secs timeout for Final_response_timeout - nobody answers, ringing.
Of course, everybody expects that CALL3 will timeout before CALL1 (with more than 40 secs), but in SER 0.9.6 (latest stable for the last 2 years), this will not happened - both CALL3 and CALL1 will timeout simultaneously when the CALL3 timer hits.
Thanks a lot for the bug report.
I've made a quick fix attempt (patch attached). Note that this is work in progress, very lightly tested, not optimized. It's just a "patch" draft, if it proves not to break something else (it needs a lot of testing which complicated call scenarios), it can be optimized later (e.g. lock only once when deleting the timers for all the branches). I've made it available so early so that other people can test it, improve it, point obvious problems a.s.o. The basic ideea is to immediately remove the fr_timer from the fr timer lists, so that no fr_timer with TIMER_DELETED will remain on the FR*LISTs (which is what causes problems with the variable timers).
Some quick numbers (don't quote them, just for patched/not patched/old stuff comparison):
ser 0.9.7 (no patch) ~20000 cps (*)
ser 0.9.7 (patched) about the same (*)
ser 0.9.7 with the 0.9.4 fix removed <4000 cps (**) (TIMER_SKIP_DELETED defined )
(*) - unfortunately I cannot generate more then 20000-21000 cps right now, so this is not the maximum ser can handle, is just how much I could generate without too much trouble. Memory becomes also a problem, on a 64 bit machine the 20000 cps need over 900Mb of memory for ser 0.9.7 (ser.cvs needs ~800Mb).
(**) starts @4000 then drops to <1000
Note also that this are in fact non-INVITE transaction/s tests. INVITEs should be slower (more complex & more packets). Normal calls per second (INVITE, then BYE) should be a little faster then twice as slow (2 transaction per call).
I've left openser.org lists in the cc in case the openser developers are also interested in fixing this (which would enable them to use the 0.9.4 fix).
Andrei
On Nov 28, 2006 at 02:03, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Nov 27, 2006 at 23:14, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Nov 27, 2006 at 19:02, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
small typo below...
Bogdan-Andrei Iancu wrote:
Hi Klaus,
as the discussion about ser's improvements bounces again to openser, I had to do a bit of digging to provide a correct answer to openser's users.
yes, there were some improvements did by Andrei to TM, mainly in timer implementation. As you were wondering, the 0.9.6 SER should be relatively close to openser 0.9.4 as TM performance and merging the results from Vaclav with Andrei tests before the timer improvement in SER 0.9.6, seams to be correct. See: http://lists.iptel.org/pipermail/serdev/2005-December/006583.html
After this improvement, SER's 0.9.6 performances dramatically increased, but unfortunately, according to our tests it is also dramatically wrong. TM timers are not working correctly when variable timeouts are used in SER.
With the improvement, the following scenario gets broken - 3 calls only, no load, default cfg:
CALL 1: has 60 secs timeout for Final_response_timeout - nobody answers, still ringing in less than 2 secs -> CALL 2: has 70 secs timeout - it is immediately answered. in less than 2 secs -> CALL 3: has 10 secs timeout for Final_response_timeout - nobody answers, ringing.
Of course, everybody expects that CALL3 will timeout before CALL1 (with more than 40 secs), but in SER 0.9.6 (latest stable for the last 2 years), this will not happened - both CALL3 and CALL1 will timeout simultaneously when the CALL3 timer hits.
Thanks a lot for the bug report.
I've made a quick fix attempt (patch attached). Note that this is work in progress, very lightly tested, not optimized. It's just a "patch" draft, if it proves not to break something else (it needs a lot of testing which complicated call scenarios), it can be optimized later (e.g. lock only once when deleting the timers for all the branches). I've made it available so early so that other people can test it, improve it, point obvious problems a.s.o. The basic ideea is to immediately remove the fr_timer from the fr timer lists, so that no fr_timer with TIMER_DELETED will remain on the FR*LISTs (which is what causes problems with the variable timers).
Some quick numbers (don't quote them, just for patched/not patched/old stuff comparison):
ser 0.9.7 (no patch) ~20000 cps (*)
ser 0.9.7 (patched) about the same (*)
ser 0.9.7 with the 0.9.4 fix removed <4000 cps (**) (TIMER_SKIP_DELETED defined )
(*) - unfortunately I cannot generate more then 20000-21000 cps right now, so this is not the maximum ser can handle, is just how much I could generate without too much trouble. Memory becomes also a problem, on a 64 bit machine the 20000 cps need over 900Mb of memory for ser 0.9.7 (ser.cvs needs ~800Mb).
(**) starts @4000 then drops to <1000
Note also that this are in fact non-INVITE transaction/s tests. INVITEs should be slower (more complex & more packets). Normal calls per second (INVITE, then BYE) should be a little faster then twice as slow (2 transaction per call).
I've left openser.org lists in the cc in case the openser developers are also interested in fixing this (which would enable them to use the 0.9.4 fix).
Another completely different version, this time a new member is added to the timer_link structure, just to keep an is_deleted flag. Advantages: - simpler, much easier to verify (doesn't need so much testing) Disadvantages: a little more memory is used (can be seen after testing), probably a little slower in the normal case (though both versions maxed out my testing sipp, I think the other is faster), probably significantly slower if a lot of different variable timers are used.
Andrei
Andrei
Index: t_cancel.c
RCS file: /cvsroot/ser/sip_router/modules/tm/t_cancel.c,v retrieving revision 1.13.2.1 diff -u -r1.13.2.1 t_cancel.c --- t_cancel.c 13 Jun 2006 13:31:48 -0000 1.13.2.1 +++ t_cancel.c 28 Nov 2006 00:27:42 -0000 @@ -147,7 +147,7 @@
/* stop_rb_timers(&t->uac[i].request); */ reset_timer( &t->uac[i].request.retr_timer );
reset_timer( &t->uac[i].request.fr_timer );
del_fr_timer( &t->uac[i].request.fr_timer );Index: t_funcs.c
RCS file: /cvsroot/ser/sip_router/modules/tm/t_funcs.c,v retrieving revision 1.175.2.3 diff -u -r1.175.2.3 t_funcs.c --- t_funcs.c 28 Aug 2006 11:21:02 -0000 1.175.2.3 +++ t_funcs.c 28 Nov 2006 00:27:42 -0000 @@ -133,7 +133,7 @@ { set_kr(REQ_RLSD);
- reset_timer( & trans->uas.response.fr_timer );
del_fr_timer( & trans->uas.response.fr_timer ); reset_timer( & trans->uas.response.retr_timer );
cleanup_uac_timers( trans );
Index: t_fwd.c
RCS file: /cvsroot/ser/sip_router/modules/tm/t_fwd.c,v retrieving revision 1.61.2.2 diff -u -r1.61.2.2 t_fwd.c --- t_fwd.c 28 Aug 2006 11:21:02 -0000 1.61.2.2 +++ t_fwd.c 28 Nov 2006 00:27:42 -0000 @@ -349,7 +349,7 @@ * retransmission timers */ reset_timer(&t_invite->uac[i].request.retr_timer);
reset_timer(&t_invite->uac[i].request.fr_timer);
del_fr_timer(&t_invite->uac[i].request.fr_timer); /* Generate faked reply */ LOCK_REPLIES(t_invite);Index: t_reply.c
RCS file: /cvsroot/ser/sip_router/modules/tm/t_reply.c,v retrieving revision 1.98.2.6 diff -u -r1.98.2.6 t_reply.c --- t_reply.c 12 Jun 2006 08:22:48 -0000 1.98.2.6 +++ t_reply.c 28 Nov 2006 00:27:43 -0000 @@ -66,6 +66,7 @@
the request (bogdan)- 2005-09-01 reverted to the old way of checking response.dst.send_sock
in t_retransmit_reply & reply_light (andrei)
*/
- 2006-12-27 replaced reset(fr_timer) with del_fr_timer(...) (andrei)
@@ -954,7 +955,7 @@ /* reset FR/retransmission timers */ for (i=0; i<t->nr_of_outgoings; i++ ) { reset_timer( &t->uac[i].request.retr_timer );
reset_timer( &t->uac[i].request.fr_timer );
del_fr_timer( &t->uac[i].request.fr_timer );} @@ -1282,7 +1283,7 @@ /* ... then just stop timers */ reset_timer( &uac->local_cancel.retr_timer); if ( msg_status >= 200 ) {
reset_timer( &uac->local_cancel.fr_timer);
del_fr_timer( &uac->local_cancel.fr_timer);@@ -1294,7 +1295,7 @@
/* stop final response timer only if I got a final response */if ( msg_status >= 200 ) {
reset_timer( &uac->request.fr_timer);
del_fr_timer(&uac->request.fr_timer);}
/* acknowledge negative INVITE replies (do it before detailed
Index: timer.c
RCS file: /cvsroot/ser/sip_router/modules/tm/timer.c,v retrieving revision 1.58.2.3 diff -u -r1.58.2.3 timer.c --- timer.c 6 Dec 2005 13:20:14 -0000 1.58.2.3 +++ timer.c 28 Nov 2006 00:27:43 -0000 @@ -98,6 +98,8 @@
- 2003-06-27 timers are not unlinked if timerlist is 0 (andrei)
- 2004-02-13 t->is_invite, t->local, t->noisy_ctimer replaced;
timer_link.payload removed (bogdan)
- 2006-11-27 added del_fr_timer(): fr timers are immediately removed
*/
from the FR* lists (andrei)#include "defs.h" @@ -322,7 +324,7 @@ "request resending (t=%p, %.9s ... )\n", r_buf->my_T, r_buf->buffer); if (SEND_BUFFER( r_buf )==-1) {
reset_timer( &r_buf->fr_timer );
del_fr_timer( &r_buf->fr_timer ); fake_reply(r_buf->my_T, r_buf->branch, 503 ); return; }@@ -436,7 +438,7 @@ int i; for (i=0; i<t->nr_of_outgoings; i++ ) { reset_timer( &t->uac[i].local_cancel.retr_timer );
reset_timer( &t->uac[i].local_cancel.fr_timer );
del_fr_timer( &t->uac[i].local_cancel.fr_timer );}
@@ -776,6 +778,33 @@ #endif }
+/* remove a timer from the FR_TIMER_LIST or FR_INV_TIMER_LIST
- (it allows immediate delete of a fr timer => solves the race with
- variables timers inserted after longer deleted timers)
- WARNING: - don't try to use it to "move" a timer from one list
to another, you'll run into races- */
+void del_fr_timer( struct timer_link *tl) +{
- /* the FR lock is common/shared by both FR_INV_TIMER_LIST
* and FR_TIMER_LIST, so we must lock only one of them */- lock(timertable->timers[FR_TIMER_LIST].mutex);
- /* check first if we are on the "detached" timer_routine list (the fr
* handle is executing or timer_routine prepares to execute it).* if so do nothing, except reseting the timer to TIMER_DELETED* (just to give us a change at racing with timer_routine, if* TIMER_DELETED is set and the fr handle is not already executing =>* it will not be called anymore)*/- if (tl->timer_list!=DETACHED_LIST){
remove_timer_unsafe(tl); /* safe to call for null list */- }else{
reset_timer(tl);- }
- unlock(timertable->timers[FR_TIMER_LIST].mutex);
+}
Index: timer.h
RCS file: /cvsroot/ser/sip_router/modules/tm/timer.h,v retrieving revision 1.37 diff -u -r1.37 timer.h --- timer.h 1 Nov 2004 14:09:09 -0000 1.37 +++ timer.h 28 Nov 2006 00:27:43 -0000 @@ -109,6 +109,8 @@ */
void reset_timer( struct timer_link* tl ); +/* remove a timer from FR_TIMER_LIST or FR_INV_TIMER_LIST */ +void del_fr_timer( struct timer_link *tl); /* determine timer length and put on a correct timer list */ void set_timer( struct timer_link *new_tl, enum lists list_id, unsigned int* ext_timeout ); /* similar to set_timer, except it allows only one-time
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On 11/27/06, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
This get funny... :-) Well this is a bug that appears _only_ when _variable_ timers are used (which should not be used with the old tm code anyway) and only if you catch a race (rather large, ~ 2 sec) and the worst that will happen is that you'll have a timer extended to another value (last variable timer used). Very dangerous :-)
I think so too! VoIP doesn't quite feel at home on the land of five nines. Misbehaviours was all that was missing. I have to vote with Bogdan's "stability over performance".
But I also have to appreciate the very fast fix. The responsiveness seems to have improved dramatically lately. Let's hope for durability.
WL.
As I can see, you get better and better with openser, maybe you can get some training so you will be able to configure and tune it properly to fit your needs and get the appropriate results (googling will reveal some doing trainings for openser). So which are right, these ones, the previous ones or the next testing results? You tested something, which (I suppose) you are very familiar with (ser), against something that you do not know properly to configure. There are some internals that differ a lot and may have quite a lot of performance impact.
Just after you sent this mail, I have seen a commit to usrloc which saves some problems I pointed in my previous email in this thread (so, yes, we are concerned about performance, and see you need to catch up now in some directions). The difference is now that ser's usrloc hash table size is by default 2^14 (16384) while in openser is 2^9 (512). So I guess some tests you can do now will be faster for ser, but to change the hash value in ser you have to re-compile, as opposite to openser where you can do it via module parameter.
So please, try to make sure that the corresponding parameters have same values, from number of processes, to memory, hash tables sizes, and so on ... for future tests. If you are not able to do fair tests, it is better to leave it for some impartial entities. With the description of your tests a lot of parameters and variables are hidden, and do not reflect the real capacity of the applications (I can say it now at least for openser).
And just to remember, as proved, you got very good performances but wrong processing. I will ask you and users: do you prefer to have *high performances* tied to *invalid processing* of the requests? http://openser.org/pipermail/users/2006-November/007843.html Well, maybe for some folks it is a 'proud' to say: *ser offers very fast _invalid_ functionalities* or "ser can scale to millions of _offline_ users*.
You owe to say to the users that the performances were obtained with a *buggy SIP transaction processing*, and correct the web pages posted at the link below.
Actually I replied to this mail because of some accuses that 'we spread the rumor "ser is dead"'. Nowhere you can find such statement from our side. After some investigations proved that the phrase in charge is: "Soon after, /iptelorg.com Gmbh/ was sold to /Tekelec/, which had no intention to continue the development of the public project." from oepnser history (http://www.openser.org/index.php?option=com_content&task=view&id=40&...).
This is quite different than "ser is dead", and many of you know the statement made in "openser history" is true. I cannot name some private channels I have, but there are publicly spoken ones. I paste from https://mail.internet2.edu/wws/arc/sip.edu/2006-10/msg00003.html:
<snip> Christian says that he was surprised at the continued development of SER after speaking with people from Tekelec, as they mentioned that they were not as interested in continuing SER as an open source project and were more interested in integrating SER into their IMS offerings. He asks about the future of SER as an open source project. Jiri feels that there should be no issues, and the main contributors are still making contributions. He's hesitant to speak on the behalf of the company, but feels that based on past performance nothing should be changing. </snip>
I would polite ask those persons not to twist the phrases without giving good proof.
Users can see now who and how tries to hoke up the reality.
Cheers, Daniel
On 11/24/06 17:06, 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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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));
On Nov 27, 2006 at 23:16, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
As I can see, you get better and better with openser, maybe you can get some training so you will be able to configure and tune it properly to fit your needs and get the appropriate results (googling will reveal some doing trainings for openser). So which are right, these ones, the previous ones or the next testing results? You tested something, which (I suppose) you are very familiar with (ser), against something that you do not know properly to configure. There are some internals that differ a lot and may have quite a lot of performance impact.
Such as? I really think that you should try to chill out a little.
Instead of being happy that someone ran some benchmarks (which you should probably do more often), you continue to try attack our tests, but you fail to point what's wrong with them (you can see all the configs and the compile parameters used). As a matter of fact there was an error, but this involved ser. ser.cvs was compiled with malloc debugging (-DDBG_QM_MALLOC and without -DF_MALLOC). So ser pre-release is even faster.
These were only some benchmarks, you can fix the performance problems in a new release or you can ignore them and concentrate on stuff you find more important. If you dislike so much being benchmarked, then put something like "please don't publish benchmark results for openser" in the README and/ or the web page.
Just after you sent this mail, I have seen a commit to usrloc which saves some problems I pointed in my previous email in this thread (so, yes, we are concerned about performance, and see you need to catch up now in some directions). The difference is now that ser's usrloc hash table size is by default 2^14 (16384) while in openser is 2^9 (512). So I guess some tests you can do now will be faster for ser, but to change the hash value in ser you have to re-compile, as opposite to openser where you can do it via module parameter.
To answer in the same spirit you wrote all your mails in this thread: if this was not a cosmetic fix (you've just replaced the hash with the hash from core) and you were really concerned about the performance then why haven't you changed the hash table size too? 512 is far too small (I won't give any perfromance numbers I don't want to make you even more angrier :-)) Why would you want to change the hash size from the config? Do you really know somebody who wanted/needed to do this? If you use a variable for the hash size the compiler will not be able to optimize the modulo operation (x % hash_size) and it will have to implement it using slow DIVs. Using a 2^k constant the whole modulo operation will be optimized to & (2^k - 1). A DIV takes minimum 56 cycles on a P4 and 16 on an AMD64 (and this if the operands are in _registers_ which will probably not happen for the variable containing the hash size). An "and" takes only 1 cycle (and the operand is an immediate constant). Look also at the rest of the hash function: it uses only XORs, shifts and additions, operations that all execute in 1 cycle => for normal small uris your DIV operation will take a very significant time from the total ammount spent hashing. Note also that there is another difference: we use a different hash function in ser, one that gives very good distributions also for numbers (.e.g. 12345@foo.bar) and not only strings.
So please, try to make sure that the corresponding parameters have same values, from number of processes, to memory, hash tables sizes, and so on ... for future tests. If you are not able to do fair tests, it is better to leave it for some impartial entities. With the description of your tests a lot of parameters and variables are hidden, and do not reflect the real capacity of the applications (I can say it now at least for openser).
We never claimed this was the most optimized setup possible. As I pointed out ser was the one which was handicaped. I would however appreciate if you would share some of the secret openser tunning that would have changed the test results. Speaking of the hashes: it's not our fault if you choose the wrong value for them. Hash size is always a compromise between memory usage and speed (and usually some testing is necessary to find the best values). openser was neither exactly a "low memory" user or fast. Note: I have no ideea if you did really choose bad hash sizes for tm (since this is what you seem to imply), but if you kept the values from 0.9.4 you should be safe.
And just to remember, as proved, you got very good performances but wrong processing. I will ask you and users: do you prefer to have *high performances* tied to *invalid processing* of the requests? http://openser.org/pipermail/users/2006-November/007843.html Well, maybe for some folks it is a 'proud' to say: *ser offers very fast _invalid_ functionalities* or "ser can scale to millions of _offline_ users*.
Let me thank once again for the bug report. However let me point out that what you call invalid functionalities are some minor variable timer problems that in the worst case will extend a final reponse timer for ser 0.9.x (if variable timers are used).
You owe to say to the users that the performances were obtained with a *buggy SIP transaction processing*, and correct the web pages posted at the link below.
Do you mean in openser? Sorry, all this time I thought you were in denial, I haven't expected such a straight confession :-)
Actually I replied to this mail because of some accuses that 'we spread the rumor "ser is dead"'. Nowhere you can find such statement from our side. After some investigations proved that the phrase in charge is: "Soon after, /iptelorg.com Gmbh/ was sold to /Tekelec/, which had no intention to continue the development of the public project." from oepnser history (http://www.openser.org/index.php?option=com_content&task=view&id=40&...).
Indeed, you're not saying directly that ser is dead, you're only spreading FUD.
This is quite different than "ser is dead", and many of you know the statement made in "openser history" is true. I cannot name some private channels I have, but there are publicly spoken ones. I paste from https://mail.internet2.edu/wws/arc/sip.edu/2006-10/msg00003.html:
<snip> Christian says that he was surprised at the continued development of SER after speaking with people from Tekelec, as they mentioned that they were not as interested in continuing SER as an open source project and were more interested in integrating SER into their IMS offerings. He asks about the future of SER as an open source project. Jiri feels that there should be no issues, and the main contributors are still making contributions. He's hesitant to speak on the behalf of the company, but feels that based on past performance nothing should be changing. </snip>
I would polite ask those persons not to twist the phrases without giving good proof.
Users can see now who and how tries to hoke up the reality.
Cheers, Daniel
Andrei, amazed on how much anger a few simple benchmarks can produce
[...]
Right, these tests were not objective. I don't know really objective tests. But I tried to do them. Please, does anybody has a suggestion what should I set up (config, compilation parameters) to get more objective tests?
thanks, Vaclav
P.S. Resending message because it was marked as spam, sorry.
On Tue, Nov 28, 2006 at 12:28:12AM +0100, Andrei Pelinescu-Onciul wrote:
On Nov 27, 2006 at 23:16, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
As I can see, you get better and better with openser, maybe you can get some training so you will be able to configure and tune it properly to fit your needs and get the appropriate results (googling will reveal some doing trainings for openser). So which are right, these ones, the previous ones or the next testing results? You tested something, which (I suppose) you are very familiar with (ser), against something that you do not know properly to configure. There are some internals that differ a lot and may have quite a lot of performance impact.
Such as? I really think that you should try to chill out a little.
Instead of being happy that someone ran some benchmarks (which you should probably do more often), you continue to try attack our tests, but you fail to point what's wrong with them (you can see all the configs and the compile parameters used). As a matter of fact there was an error, but this involved ser. ser.cvs was compiled with malloc debugging (-DDBG_QM_MALLOC and without -DF_MALLOC). So ser pre-release is even faster.
These were only some benchmarks, you can fix the performance problems in a new release or you can ignore them and concentrate on stuff you find more important. If you dislike so much being benchmarked, then put something like "please don't publish benchmark results for openser" in the README and/ or the web page.
Just after you sent this mail, I have seen a commit to usrloc which saves some problems I pointed in my previous email in this thread (so, yes, we are concerned about performance, and see you need to catch up now in some directions). The difference is now that ser's usrloc hash table size is by default 2^14 (16384) while in openser is 2^9 (512). So I guess some tests you can do now will be faster for ser, but to change the hash value in ser you have to re-compile, as opposite to openser where you can do it via module parameter.
To answer in the same spirit you wrote all your mails in this thread: if this was not a cosmetic fix (you've just replaced the hash with the hash from core) and you were really concerned about the performance then why haven't you changed the hash table size too? 512 is far too small (I won't give any perfromance numbers I don't want to make you even more angrier :-)) Why would you want to change the hash size from the config? Do you really know somebody who wanted/needed to do this? If you use a variable for the hash size the compiler will not be able to optimize the modulo operation (x % hash_size) and it will have to implement it using slow DIVs. Using a 2^k constant the whole modulo operation will be optimized to & (2^k - 1). A DIV takes minimum 56 cycles on a P4 and 16 on an AMD64 (and this if the operands are in _registers_ which will probably not happen for the variable containing the hash size). An "and" takes only 1 cycle (and the operand is an immediate constant). Look also at the rest of the hash function: it uses only XORs, shifts and additions, operations that all execute in 1 cycle => for normal small uris your DIV operation will take a very significant time from the total ammount spent hashing. Note also that there is another difference: we use a different hash function in ser, one that gives very good distributions also for numbers (.e.g. 12345@foo.bar) and not only strings.
So please, try to make sure that the corresponding parameters have same values, from number of processes, to memory, hash tables sizes, and so on ... for future tests. If you are not able to do fair tests, it is better to leave it for some impartial entities. With the description of your tests a lot of parameters and variables are hidden, and do not reflect the real capacity of the applications (I can say it now at least for openser).
We never claimed this was the most optimized setup possible. As I pointed out ser was the one which was handicaped. I would however appreciate if you would share some of the secret openser tunning that would have changed the test results. Speaking of the hashes: it's not our fault if you choose the wrong value for them. Hash size is always a compromise between memory usage and speed (and usually some testing is necessary to find the best values). openser was neither exactly a "low memory" user or fast. Note: I have no ideea if you did really choose bad hash sizes for tm (since this is what you seem to imply), but if you kept the values from 0.9.4 you should be safe.
And just to remember, as proved, you got very good performances but wrong processing. I will ask you and users: do you prefer to have *high performances* tied to *invalid processing* of the requests? http://openser.org/pipermail/users/2006-November/007843.html Well, maybe for some folks it is a 'proud' to say: *ser offers very fast _invalid_ functionalities* or "ser can scale to millions of _offline_ users*.
Let me thank once again for the bug report. However let me point out that what you call invalid functionalities are some minor variable timer problems that in the worst case will extend a final reponse timer for ser 0.9.x (if variable timers are used).
You owe to say to the users that the performances were obtained with a *buggy SIP transaction processing*, and correct the web pages posted at the link below.
Do you mean in openser? Sorry, all this time I thought you were in denial, I haven't expected such a straight confession :-)
Actually I replied to this mail because of some accuses that 'we spread the rumor "ser is dead"'. Nowhere you can find such statement from our side. After some investigations proved that the phrase in charge is: "Soon after, /iptelorg.com Gmbh/ was sold to /Tekelec/, which had no intention to continue the development of the public project." from oepnser history (http://www.openser.org/index.php?option=com_content&task=view&id=40&...).
Indeed, you're not saying directly that ser is dead, you're only spreading FUD.
This is quite different than "ser is dead", and many of you know the statement made in "openser history" is true. I cannot name some private channels I have, but there are publicly spoken ones. I paste from https://mail.internet2.edu/wws/arc/sip.edu/2006-10/msg00003.html:
<snip> Christian says that he was surprised at the continued development of SER after speaking with people from Tekelec, as they mentioned that they were not as interested in continuing SER as an open source project and were more interested in integrating SER into their IMS offerings. He asks about the future of SER as an open source project. Jiri feels that there should be no issues, and the main contributors are still making contributions. He's hesitant to speak on the behalf of the company, but feels that based on past performance nothing should be changing. </snip>
I would polite ask those persons not to twist the phrases without giving good proof.
Users can see now who and how tries to hoke up the reality.
Cheers, Daniel
Andrei, amazed on how much anger a few simple benchmarks can produce
[...]
Hi,
Why would you want to change the hash size from the config? Do you really know somebody who wanted/needed to do this? If you use a variable for the hash size the compiler will not be able to optimize the modulo operation (x % hash_size) and it will have to implement it using slow DIVs. Using a 2^k constant the whole modulo operation will be optimized to & (2^k - 1). A DIV takes minimum 56 cycles on a P4 and 16 on an AMD64 (and this if the operands are in _registers_ which will probably not happen for the variable containing the hash size). An "and" takes only 1 cycle (and the operand is an immediate constant). Look also at the rest of the hash function: it uses only XORs, shifts and additions, operations that all execute in 1 cycle => for normal small uris your DIV operation will take a very significant time from the total ammount spent hashing.
Sorry for reraising this issue now, but I just became curious and did the math. :-)
First of all, the hash table size will most probably not have to be fetched from main memory. It is accessed frequently, so it is likely to be in the 2nd level cache. Furthermore, CPUs nowadays do very clever instruction reordering and prefetching, so loading the operand from the cache will likely only add a few cycles of latency. Let's assume that the total time required for the DIV instruction with memory operand is 100 cycles.
Let's assume that we have a very busy server that does 20000 hash lookups per second. Furthermore, let's make the unrealistic assumption that this server handles all the traffic using a single 3GHz CPU.
Now, the total time spent on the DIV instruction will be 2 million cycles per second, or 0.07% of the available processing time.
Let's say that the same server is preloading 1 million contacts from a database on startup. The total time spent on the DIV instruction will be 100 million cycles, or 33 milliseconds (while the whole preload operation will, at the very least, take several seconds to complete).
On the other hand, with a default hash table size of 16k, the hash buckets will still grow very big when the number of users gets large. I don't see the point in having users waste their valuable CPU time on searching through linked lists when they really wouldn't have to.
Many people will evaluate SER without first checking udomain.h to see whether there's any tunables inside. If they have many users, they're likely to be disappointed.
Looking at these figures, I don't see any reason not to make the hash table size configurable at runtime.
Just my 2 pence.
Regards, Jan
This definitely sounds impressive, but, FMI:
On 11/28/06, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
Why would you want to change the hash size from the config? Do you really know somebody who wanted/needed to do this? If you use a variable for the hash size the compiler will not be able to optimize the modulo operation (x % hash_size) and it will have to implement it using slow DIVs. Using a 2^k constant the whole modulo operation will be optimized to & (2^k - 1). A DIV takes minimum 56 cycles on a P4 and 16 on an AMD64 (and this if the operands are in _registers_ which will probably not happen for the variable containing the hash size). An "and" takes only 1 cycle (and the operand is an immediate constant). Look also at the rest of the hash function: it uses only XORs, shifts and additions, operations that all execute in 1 cycle => for normal small uris your DIV operation will take a very significant time from the total ammount spent hashing.
Unfortunately Daniel didn't reply anymore (maybe he wants to cover trade secrets ;-) ), but OpenSER uses now the much faster masking operation instead of the always costly modulo (which I expect to execute faster even with the cost of extra memory fetch for the hash size). I don't know whether hashing is also cheap or the result has a good distribution, but this should be something you should look at: I expect he did some research too, before changing, maybe this is a fix worth porting.
WL.
this is getting more and more confusing. The one side says this is a bug, the other says it is a feature. I will try to summarize my understanding till now: * openser claims that they improved something and the ser guys say this fix is useless. Daniel, Bogdan could you plesase explain what is really behind this improvement (Sorry Weiter, but your explanation is far from being sufficient). * The ser guys show that openser is inferior to ser but Bogdan replies this is on purpose (because otherwise a strange race situation can occur which Andrei tells us is negligable). * I will not get into the history discussion -which I have already touched in previous mails, let alone those mails about respect and the other stuff I could not really see how they relate to this discussion. I would really appreciate if these points were clarified -I have the impression the ball is now with Daniel and Bogdan. So plesse Bogdan do not hold to your one mail policy and help clarifying this and provide a bit more of details on the improvements of openser to core and tm.
I believe Andrei has made a good suggestion that it is in the interest of the entire community to cooperate and divide the areas of interest. By combining the great work the openser guys have done in the area of documentation and featutres with the work of ser in the area of core we will all get an even better ser/openser. I am afraid though that while this is surely in the interest of the community this might not be in the interest of the commercial entities behind the projects.
Finally I fully agree with all of the voices that have asked to be polite and concentrate on the technical aspects of the dicussion. I find it most destressing that in an environment that is based on cooperation for the benefit of all that an effort aiming at informing the community is faced with such remarks and sarcastic attitude.
best regards Weiter Leiter bp4mls@googlemail.com wrote: This definitely sounds impressive, but, FMI:
On 11/28/06, Andrei Pelinescu-Onciul andrei@iptel.org wrote: Why would you want to change the hash size from the config? Do you really know somebody who wanted/needed to do this? If you use a variable for the hash size the compiler will not be able to optimize the modulo operation (x % hash_size) and it will have to implement it using slow DIVs. Using a 2^k constant the whole modulo operation will be optimized to & (2^k - 1). A DIV takes minimum 56 cycles on a P4 and 16 on an AMD64 (and this if the operands are in _registers_ which will probably not happen for the variable containing the hash size). An "and" takes only 1 cycle (and the operand is an immediate constant). Look also at the rest of the hash function: it uses only XORs, shifts and additions, operations that all execute in 1 cycle => for normal small uris your DIV operation will take a very significant time from the total ammount spent hashing. Unfortunately Daniel didn't reply anymore (maybe he wants to cover trade secrets ;-) ), but OpenSER uses now the much faster masking operation instead of the always costly modulo (which I expect to execute faster even with the cost of extra memory fetch for the hash size). I don't know whether hashing is also cheap or the result has a good distribution, but this should be something you should look at: I expect he did some research too, before changing, maybe this is a fix worth porting.
WL.
--------------------------------- Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.
On Nov 29, 2006 at 14:05, Kim Il kim_il_s@yahoo.com wrote:
this is getting more and more confusing. The one side says this is a bug, the other says it is a feature. I will try to summarize my understanding till now:
I believe we better stop this line of discussion at least for now and instead concentrate on fixing the technical problems that were revealed on both sides. I wouldn't want it to hinder possible future collaboration.
- openser claims that they improved something and the ser guys say this fix is useless. Daniel, Bogdan could you plesase explain what is really behind this improvement (Sorry Weiter, but your explanation is far from being sufficient).
I don't know exactly what are you referring to ("something"?), but I don't remember claiming that an openser fix was useless (at least I haven't, I might have implied that something, IMHO was not as important as claimed, but not that was useless).
- The ser guys show that openser is inferior to ser but Bogdan replies this is on purpose (because otherwise a strange race situation can occur which Andrei tells us is negligable).
Actually, the claim was along the lines that tm (the statefull part of the sip stack in ser) and/or the core performance was inferior.
The bug that Bogdan discovered is not negligible. I wanted to point out that it was not as important as suggested. This probably deserves a better explanation, so that people without ser-internals knowledge can understand. First of all variable timers in this context mean the possibility to set different values for the fr_timer and fr_inv_timer at runtime (e.g. in function of some user preferences/avps or some special script logic) as oppossed to having some fixed (but configurable) values. What really matters here is the fr_inv_timer. The fr_inv_timer is the time that ser waits for a final response on an INVITE transaction _after_ a provisional response was received (e.g. 180 Ringing). This roughly corresponds to the Timer C from the sip rfc (rfc3261). According to the sip rfc both fr_tiemr and fr_inv_timer should be fixed and _not_ configurable. However in practice it makes sense to change them (especially the fr_inv_timer), to implement services such as redirect to voicemail after x seconds. The most common use of the variable timers is user (or group) configurable voicemail redirection. This means that the user is somehow able to configure the "ringing" interval after which a caller will be redirected to his voicemail. If variable timers are not used, the voicemail config option would include only on or off (the ringing time before voicemail redirection wouldn't be configurable, it would be the same for all the users). Now what the bug did, was that it could cause the extension of fr_inv_timer to the fr_inv_timer of another transaction, if _different_ variable timers were used and some race occured (note that the probability of hitting the race is quite high if lots of variable fr_inv_timers with different values are used and the system is very busy). This IMHO is not such a big problem since in the case when you are hit by it, it really doesn't break anything important (I don't see sometimes redirecting later to voicemail as such a big problem, OTOH people might use it for other stuff).
- I will not get into the history discussion -which I have already touched in previous mails, let alone those mails about respect and the other stuff I could not really see how they relate to this discussion.
I would really appreciate if these points were clarified -I have the impression the ball is now with Daniel and Bogdan. So plesse Bogdan do not hold to your one mail policy and help clarifying this and provide a bit more of details on the improvements of openser to core and tm.
I believe Andrei has made a good suggestion that it is in the interest of the entire community to cooperate and divide the areas of interest. By combining the great work the openser guys have done in the area of documentation and featutres with the work of ser in the area of core we will all get an even better ser/openser.
In fact even if we can't reach an agreement in dividing areas, small cooperation like on fixing/improving code that is the same in both versions would still be good. I would say that even a friendly competing approach would be better then nothing (with comparisons, benchmarks a.s.o), it points out problems in both versions and serves as a motivation to improve.
Andrei [...]
[everything else above snipped -- I just got intrigued by this]
At 12:19 30/11/2006, Andrei Pelinescu-Onciul wrote:
In fact even if we can't reach an agreement in dividing areas, small cooperation like on fixing/improving code that is the same in both versions would still be good. I would say that even a friendly competing approach would be better then nothing (with comparisons, benchmarks a.s.o), it points out problems in both versions and serves as a motivation to improve.
I think this is really the point. I haven't commented on the fork before but I argue that if folks want to have advantage of that (and to be clear I don't dispute openser advantages, among others documentation is marvellous), there should be damage control in place to compensate the disadvantages. Presumably because many folks perceive this (not without a reason) as a contraversial topic, I have received quite some feedback in privacy and it is too what I personally think: split development does split results. openser folks may correct me if I'm wrong, but openser has not undergone an overhaul like we did (timers, DNS, STUN, DB, etc etc) with ottendorf which means some parts do not appear to be state-of-the-art. Again: I'm sure that openser folks working hard may be upset about this statement, but in the end it is not meant to devalue anyone's work -- I'm saying the maths is easy -- some folks were focusing on DNS and made it better, some on XMPP and made XMPP better.
I better don't speak for Andrei to avoid any possible misinterpretations, but I think the alternaves he has offered are very reasonable. Labor division, coordination of fixes, friendly progress-stimulating competition, all of that are things which can make results better.
I'm just curious what the openser-oriented answers will be. I mean no answer is in a sense answer too, but I'm still wondering if I could get something more explicit.
We will definitely be contributing to the synergies in some or other ways.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Well... the TM bug may not be earth-shattering, but it's most decidedly important. One of the functions we have that our users LOVE is the ability to set their own timeout values for voicemail. We had had a default value that we thought would make everyone happy, but soon discovered that many would complain that it was too long, and many would complain that it was too short.
Having had many users who came along from asterisk-based services, where setting individual timeout values is rather straightforward and easy.
One of the things we've been struggling with has been the timing values. While it may not be important in the scheme that it's not ACTUALLY service-affecting, I can assure you, if you offer a service, and it doesn't work as prescribed, the consequences can be deadly. You shake user-confidence -- and that sort of thing travels VERY quickly by word of mouth. It's so very hard to gain users, and so very easy to lose them to a competitor -- even if that competitor doesn't offer the same options. For what good are options that only work sometimes?
SO... in short... yeah... I'm really happy that the timer stuff has been fixed in Ottendorf. Of course, it'll be a LONG time before we can migrate the production systems to it, but it gives me something to look forward to.
N.
On Thu, 30 Nov 2006 12:19:03 +0100, Andrei Pelinescu-Onciul wrote
On Nov 29, 2006 at 14:05, Kim Il kim_il_s@yahoo.com wrote:
this is getting more and more confusing. The one side says this is a bug,
the other says it is a feature. I will try to summarize my understanding till now:
I believe we better stop this line of discussion at least for now and instead concentrate on fixing the technical problems that were revealed on both sides. I wouldn't want it to hinder possible future collaboration.
- openser claims that they improved something and the ser guys say this
fix is useless. Daniel, Bogdan could you plesase explain what is really behind this improvement (Sorry Weiter, but your explanation is far from being sufficient).
I don't know exactly what are you referring to ("something"?), but I don't remember claiming that an openser fix was useless (at least I haven't, I might have implied that something, IMHO was not as important as claimed, but not that was useless).
- The ser guys show that openser is inferior to ser but Bogdan replies
this is on purpose (because otherwise a strange race situation can occur which Andrei tells us is negligable).
Actually, the claim was along the lines that tm (the statefull part of the sip stack in ser) and/or the core performance was inferior.
The bug that Bogdan discovered is not negligible. I wanted to point out that it was not as important as suggested. This probably deserves a better explanation, so that people without ser-internals knowledge can understand. First of all variable timers in this context mean the possibility to set different values for the fr_timer and fr_inv_timer at runtime
(e.g. in function of some user preferences/avps or some special script logic) as oppossed to having some fixed (but configurable) values. What really matters here is the fr_inv_timer. The fr_inv_timer is the time that ser waits for a final response on an INVITE transaction _after_ a provisional response was received (e.g. 180 Ringing). This roughly corresponds to the Timer C from the sip rfc (rfc3261). According to the sip rfc both fr_tiemr and fr_inv_timer should be fixed and _not_ configurable. However in practice it makes sense to change them (especially the fr_inv_timer), to implement services such as redirect to voicemail after x seconds. The most common use of the variable timers is user (or group) configurable voicemail redirection. This means that the user is somehow able to configure the "ringing" interval after which a caller will be redirected to his voicemail. If variable timers are not used, the voicemail config option would include only on or off (the ringing time before voicemail redirection wouldn't be configurable, it would be the same for all the users). Now what the bug did, was that it could cause the extension of fr_inv_timer to the fr_inv_timer of another transaction, if _different_ variable timers were used and some race occured (note that the probability of hitting the race is quite high if lots of variable fr_inv_timers with different values are used and the system is very busy). This IMHO is not such a big problem since in the case when you are hit by it, it really doesn't break anything important (I don't see sometimes redirecting later to voicemail as such a big problem, OTOH people might use it for other stuff).
- I will not get into the history discussion -which I have already touched
in previous mails, let alone those mails about respect and the other stuff I could not really see how they relate to this discussion.
I would really appreciate if these points were clarified -I have the
impression the ball is now with Daniel and Bogdan. So plesse Bogdan do not hold to your one mail policy and help clarifying this and provide a bit more of details on the improvements of openser to core and tm.
I believe Andrei has made a good suggestion that it is in the interest of
the entire community to cooperate and divide the areas of interest. By combining the great work the openser guys have done in the area of documentation and featutres with the work of ser in the area of core we will all get an even better ser/openser.
In fact even if we can't reach an agreement in dividing areas, small cooperation like on fixing/improving code that is the same in both versions would still be good. I would say that even a friendly competing approach would be better then nothing (with comparisons, benchmarks a.s.o), it points out problems in both versions and serves as a motivation to improve.
Andrei [...] _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Just to make it clear, it is pretty much only possible with Ottendorf if you are having a reasonably big setup. The previous timer system was not accurate (you might have noticed, that retransmission timer fired in a range of +/- 1 sec which is kind of unexact given the timer length 0.5 sec), variable (all timers were pretty much supposed to be of the same length), high-resolution (it used to be 1 second).
I concur that migration is alway a painful exercise, but I can only recommend folks to make themselves busy with it earlier than too late.
-jiri
At 23:05 01/12/2006, sip wrote:
Well... the TM bug may not be earth-shattering, but it's most decidedly important. One of the functions we have that our users LOVE is the ability to set their own timeout values for voicemail. We had had a default value that we thought would make everyone happy, but soon discovered that many would complain that it was too long, and many would complain that it was too short.
Having had many users who came along from asterisk-based services, where setting individual timeout values is rather straightforward and easy.
One of the things we've been struggling with has been the timing values. While it may not be important in the scheme that it's not ACTUALLY service-affecting, I can assure you, if you offer a service, and it doesn't work as prescribed, the consequences can be deadly. You shake user-confidence -- and that sort of thing travels VERY quickly by word of mouth. It's so very hard to gain users, and so very easy to lose them to a competitor -- even if that competitor doesn't offer the same options. For what good are options that only work sometimes?
SO... in short... yeah... I'm really happy that the timer stuff has been fixed in Ottendorf. Of course, it'll be a LONG time before we can migrate the production systems to it, but it gives me something to look forward to.
N.
On Thu, 30 Nov 2006 12:19:03 +0100, Andrei Pelinescu-Onciul wrote
On Nov 29, 2006 at 14:05, Kim Il kim_il_s@yahoo.com wrote:
this is getting more and more confusing. The one side says this is a bug,
the other says it is a feature. I will try to summarize my understanding till now:
I believe we better stop this line of discussion at least for now and instead concentrate on fixing the technical problems that were revealed on both sides. I wouldn't want it to hinder possible future collaboration.
- openser claims that they improved something and the ser guys say this
fix is useless. Daniel, Bogdan could you plesase explain what is really behind this improvement (Sorry Weiter, but your explanation is far from being sufficient).
I don't know exactly what are you referring to ("something"?), but I don't remember claiming that an openser fix was useless (at least I haven't, I might have implied that something, IMHO was not as important as claimed, but not that was useless).
- The ser guys show that openser is inferior to ser but Bogdan replies
this is on purpose (because otherwise a strange race situation can occur which Andrei tells us is negligable).
Actually, the claim was along the lines that tm (the statefull part of the sip stack in ser) and/or the core performance was inferior.
The bug that Bogdan discovered is not negligible. I wanted to point out that it was not as important as suggested. This probably deserves a better explanation, so that people without ser-internals knowledge can understand. First of all variable timers in this context mean the possibility to set different values for the fr_timer and fr_inv_timer at runtime
(e.g. in function of some user preferences/avps or some special script logic) as oppossed to having some fixed (but configurable) values. What really matters here is the fr_inv_timer. The fr_inv_timer is the time that ser waits for a final response on an INVITE transaction _after_ a provisional response was received (e.g. 180 Ringing). This roughly corresponds to the Timer C from the sip rfc (rfc3261). According to the sip rfc both fr_tiemr and fr_inv_timer should be fixed and _not_ configurable. However in practice it makes sense to change them (especially the fr_inv_timer), to implement services such as redirect to voicemail after x seconds. The most common use of the variable timers is user (or group) configurable voicemail redirection. This means that the user is somehow able to configure the "ringing" interval after which a caller will be redirected to his voicemail. If variable timers are not used, the voicemail config option would include only on or off (the ringing time before voicemail redirection wouldn't be configurable, it would be the same for all the users). Now what the bug did, was that it could cause the extension of fr_inv_timer to the fr_inv_timer of another transaction, if _different_ variable timers were used and some race occured (note that the probability of hitting the race is quite high if lots of variable fr_inv_timers with different values are used and the system is very busy). This IMHO is not such a big problem since in the case when you are hit by it, it really doesn't break anything important (I don't see sometimes redirecting later to voicemail as such a big problem, OTOH people might use it for other stuff).
- I will not get into the history discussion -which I have already touched
in previous mails, let alone those mails about respect and the other stuff I could not really see how they relate to this discussion.
I would really appreciate if these points were clarified -I have the
impression the ball is now with Daniel and Bogdan. So plesse Bogdan do not hold to your one mail policy and help clarifying this and provide a bit more of details on the improvements of openser to core and tm.
I believe Andrei has made a good suggestion that it is in the interest of
the entire community to cooperate and divide the areas of interest. By combining the great work the openser guys have done in the area of documentation and featutres with the work of ser in the area of core we will all get an even better ser/openser.
In fact even if we can't reach an agreement in dividing areas, small cooperation like on fixing/improving code that is the same in both versions would still be good. I would say that even a friendly competing approach would be better then nothing (with comparisons, benchmarks a.s.o), it points out problems in both versions and serves as a motivation to improve.
Andrei [...] _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Indeed. No fears there. We've already got a dedicated server on order to test it with. Won't likely be here until the beginning of the year, but we won't have time to muck with it before then anyway with the usual end-of-year madness going on.
Very much looking forward to testing Ottendorf and trying to figure out the best way to migrate. As is, it will be slightly complex as we've spent a good portion of time redoing the SER database to our particular specifications and needs... and many of the tables we use have been removed or redone for Ottendorf, and many of the features we rely upon have been completely done away with.
Also, since we use a mixture of SER and OpenSER modules in our code, as well as in-house modules to handle several things, migrating to Ottendorf is going to be an exercise in frustration and pain. :) I'm not eager to start even looking at that until after the holidays.
N.
On Mon, 04 Dec 2006 10:39:25 +0100, Jiri Kuthan wrote
Just to make it clear, it is pretty much only possible with Ottendorf if you are having a reasonably big setup. The previous timer system was not accurate (you might have noticed, that retransmission timer fired in a range of +/- 1 sec which is kind of unexact given the timer length 0.5 sec), variable (all timers were pretty much supposed to be of the same length), high-resolution (it used to be 1 second).
I concur that migration is alway a painful exercise, but I can only recommend folks to make themselves busy with it earlier than too late.
-jiri
At 23:05 01/12/2006, sip wrote:
Well... the TM bug may not be earth-shattering, but it's most decidedly important. One of the functions we have that our users LOVE is the ability to set their own timeout values for voicemail. We had had a default value that we thought would make everyone happy, but soon discovered that many would complain that it was too long, and many would complain that it was too short.
Having had many users who came along from asterisk-based services, where setting individual timeout values is rather straightforward and easy.
One of the things we've been struggling with has been the timing values. While it may not be important in the scheme that it's not ACTUALLY service-affecting, I can assure you, if you offer a service, and it doesn't work as prescribed, the consequences can be deadly. You shake user-confidence -- and that sort of thing travels VERY quickly by word of mouth. It's so very hard to gain users, and so very easy to lose them to a competitor -- even if that competitor doesn't offer the same options. For what good are options that only work sometimes?
SO... in short... yeah... I'm really happy that the timer stuff has been fixed in Ottendorf. Of course, it'll be a LONG time before we can migrate the production systems to it, but it gives me something to look forward to.
N.
On Thu, 30 Nov 2006 12:19:03 +0100, Andrei Pelinescu-Onciul wrote
On Nov 29, 2006 at 14:05, Kim Il kim_il_s@yahoo.com wrote:
this is getting more and more confusing. The one side says this is a bug,
the other says it is a feature. I will try to summarize my understanding
till now:
I believe we better stop this line of discussion at least for now and instead concentrate on fixing the technical problems that were revealed on both sides. I wouldn't want it to hinder possible future collaboration.
- openser claims that they improved something and the ser guys say this
fix is useless. Daniel, Bogdan could you plesase explain what is really behind this improvement (Sorry Weiter, but your explanation is far from being sufficient).
I don't know exactly what are you referring to ("something"?), but I don't remember claiming that an openser fix was useless (at least I haven't, I might have implied that something, IMHO was not as important as claimed, but not that was useless).
- The ser guys show that openser is inferior to ser but Bogdan replies
this is on purpose (because otherwise a strange race situation can occur which Andrei tells us is negligable).
Actually, the claim was along the lines that tm (the statefull part of the sip stack in ser) and/or the core performance was inferior.
The bug that Bogdan discovered is not negligible. I wanted to point out that it was not as important as suggested. This probably deserves a better explanation, so that people without ser-internals knowledge can understand. First of all variable timers in this context mean the possibility to set different values for the fr_timer and fr_inv_timer at runtime
(e.g. in function of some user preferences/avps or some special script logic) as oppossed to having some fixed (but configurable) values. What really matters here is the fr_inv_timer. The fr_inv_timer is the time that ser waits for a final response on an INVITE transaction _after_ a provisional response was received (e.g. 180 Ringing). This roughly corresponds to the Timer C from the sip rfc (rfc3261). According to the sip rfc both fr_tiemr and fr_inv_timer should be fixed and _not_ configurable. However in practice it makes sense to change them (especially the fr_inv_timer), to implement services such as redirect to voicemail after x seconds. The most common use of the variable timers is user (or group) configurable voicemail redirection. This means that the user is somehow able to configure the "ringing" interval after which a caller will be redirected to his voicemail. If variable timers are not used, the voicemail config option would include only on or off (the ringing time before voicemail redirection wouldn't be configurable, it would be the same for all the users). Now what the bug did, was that it could cause the extension of fr_inv_timer to the fr_inv_timer of another transaction, if _different_ variable timers were used and some race occured (note that the probability of hitting the race is quite high if lots of variable fr_inv_timers with different values are used and the system is very busy). This IMHO is not such a big problem since in the case when you are hit by it, it really doesn't break anything important (I don't see sometimes redirecting later to voicemail as such a big problem, OTOH people might use it for other stuff).
- I will not get into the history discussion -which I have already touched
in previous mails, let alone those mails about respect and the other stuff I could not really see how they relate to this discussion.
I would really appreciate if these points were clarified -I have the
impression the ball is now with Daniel and Bogdan. So plesse Bogdan do not hold to your one mail policy and help clarifying this and provide a bit more of details on the improvements of openser to core and tm.
I believe Andrei has made a good suggestion that it is in the interest of
the entire community to cooperate and divide the areas of interest. By combining the great work the openser guys have done in the area of documentation and featutres with the work of ser in the area of core we will all get an even better ser/openser.
In fact even if we can't reach an agreement in dividing areas, small cooperation like on fixing/improving code that is the same in both versions would still be good. I would say that even a friendly competing approach would be better then nothing (with comparisons, benchmarks a.s.o), it points out problems in both versions and serves as a motivation to improve.
Andrei [...] _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
I'm trying to figure out how people use SER in order to get a picture of what the needs really are. My goal is to be able to group various usage patterns and create "best practice" areas at iptel.org, where people also can add comments and describe their experiences.
Would you mind sharing a bit about the "mixture of SER and OpenSER modules" you are using, as well as why you opted to change the database model? g-)
sip wrote:
Indeed. No fears there. We've already got a dedicated server on order to test it with. Won't likely be here until the beginning of the year, but we won't have time to muck with it before then anyway with the usual end-of-year madness going on.
Very much looking forward to testing Ottendorf and trying to figure out the best way to migrate. As is, it will be slightly complex as we've spent a good portion of time redoing the SER database to our particular specifications and needs... and many of the tables we use have been removed or redone for Ottendorf, and many of the features we rely upon have been completely done away with.
Also, since we use a mixture of SER and OpenSER modules in our code, as well as in-house modules to handle several things, migrating to Ottendorf is going to be an exercise in frustration and pain. :) I'm not eager to start even looking at that until after the holidays.
N.
On Mon, 04 Dec 2006 10:39:25 +0100, Jiri Kuthan wrote
Just to make it clear, it is pretty much only possible with Ottendorf if you are having a reasonably big setup. The previous timer system was not accurate (you might have noticed, that retransmission timer fired in a range of +/- 1 sec which is kind of unexact given the timer length 0.5 sec), variable (all timers were pretty much supposed to be of the same length), high-resolution (it used to be 1 second).
I concur that migration is alway a painful exercise, but I can only recommend folks to make themselves busy with it earlier than too late.
-jiri
At 23:05 01/12/2006, sip wrote:
Well... the TM bug may not be earth-shattering, but it's most decidedly important. One of the functions we have that our users LOVE is the ability to set their own timeout values for voicemail. We had had a default value that we thought would make everyone happy, but soon discovered that many would complain that it was too long, and many would complain that it was too short.
Having had many users who came along from asterisk-based services, where setting individual timeout values is rather straightforward and easy.
One of the things we've been struggling with has been the timing values. While it may not be important in the scheme that it's not ACTUALLY service-affecting, I can assure you, if you offer a service, and it doesn't work as prescribed, the consequences can be deadly. You shake user-confidence -- and that sort of thing travels VERY quickly by word of mouth. It's so very hard to gain users, and so very easy to lose them to a competitor -- even if that competitor doesn't offer the same options. For what good are options that only work sometimes?
SO... in short... yeah... I'm really happy that the timer stuff has been fixed in Ottendorf. Of course, it'll be a LONG time before we can migrate the production systems to it, but it gives me something to look forward to.
N.
On Thu, 30 Nov 2006 12:19:03 +0100, Andrei Pelinescu-Onciul wrote
On Nov 29, 2006 at 14:05, Kim Il kim_il_s@yahoo.com wrote:
this is getting more and more confusing. The one side says this is a bug,
the other says it is a feature. I will try to summarize my understanding
till now:
I believe we better stop this line of discussion at least for now and instead concentrate on fixing the technical problems that were revealed on both sides. I wouldn't want it to hinder possible future collaboration.
- openser claims that they improved something and the ser guys say this
fix is useless. Daniel, Bogdan could you plesase explain what is really behind this improvement (Sorry Weiter, but your explanation is far from being sufficient).
I don't know exactly what are you referring to ("something"?), but I don't remember claiming that an openser fix was useless (at least I haven't, I might have implied that something, IMHO was not as important as claimed, but not that was useless).
- The ser guys show that openser is inferior to ser but Bogdan replies
this is on purpose (because otherwise a strange race situation can occur which Andrei tells us is negligable).
Actually, the claim was along the lines that tm (the statefull part of the sip stack in ser) and/or the core performance was inferior.
The bug that Bogdan discovered is not negligible. I wanted to point out that it was not as important as suggested. This probably deserves a better explanation, so that people without ser-internals knowledge can understand. First of all variable timers in this context mean the possibility to set different values for the fr_timer and fr_inv_timer at runtime
(e.g. in function of some user preferences/avps or some special script logic) as oppossed to having some fixed (but configurable) values. What really matters here is the fr_inv_timer. The fr_inv_timer is the time that ser waits for a final response on an INVITE transaction _after_ a provisional response was received (e.g. 180 Ringing). This roughly corresponds to the Timer C from the sip rfc (rfc3261). According to the sip rfc both fr_tiemr and fr_inv_timer should be fixed and _not_ configurable. However in practice it makes sense to change them (especially the fr_inv_timer), to implement services such as redirect to voicemail after x seconds. The most common use of the variable timers is user (or group) configurable voicemail redirection. This means that the user is somehow able to configure the "ringing" interval after which a caller will be redirected to his voicemail. If variable timers are not used, the voicemail config option would include only on or off (the ringing time before voicemail redirection wouldn't be configurable, it would be the same for all the users). Now what the bug did, was that it could cause the extension of fr_inv_timer to the fr_inv_timer of another transaction, if _different_ variable timers were used and some race occured (note that the probability of hitting the race is quite high if lots of variable fr_inv_timers with different values are used and the system is very busy). This IMHO is not such a big problem since in the case when you are hit by it, it really doesn't break anything important (I don't see sometimes redirecting later to voicemail as such a big problem, OTOH people might use it for other stuff).
- I will not get into the history discussion -which I have already touched
in previous mails, let alone those mails about respect and the other stuff I could not really see how they relate to this discussion.
I would really appreciate if these points were clarified -I have the
impression the ball is now with Daniel and Bogdan. So plesse Bogdan do not hold to your one mail policy and help clarifying this and provide a bit more of details on the improvements of openser to core and tm.
I believe Andrei has made a good suggestion that it is in the interest of
the entire community to cooperate and divide the areas of interest. By combining the great work the openser guys have done in the area of documentation and featutres with the work of ser in the area of core we will all get an even better ser/openser.
In fact even if we can't reach an agreement in dividing areas, small cooperation like on fixing/improving code that is the same in both versions would still be good. I would say that even a friendly competing approach would be better then nothing (with comparisons, benchmarks a.s.o), it points out problems in both versions and serves as a motivation to improve.
Andrei [...] _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Sure. I'll share what I can share without giving too much of the business away.
For the most part, we use SER's modules from the 0.9.x set. However, we do use the alias_db module from OpenSER as it's FAR easier to securely code a web-based system that only accesses the database than it is to have to rely on ANY access to the command line (using SER, because it places its aliases into memory, it would require us to add them via serctl or it wouldn't pick them up (or manually add them with fifo commands ourselves, which is out of the question. First rule of web security: thou shalt avoid ever writing to the filesystem from the web)). The alias_db module allows us to just add aliases during runtime to the DB. We take a tiny performance hit from that, but considering the other DB calls that have to be made for checks and what not for every incoming call, an extra call to check the alias is really insignificant.
One of our programmers also backported the AVP functionality from the 0.1.x OpenSER uac module. We use this to modify the SIP comment portion of the From: header (which is allowed under the RFC) dynamically to ensure no spoofing.
As for why we modified the db model... well... it just wasn't right for our setup. We don't user SERWeb for anything. I'm sure it's a lovely product for basic administration, but we have our own site code, and we use a strict OO model for coding, so the use of any SERWeb code was out of the question.
We modified speeddial for our own purposes, so the speed_dial table had to be modified. We use the subscriber table for the website, which started off as a way to unify information, but then we switched to radius authentication and use the subscriber table strictly for the web (and for referencing other tables). Of course, that meant we needed to add things to it such as a signup IP address to keep track of user signups for statistics, we modified some of the fields here and there for our own use. We also added a lot of tables we need for other things, such as a call blocking table and a call return table.
We went down the road of dynamic timers, so we needed a timer table for the users' timers. We completely redid the phonebook information, so we keep user phonebooks in a rather complex scheme.
Of course, we have our pricing tables and what not.
And that's just the SER side. It's constantly trading information back and forth with Asterisk, which has its own tables to handle our own billing code and proper billing for call forwards and such, as well as information about the expirations for users' DIDs and Voicemail.
We also have SEMS in the mix for basic voicemail and conference rooms, but we made some modifications here and there to handle our userbase.
We use SER primarily for SIP, but we've tied it in very closely with our web applications, so we've tied the DB all together. I'm not sure we're a normal case in that sense, but who's to say. We may well be.
And you, Greger, I KNOW, would absolutely CRINGE at our ser.cfg. It's a massive, 40k file of madness. Amusingly, however, it's pretty well optimised. It just has to take a LOT of different situations into account.
N.
On Mon, 04 Dec 2006 21:45:35 +0100, Greger V. Teigre wrote
I'm trying to figure out how people use SER in order to get a pictureof what the needs really are. My goal is to be able to group varioususage patterns and create "best practice" areas at iptel.org, wherepeople also can add comments and describe their experiences.
Would you mind sharing a bit about the "mixture of SER and OpenSERmodules" you are using, as well as why you opted to change the databasemodel? g-)
sip wrote: Indeed. No fears there. We've already got a dedicated server on order to testit with. Won't likely be here until the beginning of the year, but we won'thave time to muck with it before then anyway with the usual end-of-yearmadness going on. Very much looking forward to testing Ottendorf and trying to figure out thebest way to migrate. As is, it will be slightly complex as we've spent a goodportion of time redoing the SER database to our particular specifications andneeds... and many of the tables we use have been removed or redone forOttendorf, and many of the features we rely upon have been completely doneaway with. Also, since we use a mixture of SER and OpenSER modules in our code, as wellas in-house modules to handle several things, migrating to Ottendorf is goingto be an exercise in frustration and pain. :) I'm not eager to start evenlooking at that until after the holidays. N.On Mon, 04 Dec 2006 10:39:25 +0100, Jiri Kuthan wrote Just to make it clear, it!
is pretty much only possible with Ottendorf if you are having a reasonably big setup. The previous timer system was not accurate (you might have noticed, that retransmission timer fired in a range of +/- 1 sec which is kind of unexact given the timer length 0.5 sec), variable (all timers were pretty much supposed to be of the same length), high-resolution (it used to be 1 second).I concur that migration is alway a painful exercise, but I can only recommendfolks to make themselves busy with it earlier than too late.-jiriAt 23:05 01/12/2006, sip wrote: Well... the TM bug may not be earth-shattering, but it's most decidedlyimportant. One of the functions we have that our users LOVE is the ability toset their own timeout values for voicemail. We had had a default value that wethought would make everyone happy, but soon discovered that many wouldcomplain that it was too long, and many would complain that it was too short.Having had many users who came along from asterisk-base! d services, wheresetting individual timeout values is rather straightf orward and easy.One of the things we've been struggling with has been the timing values. Whileit may not be important in the scheme that it's not ACTUALLYservice-affecting, I can assure you, if you offer a service, and it doesn'twork as prescribed, the consequences can be deadly. You shake user-confidence-- and that sort of thing travels VERY quickly by word of mouth. It's so veryhard to gain users, and so very easy to lose them to a competitor -- even ifthat competitor doesn't offer the same options. For what good are options thatonly work sometimes?SO... in short... yeah... I'm really happy that the timer stuff has been fixedin Ottendorf. Of course, it'll be a LONG time before we can migrate theproduction systems to it, but it gives me something to look forward to.N.On Thu, 30 Nov 2006 12:19:03 +0100, Andrei Pelinescu-Onciul wrote On Nov 29, 2006 at 14:05, Kim Il kim_il_s@yahoo.com wrote: this is getting more and more confusing. The one side says this is a bug, th! e other says it is a feature. I will try to summarize my understanding till now: I believe we better stop this line of discussion at least for now and instead concentrate on fixing the technical problems that were revealedon both sides. I wouldn't want it to hinder possible futurecollaboration. * openser claims that they improved something and the ser guys say this fix is useless. Daniel, Bogdan could you plesase explain what is reallybehind this improvement (Sorry Weiter, but your explanation is far from beingsufficient). I don't know exactly what are you referring to ("something"?), but I don't remember claiming that an openser fix was useless (at least I haven't, I might have implied that something, IMHO was not as important as claimed, but not that was useless). * The ser guys show that openser is inferior to ser but Bogdan replies this is on purpose (because otherwise a strange race situation can occur whichAndrei tells us is negligable). Actually,! the claim was along the lines that tm (the statefull part of the sip stack in ser) and/or the core performance was inferior.The bug that Bogdan discovered is not negligible. I wanted to point outthat it was not as important as suggested.This probably deserves a better explanation, so that people withoutser-internals knowledge can understand.First of all variable timers in this context mean the possibility toset different values for the fr_timer and fr_inv_timer at runtime(e.g. in function of some user preferences/avps or some special script logic) as oppossed to having some fixed (but configurable) values.What really matters here is the fr_inv_timer. The fr_inv_timer is thetime that ser waits for a final response on an INVITE transaction_after_ a provisional response was received (e.g. 180 Ringing). This roughly corresponds to the Timer C from the sip rfc (rfc3261). According to the sip rfc both fr_tiemr and fr_inv_timer should be fixedand _not_ configurable. However in practice it makes sense to change them(especially the fr_inv_timer), to ! implement services such as redirect to voicemail after x seconds. The most common use of the variable timers is user (or group) configurable voicemail redirection. This means that the user is somehow able to configure the "ringing" interval after which a caller will be redirected to his voicemail. If variable timers are not used, the voicemail config option would include only on or off (the ringing time before voicemail redirection wouldn't be configurable, it would be the same for all the users). Now what the bug did, was that it could cause the extension of fr_inv_timer to the fr_inv_timer of another transaction, if _different_ variable timers were used and some race occured (note that the probability of hitting the race is quite high if lots of variable fr_inv_timers with different values are used and the system is very busy). This IMHO is not such a big problem since in the case when you are hit by it, it really doesn't break anything important (I don't see sometimes re! directing later to voicemail as such a big problem, OTOH people might use it for other stuff). * I will not get into the history discussion -which I have already touched in previous mails, let alone those mails about respect and the other stuff Icould not really see how they relate to this discussion. I would really appreciate if these points were clarified -I have the impression the ball is now with Daniel and Bogdan. So plesse Bogdan do nothold to your one mail policy and help clarifying this and provide a bit moreof details on the improvements of openser to core and tm. I believe Andrei has made a good suggestion that it is in the interest of the entire community to cooperate and divide the areas of interest. Bycombining the great work the openser guys have done in the area ofdocumentation and featutres with the work of ser in the area of core we willall get an even better ser/openser. In fact even if we can't reach an agreement in dividing areas, smallcooperation like on fixing/improving code that is the same in bothvers! ions would still be good.I would say that even a friendly competing approach would be better thennothing (with comparisons, benchmarks a.s.o), it points out problems in both versions and serves as a motivation to improve.Andrei[...]_______________________________________________Serusers mailing listSerusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers _______________________________________________Serusers mailing listSerusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers --Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________Serusers mailing listSerusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
At 13:48 05/12/2006, sip wrote:
Sure. I'll share what I can share without giving too much of the business away.
For the most part, we use SER's modules from the 0.9.x set. However, we do use the alias_db module from OpenSER as it's FAR easier to securely code a web-based system that only accesses the database than it is to have to rely on ANY access to the command line (using SER, because it places its aliases into memory, it would require us to add them via serctl or it wouldn't pick them up (or manually add them with fifo commands ourselves, which is out of the question. First rule of web security: thou shalt avoid ever writing to the filesystem from the web)). The alias_db module allows us to just add aliases during runtime to the DB. We take a tiny performance hit from that, but considering the other DB calls that have to be made for checks and what not for every incoming call, an extra call to check the alias is really insignificant.
I think that's fair assessment of the situation. which happens to be addressed by ottendrof -- all URIs, as many as you can eat, map to a single expression of your identity (user_id) and this mapping is stored in the URI table.
(I thought the document was under http://www.iptel.org/ser/doc/010whatsnew and can't find it anymore -- Greger, would you please mind checking?)
...
We went down the road of dynamic timers, so we needed a timer table for the users' timers.
The user_attrs table now holds all user-related pieces of information in a way that if you add a new feature you dont have to change table structure again. (attribute-value-pair-based)
Thanks!
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
http://www.iptel.org/ser/development/documentation
Jiri Kuthan wrote:
At 13:48 05/12/2006, sip wrote:
Sure. I'll share what I can share without giving too much of the business away.
For the most part, we use SER's modules from the 0.9.x set. However, we do use the alias_db module from OpenSER as it's FAR easier to securely code a web-based system that only accesses the database than it is to have to rely on ANY access to the command line (using SER, because it places its aliases into memory, it would require us to add them via serctl or it wouldn't pick them up (or manually add them with fifo commands ourselves, which is out of the question. First rule of web security: thou shalt avoid ever writing to the filesystem from the web)). The alias_db module allows us to just add aliases during runtime to the DB. We take a tiny performance hit from that, but considering the other DB calls that have to be made for checks and what not for every incoming call, an extra call to check the alias is really insignificant.
I think that's fair assessment of the situation. which happens to be addressed by ottendrof -- all URIs, as many as you can eat, map to a single expression of your identity (user_id) and this mapping is stored in the URI table.
(I thought the document was under http://www.iptel.org/ser/doc/010whatsnew and can't find it anymore -- Greger, would you please mind checking?)
...
We went down the road of dynamic timers, so we needed a timer table for the users' timers.
The user_attrs table now holds all user-related pieces of information in a way that if you add a new feature you dont have to change table structure again. (attribute-value-pair-based)
Thanks!
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Thanks for a thorough write-up! I'm "afraid" you are not very atypical when it comes to mixing your own data model into SER's. In general, I miss an "official" opinion on how to extend the data model, which could help in migration. I know many people (including myself) use RADIUS to split the authentication, groups, and AVPs away from the internal run-time data of SER (primarily usrloc). This way the SER db can as a worst case be totally discarded on an upgrade (loosing current registrations). You also offload the DB lookups to another server. I have also written up a suggestion for a patch that would avoid user authentication against the RADIUS servers as long as a reREGISTER is just a refresh of the registration. http://www.iptel.org/refresh_of_reregister_instead_of_new_authentication_in_...
For some reason or another, many (most?) people opt for extending the SER database, which makes for painful migrations. How to extend and not extend would be a very useful guide, if it could help people avoid some migration headaches.
See inline for specific comments.
sip wrote:
Sure. I'll share what I can share without giving too much of the business away.
For the most part, we use SER's modules from the 0.9.x set. However, we do use the alias_db module from OpenSER as it's FAR easier to securely code a web-based system that only accesses the database than it is to have to rely on ANY access to the command line (using SER, because it places its aliases into memory, it would require us to add them via serctl or it wouldn't pick them up (or manually add them with fifo commands ourselves, which is out of the question. First rule of web security: thou shalt avoid ever writing to the filesystem from the web)). The alias_db module allows us to just add aliases during runtime to the DB. We take a tiny performance hit from that, but considering the other DB calls that have to be made for checks and what not for every incoming call, an extra call to check the alias is really insignificant.
Yes, makes sense. As Jiri pointed out, this is improved a lot in Ottendorf. Also, with the new management interface, I assume the XMLRPC front-end would be your choice?
One of our programmers also backported the AVP functionality from the 0.1.x OpenSER uac module. We use this to modify the SIP comment portion of the From: header (which is allowed under the RFC) dynamically to ensure no spoofing.
;-) http://www.iptel.org/ser/contributions makes it easy to submit a module or patch for various versions of SER. It is meant as a library of modules and patches that people can go to to extend functionality regardless of the version of SER they are using.
So if you consider "giving it back", feel free! :-)
As for why we modified the db model... well... it just wasn't right for our setup. We don't user SERWeb for anything. I'm sure it's a lovely product for basic administration, but we have our own site code, and we use a strict OO model for coding, so the use of any SERWeb code was out of the question.
We modified speeddial for our own purposes, so the speed_dial table had to be modified. We use the subscriber table for the website, which started off as a way to unify information, but then we switched to radius authentication and use the subscriber table strictly for the web (and for referencing other tables). Of course, that meant we needed to add things to it such as a signup IP address to keep track of user signups for statistics, we modified some of the fields here and there for our own use. We also added a lot of tables we need for other things, such as a call blocking table and a call return table.
:-) Yes, one thing leads to another... What kind of resource would have helped you before you started? Any ideas?
We went down the road of dynamic timers, so we needed a timer table for the users' timers. We completely redid the phonebook information, so we keep user phonebooks in a rather complex scheme.
Of course, we have our pricing tables and what not.
And that's just the SER side. It's constantly trading information back and forth with Asterisk, which has its own tables to handle our own billing code and proper billing for call forwards and such, as well as information about the expirations for users' DIDs and Voicemail.
:-) I see. You're starting to get some dependencies, yes.
We also have SEMS in the mix for basic voicemail and conference rooms, but we made some modifications here and there to handle our userbase.
We use SER primarily for SIP, but we've tied it in very closely with our web applications, so we've tied the DB all together. I'm not sure we're a normal case in that sense, but who's to say. We may well be.
As I said, my feeling is that you're the normal case.
And you, Greger, I KNOW, would absolutely CRINGE at our ser.cfg. It's a massive, 40k file of madness. Amusingly, however, it's pretty well optimised. It just has to take a LOT of different situations into account.
:-D You will probably like the new m4 build system I'm creating then... It splits up ser.cfg into logical pieces that can be maintained separately. g-)
N.
On Mon, 04 Dec 2006 21:45:35 +0100, Greger V. Teigre wrote*
I'm trying to figure out how people use SER in order to get a
picture of what the needs really are. My goal is to be able to group various usage patterns and create "best practice" areas at iptel.org, where people also can add comments and describe their experiences.
Would you mind sharing a bit about the "mixture of SER and OpenSER
modules" you are using, as well as why you opted to change the database model?
g-)
sip wrote: Indeed. No fears there. We've already got a dedicated server on order to test it with. Won't likely be here until the beginning of the year, but we won't have time to muck with it before then anyway with the usual end-of-year madness going on.
Very much looking forward to testing Ottendorf and trying to figure out the best way to migrate. As is, it will be slightly complex as we've spent a good portion of time redoing the SER database to our particular specifications and needs... and many of the tables we use have been removed or redone for Ottendorf, and many of the features we rely upon have been completely done away with.
Also, since we use a mixture of SER and OpenSER modules in our code, as well as in-house modules to handle several things, migrating to Ottendorf is going to be an exercise in frustration and pain. :) I'm not eager to start even looking at that until after the holidays.
N.
On Mon, 04 Dec 2006 10:39:25 +0100, Jiri Kuthan wrote
Just to make it clear, it is pretty much only possible with Ottendorf if you are having a reasonably big setup. The previous timer system was not accurate (you might have noticed, that retransmission timer fired in a range of +/- 1 sec which is kind of unexact given the timer length 0.5 sec), variable (all timers were pretty much supposed to be of the same length), high-resolution (it used to be 1 second).
I concur that migration is alway a painful exercise, but I can only recommend folks to make themselves busy with it earlier than too late.
-jiri
At 23:05 01/12/2006, sip wrote:
Well... the TM bug may not be earth-shattering, but it's most decidedly important. One of the functions we have that our users LOVE is the ability to set their own timeout values for voicemail. We had had a default value that we thought would make everyone happy, but soon discovered that many would complain that it was too long, and many would complain that it was too short.
Having had many users who came along from asterisk-based services, where setting individual timeout values is rather straightforward and easy.
One of the things we've been struggling with has been the timing values. While it may not be important in the scheme that it's not ACTUALLY service-affecting, I can assure you, if you offer a service, and it doesn't work as prescribed, the consequences can be deadly. You shake user-confidence -- and that sort of thing travels VERY quickly by word of mouth. It's so very hard to gain users, and so very easy to lose them to a competitor -- even if that competitor doesn't offer the same options. For what good are options that only work sometimes?
SO... in short... yeah... I'm really happy that the timer stuff has been fixed in Ottendorf. Of course, it'll be a LONG time before we can migrate the production systems to it, but it gives me something to look forward to.
N.
On Thu, 30 Nov 2006 12:19:03 +0100, Andrei Pelinescu-Onciul wrote
On Nov 29, 2006 at 14:05, Kim Il kim_il_s@yahoo.com wrote:
this is getting more and more confusing. The one side says this is a bug,
the other says it is a feature. I will try to summarize my understanding
till now:
I believe we better stop this line of discussion at least for now and instead concentrate on fixing the technical problems that were revealed on both sides. I wouldn't want it to hinder possible future collaboration.
- openser claims that they improved something and the ser guys say this
fix is useless. Daniel, Bogdan could you plesase explain what is really behind this improvement (Sorry Weiter, but your explanation is far from being sufficient).
I don't know exactly what are you referring to ("something"?), but I don't remember claiming that an openser fix was useless (at least I haven't, I might have implied that something, IMHO was not as important as claimed, but not that was useless).
- The ser guys show that openser is inferior to ser but Bogdan replies
this is on purpose (because otherwise a strange race situation can occur which Andrei tells us is negligable).
Actually, the claim was along the lines that tm (the statefull part of the sip stack in ser) and/or the core performance was inferior.
The bug that Bogdan discovered is not negligible. I wanted to point out that it was not as important as suggested. This probably deserves a better explanation, so that people without ser-internals knowledge can understand. First of all variable timers in this context mean the possibility to set different values for the fr_timer and fr_inv_timer at runtime
(e.g. in function of some user preferences/avps or some special script logic) as oppossed to having some fixed (but configurable) values. What really matters here is the fr_inv_timer. The fr_inv_timer is the time that ser waits for a final response on an INVITE transaction _after_ a provisional response was received (e.g. 180 Ringing). This roughly corresponds to the Timer C from the sip rfc (rfc3261). According to the sip rfc both fr_tiemr and fr_inv_timer should be fixed and _not_ configurable. However in practice it makes sense to change them (especially the fr_inv_timer), to implement services such as redirect to voicemail after x seconds. The most common use of the variable timers is user (or group) configurable voicemail redirection. This means that the user is somehow able to configure the "ringing" interval after which a caller will be redirected to his voicemail. If variable timers are not used, the voicemail config option would include only on or off (the ringing time before voicemail redirection wouldn't be configurable, it would be the same for all the users). Now what the bug did, was that it could cause the extension of fr_inv_timer to the fr_inv_timer of another transaction, if _different_ variable timers were used and some race occured (note that the probability of hitting the race is quite high if lots of variable fr_inv_timers with different values are used and the system is very busy). This IMHO is not such a big problem since in the case when you are hit by it, it really doesn't break anything important (I don't see sometimes redirecting later to voicemail as such a big problem, OTOH people might use it for other stuff).
- I will not get into the history discussion -which I have already touched
in previous mails, let alone those mails about respect and the other stuff I could not really see how they relate to this discussion.
I would really appreciate if these points were clarified -I have the
impression the ball is now with Daniel and Bogdan. So plesse Bogdan do not hold to your one mail policy and help clarifying this and provide a bit more of details on the improvements of openser to core and tm.
I believe Andrei has made a good suggestion that it is in the interest of
the entire community to cooperate and divide the areas of interest. By combining the great work the openser guys have done in the area of documentation and featutres with the work of ser in the area of core we will all get an even better ser/openser.
In fact even if we can't reach an agreement in dividing areas, small cooperation like on fixing/improving code that is the same in both versions would still be good. I would say that even a friendly competing approach would be better then nothing (with comparisons, benchmarks a.s.o), it points out problems in both versions and serves as a motivation to improve.
Andrei [...] _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 16:41 04/12/2006, sip wrote:
Very much looking forward to testing Ottendorf and trying to figure out the best way to migrate. As is, it will be slightly complex as we've spent a good portion of time redoing the SER database to our particular specifications and needs... and many of the tables we use have been removed or redone for Ottendorf, and many of the features we rely upon have been completely done away with.
I hope the migration script posted recently and the scheme doc makes it at least a bit easier.
Also, since we use a mixture of SER and OpenSER modules in our code, as well as in-house modules to handle several things, migrating to Ottendorf is going to be an exercise in frustration and pain. :) I'm not eager to start even looking at that until after the holidays.
That's understandable. We thought about what it would take to make it easier but that's unfortunately an activity which is cumbersome too.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
On Mon, Nov 27, 2006 at 11:16:01PM +0200, Daniel-Constantin Mierla wrote:
As I can see, you get better and better with openser, maybe you can get some training so you will be able to configure and tune it properly to fit your needs and get the appropriate results (googling will reveal some doing trainings for openser). So which are right, these ones, the previous ones or the next testing results? You tested something, which (I suppose) you are very familiar with (ser), against something that you do not know properly to configure. There are some internals that differ a lot and may have quite a lot of performance impact.
Might be. I have increased shared memory size to get less errors (and timeouts) got by some openser tests which have influence on average throughput - I wanted to have this number to be comparable with ser. In the last one I reduced number of created transactions because 768 MB was not sufficient.
Just after you sent this mail, I have seen a commit to usrloc which saves some problems I pointed in my previous email in this thread (so, yes, we are concerned about performance, and see you need to catch up now in some directions). The difference is now that ser's usrloc hash table size is by default 2^14 (16384) while in openser is 2^9 (512). So I guess some tests you can do now will be faster for ser, but to change the hash value in ser you have to re-compile, as opposite to openser where you can do it via module parameter.
:-) This usrloc problem is known to us for some weeks as a result of other performance tests. It is really good to do them. ;-) I suggested to Andrei to do hash table parameters (hash function and size) configurable but he conviced me, that fixed solution (at least for the size) will be sufficient...
So please, try to make sure that the corresponding parameters have same values, from number of processes, to memory, hash tables sizes, and so on ... for future tests. If you are not able to do fair tests, it is better to leave it for some impartial entities. With the description of your tests a lot of parameters and variables are hidden, and do not reflect the real capacity of the applications (I can say it now at least for openser).
Might be, I only tried to run with default compilation flags and very simple config. I didn't try to play with anything else. Such tests are good to check a small closed part of code to show if there are problems or not - the usrloc problem was found this way...
And just to remember, as proved, you got very good performances but wrong processing. I will ask you and users: do you prefer to have *high performances* tied to *invalid processing* of the requests? http://openser.org/pipermail/users/2006-November/007843.html Well, maybe for some folks it is a 'proud' to say: *ser offers very fast _invalid_ functionalities* or "ser can scale to millions of _offline_ users*.
You owe to say to the users that the performances were obtained with a *buggy SIP transaction processing*, and correct the web pages posted at the link below.
OK, I will try to verify your bug report - if it will show, that you are right I can do the tests again as soon as it will be corrected.
Vaclav
P.S. Resending message because it was marked as spam, sorry.
Actually I replied to this mail because of some accuses that 'we spread the rumor "ser is dead"'. Nowhere you can find such statement from our side. After some investigations proved that the phrase in charge is: "Soon after, /iptelorg.com Gmbh/ was sold to /Tekelec/, which had no intention to continue the development of the public project." from oepnser history (http://www.openser.org/index.php?option=com_content&task=view&id=40&...).
This is quite different than "ser is dead", and many of you know the statement made in "openser history" is true. I cannot name some private channels I have, but there are publicly spoken ones. I paste from https://mail.internet2.edu/wws/arc/sip.edu/2006-10/msg00003.html:
<snip> Christian says that he was surprised at the continued development of SER after speaking with people from Tekelec, as they mentioned that they were not as interested in continuing SER as an open source project and were more interested in integrating SER into their IMS offerings. He asks about the future of SER as an open source project. Jiri feels that there should be no issues, and the main contributors are still making contributions. He's hesitant to speak on the behalf of the company, but feels that based on past performance nothing should be changing. </snip>
I would polite ask those persons not to twist the phrases without giving good proof.
Users can see now who and how tries to hoke up the reality.
Cheers, Daniel
On 11/24/06 17:06, 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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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));
At 00:33 28/11/2006, Vaclav Kubart wrote:
On Mon, Nov 27, 2006 at 11:16:01PM +0200, Daniel-Constantin Mierla wrote:
So which are right, these ones, the previous ones or the next testing results? You tested something, which (I suppose) you are very familiar with (ser), against something that you do not know properly to configure. There are some internals that differ a lot and may have quite a lot of performance impact.
Hi Daniel,
just to make sure your concerns about accurancy of the measurements do not remain unattanded -- has been the version mismatch concern been addressed for you? Are there still any internals-oriented aspects which haven't been reflected and make the benchmarking results possibly inaccurate?
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Hello,
On 12/15/06 21:59, Jiri Kuthan wrote:
At 00:33 28/11/2006, Vaclav Kubart wrote:
On Mon, Nov 27, 2006 at 11:16:01PM +0200, Daniel-Constantin Mierla wrote:
So which are right, these ones, the previous ones or the next testing results? You tested something, which (I suppose) you are very familiar with (ser), against something that you do not know properly to configure. There are some internals that differ a lot and may have quite a lot of performance impact.
Hi Daniel,
just to make sure your concerns about accurancy of the measurements do not remain unattanded -- has been the version mismatch concern been addressed for you? Are there still any internals-oriented aspects which haven't been reflected and make the benchmarking results possibly inaccurate?
as you should know, there are many internal parameters that can make the results totally different (e.g., number of processes, size of memory, size of hash tables, and so on ..). A comparison will be accurate when every parameter will be correlated, which is hard to do and I have not time for it -- so, my concerns are still on. Using same config does not mean all internal parameters have same values. Also, as proved, some misbehaviors or bugs in software can increase (decrease) the performances to high levels, but useless or worse.
We will do performance tests for OpenSER only once we get in testing phase with current development. Till then, since that moment is not that far (see roadmap), makes no sense to spend time in testing a moving target. The tests will be just for OpenSER, because I consider that the right knowledge will be applied, avoiding in this way to mislead users (intentionally or not).
Daniel
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Dear Daniel, You are free to voice any opinion on serusers, but please follow the netiquette rules (http://www.albion.com/netiquette/corerules.html).
One should be able to expect more from you, considering your role in openser. I will not interfere with how you behave on openser lists, however, on serusers you are a list member as any other and you should behave.
IMO, Vaclev deserves an apology from you. He has by no means showed any bad will or on purpose tried to make openser look bad in his testing. On the contrary, he has explicitly requested suggestions for improving the test to make it more balanced.
Finally, to the topic: I think people should be allowed to choose between ser and openser based on the merits of each. People are not stupid and they use the information available. Information sources from different angles allow people to balance out pros and cons make an informed decision. Due to this thread, I have checked the online archives of the openser users list, and I see many posts that clearly are made based on limited information or are plain wrong. However, I do not think active corrections from my side on your list would do any good. If people seek more information about SER, they have http://iptel.org/ the mailing lists.
I call for an honest competition where as much information as possible is provided to the users!
Regards, Greger
PS! To OpenSER users list members (if this post gets through): Posts from myself and others who are not subscribers to the openser users list must be moderated manually and even though posts used to get through, several have been stopped. You can see the full thread here: http://lists.iptel.org/pipermail/serusers/2006-November/031289.html
Daniel-Constantin Mierla wrote:
As I can see, you get better and better with openser, maybe you can get some training so you will be able to configure and tune it properly to fit your needs and get the appropriate results (googling will reveal some doing trainings for openser). So which are right, these ones, the previous ones or the next testing results? You tested something, which (I suppose) you are very familiar with (ser), against something that you do not know properly to configure. There are some internals that differ a lot and may have quite a lot of performance impact.
Just after you sent this mail, I have seen a commit to usrloc which saves some problems I pointed in my previous email in this thread (so, yes, we are concerned about performance, and see you need to catch up now in some directions). The difference is now that ser's usrloc hash table size is by default 2^14 (16384) while in openser is 2^9 (512). So I guess some tests you can do now will be faster for ser, but to change the hash value in ser you have to re-compile, as opposite to openser where you can do it via module parameter.
So please, try to make sure that the corresponding parameters have same values, from number of processes, to memory, hash tables sizes, and so on ... for future tests. If you are not able to do fair tests, it is better to leave it for some impartial entities. With the description of your tests a lot of parameters and variables are hidden, and do not reflect the real capacity of the applications (I can say it now at least for openser).
And just to remember, as proved, you got very good performances but wrong processing. I will ask you and users: do you prefer to have *high performances* tied to *invalid processing* of the requests? http://openser.org/pipermail/users/2006-November/007843.html Well, maybe for some folks it is a 'proud' to say: *ser offers very fast _invalid_ functionalities* or "ser can scale to millions of _offline_ users*.
You owe to say to the users that the performances were obtained with a *buggy SIP transaction processing*, and correct the web pages posted at the link below.
Actually I replied to this mail because of some accuses that 'we spread the rumor "ser is dead"'. Nowhere you can find such statement from our side. After some investigations proved that the phrase in charge is: "Soon after, /iptelorg.com Gmbh/ was sold to /Tekelec/, which had no intention to continue the development of the public project." from oepnser history (http://www.openser.org/index.php?option=com_content&task=view&id=40&...).
This is quite different than "ser is dead", and many of you know the statement made in "openser history" is true. I cannot name some private channels I have, but there are publicly spoken ones. I paste from https://mail.internet2.edu/wws/arc/sip.edu/2006-10/msg00003.html:
<snip> Christian says that he was surprised at the continued development of SER after speaking with people from Tekelec, as they mentioned that they were not as interested in continuing SER as an open source project and were more interested in integrating SER into their IMS offerings. He asks about the future of SER as an open source project. Jiri feels that there should be no issues, and the main contributors are still making contributions. He's hesitant to speak on the behalf of the company, but feels that based on past performance nothing should be changing. </snip>
I would polite ask those persons not to twist the phrases without giving good proof.
Users can see now who and how tries to hoke up the reality.
Cheers, Daniel
On 11/24/06 17:06, 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/
VaclavP.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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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];
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi folks, I've tried to stay out of this thread but I think it has gone far beyond technical arguments and I don't think it will help neither SER or openSER projects. I would just ask to stop this thread before it get worst or stack to technical discussions (which I'm learning a lot) and leave personal appreciations aside.
I still see advantages on each project and depending on the requirements, one is more suited than the other. I had the hope that both would merge with the best of them but I see this almost impossible right now...
I'll try to summarize differences and I would apreciate *technical* corrections to it (it's almost impossible to have an update list....fortunately, i've tried to enumerate diferences in the dev versions which will soon become stable): *openSER: o1)detailled documentation, including howtos o2)fast reaction in the mailing list from the core developers o3)incorporate user comments into new features o4)decentralised developers o5)improved usrloc (loading on mem, cacheless) o6)gaining user acceptance->biggest testing comunity
*SER s1)improved TCP code s2)improved timers s3)easier integration with SEMS/SERWEB
I have tried to be as opbjective as possible (but everyone knows it's almost impossible) and it would be great to create a common place to share experiences with both projects as someone has proposed but I guess everyone is really really busy right now...
Samuel.
All,
By the way, can anyone confirm whether or not serweb is being actively developed?
Thanks,
Mike Williams
On Tuesday 28 November 2006 05:34, samuel wrote:
Hi folks, I've tried to stay out of this thread but I think it has gone far beyond technical arguments and I don't think it will help neither SER or openSER projects. I would just ask to stop this thread before it get worst or stack to technical discussions (which I'm learning a lot) and leave personal appreciations aside.
I still see advantages on each project and depending on the requirements, one is more suited than the other. I had the hope that both would merge with the best of them but I see this almost impossible right now...
I'll try to summarize differences and I would apreciate *technical* corrections to it (it's almost impossible to have an update list....fortunately, i've tried to enumerate diferences in the dev versions which will soon become stable): *openSER: o1)detailled documentation, including howtos o2)fast reaction in the mailing list from the core developers o3)incorporate user comments into new features o4)decentralised developers o5)improved usrloc (loading on mem, cacheless) o6)gaining user acceptance->biggest testing comunity
*SER s1)improved TCP code s2)improved timers s3)easier integration with SEMS/SERWEB
I have tried to be as opbjective as possible (but everyone knows it's almost impossible) and it would be great to create a common place to share experiences with both projects as someone has proposed but I guess everyone is really really busy right now...
Samuel.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
it is. Samuel
2006/11/28, Mike Williams mike@mikebwilliams.com:
All,
By the way, can anyone confirm whether or not serweb is being actively developed?
Thanks,
Mike Williams
On Tuesday 28 November 2006 05:34, samuel wrote:
Hi folks, I've tried to stay out of this thread but I think it has gone far beyond technical arguments and I don't think it will help neither SER or openSER projects. I would just ask to stop this thread before it get worst or stack to technical discussions (which I'm learning a lot) and leave personal appreciations aside.
I still see advantages on each project and depending on the requirements, one is more suited than the other. I had the hope that both would merge with the best of them but I see this almost impossible right now...
I'll try to summarize differences and I would apreciate *technical* corrections to it (it's almost impossible to have an update list....fortunately, i've tried to enumerate diferences in the dev versions which will soon become stable): *openSER: o1)detailled documentation, including howtos o2)fast reaction in the mailing list from the core developers o3)incorporate user comments into new features o4)decentralised developers o5)improved usrloc (loading on mem, cacheless) o6)gaining user acceptance->biggest testing comunity
*SER s1)improved TCP code s2)improved timers s3)easier integration with SEMS/SERWEB
I have tried to be as opbjective as possible (but everyone knows it's almost impossible) and it would be great to create a common place to share experiences with both projects as someone has proposed but I guess everyone is really really busy right now...
Samuel.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
the ottendorf announcement (http://www.iptel.org/new_major_ser_pre_release_ottendorf_is_out_for_testing) pecifically mentiones some of serweb features. it should be said that the documentation has been traditionally underwhelming and there has been no attempt yet to address that.
-jiri
At 12:45 28/11/2006, Mike Williams wrote:
All,
By the way, can anyone confirm whether or not serweb is being actively developed?
Thanks,
Mike Williams
On Tuesday 28 November 2006 05:34, samuel wrote:
Hi folks, I've tried to stay out of this thread but I think it has gone far beyond technical arguments and I don't think it will help neither SER or openSER projects. I would just ask to stop this thread before it get worst or stack to technical discussions (which I'm learning a lot) and leave personal appreciations aside.
I still see advantages on each project and depending on the requirements, one is more suited than the other. I had the hope that both would merge with the best of them but I see this almost impossible right now...
I'll try to summarize differences and I would apreciate *technical* corrections to it (it's almost impossible to have an update list....fortunately, i've tried to enumerate diferences in the dev versions which will soon become stable): *openSER: o1)detailled documentation, including howtos o2)fast reaction in the mailing list from the core developers o3)incorporate user comments into new features o4)decentralised developers o5)improved usrloc (loading on mem, cacheless) o6)gaining user acceptance->biggest testing comunity
*SER s1)improved TCP code s2)improved timers s3)easier integration with SEMS/SERWEB
I have tried to be as opbjective as possible (but everyone knows it's almost impossible) and it would be great to create a common place to share experiences with both projects as someone has proposed but I guess everyone is really really busy right now...
Samuel.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Hi Samuel,
I'm just curious:
On Tuesday 28 November 2006 11:34, samuel wrote:
I'll try to summarize differences and I would apreciate *technical* corrections to it (it's almost impossible to have an update list....fortunately, i've tried to enumerate diferences in the dev versions which will soon become stable): *openSER: o1)detailled documentation, including howtos o2)fast reaction in the mailing list from the core developers o3)incorporate user comments into new features o4)decentralised developers
What do you mean by this point: are you afraid that all the SER or OpenSER developers are striked out by an atomic nuke?
Nils
o5)improved usrloc (loading on mem, cacheless) o6)gaining user acceptance->biggest testing comunity
*SER s1)improved TCP code s2)improved timers s3)easier integration with SEMS/SERWEB
I have tried to be as opbjective as possible (but everyone knows it's almost impossible) and it would be great to create a common place to share experiences with both projects as someone has proposed but I guess everyone is really really busy right now...
Samuel. _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi all,
I've got some problems with the MediaProxy.
I found a UA with a Public IP that reaches my SIP Server through a NAT. Then the MediaProxy receives the RTP flow from the NAT's IP address, and relay the same flow to the real UAC's IP address (that is public too).
[UA (Public IP)] --> [NAT (Public IP)] --> [SIP Server (Public IP)]
What about the RTP flow sent by the other party? MediaProxy just ignores it.
Anybody knows why is the MediaProxy acting that way?
Thanks in advance,
Víctor
o4)decentralised developers
What do you mean by this point: are you afraid that all the SER or OpenSER developers are striked out by an atomic nuke?
I hope not!! What I was trying to mention is that openSER is getting contribution from many different developers while SER is lately getting code from people from iptel. This means that openser has many scatered people around with enough knowledge to develop extensions and this guarantees the continuation of the project even if some developer can not working on it anymore. This point gives the project a futureproof perception... It also means that several people with really good knowledge on the project are using it for different purpouses, different scenarios, different use cases, different deployments, etc... and they can come up with new extensions and bugs...
This point is related to the user's community and the documentation, and that is why in my initial list I even mentioned them even before the technical ones. Providing good documentation and listening to the users has proved to be one the best ways to get really good open source projects.
I hope I have explained better now, Samuel.
P.D. Let weapons out of this discussions, bitte!!!!!
Daniel,
and please of course anyone else.
Please, I am kindly asking folks to discontinue use of offensive language, inaccurate information, personal attacks, and other flammables -- that really must stop.
I think that pure technical content is the best we can get, is of solid value, and can (and should) be challenged in the technical language too. I think it is great to see measurements, technical counter-arguments and updated measurements reflecting the arguments -- I'm looking forward to more of those.
But don't let us get it mixed with hostile non-technical content. In the end, it is this hostile tone which effectively impedes ser/openser progress. Users benefit of each, and actually there is a reasonable desire to cross-benefit of both, which is not achievable without respect.
Addressing that would (will) be a longer email, but for now I hope people will be fine with understandable suggestion: CONSIDER BEING POLITE! With this very simple suggestion, all of the lengthy recommendations bellow will automatically become useless :-)
-jiri
----
Now the things I really consider counterproductive and I would like their respective authors to develop a more appropriate communication style for: - the pseudo "history" webpage for openser is just too dishonest. I have posted my opinion on it and site owners, voice sistem, have not provided an answer, not speaking of an excuse. (I know Klaus did answer nicely, but still I think people who own it should stand up.) It is twisted language, but it really suggests that SER was discontinued when at the same time the originators of the gossip actively copied-and-pasted SER code. http://lists.iptel.org/pipermail/serusers/2006-November/031423.html The level of how dishonest this is and how little respect to SER developers it shows makes me really concerned. - personal attacks are just silly. I really don't think there is any possible gain in suggesting someone's ignorance by offering tutorials. http://lists.iptel.org/pipermail/serusers/2006-November/031490.html I'm sure the email author, who is largely leveraging Andrei's code in openser, will feel painful when he cools down later, but let's better be polite before than too late. - I really advise people not to use gossip language. Reference to "undisclosed private channels" regarding SER activity status in DAniel's Email I am replying to, compared to facts such as SER release announcement (http://www.iptel.org/new_major_ser_pre_release_ottendorf_is_out_for_testing) provides you with quite different information density (ehmmm....) - Responding to technical information with rants does not make things any better either. I am sure that openser's performance may be a negative experience, but that's not an excuse to attack a solid performance report with derogative attempts to undermine its credibility. E.g., this is an example of inappropriate communication: http://lists.iptel.org/pipermail/serusers/2006-November/031421.html -- it tries to attack credibility, but it is not getting to the point. Later, Bogdan Iancu, is trying to question it by reference to a bug http://lists.iptel.org/pipermail/serusers/2006-November/031487.html Seriously, this only helps to generate flames and conceal some structural shortcomings, but it really does not make things better. I suggest folks examine the performance report in terms of technical validity -- so far I have seen updated measurements were provided in response to technical arguments dilligently. - Generally, the level of credits SER authors obtain from those who have commit rights to openser shows that the communication culture really needs to be improved. It just can't be that credits for the work, on which openser depends, are concealed and credited to someone else. For sake of completness, I'm referring to this http://lists.iptel.org/pipermail/serusers/2006-November/031439.html
Some of these things are really matter of attitude, but even with that, as absolute minimum, everyone should develop effort to speak facts in cultivated, polite manner which does not ofend anyone else.
I have been travelling and off-line and cannot quickly catch up on the content exchanged now and will try to, but folks: the tone really must change.
ps -- I subscribed to openser, hopefuly my emails will get through now.
At 22:16 27/11/2006, Daniel-Constantin Mierla wrote:
As I can see, you get better and better with openser, maybe you can get some training so you will be able to configure and tune it properly to fit your needs and get the appropriate results (googling will reveal some doing trainings for openser). So which are right, these ones, the previous ones or the next testing results? You tested something, which (I suppose) you are very familiar with (ser), against something that you do not know properly to configure. There are some internals that differ a lot and may have quite a lot of performance impact.
Just after you sent this mail, I have seen a commit to usrloc which saves some problems I pointed in my previous email in this thread (so, yes, we are concerned about performance, and see you need to catch up now in some directions). The difference is now that ser's usrloc hash table size is by default 2^14 (16384) while in openser is 2^9 (512). So I guess some tests you can do now will be faster for ser, but to change the hash value in ser you have to re-compile, as opposite to openser where you can do it via module parameter.
So please, try to make sure that the corresponding parameters have same values, from number of processes, to memory, hash tables sizes, and so on ... for future tests. If you are not able to do fair tests, it is better to leave it for some impartial entities. With the description of your tests a lot of parameters and variables are hidden, and do not reflect the real capacity of the applications (I can say it now at least for openser).
And just to remember, as proved, you got very good performances but wrong processing. I will ask you and users: do you prefer to have *high performances* tied to *invalid processing* of the requests? http://openser.org/pipermail/users/2006-November/007843.html Well, maybe for some folks it is a 'proud' to say: *ser offers very fast _invalid_ functionalities* or "ser can scale to millions of _offline_ users*.
You owe to say to the users that the performances were obtained with a *buggy SIP transaction processing*, and correct the web pages posted at the link below.
Actually I replied to this mail because of some accuses that 'we spread the rumor "ser is dead"'. Nowhere you can find such statement from our side. After some investigations proved that the phrase in charge is: "Soon after, /iptelorg.com Gmbh/ was sold to /Tekelec/, which had no intention to continue the development of the public project." from oepnser history (http://www.openser.org/index.php?option=com_content&task=view&id=40&...).
This is quite different than "ser is dead", and many of you know the statement made in "openser history" is true. I cannot name some private channels I have, but there are publicly spoken ones. I paste from https://mail.internet2.edu/wws/arc/sip.edu/2006-10/msg00003.html:
<snip> Christian says that he was surprised at the continued development of SER after speaking with people from Tekelec, as they mentioned that they were not as interested in continuing SER as an open source project and were more interested in integrating SER into their IMS offerings. He asks about the future of SER as an open source project. Jiri feels that there should be no issues, and the main contributors are still making contributions. He's hesitant to speak on the behalf of the company, but feels that based on past performance nothing should be changing. </snip>
I would polite ask those persons not to twist the phrases without giving good proof.
Users can see now who and how tries to hoke up the reality.
Cheers, Daniel
On 11/24/06 17:06, 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/
VaclavP.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@googlemail.com To: Kim Il kim_il_s@yahoo.com Cc: users@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.comkim_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.combp4mls@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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));
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
-
"tzieleniewski" -
Andrei Pelinescu-Onciul -
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Greger V. Teigre -
Jan Andres -
Jan Janak -
Jiri Kuthan -
Kim Il -
Klaus Darilion -
Mike Williams -
Nils Ohlmeier -
Ovidiu Sas -
Rao Ramaratnamma -
samuel -
sip -
Vaclav Kubart -
Victoria Cortez -
Weiter Leiter