UDP Random Packet Size and Random Delay (Gap) Time between Packets - #1075
UDP Random Packet Size and Random Delay (Gap) Time between Packets#1075davidBar-On wants to merge 5 commits into
Conversation
Catchup with laters iper3 changes
|
@davidBar-On - Had to change this around to get it to build, which seems to work for the regular forward mode: However. on reverse, the packet counts get doubled and the error rate is almost ~50+%. Did I miss something here? When not using random packet sizes, reverse mode gets the proper packet counts as well as packet loss stats. Here's my working tree so far: https://github.com/swg0101/iperf/ |
|
@swg0101, I built and run my original code (more than a 1.5 years old) and it runs o.k. in both direction. I didn't have time yet to evaluate your code, but from the log I see that you merged the changes into current master. Is this correct? If correct, then there may be changes that were done after I did the changes that are causing the issues. I assume that the server is also using the same iperf3 as the client. In any case, I see that in reverse mode, packet size is always 200 bytes and not random between 100 and 200 as expected. Can you also get the server's size logs to see if it got the proper parameters? Did you merge all changes? If you don't find the issue, I will try to help with the evaluation later this week. |
|
Hi David. Thanks for the quick response. Yes, I built it on master since I was trying to combine your other patches (where the same socket patch would only build on master). The server itself is running the exact same build as the client (actually the same executable, running on localhost). I did merge all changes, but some of them had to be changed slightly (i.e. a size variable was calculated a few lines beforehand, readjust some case values already used by master, adjust some offsets, etc), but afaik all of them were merged in. On the server, the debug output says: On the client, it says receiving only odd number of packets and the wrong size (interestingly, when doing reverse mode, the server mode tries to send ~2x the packets but the client is only expecting half of these, marking the rest as errors). The varying sizes were confirmed on tcpdump with a sequential seq # and I did it on localhost to rule out any packet loss, although this happens on a remote server as well. I wonder if I missed a piece of the code somewhere, or other changes in master may have changed some behavior that I need to readjust for. Thanks for your time. |
|
@davidBar-On - Excellent - thanks for catching that. Now everything seems to be working correctly. |
|
I believe that current iperf3 does not allow variable packet size, so closing this PR. The random delay between packets is still open in PR #1343. |
Version of iperf3 (or development branch, such as
masteror3.1-STABLE) to which this pull request applies:master
Issues fixed (if any):
Brief description of code changes (suitable for use as a commit message):
Add support for sending random length of UDP from defined lengths range (second argument to
l), and ability to add a delay before sending a packet (--gap-time min[/max]). The delay is either fixed or random taken from a specified range. These enhancements allow to create simple traffic profile, which can be important for testing packet lost, jitter and delay in low bandwidth networks (e.g. for IoT) and in unstable networks.This is a simplified subset functionality from the rejected PR #1004. I believe that although these enhancements main purpose is to test expected behavior of different traffic profiles, and not directly to test throughput, they can still be very useful for iperf3 users.
(A note about the delay between packets. Since OS minimum sleep() time may be relatively large, the minimum sleep time is estimated. If a small delay time is required, then delay will not be used for each packet, but only for one out of some packets. E.g. if estimated minimum sleep() time is 15ms and the requested wait time is 3ms, delay will be done only for 1 packet out of 5.)
UPDATE
PR #1343 suggest a better way for the Gap delay time implementation (using
selecttimeout instead ofsleep), so this PR is relevant only for the random packet sizes part.