[Bug] Incorrect speed of playing traffic after some time

Hi!

I observe strange behavior of tcpreplay regarding speed of traffic. I'll try to describe it now

1) Test on a server 1. tcpreplay -V: tcpreplay version: 4.3.1 (build git:v4.3.1) (debug) Copyright 2013-2018 by Fred Klassen - AppNeta Copyright 2000-2012 by Aaron Turner The entire Tcpreplay Suite is licensed under the GPLv3 Cache file supported: 04 Not compiled with libdnet. Compiled against libpcap: 1.7.4 64 bit packet counters: enabled Verbose printing via tcpdump: enabled Packet editing: disabled Fragroute engine: disabled Injection method: PF_PACKET send() Not compiled with netmap

hostnamectl: Virtualization: vmware Operating System: Ubuntu 16.04 LTS Kernel: Linux 4.4.0-210-generic Architecture: x86-64

Network adapter: e1000 (82545EM Gigabit Ethernet Controller)

I took test.pcap from https://tcpreplay.appneta.com/wiki/captures.html (64 KB, 140 packets)

I used such command for playing traffic: tcpreplay -K -i eth0 --pps=185000 -l 0 --unique_ip test.pcap

Everything was good for 8 hours, I saw that speed was 185K pps (660 MB/s). But suddenly after 8 hours I've noticed that speed became 210-220K pps (750 MB/s) I calculated some statistics and I made a conclusion that problems start to appear after approximately 5.37 billions packets were sent. Note that if I stop tcpreplay command and run it again, this situation will repeat. i.e I'll have no problems during first 8 hours playing traffic, but eventually the problem will appear.

I've tried some tests and I've faced similar problems. Here are another examples:

2) Test on a server 2 tcpreplay -V tcpreplay version: 4.3.1 (build git:v4.3.1) Copyright 2013-2018 by Fred Klassen - AppNeta Copyright 2000-2012 by Aaron Turner The entire Tcpreplay Suite is licensed under the GPLv3 Cache file supported: 04 Not compiled with libdnet. Compiled against libpcap: 1.7.4 64 bit packet counters: enabled Verbose printing via tcpdump: enabled Packet editing: disabled Fragroute engine: disabled Default injection method: PF_PACKET send() Optional injection method: netmap

hostnamectl: Virtualization: qemu Operating System: Ubuntu 16.04.6 LTS Kernel: Linux 4.4.0-131-generic Architecture: x86-64

Network adapter: Ethernet 10G 2P X520 Adapter

I have a quite big pcap file (310 MB, 915K packets). I used such command: tcpreplay --unique-ip -K --loop=0 --no-flow-stats -i eth0 --pps=65000 test_2.pcap

Everything was good during almost 22 hours (speed was equal to 65K pps or 180 MB/s). When problems started I've noticed that speed became 500K - 600K pps (1.5 Gb/s) I calulated that circa 5.2 billions packets were played before the problem.

3) Test with a different pcap, still on a server 2. tcpreplay -V: tcpreplay version: 4.3.1 (build git:v4.3.1) Copyright 2013-2018 by Fred Klassen - AppNeta Copyright 2000-2012 by Aaron Turner The entire Tcpreplay Suite is licensed under the GPLv3 Cache file supported: 04 Not compiled with libdnet. Compiled against libpcap: 1.7.4 64 bit packet counters: enabled Verbose printing via tcpdump: enabled Packet editing: disabled Fragroute engine: disabled Default injection method: PF_PACKET send() Optional injection method: netmap

hostnamectl: Virtualization: qemu Operating System: Ubuntu 16.04.6 LTS Kernel: Linux 4.4.0-131-generic Architecture: x86-64

Network adapter: Ethernet 10G 2P X520 Adapter

I used a pcap which has 10KB length (it contains 100 packets). Command for playing traffic: tcpreplay -i eth0 -K -l 0 --netmap -p 500000 --unique-ip test_3.pcap Traffic was played correctly for 3 hours (500K pps, 30 MB/s). After 3 hours I saw such statistics of speed: roughly 2M pps (120-130 MB/s). Note that almost 5.4 billions packets were sent before the problem appeared.

Please help with that situation, ask additional info if you need. Thanks in adavance!

appneta / tcpreplay

[Bug] Incorrect speed of playing traffic after some time #679