Performance measurement
Carter Bullard
carter at qosient.com
Fri Dec 6 14:14:27 EST 2002
Hey Christian,
A few things. You should set up a ~/.rarc file so that you
will get Labels for the ra() output and help control column
sizes, and set the precision of floating point numbers.
Make the PRECISION variable = 6, which will help a lot,
and set PRINT_HOSTNAME=no, and LABEL=0.
OK, you have a lot of questions and I'm going to send my
response to the mailing list, as that is where you should be
sending these types of questions, unless of course you want
to spend some money for support ;o)
First use raxml() to read some records. It will give
you a better understanding of some of the fields.
OK, duration is in seconds, and it is equivalent to RTT
for single request/response transactions, such as 'echo' and
DNS. Of course the value you get for duration will include
the remote host processing time, but for some transactions
that is minimal. Stick to 'echo', most people do.
ra -r argus0.out -s dur proto saddr dir daddr status - echo
If you use raxml(), there are two partial RTT times per TCP
connection in the <ExtFlow><TCPExtFlow> SynAckuSecs and AckDatauSecs>
values. Adding both of these together will give you a good
estimate of RTT for the TCP connection setup handshake. This
value is in uSecs.
For multi-packet transactions, the duration is the transaction
duration, which is very useful in service oriented QoS measurements.
If the transaction duration is greater than the argus status
interval timer, then there will be multiple argus records for
a single transaction. Use ragator() to put them back together.
QoS metrics make sense relative to the service, so you should
print out the proto and the dport as a minimum, in order to
realize whether the values make any sense.
For loss data, the values are percentage loss directly
measured from the traffic on the wire. As I said before, argus
has an integrated TCP state machine and it calculates loss based
on the observed retransmissions it observes.
Jitter is the mean interpacket arrival times in mSecs.
Its milliSeconds because most of the VoIP jitter values are
in mSecs. Some are in deciSecs which is really stupid.
Formally, jitter is the variance of interpacket arrival
about an expected value. Since there is no expected value, (how
could one know the expected?) the formal definition reduces
to the mean interpacket arrival time. There is a std deviation
value available, and you can read it using raxml(). The values
are in the <ArgusTimeStats> record and contains mean, max, min
and std deviation. There are Active and Idle measures, primarily
to understand protocol specific bursting behavior and idle
suppression values in VoIP applications. For TCP, active is
interpacket arrival for transmission in the window, and idle
is for traffic outside the window, which is the interwindow
times and acks.
There have to be at least 2 packets in the transaction to
calculate jitter, so some of your lines will have 0 jitter.
Hope this helps, and please send mail to the mailing list.
Carter
-----Original Message-----
From: Christian O'Donnell [mailto:c.a.o'donnell at durham.ac.uk]
Sent: Friday, December 06, 2002 9:31 AM
To: carter at qosient.com
Subject: Performance measurement
Hi Carter,
Once again I want to thank you for being so forthcoming these last few
days. To give you some background info, I am currently a fourth year
engineering student at Durham University, and I'm investigating the
Quality of Service issue across my network as part of my final year
thesis work. I used the commands you recommended to get the RTT, jitter
and loss, and the results have been interesting, but I've struggled to
understand them J I discussed them with my tutor and he thought it would
be best if I consult you before proceeding.
Here is what I got for the RTT command:
[root at secs233 christian]# ra -r argus0.out -s saddr daddr dur
localhost.local 1 10
localhost.local 1 9
192.168.0.2 phatbeats 5
192.168.0.2 192.168.0.1 0
192.168.0.1 192.168.0.2 0
localhost.local 4 10
localhost.local 4 10
localhost.local 4 4301
192.168.0.2 phatbeats 0
192.168.0.2 phatbeats 0
localhost.local 6 17
localhost.local 6 9
localhost.local 6 11
localhost.local 6 14
localhost.local 6 9
localhost.local 6 13
192.168.0.2 phatbeats 9
192.168.0.2 phatbeats 9
192.168.0.2 phatbeats 9
192.168.0.2 phatbeats 9
192.168.0.2 phatbeats 9
192.168.0.2 phatbeats 9
192.168.0.1 192.168.0.2 0
This is an excerpt of the argus.out file, phatbeats is my audio server,
streaming mp3s to the host 192.168.0.2. You say that the times are in
fractions of a second. What does this mean? Hundredth of a second, tenth
of a second? How does argus generate this data?? Does Argus generate its
own traffic??
As for loss data:
[root at secs233 christian]# ra -r argus0.out -s saddr daddr bytes loss
Column1 Column2 Column3
Column4
localhost.local 6 0 0
localhost.local 6 0 0
localhost.local 6 0 0
192.168.0.2 phatbeats 8167 168026 0.0000
0.0000
192.168.0.2 phatbeats 7536 163172 0.0000
0.8772
192.168.0.2 phatbeats 8178 175558 0.0000
3.2520
192.168.0.2 phatbeats 7848 171512 0.0000
3.3333
192.168.0.2 phatbeats 8022 169750 0.0000
2.5210
192.168.0.2 phatbeats 8088 174292 0.0000
2.4590
192.168.0.1 192.168.0.2 42 60 0.0000
0.0000
192.168.0.2 phatbeats 7560 163172 0.0000
2.6316
localhost.local 14 1411883 0
192.168.0.2 phatbeats 7524 163172 0.0000
0.0000
192.168.0.1 192.168.0.2 42 60 0.0000
0.0000
phatbeats 192.168.0.2 178338 8274 1.6000
0.0000
phatbeats 192.168.0.2 167466 7758 2.5641
0.0000
phatbeats 192.168.0.2 171760 7920 0.0000
0.0000
phatbeats 192.168.0.2 171760 7920 0.0000
0.0000
192.168.0.1 192.168.0.2 42 60 0.0000
0.0000
localhost.local 21 883755 2
192.168.0.2 192.168.0.1 60 42 0.0000
0.0000
phatbeats 192.168.0.2 154336 7152 0.9259
We were a bit confused by the four last columns (as labelled). I am
assuming that the first two columns shows the number of bytes sent by
the particular host, the real confusion kicks in for columns 3 and 4,
what exactly are these showing? What do Column and 3 and 4 refer to? And
again, how does Argus obtain this data? Is it based on processing of its
own generated data or does it actually look at the audio stream in the
network?
And finally for Jitter:
[root at secs233 christian]# ra -r argus0.out -s saddr daddr jitter
localhost.local 1 0.000 0.000
localhost.local 1 0.000 0.000
192.168.0.2 phatbeats 714.393 701.295
192.168.0.2 192.168.0.1 0.000 0.000
192.168.0.1 192.168.0.2 0.000 0.000
localhost.local 4 0.000 0.000
localhost.local 4 0.000 0.000
localhost.local 4 0.000 0.000
192.168.0.2 phatbeats 29.768 0.000
192.168.0.2 phatbeats 22.069 15.282
localhost.local 6 0.000 0.000
localhost.local 6 0.000 0.000
localhost.local 6 0.000 0.000
localhost.local 6 0.000 0.000
localhost.local 6 0.000 0.000
localhost.local 6 0.000 0.000
192.168.0.2 phatbeats 84.057 81.912
192.168.0.2 phatbeats 88.053 88.062
192.168.0.2 phatbeats 84.362 84.375
192.168.0.2 phatbeats 85.106 83.816
192.168.0.2 phatbeats 79.584 80.778
192.168.0.2 phatbeats 87.613 86.161
192.168.0.1 192.168.0.2 0.000 0.000
192.168.0.2 phatbeats 88.750 86.462
localhost.local 14 0.000 0.000
192.168.0.2 phatbeats 83.519 81.975
192.168.0.1 192.168.0.2 0.000 0.
Again, the last two columns are confusing us. Jitter is obviously the
variance in latency, which could be measured in milliseconds as the
variation in interpacket arrival times, but you specified it as AVERAGE
interpacket arrivals. If you take the average value, that wouldn't be
giving the variation in delay.I don't know, I'm confused. Again, the
same applies to this, how does Argus generate this data. If you could
just give me a brief idea of how Argus obtains all its data.
Thanks a lot for your time Carter.
Christian
More information about the argus
mailing list