Argus newbie

Carter Bullard carter at qosient.com
Wed Aug 11 10:27:03 EDT 2010


Hey George,
OK, the jitter is a good looking graph, but your methods may not be correct for generating it.
Don't merge the files together, the jitter is different from each observation domain.  And it looks
like this is a good candidate for log graphing. The best graph(s) could be these:

   ragraph sjit -M time 5s -r argus1.out -w ragraph.argus.1.sjitter.png -title "argus1 src jitter" -log - port iax
   ragraph djit -M time 5s -r argus1.out -w ragraph.argus.1.djitter.png -title "argus1 dst jitter" -log - port iax
   ragraph sjit -M time 5s -r argus2.out -w ragraph.argus.2.sjitter.png -title "argus2 src jitter" -log - port iax
   ragraph djit -M time 5s -r argus2.out -w ragraph.argus.2.djitter.png -title "argus2 dst jitter" -log - port iax



Because you have some pings in there between your two endpoints, you can get an approximation of the round-trip delay

% 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%    

Divide by 2 and you get an estimated one-way delay of 0.000253 but 1/2 of
the median may be the best estimate, 0.000210.

There is not loss data here, and because you don't have a unique Srcid in the
two argus files, we can't  do some of the more interesting comparisons.  You
can use ranonymize() to poke srcid's into the files.  I'll do that later today
and send email.

Hope this is helpful.

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/205a1340/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ragraph.argus.1.djit.png
Type: image/png
Size: 23390 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100811/205a1340/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ragraph.argus.1.sjit.png
Type: image/png
Size: 24013 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100811/205a1340/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ragraph.argus.2.djit.png
Type: image/png
Size: 24241 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100811/205a1340/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ragraph.argus.2.sjit.png
Type: image/png
Size: 24951 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100811/205a1340/attachment-0003.png>
-------------- 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/205a1340/attachment.bin>


More information about the argus mailing list