[Bug] Incorrect speed of playing traffic after some time

[dimanist]

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!

[fklassen]

updated incorrect calculation for long-running PPS tests. Fixed in PR #679.