-
Notifications
You must be signed in to change notification settings - Fork 187
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
Limiting UDP Bandwidth capped at 957 Mbits/sec #39
Comments
On Tue, Feb 11, 2020 at 10:22 AM Brian Quinn ***@***.***> 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
<#39?email_source=notifications&email_token=AIUROSHJKU5IOK4IPCS4AD3RCLUHFA5CNFSM4KTGAGO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IMUVM7A>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIUROSHOV3JA45ZQY5RQGSDRCLUHFANCNFSM4KTGAGOQ>
.
|
Grant,
I am performing the calculation manually so any mishandling of values would be done by netperf, no?
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: 958 Mbits/sec: |
On Tue, Feb 11, 2020 at 2:51 PM Brian Quinn ***@***.***> 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
<#39?email_source=notifications&email_token=AIUROSGVCZ36HRIFMTQGKRLRCMTWDA5CNFSM4KTGAGO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELOM7DA#issuecomment-584896396>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIUROSE3AS3HZPIIUSEXLRLRCMTWDANCNFSM4KTGAGOQ>
.
|
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. |
On Wed, Feb 12, 2020 at 1:45 PM Brian Quinn ***@***.***> 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
|
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?
|
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).
The text was updated successfully, but these errors were encountered: