Details on packet rates and interpacket arrival times

Daniel Hunter via Argus-info argus-info at
Mon Apr 4 15:31:52 EDT 2016


Thank you for the prompt and interesting answer to my previous question,
and hello again! This time I am asking about how exactly the timing fields
- Rate, SrcRate, SIntPkt, SrcJitter, and so on - are computed. I have
reverse-engineered the precise meaning of these to some extent, but I still
struggle with apparent inconsistencies. I have checked that I have only one
instance each of argus and ra running.

I have checked that 'Rate' is the average number of packets (either kind)
per second within the duration of the record, NOT including the last
packet. In other words:
   Rate = (# packets - 1)/Dur

This is as expected. For the SrcRate of any particular record, we would have
   SrcRate = (# src packets - 1)/(time of last src packet - time of first
src packet)
The equation for DstRate is similar, of course. I do not have the time
between the last and first src/dst packets, so I cannot check these
exactly, but using Dur instead gives an approximate confirmation.

The average interpacket arrival times must be computed differently, since
in general SrcRate != 1/SIntPkt (similarly for Dst). The best explanation I
have from studying Ra's output is that the average src/dst interpacket
arrival times includes the time between the last src/dst packet of the
previous record and the first of the current record.
For example,
I have mostly confirmed this must be the case (an easy way to motivate this
conclusion is to note that SIntPkt*(SrcPkts-1) is almost always greater
than the record duration). To make sure we're on the same page, here's an
Say the last source packet from the previous record of a flow arrived at
time 0. At time 30s, another packet arrives (starting a new record),
followed by more packets at 35, 40, and 50. So the new record has: SrcPkts
= 4, Dur = 20s.
The source rate would be (4-1)/20 = 0.15 Hz. The average interpacket
arrival time, however, would include the 30 second gap after the previous
record's last packet:
SIntPkt = (30 + 5 + 5 + 10)/(4 + 1 - 1) = 12.5s

The Src/Dst Jitter also seem to use this "inter-record" gap of time.

I have experimented enough to be convinced that this is the intended
behavior, but I do see inconsistencies occasionally. Here is some real
data, the first four records from a SSH session (I have converted SIntPkt
to seconds for consistency):
        Dur        SrcPkts      SrcRate   SIntPkt      IntFlow
1  2.197997       55       24.567822  0.043098        NaN
2  4.012610        9          1.993715  1.000506    4.991947
3  2.868474       13         4.183409  0.410036    2.051961
4  0.356273        4          8.420509  0.118758  31.897254

'IntFlow' is the time between the end of the previous record from a session
and the start of the current flow, which I have calculated manually by
grouping records by Seq, SrcAddr, SPort, DstAddr, DPort, and Proto. This is
NaN for the 1st record because there was no previous record for this

According to what I've claimed above, things make sense for the second
record. The average time between packets, including the last packet of the
previous flow, is
   (4.991947 + 4.012610)/(9+1-1) = 1.000506 sec.
However, this does not work for the other three records. Note that for the
first record,
   0.043098 * (55-1) = 2.327292 > 2.197997,
which means that there is not enough time within the duration for all 55
source packets to arrive!
You can say the same thing about the third record (whether or not you
include the last packet from the second):
   0.410036 * (13-1) = 4.920432 > 2.868474
   0.410036 * (14-1) = 5.330468 > 2.868474 + 2.051961
Strangely, though, for the third record: SIntPkt = (Dur + IntFlow)/(SrcPkts
- 1), which seems like a counting error.

Sorry if my examples are superfluous. Ultimately, I just want to know the
precise details of how Rate, SrcRate, DstRate, SIntPkt, DIntPkt, SrcJitter,
and DstJitter are computed.
Thanks very much!!

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

More information about the argus mailing list