search

HewlettPackard / netperf

Netperf is a benchmark that can be used to measure the performance of many different types of networking. It provides tests for both unidirectional throughput, and end-to-end latency.
MIT License
859 stars 187 forks source link

Limiting UDP Bandwidth capped at 957 Mbits/sec #39

Open quinn56 opened 4 years ago

quinn56 commented 4 years ago

When trying to simulate UDP bandwidth limiting with -b and -w flags, trying to set a limit equivalent to 958 Mbits/sec or greater results in netperf sending at half of the desired bandwidth. My calculation for translating bandwidth to burst_size and wait_time is:

burst_size = Mbits/sec bandwidth * 10^6 / 8 / packet_size wait_time = 1000ms (1 second)

Example: burst_size = 957 Mbits/sec * 10^6 / 8 / 1470 = 81377 wait_time = 1000

This limits bandwidth at 957 Mbits/sec as expected for 1470B sized packets. When doing the same calculation for 958 Mbits/sec, bandwidth is capped at 479 Mbits/sec.

I have tried this running on multiple platforms (that I verified can send at a faster rate than this without limiting bandwidth).

grundlerchromium commented 4 years ago

On Tue, Feb 11, 2020 at 10:22 AM Brian Quinn notifications@github.com wrote:

When trying to simulate UDP bandwidth limiting with -b and -w flags, trying to set a limit equivalent to 958 Mbits/sec or greater results in netperf sending at half of the desired bandwidth. My calculation for translating bandwidth to burst_size and wait_time is:

burst_size = Mbits/sec bandwidth * 10^6 / 8 / packet_size wait_time = 1000ms (1 second)

Example: burst_size = 957 Mbits/sec * 10^6 / 8 / 1470 = 81377 wait_time = 1000

Brian, I think you'll have to post a diff of what you are doing to rule out signed value overflow or some other compiler wierdness related to "unsigned promotion".

This limits bandwidth at 957 Mbits/sec as expected for 1470B sized packets. When doing the same calculation for 958 Mbits/sec, bandwidth is capped at 479 Mbits/sec.

Can you print out the burst_size value in that case? it should be: grundler <2123>printf "%d\n" $(echo "957000000 / 8 / 1470" | bc) 81377 grundler <2124>printf "%d\n" $(echo "958000000 / 8 / 1470" | bc) 81462

cheers, grant

I have tried this running on multiple platforms (that I verified can send at a faster rate than this without limiting bandwidth).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HewlettPackard/netperf/issues/39?email_source=notifications&email_token=AIUROSHJKU5IOK4IPCS4AD3RCLUHFA5CNFSM4KTGAGO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IMUVM7A, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIUROSHOV3JA45ZQY5RQGSDRCLUHFANCNFSM4KTGAGOQ .

quinn56 commented 4 years ago

Grant,

Brian, I think you'll have to post a diff of what you are doing to rule out signed value overflow or some other compiler wierdness related to "unsigned promotion".

I am performing the calculation manually so any mishandling of values would be done by netperf, no?

Can you print out the burst_size value in that case? it should be: grundler <2123>printf "%d\n" $(echo "957000000 / 8 / 1470" | bc) 81377 grundler <2124>printf "%d\n" $(echo "958000000 / 8 / 1470" | bc) 81462

The values above are the same that I am calculating

I re-compiled with --enable-demo to try and get more debug info, looks very different when sending at the two different bandwidths:

957 Mbits/sec: netperf -H 192.168.1.99 -c -C -l 10 -t UDP_STREAM -b 81377 -w 1000 -D 1 -- -m 1470 -M 1470 Interim result: 957.42 10^6bits/s over 1.055 seconds ending at 1581461073.803 Interim result: 956.99 10^6bits/s over 1.000 seconds ending at 1581461074.804 Interim result: 956.99 10^6bits/s over 1.000 seconds ending at 1581461075.804 Interim result: 957.13 10^6bits/s over 1.000 seconds ending at 1581461076.804 Interim result: 956.96 10^6bits/s over 1.000 seconds ending at 1581461077.804 Interim result: 957.17 10^6bits/s over 1.000 seconds ending at 1581461078.804 Interim result: 957.06 10^6bits/s over 1.000 seconds ending at 1581461079.804 Interim result: 956.59 10^6bits/s over 1.001 seconds ending at 1581461080.805 Interim result: 957.35 10^6bits/s over 1.000 seconds ending at 1581461081.805 Interim result: 956.16 10^6bits/s over 0.943 seconds ending at 1581461082.748

958 Mbits/sec: netperf -H 192.168.1.99 -c -C -l 10 -t UDP_STREAM -b 81462 -w 1000 -D 1 -- -m 1470 -M 1470 Interim result: 485.24 10^6bits/s over 2.025 seconds ending at 1581461346.711 Interim result: 478.61 10^6bits/s over 1.999 seconds ending at 1581461348.710 Interim result: 478.65 10^6bits/s over 1.999 seconds ending at 1581461350.708 Interim result: 478.42 10^6bits/s over 1.999 seconds ending at 1581461352.707 Interim result: 473.90 10^6bits/s over 1.980 seconds ending at 1581461354.687

grundlerchromium commented 4 years ago

On Tue, Feb 11, 2020 at 2:51 PM Brian Quinn notifications@github.com wrote:

Grant,

Brian, I think you'll have to post a diff of what you are doing to rule out signed value overflow or some other compiler wierdness related to "unsigned promotion".

I am performing the calculation manually so any mishandling of values would be done by netperf, no?

netperf isn't the problem here. It's either a compiler bug (very small chance of that) OR the code changes are wrong somehow. No one can tell you which it is if we can't see the code. Care to post a diff?

Can you print out the burst_size value in that case? it should be: grundler <2123>printf "%d\n" $(echo "957000000 / 8 / 1470" | bc) 81377 grundler <2124>printf "%d\n" $(echo "958000000 / 8 / 1470" | bc) 81462

The values above are the same that I am calculating

I re-compiled with --enable-demo to try and get more debug info, looks very different when sending at the two different bandwidths:

957 Mbits/sec: netperf -H 192.168.1.99 -c -C -l 10 -t UDP_STREAM -b 81377 -w 1000 -D 1 -- -m 1470 -M 1470

I thought you were passing the desired Mbps and then computing the burst size.

This really feels like some calculation is "off by one" (when dividing or something like that).

BTW, in case it helps, I think pktgen is probably better suited for UDP TX rates since pktgen gives finer control and more precise measurements of the throughput.

cheers, grant

Interim result: 957.42 10^6bits/s over 1.055 seconds ending at 1581461073.803 Interim result: 956.99 10^6bits/s over 1.000 seconds ending at 1581461074.804 Interim result: 956.99 10^6bits/s over 1.000 seconds ending at 1581461075.804 Interim result: 957.13 10^6bits/s over 1.000 seconds ending at 1581461076.804 Interim result: 956.96 10^6bits/s over 1.000 seconds ending at 1581461077.804 Interim result: 957.17 10^6bits/s over 1.000 seconds ending at 1581461078.804 Interim result: 957.06 10^6bits/s over 1.000 seconds ending at 1581461079.804 Interim result: 956.59 10^6bits/s over 1.001 seconds ending at 1581461080.805 Interim result: 957.35 10^6bits/s over 1.000 seconds ending at 1581461081.805 Interim result: 956.16 10^6bits/s over 0.943 seconds ending at 1581461082.748

958 Mbits/sec: netperf -H 192.168.1.99 -c -C -l 10 -t UDP_STREAM -b 81462 -w 1000 -D 1 -- -m 1470 -M 1470 Interim result: 485.24 10^6bits/s over 2.025 seconds ending at 1581461346.711 Interim result: 478.61 10^6bits/s over 1.999 seconds ending at 1581461348.710 Interim result: 478.65 10^6bits/s over 1.999 seconds ending at 1581461350.708 Interim result: 478.42 10^6bits/s over 1.999 seconds ending at 1581461352.707 Interim result: 473.90 10^6bits/s over 1.980 seconds ending at 1581461354.687

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/HewlettPackard/netperf/issues/39?email_source=notifications&email_token=AIUROSGVCZ36HRIFMTQGKRLRCMTWDA5CNFSM4KTGAGO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELOM7DA#issuecomment-584896396, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIUROSE3AS3HZPIIUSEXLRLRCMTWDANCNFSM4KTGAGOQ .

quinn56 commented 4 years ago

Grant,

A diff of what exactly? I have made no changes to any netperf code, I am simply calling the commands with the values we both calculated.

grundlerchromium commented 4 years ago

On Wed, Feb 12, 2020 at 1:45 PM Brian Quinn notifications@github.com wrote:

Grant,

A diff of what exactly? I have made no changes to any netperf code, I am simply calling the commands with the values we both calculated.

Oh! Sorry - I thought you were adding -b parameter support since I wasn't familiar with them.

A\nd looks like I can't easily test this locally since demo mode isn't enable in the Chrome OS builds: :(

localhost ~ # netperf -H 192.168.xx.nn -c -C -l 10 -t UDP_STREAM -b 81377 -w 1000 -D 1 -- -m 1470 -M 1470 Packet burst size is not compiled in. Packet rate control is not compiled in. Sorry, Demo Mode not configured into this netperf. Please consider reconfiguring netperf with --enable-demo=yes and recompiling ^C localhost ~ # netperf -V Netperf version 2.7.0

Anyone else can?

cheers, grant

mzhang741 commented 8 months ago

Hi Brian, I wonder how you setup netperf to use -b and -w to rate limit netperf. I'm trying to do the same thing, but it seems that -w doesn't have any effect on the throughput of UDP and TCP stream test. The following is how I configure and run netperf. Any problem here?

./configure --enable-burst --enable-intervals --enable-demo --enable-histogram && make CFLAGS=-fcommon && sudo make install

/opt/pkb/netperf-netperf-2.7.0/src/netperf -p {command_port} -j  -t UDP_STREAM -H 10.34.137.3 -l 60  -- -P ,{data_port} -o THROUGHPUT,THROUGHPUT_UNITS,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,MIN_LATENCY,MAX_LATENCY,CONFIDENCE_ITERATION,THROUGHPUT_CONFID,LOCAL_TRANSPORT_RETRANS,REMOTE_TRANSPORT_RETRANS,TRANSPORT_MSS -R 1 -m 10 -M 10  -b 10 -w 10000