How does Argus measure jitter?

Pallis, Georgios 07001710 at
Mon Oct 31 18:15:17 EDT 2011

Hi Carter,

Yes, please go ahead and post the link of my thesis in the Publications section. I 've also submitted a journal paper based on that work. I 'll let you know once this gets published (it's still under review) :)

Best regards,
From: Carter Bullard [carter at]
Sent: 31 October 2011 22:00
To: Pallis, Georgios
Cc: Nik Mitev; argus-info at
Subject: Re: [ARGUS] How does Argus measure jitter?

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

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: 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,

From: at< at> [ at< at>] on behalf of Carter Bullard [carter at<mailto:carter at>]
Sent: 31 October 2011 18:11
To: Nik Mitev
Cc: argus-info at<mailto:argus-info at>
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.


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the argus mailing list