[Bug] Packets send date drift

[Manao4]

Describe the bug
Bug that was described in #630 was fixed with #631 and #645 , but subsequently reverted with #699 to address #674

To Reproduce
See #630

Expected behavior
See #630

System

• OS: Debian linux
• OS version: 4.19.0-9-amd64 netmap injector #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
• Tcpreplay Version: 4.4.1

[fklassen]

Attempt to recreate on Debian 10 (Buster). Not seeing any difference in performance between #660 (b53d916) and 4.4.1. Reopen if you have steps to reproduce.

Here is commit b53d916:

$ sudo src/tcpreplay -K --multiplier=10000 -i ens33 test-udp.pcap
File Cache is enabled
Actual: 100000 packets (71731802 bytes) sent in 11.39 seconds
Rated: 6292263.8 Bps, 50.33 Mbps, 8771.93 pps
Flows: 94038 flows, 8248.94 fps, 99400 flow packets, 0 non-flow
Statistics for network device: ens33
	Successful packets:        100000
	Failed packets:            0
	Truncated packets:         0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0
$ sudo src/tcpreplay -K --multiplier=10000 -i ens33 -l2 test-udp.pcap
File Cache is enabled
Actual: 200000 packets (143463604 bytes) sent in 23.65 seconds
Rated: 6065038.2 Bps, 48.52 Mbps, 8455.15 pps
Flows: 94038 flows, 3975.53 fps, 198800 flow packets, 0 non-flow
Statistics for network device: ens33
	Successful packets:        200000
	Failed packets:            0
	Truncated packets:         0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0

here is 4.4.1:

$ sudo src/tcpreplay -K --multiplier=10000 -i ens33 test-udp.pcap
File Cache is enabled
Actual: 100000 packets (71731802 bytes) sent in 11.39 seconds
Rated: 6296967.2 Bps, 50.37 Mbps, 8778.48 pps
Flows: 94038 flows, 8255.11 fps, 99400 flow packets, 0 non-flow
Statistics for network device: ens33
	Successful packets:        100000
	Failed packets:            0
	Truncated packets:         0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0
$ sudo src/tcpreplay -K --multiplier=10000 -i ens33 -l2 test-udp.pcap
File Cache is enabled
Actual: 200000 packets (143463604 bytes) sent in 24.91 seconds
Rated: 5758383.4 Bps, 46.06 Mbps, 8027.65 pps
Flows: 94038 flows, 3774.52 fps, 198800 flow packets, 0 non-flow
Statistics for network device: ens33
	Successful packets:        200000
	Failed packets:            0
	Truncated packets:         0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0

[Manao4]

Hi @fklassen.

You've tested two versions that are impacted by the issue. You should test the commit before b53d916 if you want to see a difference. Beware, mutliplier option was broken with #631, so previous version with this specific command line will have a different behavior, but will be broken as well.

Anyway, if you look at the duration it took to send the packets, you can see something is wrong : you are trying to send 100000 packets at a rate of 10000 packets a second, and it takes 11.39 seconds. This is the issue: it should take 10 seconds. It's not a performance issue. #631 was fixing that, by waiting to reach packet date to send a packet, instead of waiting to reach duration since previous packet send date to send a packet (which introduces drift). But it looks like #631 also broke multiplier option in tcpreplay, and was subsequently reverted, fixing multiplier, but recreating drift issue.

Can you reopen the issue or do you need more information ?

Regards,

Mathieu

[fklassen]

I'll check it out.

[fklassen]

Tried to recreate, and I cannot find any versions pre #699 that doesn't hang when reproducing #630 setup. That includes #630 (b53d916), and pre #630 (b53d916~1). It appears that #631 introduced bugs that have since been fixed.

Question. Is there any commit that works, i.e. reproduces #630 setup with no drift?

I'll see if I can make a routine that has less drift, but doesn't break with extreme multiplies, e.g. 10000 and 0.000001.

[fklassen]

Labeling as a feature due to the fact that we cannot find a version where this worked better than it does now. Moving out to feature version 4.5.