Hello Bruno As the way sipp computes its statistics has been enhanced, may I ask you if you still encounter the same problem with the 2.0 version ?
Regards, Olivier Boulkroune Message: 5 Date: Tue, 23 Jan 2007 21:22:47 +0100 From: Bruno Van Den Bossche <[EMAIL PROTECTED]> Subject: [Sipp-users] Accuracy of time-measurements by SIPp To: [email protected] Cc: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-15 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 ************* ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
