<br><br><div><span class="gmail_quote">On 11/17/07, <b class="gmail_sendername">Talking Voice</b> <<a href="mailto:talkingvoice@gmail.com">talkingvoice@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Have you seen the stats on rtpproxy <a href="http://www.rtpproxy.org">http://www.rtpproxy.org</a> it seems<br>to be far more impressive than those of Asterisk B2BUA.</blockquote><div><br><br>it also does less work. It does not relay media, and those numbers arent impressive when you consider there are other open source projects that in a B2BUA without media can do 30,000 on a box less than what the asterisk test platform was. But since this is the asterisk-biz list I wont comment on them. I only bring that up to say that if you arent shovenling the media bits around there is less work to do and performance increases. If you are a reseller of traffic you can cut your bandwidth costs by going direct to the carriers and not touching the media, which makes it easier to lower your rates and be more competitive, since most end users dont care about that although other ITSPs would most likely.
<br><br>150-200 cps is a good number though, much higher than than the 8.5, and while that may be high unless you have a lot of campaign customers, it does give these stats a run for their money, since that is generally more expensive than just shoveling bits.
<br><br>1-8 cps also makes it harder to extrapolate, if you look at the progression in the pdf, if you go from 1-2 cps you double the concurrent calls (more or less) which keeps progressing off the base, until you reach 8.5
. Why was 8.5 the stopping point and not 9 anyway, it seems like an odd count to stop at, but anyway. If you were to just do linear math, which never works since management overhead in this situation will grow exponentially not linearly as you add more channels (context switches, servicing NIC irqs, etc) you cannot extrapolate that if you get 3000 legs at 8 cps that at 16 you will have 6000. I have a guess and would love it if someone could confirm this that if you were to test at 16, 32 and 64 cps that the total number of channels would drop dramatically, and you would see calls fail to start.
<br><br>Now there are other factors, to be fair I will comment on sippy since you brought it up :) They say "per server" but do not define the server in question, in the asterisk report the server was specifically defined (although it would have been nicer to have more details on which versions of libs were installed, sysctl settings, etc). A server could be for example a sun with 16 cores or whatever. That should get more performance than a dual woodcrest 5140 box.
<br><br>Then we get into more details of the woodcrest cpu, something I neglected to comment on last night when trying to say that they are different from other xeon chips. The woodcrest (dual core) and clovertown (quad core) are branded as a xeon, but there is a huge performance difference between these and other xeon chips, for one thing they can do 4 instructions per clock tick (per intel, dunno how this works exactly since its CISC and not RISC so instructions can have variable numbers of ticks required to complete). This is much faster than previous xeons. They also require a 1333MHz FSB instead of 1066 or slower.
<br><br>Then you can get into the linux kernel, 2.6.23 is supposed to have a new scheduler that is faster, the low latency patches for faster io should be in place as well by that version, and you can even get into interrupt coalescence where instead of a 1:1 irq per packet if the card and driver support it you can buffer data until a timeout has occured or a certain amount of data has accumulated, which adds a tiny amount of latency (generally well below 2ms) but increases over all performance. All of these have been available as independant patches, but will see their way into
2.6.23 or so the rumor mill goes. I dont know if centos has applied any of these patches in what they shipped.<br><br>And finally we come to GCC, which can make a dramatic difference in the way it optimizes, or rather doesnt. If you have many .c files it will not optimize between them nearly as much as if its all one big .c file. If you took all the asterisk "core" code and made one huge .c file and built it with that you would probably see some performance improvements - although code manageability would be diminished (this could be a build script for example, and likely would require some cleanup to deal with includes and other things). There is a rumor that sqlite for example did this and saw a 10% performance increase, yeah its a 68,000 line .c file or something but its faster :) I have not confirmed that, its just a rumor that I heard somewhere, and I hear a lot of stuff it cant all be true. I dont know how many files rtpproxy is, or how they are structured, depending on that it could optimize better based solely on that.
<br><br>I do not know if asterisk will compile with anything but GCC, I havent tried, but if it does other compilers may optimize the code better. The march settings can also cause a bit of a performance change, since you can get more optimized binaries for your specific platform.
<br><br>So when doing tests I think that its important to talk about how the program was built and what hardware it was running on, otherwise you are comparing apples to quasars. The url that you provided does not give as much detail as the asterisk test, which I think is still missing some details that could dramatically impact performance, so you can never be sure that you are comparing 'head to head'.
<br><br></div></div><br>-- <br>Trixter <a href="http://www.0xdecafbad.com">http://www.0xdecafbad.com</a> Bret McDanel<br>Belfast +44 28 9099 6461 US +1 516 687 5200<br><a href="http://www.trxtel.com">http://www.trxtel.com
</a> the phone company that pays you!