-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Support sending IMIX traffic pattern #1576
base: master
Are you sure you want to change the base?
Conversation
I think there is a bug resulting in packet drops even over loopback. Still debugging. Will update when I figure it out |
Figured it out. Fix is in commit 1. |
a060030
to
ff08316
Compare
* 576 4 33.333333% | ||
* 1500 1 8.333333% | ||
*/ | ||
r = random() % 1000; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the Random seed set explicitly?
I am wondering what is the behaviour we want ?
if we set a static seed (or give control of setting a seed), then successive runs are identical and conform to the packet size mixture distribution.
Without that every run is different, giving seed explicit control to the user will enable both behaviors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seed is set lower in file (srandom(0xDEADF00D);
). Would prefer to avoid another config flag (already quite a few) but don't mind adding if necessary
read() guarantees atomic delivery of a UDP datagram if the buffer supplied is big enough. It is not correct to read in a loop if the buffer is bigger than the actual datagram. This occurs often for --imix mode.
Will be used to switch on imix traffic pattern.
This provides a somewhat more realistic workload for middleware performance testing.
master
or3.1-STABLE
) to which this pull request applies:master
Added support for sending IMIX traffic pattern
One piece of criticism that iperf3 usually gets is that it is not very realistic.
IMIX traffic is fairly standard for load testing middleware and is an important
benchmark for various middleware vendors / projects. Since iperf3 is very
popular and this change is fairly simple, I thought it'd be a nice addition.
I tested this change by running a server and client locally. And I also attached
a bpftrace probe to check that the kernel actually saw the intended
distribution of packets.
Regular mode:
bpftrace output for regular mode:
IMIX mode:
bpftrace output for IMIX mode: