# Interpacket gap calculation

Good day, forum.

This is my first post, and I did try to find the answer before posting. Nothing did come up close to what I am looking for.

I am running a packet capture on my WAN interface facing the ISP. I collect just the upstream traffic (my LAN towards the ISP) and then export collected packets into CSV for calculation purposes. The capture is performed on pfSense running on dedicated hardware (Intel Xeon platform, pfSense running on bare metal). Capture is done on 1GE interface.

In the CSV, I have column with packet timestamp and packet size. I calculate the inter-packet gap, by subtracting arrival time of packet N+1 from arrival time of packet N. I get Tdelta value, in second.

Next, assuming that the packet arrival time is the time at the end of the packet (when the packet was received and processed by kernel), I calculate idle time between packet N+1 and N, using simple formula: Tdelta - Psize * 8 / 1e9. Psize is packet size in bytes, 1e9 is due to 1GE Ethernet line rate (10^9 bps at L2).

And here is the problem - in some situations, I am getting negative packet gap (shown as 5th column below) and it is not clear to me what the problem is. The capture machine has more than enough CPU time to do the capture right (CPU idles at 3%, even at capture time), the system is on SSD, so it should not have problems writing data into file, and there is enough free memory to store the capture many times over.

190854  180.983803  0.000005    -0.000006488    -0.006   -811.0 1436
190855  180.983932  0.000129     0.000117512     0.118  14689.0 1436
190856  180.983938  0.000006    -0.000005488    -0.005   -686.0 1436
190857  180.983942  0.000004    -0.000007488    -0.007   -936.0 1436
190858  180.983946  0.000004    -0.000007488    -0.007   -936.0 1436
190859  180.983951  0.000005    -0.000006488    -0.006   -811.0 1436
190860  180.983955  0.000004    -0.000007488    -0.007   -936.0 1436
190861  180.983959  0.000004     0.000000632     0.001     79.0 421


Columns above are: (1) packet number, (2) packet timestamp from wireshark, (3) TDelta, (4) Tdelta - Psize * 8 / 1e9, (5) value of (4) in ms, (6) value of (4) in byte times, and (7) packet size.

I do not see the same issue in captures under Windows OS, but I want to preserve all packet fields and VLAN information, which requires me to push for Linux-based capture

Thank you in advance for any hints.

edit retag close merge delete

I doubt you can get accurate numbers unless you have some hardware timestamping capture hardware in there.

( 2021-08-04 05:57:56 +0000 )edit

I have sniffers that can capture at full port speed, but never check the timing between frames. The advantage of a sniffer, it can capture packets with a short IFG (it is permitted per 802.3 spec). I haven't any luck with computers because usually they can read, and write fast enough. If there isn't a lot of data, an Oscope will accurately capture the IFG (bits and time).

( 2021-08-04 08:24:59 +0000 )edit

Thank you for the feedback. Do you know if the use of dedicated hardware capture cards (Napatech NT4E-4-STD, for example) help with the timestamps, i.e., whether these do hardware timestamps?

( 2021-08-04 12:50:00 +0000 )edit

I have confirmation that Napatech cards will do ns precision hardware timestamping, so I will get one, and confirm whether the issue is gone then. I will update the chain as I learn more.

( 2021-08-04 19:17:42 +0000 )edit

problem solved with the napatech card - no negative interpacket gap values right now and I have ns timestamp resolution, all done in hardware.

( 2021-08-12 00:22:21 +0000 )edit

Sort by » oldest newest most voted

apart from inprecisions in timestamping during capture, line rate of 1gbps doesn't mean that each individual bit is processed at that speed. The exact speed depends on many variables that you will not be able to accurately determine for each individual packet. Your Tdelta is as good an interpacket arrival time as you will get, i don't think there is a need to bring packet size into it. Also i'm assuming that your frames are bigger than the packet sizes you list above.

more