Argus newbie
Carter Bullard
carter at qosient.com
Wed Aug 11 10:46:42 EDT 2010
Hey George,
Oh, yes, and one other metric which will be interesting is the ping
durations at the receiver's end, argus2. This will give you host processing
delay for the echo reply, which you can subtract from argus1's ping
durations. This will give you a better estimate of the total network delay time.
Divide that by two for the best estimate of one-way network delay.
I changed the parameters for the two rahisto() calls so you can see how
the distributions go for the two sides.
rahisto -H dur 20:0-0.001 -r argus1.out - echo
N = 24 mean = 0.000506 stddev = 0.000162 max = 0.000866 min = 0.000403
median = 0.000421 95% = 0.000414
mode = 0.000412,0.000429,0.000415
Class Interval Freq Rel.Freq Cum.Freq
1 0.000000e+00 0 0.0000% 0.0000%
2 5.000000e-05 0 0.0000% 0.0000%
3 1.000000e-04 0 0.0000% 0.0000%
4 1.500000e-04 0 0.0000% 0.0000%
5 2.000000e-04 0 0.0000% 0.0000%
6 2.500000e-04 0 0.0000% 0.0000%
7 3.000000e-04 0 0.0000% 0.0000%
8 3.500000e-04 0 0.0000% 0.0000%
9 4.000000e-04 18 75.0000% 75.0000%
10 4.500000e-04 1 4.1667% 79.1667%
11 5.000000e-04 0 0.0000% 79.1667%
12 5.500000e-04 0 0.0000% 79.1667%
13 6.000000e-04 0 0.0000% 79.1667%
14 6.500000e-04 0 0.0000% 79.1667%
15 7.000000e-04 1 4.1667% 83.3333%
16 7.500000e-04 0 0.0000% 83.3333%
17 8.000000e-04 3 12.5000% 95.8333%
18 8.500000e-04 1 4.1667% 100.0000%
19 9.000000e-04 0 0.0000% 100.0000%
20 9.500000e-04 0 0.0000% 100.0000%
rahisto -H dur 20:0-0.0001 -r argus2.out - echo
N = 44 mean = 0.000024 stddev = 0.000008 max = 0.000043 min = 0.000010
median = 0.000017 95% = 0.000020
mode = 0.000016,0.000027
Class Interval Freq Rel.Freq Cum.Freq
1 0.000000e+00 0 0.0000% 0.0000%
2 5.000000e-06 1 2.2727% 2.2727%
3 1.000000e-05 7 15.9091% 18.1818%
4 1.500000e-05 7 15.9091% 34.0909%
5 2.000000e-05 6 13.6364% 47.7273%
6 2.500000e-05 17 38.6364% 86.3636%
7 3.000000e-05 1 2.2727% 88.6364%
8 3.500000e-05 4 9.0909% 97.7273%
9 4.000000e-05 1 2.2727% 100.0000%
10 4.500000e-05 0 0.0000% 100.0000%
11 5.000000e-05 0 0.0000% 100.0000%
12 5.500000e-05 0 0.0000% 100.0000%
13 6.000000e-05 0 0.0000% 100.0000%
14 6.500000e-05 0 0.0000% 100.0000%
15 7.000000e-05 0 0.0000% 100.0000%
16 7.500000e-05 0 0.0000% 100.0000%
17 8.000000e-05 0 0.0000% 100.0000%
18 8.500000e-05 0 0.0000% 100.0000%
19 9.000000e-05 0 0.0000% 100.0000%
20 9.500000e-05 0 0.0000% 100.0000%
So the best estimate of the actual one-way delay will be to take the
minimum durations for all the pings from both sides and do diffs.
This gives you a delay that approaches the theoretical minimum.
But you really want to know what you're getting, so you'll want to
diff the population, one by one. That is what rampc() can do. but
without that, you can diff the means, and get a decent estimate.
But, because the distributions aren't really normal, maybe best to
diff the two medians, rather than the two means. Here are all:
Mins (0.000403 - 0.000010) / 2 = 196.5 uSecs
Means (0.000506 - 0.000024) / 2 = 241 uSecs
Medians (0.000421 - 0.000017) / 2 = 202 uSecs
which is the best estimate for one-way delay? I'd go with the
202 and remember that 196.5 is doable.
Carter
On Aug 11, 2010, at 8:02 AM, Pallis, Georgios wrote:
> Well, regarding the packet loss metric, I 've consulted the IAX2 RFC and saw that it supports sequence numbers, like the other protocols that you mentioned. Furthermore, a little bit after sending my previous email, I remembered about radium. So what I did was to merge the Argus records from the two Asterisk servers and then run the following command:
>
> ragraph loss spkts dpkts -M 1s -r argus.out -title 'Packet Loss / Packets' -w ploss.png
>
> that gave me a very nice graph for packet loss in both directions of the flow. Can you verify if what I did is correct?
>
> For the one-way delay, I absolutely understand what you are talking about. The problem is that I cannot figure out how do I have to process the Argus files in order to diff the outputs. I 've studied many times the man pages, but I 'm still confused on that. Does radium is once again the answer? Do I have to merge the Argus files in order to calculate the one-way delay? But then how do I diff the timestamps?
>
> Best regards,
> George Pallis
>
> ________________________________________
> From: carter at qosient.com [carter at qosient.com]
> Sent: 08 August 2010 16:48
> To: Pallis, Georgios
> Cc: Argus
> Subject: Re: [ARGUS] Argus newbie
>
> Hey Georgios,
> Loss indications are already in the argus records, for loss between A -> B, the loss stat will be in the B records, and for B-> A they will be on the A's records.
> At least for TCP, RTP, ESP, GRE, those protocols that have sequence numbers. Print the field "sloss" or "sploss".
>
> For all other protocols, you need to diff the offered packet count with the received load packet count. For loss from A -> B take the packet count from an A record and subtract the packet count of the corresponding B record. The bytes lost is not as simple, when the unknown protocol is reliable, the best stat maybe difference in sappbytes and dappbytes, which is the notion of lost "goodput" rather than lost "throughput".
>
> The same is true for one-way delay. Argus can be configured to generate 4 timestamps per record. A start and last time for each direction, which are the microsecond timestamps for the first and last packet seen in each direction. Each argus is somewhat self-synchronizing, which means that most of the time when you have a record from two endpoint argi, for the same network transaction (say a DNS transaction), all 4 timestamps correspond to the same 4 packets, and can be diff'd to create 4 one-way delay calculations. 2 for each direction. When the transaction is not as simple as a single request response transaction, the argus data usually has all the info needed to tell you if the timestamps correspond to the same packets, which is critical to making the derived values useful.
>
> Carter
>
>
> Sent from my Verizon Wireless BlackBerry
>
> -----Original Message-----
> From: "Pallis, Georgios" <07001710 at live.napier.ac.uk>
> Date: Sun, 8 Aug 2010 00:13:03
> To: Carter Bullard<carter at qosient.com>
> Cc: argus-info at lists.andrew.cmu.edu<argus-info at lists.andrew.cmu.edu>
> Subject: RE: [ARGUS] Argus newbie
>
> Hello again after a long time! So, I 've done my measurements. As you suggested I used Argus on both of my machines. Question now is how do I process the Argus data in order to get the desired graphs for one-way delay, jitter and packet loss? For example for getting jitter I run the following command:
>
> ragraph djit -M 1s -r argus1.out -title "Jitter" -w jitter.png
>
> which gave me the attached graph, but what about one-way delay and packet loss? For the latter I know that I can do something like:
>
> ragraph dloss -M 1s -r argus.out -title "Loss" -w loss.png
>
> but this gives me an empty graph which I suppose is normal, because we are talking about UDP traffic (unless there is truly no packet loss). As you 've already pointed out for the one-way delay and packet loss metrics the Argus outputs from my two Asterisk machines need to be compared. However, from studying the man pages, I did not manage to find out how that is possible...
>
> Best regards,
> George
>
> PS As a sample I attached the Argus output files from an IAX2 flow (G711 codec was used).
>
>
> ________________________________________
> From: Carter Bullard [carter at qosient.com]
> Sent: 15 July 2010 18:07
> To: Pallis, Georgios
> Cc: argus-info at lists.andrew.cmu.edu
> Subject: Re: [ARGUS] Argus newbie
>
> You will want to collect argus records/packets on both systems because:
> 1) you'll need loss detection and jitter measures for both sides of the two-way conversation
> 2) one-way delay measurements
> 3) SIP performance
>
> The only way to measure one way delay is to have timestamps from both the
> sender and receiver so you can do the difference. In your case, you will need
> both your asterisk machines to be time synchronized (to some level of tolerance).
> NTP does a pretty good job, and you should have a single NTP server that both
> machines can sync up to. This does better than if they are using a group of
> disjoint NTP servers.
>
> For SIP performance, you'll want to compare the timestamps of SIP initiation
> packets from the originator and the target machines, so you can understand
> how well the SIP system is doing.
>
> Argus on both machines can provide up to 4 timestamps per flow status report.
> The flows are synchronized in a lot of ways, and so comparing the start and last
> timestamps in the argus records for the SIP exchange from both machines,
> can give you a lot of info on propagation and processing delays of the SIP
> service. Compare those with something like a ping session that can be ongoing
> between your machines for measuring round-trip delay, and you can get a lot
> of good metrics. Argus on both machines.
>
> Carter
>
>
>
> On Jul 15, 2010, at 12:31 PM, Pallis, Georgios wrote:
>
>> Hello! Thanks for the detailed answer. For the purpose of my project, I don't care about QoS (like in DiffServ sense), operations
>> and/or security. The project is about comparing SIP/RTP with IAX2 in terms of bandwidth usage, one way delay, jitter and packet loss
>> as I mentioned earlier (and also CPU and memory usage, but that's easy to do) . A number of experiments will be carried out,
>> for example 30 calls, then 50 calls between the two Asterisk servers, etc Trying also encryption, different codecs (G711and Speex)
>> and MPLS in my small cloud (see the attached image in my previous mail) every time. So you said that it will be better if I have
>> argus running in both of my servers. The rational behind it? Is this is for comparing the results? Or some different reason?
>>
>> Regarding the graphs I have to present in my project: Ragraph (RRD) looks good for what I want to do. Don't need any fancy stuff,
>> but I guess as a first option you mean gnuplot?
>>
>> Regards,
>> George
>>
>>
>>
>> __________________________________________________________________________________
>> From: Carter Bullard [carter at qosient.com]
>>
>> Sent: 15 July 2010 15:32
>>
>> To: Pallis, Georgios
>>
>> Cc: argus-info at lists.andrew.cmu.edu
>>
>> Subject: Re: [ARGUS] Argus newbie
>>
>>
>>
>>
>>
>> Hey George,
>> These types of questions are great for the list, and really are all about process,
>> so the conversation can get quite long. Hopefully, you will keep the questions coming
>> and we'll capture a lot of the process of doing QoS measurement and analysis.
>>
>>
>>
>> So, you're talking about doing end-to-end (E2E) QoS measurements for your VoIP
>> service. So what are you most interested in? Operations? Performance? Security?
>>
>>
>>
>> If Operations is the case then metrics for reachability and availability are really
>> important. This is important especially with SIP based VoIP, since the service
>> is dependent on reachability/availability of the end system but also the SIP
>> service, which can be a complex distributed service all in its own right.
>>
>>
>>
>> The presence support for SIP can have you trying lots of different destination
>> addresses and paths in order to place a call to a single individual, and so
>> there can be uncertainty as to why a call failed. Things like call frequency,
>> call duration, percentage of successful calls, number of interrupted calls, and
>> having cause indications for call failure etc ..... can be important. Argus data
>> can help a lot with all of that, but we don't do SIP protocol specific processing,
>> so some of the cause stuff you'll have to do on your own.
>>
>>
>>
>> For Performance, we become more interested in loss, jitter and one-way delay
>> as these have the biggest impact on call quality, and of course DSByte tracking
>> becomes important, when DiffServ is being used for voice calls.
>>
>>
>>
>> Sometimes its good to know just the # of calls with loss, rather than dealing
>> with the severity of the loss per call, as an example. It really all depends on
>> what you want to know.
>>
>>
>>
>> For Security, we interested in protocol conformance, access control, and for SIP,
>> we're interested in SIP server/client scanning. We've just added the first round of
>> support for ZRTP encrypted voice tracking (not decrypting the call, but know that
>> encryption is being used), so if you have any ideas on what you
>> would like to know about these features, then, of course, send some mail.
>>
>>
>>
>> So you mentioned bandwidth, end-to-end delay, loss and jitter. So lets email
>> regarding each of these metrics, and I'll try to walk you through some approaches.
>> I think it will be easier if we keep the emails shorter, than longer.
>>
>>
>> Running argus on both asterisk servers will generate all the data you need to
>> do what you're after. It's important to know what you want to know about your
>> service and then generate meaningful metrics that directly answer your questions.
>>
>>
>>
>> You don't really need to worry about the "-R" option. Argus now generates response
>> data regardless of the option, so the option is somewhat obsolete.
>>
>>
>>
>> Yes, you can capture packets for say experimental runs, and then use argus afterwards
>> to generate stats. That is a great way to proceed when you're just starting to build
>> out an infrastructure and have a lot of issues to deal with. When you want to have
>> more of a real-time awareness, then running argus() somewhere along the path
>> becomes important.
>>
>>
>>
>> With regard to ragraph(). The argus project is really all about the metrics, and so we
>> recommend using all and any types of graphing, processing, whatever, to get the answer
>> you need. ragraph() is not bad for plotting some simple time series graphs of some metrics
>> in argus data, but there are lots of other strategies. I would suggest that ragraph() be
>> your second or third tool at this point.
>>
>>
>> Carter
>>
>>
>>
>>
>>
>>
>> On Jul 15, 2010, at 9:22 AM, Pallis, Georgios wrote:
>>
>>
>>
>>
>> Hello! Finished with setting up my Asterisk servers, so now it's time to move to Argus and performance measurements. You can see my topology in the attached image. VoIP calls (SIP
>> & IAX2) are generated from Asterisk1 to Asterisk2 (upon connection a pre-recorded message is played in both directions). So what I want to do is measure bandwidth, end-to-end delay, jitter and packet loss in the packet flow between the two servers . I 've
>> read the man pages of argus, ra and ragraph as well as the wiki and the documentation provided in the tar files, but I 'm still a bit confused. Mainly I 'm confused with ragraph and the way it generates graphics regarding the metrics I 'm interested in (I
>> 've played a bit with a sample capture, but I did not succeed much). Apparently, I have to run argus with -R option, right? Also, is it the same if I capture data with something like wireshark and then process the pcap file with argus? Thank you for you time.
>>
>> Kind regards,
>> George Pallis
>>
>> <topology.jpg>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> Carter Bullard
> CEO/President
> QoSient, LLC
> 150 E 57th Street Suite 12D
> New York, New York 10022
>
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax
>
>
>
>
>
Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100811/13bc1eab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100811/13bc1eab/attachment.bin>
More information about the argus
mailing list