How does Argus measure jitter?
Carter Bullard
carter at qosient.com
Mon Oct 31 18:00:37 EDT 2011
Hey George,
Great to hear from you. Can I point to your thesis from the argus 'Publications' page?
In re-reading the email thread, I see a cut-copy-paste error in my little algorithm. It
should be:
3. D to S One-way delay
abs(ArgusRecord1.dstime - ArgusRecord2.dstime);
abs(ArgusRecord1.dltime - ArgusRecord2.dltime);
I left an errant reference to the source (sl),
Sorry about that !!!!
Carter
On Oct 31, 2011, at 5:27 PM, Pallis, Georgios wrote:
> Hello Nik (and hello Carter after a long long time :) ),
>
> Apologies for interrupting your chat with Carter. You can see an example of an Argus setup in my MSc thesis that I did last year:http://researchrepository.napier.ac.uk/4005/ In my work I did exactly what you are looking for (one way delay, Jitter, packet loss). I think that this project illustrates to a great extent what Argus can achieve with respect to QoS and performance measurements. You can also search this mailing list for my posts about a year+ ago. I think Carter's answers to my questions back then are really useful for what you try to achieve here.
>
> Best regards,
> George
>
> From: argus-info-bounces+07001710=live.napier.ac.uk at lists.andrew.cmu.edu [argus-info-bounces+07001710=live.napier.ac.uk at lists.andrew.cmu.edu] on behalf of Carter Bullard [carter at qosient.com]
> Sent: 31 October 2011 18:11
> To: Nik Mitev
> Cc: argus-info at lists.andrew.cmu.edu
> Subject: Re: [ARGUS] How does Argus measure jitter?
>
> Hey Nik,
> Not sure that I understand your comment:
> "Although Argus has the disadvantage that it does not have an instance at
> the source and destination of a probe,"
>
> Argus can be deployed in most sources and destinations, that is one of the big differences
> between argus and other flow / performance sensors. And because it can be
> deployed multiple points along the path, you can compare the offered metrics and
> observed metrics from multiple points, and realize where modifications to performance
> are occurring, specifically path utilization, loss and shaping (queuing).
>
> One of the interesting things about Argus, is that it understands many VoIP codecs,
> and adjusts its packet jitter calculation to deal with issues like silence suppression.
> I didn't want to get into too much detail in the first email. Argus tracks 2 packet jitter
> measurements, for each flow, both "active" and "idle" packet inter-packet arrivals, and jitter.
> All flows have these metrics, for VoIP, and some codecs, the idle time is the time in between
> packets during silent suppression, and the active time is when silent suppression is not on.
>
> In the early days, many commercial VoIP end systems would shape traffic in the worst way.
> The mean arrival times were great, but the packet jitter was terrible. Some were 2 packets
> at line rate, then idle, and then 2 packets at line rate. So, argus has been very helpful for
> some to measure the offered load and jitter for VoIP, and to compare that with received
> load and jitter by using argus within matching sets of equipment. Argus has been used for
> many years by companies like Nortel (not so anymore) and Ericsonn, to measure video
> conferencing terminal performance. For video, unexpected issues like fragmentation really
> cause performance problems, as the fragments are written at line rate, which of course,
> can create problems for long haul and satellite video conferencing.
>
> I would try to get argus into the phone, thats what most of them do. The SPAN port
> shapes the traffic and can introduce loss that is not there. Of course the impact is
> not infinitely huge if you're tracking voice, not the best if you're tracking HD video,
> as it does introduce queuing issues that the user traffic doesn't experience. Taps do
> a much better job, and companies like Endace really shine here, as they can provide
> the time sync needed to do short segment one-way delay (sub uSec), as they can be
> sync'd up using GPS equipment.
>
> So, an argus flow status record, collected from two argus probes, trivial algorithm goes:
> 1. Compare records from different probes to find match.
> With matching records:
> 2. S to D One-way delay
> abs(ArgusRecord1.sstime - ArgusRecord2.sstime);
> abs(ArgusRecord1.sltime - ArgusRecord2.sltime);
> 3. D to S One-way delay
> abs(ArgusRecord1.sltime - ArgusRecord2.sltime);
> abs(ArgusRecord1.dstime - ArgusRecord2.dstime);
> 4. NTT
> abs(ArgusRecord1.dur - ArgusRecord2.dur);
>
> Pretty trivial. Argus self-synchronization is kinda complicated, another email perhaps,
> but you have to turn it on, so its not a default behavior. Without the option, traffic
> sessions that are shorter than the flow status interval, are inherently self-synchronized.
> So many use the short traffic, like DNS and web traffic, to do the one-way delay metric estimates.
>
> Carter
>
>
> On Oct 28, 2011, at 4:59 AM, Nik Mitev wrote:
>
>> Thanks Carter - for a useful, short and to the point reply. Things look
>> promising, so I will elaborate on my targets.
>>
>> I am looking at using Argus for monitoring the QoS the network provides
>> for voice traffic. This includes network jitter as described in your
>> reply, packet loss and one-way delay.
>> Cisco IP SLA is an obvious candidate for the job, but it is currently
>> buggy and not working on our 2960S switches, plus it monitors switch to
>> switch connections rather than server to endpoint and generates extra
>> traffic.
>> Although Argus has the disadvantage that it does not have an instance at
>> the source and destination of a probe, it analyses actual production
>> traffic and not an artificial sample which hopefully offsets any
>> inaccuracy introduced by the fact that it views flows from outside.
>>
>>
>>> However, because each argus record has 4 microSecond timestamps, one for the first and last observed packet in either direction, Argus data can be used to generate sampled network jitter. This is done through differencing matching flow records from two independant probes that are deployed near or in the end systems of interest. A good one-way delay measurement requires that the two probes be time synchronized, but formulating a decent estimate of the variance of the delay ( network jitter ) doesn't require synchronization, as long as the two sensors clocks are not drifting.
>>>
>>> Argus data can also be used to calculate network transit time (NTT) which is ( RTT - Host Delay ), because argus is a bi-directional flow monitor. This is also done through differencing matching flow data from two independant probes, deployed in the end systems, in this case time synchronization is not needed. This generates a very good metric for bi-directional network jitter, as the host component is removed.
>>>
>>> Argus is designed specifcially to enable these types of metrics, as the probe is self-synchronizing. The two independent sensors, looking at the same packet stream, will generate network flow data that is packet aligned.
>>
>> Could you put this in an example, hopefully with some formulae for the
>> calculations? The best way to describe our topology would be two
>> hub-and-spoke networks linked together at the hubs with our own fibre.
>> If the stream to be analysed is a call segment from an IP phone at a
>> spoke location to a server in a data centre at the hub and Argus is fed
>> data from a SPAN port on the hub switch how would the network jitter
>> calculation look? All endpoints are synchronised to the same set of ntp
>> servers on site.
>>
>> Thanks
>> Nik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20111031/ef44f774/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20111031/ef44f774/attachment.bin>
More information about the argus
mailing list