Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Packets send date drift #724

Open
Manao4 opened this issue Apr 1, 2022 · 5 comments
Open

[Bug] Packets send date drift #724

Manao4 opened this issue Apr 1, 2022 · 5 comments
Labels

Comments

@Manao4
Copy link

Manao4 commented Apr 1, 2022

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
Copy link
Member

fklassen commented Aug 7, 2022

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

@fklassen fklassen closed this as completed Aug 7, 2022
@Manao4
Copy link
Author

Manao4 commented Aug 8, 2022

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 fklassen reopened this Aug 8, 2022
@fklassen
Copy link
Member

fklassen commented Aug 8, 2022

I'll check it out.

@fklassen
Copy link
Member

fklassen commented Aug 14, 2022

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants