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.

Sign up for GitHub

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

Jump to bottom

Consider changing 'Bandwidth' to 'Bitrate' in iperf3 output #583

Closed
bltierney opened this issue May 18, 2017 · 5 comments
Closed

Consider changing 'Bandwidth' to 'Bitrate' in iperf3 output #583

bltierney opened this issue May 18, 2017 · 5 comments
Assignees
@bmah888
Labels
enhancement
Milestone
3.2

Comments

@bltierney
Copy link
Contributor

The term 'bandwidth' is really incorrect.

should we change:
[ ID] Interval Transfer Bandwidth Retr

to
[ ID] Interval Transfer Throughput Retr

This does make the '-b' flag a bit confusing tho, and we dont want to change that.

Thoughts anyone?
@bmah888
Copy link
Contributor

bmah888 commented May 19, 2017

Isn't the basically the same as #516?

Few thoughts:

I don't have an issue changing the human-readable output, but we're the faced with the question of whether or not to rename the JSON "bandwidth" field(s), remembering that there are programs that consume the JSON. I think that's why we closed #516. (Like do we change the JSON "schema" or let the human output and JSON output use different phraseology?) I'm up for revisiting that.

As far as -b goes, "bitrate" has (in my mind anyway) the same connotation as "throughput" but it also starts with the same letter as "bandwidth", so maybe we could use that term, at least when describing the command-line option.

@bltierney
Copy link
Contributor Author

Ah, I forgot about #516. I pulled this as a separate request out of one of the other issues.

But we cant change the JSON. That would break too many things. So maybe we just leave it alone. At least the man page using the right terminology.

Lets think about this a bit more.

@bmah888
Copy link
Contributor

bmah888 commented May 19, 2017 •
edited
Loading

Rough idea: Maybe we can change the human-facing phraseology including documentation, leave the JSON schema as-is, and also make --bandwidth into --bitrate or something like that but maintain backward compatibility? I think that's as far as we can push this idea without breaking stuff. I am not to what extent something might parse the human-readable output and might break if we were to change that (hopefully nothing).

Also if we do this anytime soon, it should probably be in 3.2, or hold for 3.3 (but not 3.2.x).

@bmah888
Copy link
Contributor

bmah888 commented May 19, 2017

Addendumb: I'm stupid. There's no issue in the JSON, we write it as bits_per_second, which is kind of clunky but at least accurate. There's no bandwidth in the JSON at all:

Bruce-Mahs-MacBook-Pro:iperf% src/iperf3 --client localhost --json | grep bandwidth
Bruce-Mahs-MacBook-Pro:iperf%

@bmah888 bmah888 changed the title consider changing 'Bandwidth' to 'Throughput' in iperf3 output Consider changing 'Bandwidth' to 'Bitrate' in iperf3 output May 23, 2017
@bmah888 bmah888 self-assigned this May 23, 2017
@bmah888 bmah888 added this to the 3.2 milestone May 23, 2017
bmah888 added a commit that referenced this issue May 23, 2017
@bmah888
s/bandwidth/bitrate/ in user-facing places. Towards #583.
acc3cbd 
iperf3 has long misused terminology; bandwidth is a measure of
capacity.  iperf3 measures bitrate or throughput.  We standardize
on "bitrate" because it begins with the same letter as "bandwidth"
(to match the -b command-line option).

User-facing output mentioning "bandwidth" now uses "bitrate".
The long command-line option for -b (--bandwidth) is now --bitrate
(--bandwidth is transparently accepted for backward compatibility).
A few places in documentation that talk about bandwidth as a
measured value have been reworded to use bitrate or throughput.

There are a number of places in code where variables are still
called "bandwidth".  We leave these alone for now.
bmah888 added a commit that referenced this issue May 24, 2017
@bmah888
s/bandwidth/throughput in one place in RPM description. Towards #583.
61b5d71
@bmah888 bmah888 mentioned this issue May 24, 2017
Merged
bmah888 added a commit that referenced this issue May 24, 2017
@bmah888
Issue 583 (#586)
0f081b7 
* s/bandwidth/bitrate/ in user-facing places.  Towards #583.

iperf3 has long misused terminology; bandwidth is a measure of
capacity.  iperf3 measures bitrate or throughput.  We standardize
on "bitrate" because it begins with the same letter as "bandwidth"
(to match the -b command-line option).

User-facing output mentioning "bandwidth" now uses "bitrate".
The long command-line option for -b (--bandwidth) is now --bitrate
(--bandwidth is transparently accepted for backward compatibility).
A few places in documentation that talk about bandwidth as a
measured value have been reworded to use bitrate or throughput.

There are a number of places in code where variables are still
called "bandwidth".  We leave these alone for now.

A mention of "bandwidth" in the test parameters JSON also needs
to remain unchanged to avoid breaking compatibility.  However,
the test results JSON never used the term "bandwidth" in
the first place.

* s/bandwidth/throughput in one place in RPM description.  Towards #583.
@bmah888
Copy link
Contributor

bmah888 commented May 24, 2017

All done, at least to the point that it makes sense to do. The places I didn't touch (deliberately) are variable names in code (probably not worth the effort) and member names in JSON structures (can't change these without breaking compatibility). Closing.

@bmah888 bmah888 closed this as completed May 24, 2017
@ili101 ili101 mentioned this issue Oct 5, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bmah888 bmah888

Labels
enhancement
Projects
None yet
Milestone
3.2
Development

No branches or pull requests
2 participants
@bltierney @bmah888