some OS gives low time resolution (10ms in solaris) if high resolution timer is set. But in your case, I guess you consistenly saw the same distribution, so it may not be related with resolution.
Joy --- Bruno Van Den Bossche <[EMAIL PROTECTED]> wrote: > Hallo all, > > As we recently took up some SIP-performance testing > again and since our > tests in the past the -trace_rtt option was added, > we compared the > measurement results obtained using three different > methods: > > -trace_stat option which prints out global > statistics about all calls. > -trace_rtt which prints out more detailed statistics > about each > individual call > - a network capture using Wireshark > > Our test-setup was the following: > - switched network > - dual core intel machines running at 2.8Ghz > - Read Hat Linux Enterprise Edition installed > - a call rate of 100 caps, 2 SIPp's directly > communicating, UDP > - a slightly modified uac and uas scenario: actually > the scenario's are > the default, but we increased the response-time > repartition and > call-lenght repartition granularity to 1 ms > (<ResponseTimeRepartition > value="1,2,3,4,5,6,7,8,9,10,11,12,...,300/>) > > The measured results are as follows: > trace_stat: > <1 : 19606 > <2 : 2559 > <3 : 1 > <4 : 1 > (average: 0.615) > [ (19606*0.5 + 2559*1.5 + 2.5 + 3.5)/22167] > > trace_rtt: > <1 : 0 > <2 : 6948 > <3 : 15207 > <4 : 10 > <5 : 1 > <6 : 1 > average: 2.187 > > pcap: > <1 : 22043 > <2 : 3 > <3 : 10 > <4 : 111 > average: 0.729 > > So we notice a very big difference between the > output of -trace_stat and > -trace_rtt. The output from the Wireshark trace and > -trace_stat seems > to be more in line. Especially considering there is > already some > processing done by the time SIPp gets its hands on > the packet. > > Is this an expected result? The difference between > the -trace_rtt > output and trace_stat seems very large. Although I > initially expected > that the trace_rtt output would allow us to get more > detailed diagnostic > results. > > Another odd result is that although Wireshark > reports 111 messages to > arrive later than 3ms, nor trace_rtt nor -trace_stat > seem to detect this. > > Has anyone else noticed this behavior? And is it to > be expected or do > you think it can be fixed? > > > Kind Regards, > Bruno > > -- > Bruno Van Den Bossche > [EMAIL PROTECTED] > http://www.ibcn.intec.UGent.be > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get > the chance to share your > opinions on IT & business topics through brief > surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sipp-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sipp-users > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
