I repeated the experiments and incorporated Woof's suggestions. Results are below. Comments/independent verification of results are solicited.
On Thu, May 15, 2008 at 10:00 AM, Andy Spitzer <[EMAIL PROTECTED]> wrote: > Woof! > > On Wed, 14 May 2008 22:29:17 -0400, M. Ranganathan <[EMAIL PROTECTED]> wrote: > >> Measurements were made over 1000 packets. I performed the experiments >> on my laptop ( dual core 2 ghz intel processor ). >> The symmitron ran in the same process as the sender and receiver. > > Nice preliminary results! > > But to be fair, the test really needs to run across the network. The > interrupt load of actual packets on the wire makes a (slight, but not > negligible) difference then when running packets across the loop-back > interface. So you'll need two machines. > > One trick I do when running this type of load test is to make a "real" call > during the load test, and listen. Often I have the other side playing a > continous tone, which makes it really easy to hear audio irregularities. If > the tone is clean, the stats will be clean as well. Sometimes the stats > don't quite reflect short trouble spots--but your ears will. > > Also, what is the cpu loading during the test? Run "vmstat 30" and track the > context switching and idle times. Those are good indicators of CPU load over > a long period. > > --Woof! > CASE 2 sender and receiver on a different IP and different machine on different subnet address than sipxbridge. -------------------------------------------------------------------- Time between packets RMS jitter ( measured at receiver in ms.) -------------------- --------------------------------------- 10 ms. 6.5 ( 0 packet loss ) 20 ms. 4.1 ( 0 packet loss ) 40 ms. 4.01 ( 0 packet loss ) 80 ms. 4.01 ( 0 packet loss ) 160 ms. 4.0 ( 0 packet loss ) Analysis --------- When everything runs in a single process, the the performance is affected by the fact that the receiver and sender as well as the symmitron are sharing the same processor. Hence it becomes CPU bound and the peak thruput is reduced ( packets are dropped when I try to send packets at 10 ms interval when everything runs in a single process ). However, this case is not relevant because thats not how it will operate in a real deployment. When I put the load generator on a diferent machine than the symmitron, the RMS jitter is significantly higher. This is caused by the fact that when I push packets through the network I make the symmitron use the network adapter. The RMS jitter is hence higher. However, at 160 ms between packets, it is within the bounds of the receive buffer of the phone as evident from the (empirical) voice quality analysis below. Qualitative analysis -------------------- I started sipxbridge and continuously pumped packets over 50 bridges at the rate of 1 256 byte packet every 100 ms per bridge bidirectional. The average thruput per second at this rate is: 50bridgesx20 packets/second/bridge = 1000 packets per second. There was no noticable degredation in voice quality at this rate of thruput on the polycom phone. The nortel LG had a very slight ( almost imperceptible) hiss. There was no noticable effect on call setup time. CPU load analysis ----------------- With the load generator running packets through sipxbridge and nothing else of significant load running on the machine where sipxbridge is running, I ran vmstat 30 Here is what I get : procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 0 0 1233020 274060 1057164 0 0 4 20 48 39 4 3 93 0 0 0 0 0 1232896 274060 1057172 0 0 0 7 2950 937 15 18 67 0 0 0 0 0 1232896 274060 1057176 0 0 0 7 2936 770 8 17 75 0 0 1 0 0 1232896 274060 1057176 0 0 0 7 2939 763 7 17 76 0 0 1 0 0 1232896 274060 1057176 0 0 0 5 2941 1133 4 17 79 0 0 0 0 0 1232896 274060 1057176 0 0 0 5 2946 822 6 16 78 0 0 The conclusion that I can draw is that sipxbridge is mostly waiting for IO and hence CPU load is not an issue. Overall Conclusion ------------------ Sipxbridge can easily perform at the desired design point of 50 concurrent calls. Independent verification is requested. Thanks -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
