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.
I doubt you can get accurate numbers unless you have some hardware timestamping capture hardware in there.
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).
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?
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.
problem solved with the napatech card - no negative interpacket gap values right now and I have ns timestamp resolution, all done in hardware.