0

I need to measure certain statistics, such as latency, packet delay, and jitter. Would it be possible to measure these statistics between 2 nodes by sniffing traffic on both ends and then comparing times between when the packets were captured? BTW It is likely the two nodes won't be able to see each other, but they could later down the road.

Improve this question
5
  • 1
    There are things like IP SLA to do this specifically, and depending on the network equipment vendor, it may already be built into your network devices.
    – Ron Maupin ♦
    Commented Sep 22, 2016 at 20:43
  • Just curious, what do you mean with " It is likely the two nodes won't be able to see each other" ? That they are not in the same L2 broadcast domain (LAN/VLAN)?
    – hertitu
    Commented Sep 23, 2016 at 8:25
  • Correct they are not in same LAN.
    – noname456
    Commented Sep 23, 2016 at 12:43
  • 1
    Depending on the precision of the capturing system's timer, chances are very high that you can't really capture such small periods of time. Latencies of switches and hardware routers are in the microsecond range and usually too small to measure without special hardware or a very tricky setup.
    – Zac67 ♦
    Commented Jun 20, 2017 at 16:57
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin ♦
    Commented Aug 15, 2017 at 3:03

3 Answers 3

Reset to default
1

You can't measure these statistics by sniffing traffic because most of packets would normally pass thru OSI layer 7 and response could be delayed due to application responding slowly and many other factors.

As Ron mentioned you can use IP SLA and draw graphs for example in Cacti or nProbe, NTOP could be as well used to collect jitter statistics. Netflow would be good source of information. For very simple measurments you can use tools like mtr.

Improve this answer
2
  • Not sure if I understand the 1st paragraph. Note that OP asks about taking 2 simultaneous captures (on the 2 nodes that are sending packets to each other, or maybe just one to the other) and comparing them to one another, so there is no L7 involved IMHO. I think that the 2 captures would indeed provide enough information to determine jitter and (round-trip) delay, to some extent. Don't know if any tools exist to do that tho.
    – hertitu
    Commented Sep 23, 2016 at 8:23
  • Thank you all for your input. I think I will go with hertitu and Ron Maupin. Thank you for your suggestions Datargram.Network
    – noname456
    Commented Sep 23, 2016 at 12:51
1

You can't guarantee that the two hosts where the traffic were captured had their clocks synced. There could be 10s of ms of deviations between the two hosts even with NTP enabled on them. Now, if the two hosts were synced to the same NTP source (stratum0) and are on the same LAN network, we can ensure that they are precise to within a few ms. If they are synced to WAN based NTP sources available on the internet (like pool.ntp) which usually have stratum1/2 and different NTP sources. the deviations could be in 10s of ms. So your latency packet-delay and jitter will be quite off

Improve this answer
0

You can use tshark (or wireshark) which has some options to get latency, jitter and other metrics:

       -z icmp,srt[,filter]
           Compute total ICMP echo requests, replies, loss, and percent loss, as well as minimum, maximum, mean, median and sample standard deviation SRT statistics typical of what ping provides.

       -z rtp,streams
           Collect statistics for all RTP streams and calculate max. delta, max. and mean jitter and packet loss percentages.

Note that for the above 2 options to work, you will need to respectively have ICMP and RTP packets in your network capture.

Example using ICMP and RTP sample captures from Wireshark Sample Captures:

$ tshark -qr nflog.pcap -z icmp,srt
==========================================================================
ICMP Service Response Time (SRT) Statistics (all times in ms):
Filter: <none>

Requests  Replies   Lost      % Loss
6         4         2          33.3%

Minimum   Maximum   Mean      Median    SDeviation     Min Frame Max Frame
0.000     1116.657  279.166   0.003     558.328        29        37        
==========================================================================

$ tshark -qr aaa.pcap -z rtp,streams
========================= RTP Streams ========================
    Src IP addr  Port    Dest IP addr  Port       SSRC          Payload  Pkts         Lost   Max Delta(ms)  Max Jitter(ms) Mean Jitter(ms) Problems?
    192.168.1.2 30000   212.242.33.36 40392 0x3796CB71 ITU-T G.711 PCMA     9     0 (0.0%)           69.95            7.80           18.02 
==============================================================
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.