Use SI Units (not IEC units) for Data Transfer Rates

deekerman commented

2026-02-21 17:15:33 -05:00

Owner

Originally created by @don4of4 on GitHub (May 30, 2016).

I would like to start a discussion as to why qtorrent uses IEC units. Moreover, I would like to discuss why it opts to display transfer speeds in a base of bytes, rather than the networking standard, bits.

For reference, the IEC units:

KiloBiBit (Kib) -> 2^10 (1024^1) bits
MegaBiBit (Mib) -> 2^20 (1024^2) bits
KiloBiByte (KiB) -> 2^10 (1024^1) bytes (divide by 8 to get Kib)
MegaBiByte (MiB) -> 2^20 (1024^2) bytes (divide by 8 to get Mib)

It is important to note, I am not looking to discuss using MB/s to represent 2^20 bytes, as this representation is ambiguous and not compliant with the latest standards.

I am compelled to point out that the entirety of the world's network infrastructure uses SI Units (aka powers of ten) to represent bits going across the wire. Intuitively, the reason is simple... Why use powers of 2? The engineers who design infrastructure use SI units. While I understand why computer scientists like working with powers of 2, what relevance does powers of two have with networking? (Hint: nothing)

When our network cards are spec'ed at 100 Megabit/s or 1 Gigabit/s (and so on), why would qBittorrent opt to—instead of using powers of 10—use powers of 2?

Consider this simple use case:
A user has a 100 mbit/s internet connection from Verizon. They want qbittorrent to use no more than 40% of their upload pipe. What would they enter into the speed limit box which is denoted in KiB?

Can you come up with the answer in 20 seconds or less?

Probably not... The conversion is non-trivial.

First the user needs to convert 40 megabit/s (mbps) to megabyte/s (MB/s). 40/8 -> 5 MB/s
Then the user needs to convert that to byte/s. 5*10^6 -> 5e6 byte/s
Next the user need to divide by 1024 to convert byte/s to Kilobibyte/s. 5e6/1024 -> 4882.8125 KiB

I recognize some linux distros opt to use KiB and MiB for network speeds, and I see some open source software following suit, but for the life of me I don't understand why... Networking equipment continues to use SI units (which is completely correct) and have no intention of changing. A 10 gigabit uplink will never be referred to as a 9.31323 Gibibit or a 1.16415 Gibibyte uplink, so why list those units in software?

If the intention is to provide a unit analogous to file size's (which does use IEC units) then that information could be provided, but to imply that 1 KiB/s means a 1 Kibibyte file will take one second is incorrect. Qtorrent properly includes overhead in the data transfer rate.

So, in conclusion, what is the justification for use IEC units? And why bytes?

Originally created by @don4of4 on GitHub (May 30, 2016). **I would like to start a discussion as to why qtorrent uses IEC units. Moreover, I would like to discuss why it opts to display transfer speeds in a base of _bytes_, rather than the networking standard, _bits_.** For reference, the IEC units: - KiloBiBit (Kib) -> 2^10 (1024^1) bits - MegaBiBit (Mib) -> 2^20 (1024^2) bits - KiloBiByte (KiB) -> 2^10 (1024^1) _bytes_ (divide by 8 to get Kib) - MegaBiByte (MiB) -> 2^20 (1024^2) _bytes_ (divide by 8 to get Mib) It is important to note, I am not looking to discuss using MB/s to represent 2^20 bytes, as this representation is ambiguous and not compliant with the latest standards. I am compelled to point out that **the entirety of the world's network infrastructure uses SI Units (aka powers of ten) to represent bits going across the wire.** Intuitively, the reason is simple... Why use powers of 2? The engineers who design infrastructure use SI units. While I understand why computer scientists like working with powers of 2, what relevance does powers of two have with networking? _(Hint: nothing)_ When our network cards are spec'ed at 100 Megabit/s or 1 Gigabit/s (and so on), why would qBittorrent opt to—instead of using powers of 10—use powers of 2? **Consider this simple use case:** A user has a 100 mbit/s internet connection from Verizon. They want qbittorrent to use no more than 40% of their upload pipe. What would they enter into the speed limit box which is denoted in KiB? > Can you come up with the answer in 20 seconds or less? Probably not... The conversion is non-trivial. 1. First the user needs to convert 40 megabit/s (mbps) to megabyte/s (MB/s). 40/8 -> 5 MB/s 2. Then the user needs to convert that to byte/s. 5*10^6 -> 5e6 byte/s 3. Next the user need to divide by 1024 to convert byte/s to Kilobibyte/s. 5e6/1024 -> 4882.8125 KiB I recognize some linux distros opt to use KiB and MiB for network speeds, and I see some open source software following suit, but for the life of me I don't understand why... Networking equipment continues to use SI units (which is completely correct) and have no intention of changing. A 10 gigabit uplink will never be referred to as a 9.31323 Gibibit or a 1.16415 Gibibyte uplink, so why list those units in software? If the intention is to provide a unit analogous to _file size's_ (which does use IEC units) then that information could be provided, but to imply that 1 KiB/s means a 1 Kibibyte file will take one second is incorrect. Qtorrent properly includes overhead in the data transfer rate. So, in conclusion, what is the justification for use IEC units? And why bytes?

deekerman closed this issue

2026-02-21 17:15:35 -05:00

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@thalieht commented on GitHub (May 30, 2016):

Bytes are much more user friendly (smaller numbers).
Personally the only time i thought about my connection speed in bps was when i saw the big flashy number advertised by my isp and i didn't know what it meant and how to convert it to numbers that almost every program that interacts with the user uses: BYTES

Say you are downloading a torrent and it shows 3.67 Mbps download speed. What does that mean compared to the torrent size? Looks like you're gonna have to do those calculations every single time you look at the download speed. Or you only care about the % of your network speed this torrent utilizes?

However an option to input bps in speed limits might be useful for the "uninitiated".

@thalieht commented on GitHub (May 30, 2016): Bytes are much more user friendly (smaller numbers). Personally the only time i thought about my connection speed in bps was when i saw the big flashy number advertised by my isp and i didn't know what it meant and how to convert it to numbers that almost every program that interacts with the user uses: BYTES Say you are downloading a torrent and it shows 3.67 Mbps download speed. What does that mean compared to the torrent size? Looks like you're gonna have to do those calculations every single time you look at the download speed. Or you only care about the % of your network speed this torrent utilizes? However an option to input bps in speed limits might be useful for the "uninitiated".

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@don4of4 commented on GitHub (May 30, 2016):

@thalieht I like the points you bring up, and I would like to bring up some counter-arguments:

i didn't know what it meant and how to convert it to numbers that almost every program that interacts with the user uses: BYTES

The conversion from SI mbps <-> MB/s is a simple matter of multiplication by 8 or division by 8. KiB/s to Mbps is far less simple.

... 3.67 Mbps download speed. What does that mean compared to the torrent size?

What does 3.499 Mib/s mean compared to torrent size? Since overhead is included, it could be substantially off. So, the user not only doesn't know his network utilization, he also doesn't know file size rate of completion.

Or you only care about the % of your network speed this torrent utilizes?

I think % of network speed is incredibly relevent, especially for setting speed limits. I believe a poll of users will find that when they look at speeds on a torrent, they will want to know how fast a speed is downloading with respect to the maximum theoretical speed (aka their uplink speed). For speed limit purposes Mebibytes are almost entirely useless, and Kibibytes even more so, because it is difficult to compare to the SI standard.

Would it be fair to say that users should at least see the SI rate next to the IEC rate and/or be able to set speed limits with the SI units they are used to using?

The communities thoughts would be appreciated.

@don4of4 commented on GitHub (May 30, 2016): @thalieht I like the points you bring up, and I would like to bring up some counter-arguments: > i didn't know what it meant and how to convert it to numbers that almost every program that interacts with the user uses: BYTES The conversion from SI mbps <-> MB/s is a simple matter of multiplication by 8 or division by 8. KiB/s to Mbps is far less simple. > ... 3.67 Mbps download speed. What does that mean compared to the torrent size? What does 3.499 Mib/s mean compared to torrent size? Since overhead is included, it could be substantially off. So, the user not only doesn't know his network utilization, he also doesn't know file size rate of completion. > Or you only care about the % of your network speed this torrent utilizes? I think % of network speed is **_incredibly relevent_, especially for setting speed limits.** I believe a poll of users will find that when they look at speeds on a torrent, they will want to know how fast a speed is downloading with respect to the maximum theoretical speed (aka their uplink speed). For speed limit purposes Mebibytes are almost entirely useless, and Kibibytes even more so, because it is difficult to compare to the SI standard. #### Would it be fair to say that users should at least see the SI rate next to the IEC rate and/or be able to set speed limits with the SI units they are used to using? _The communities thoughts would be appreciated._

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@tekko commented on GitHub (May 30, 2016):

I vote for bytes. The only time I see bits is taking a speed test... All downloaders I use show speed in bytes.

@tekko commented on GitHub (May 30, 2016): I vote for bytes. The only time I see bits is taking a speed test... All downloaders I use show speed in bytes.

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@don4of4 commented on GitHub (May 30, 2016):

@tekko Do they put speed limits in KiB/s?

Can you determine approx. what half of a gigabit port would be in in KiB/s in your head?

@don4of4 commented on GitHub (May 30, 2016): @tekko Do they put speed limits in KiB/s? Can you determine approx. what half of a gigabit port would be in in KiB/s in your head?

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@tekko commented on GitHub (May 30, 2016):

yes... i.e. downThemAll, freerapid, emule, etc.
Since everything I use put limits in KiB/s or MiB/s, I only have to memorize my cap in MiB/s.

If a downloader is showing 6MiB/s and my browsing speed is slow. I'll put a limit of 4-5 MiB/s for example.
If the limit is in bits, then I would have to do the calculation...

I'm just giving my opinion, not speaking for everyone else, of course. :)

@tekko commented on GitHub (May 30, 2016): yes... i.e. downThemAll, freerapid, emule, etc. Since everything I use put limits in KiB/s or MiB/s, I only have to memorize my cap in MiB/s. If a downloader is showing 6MiB/s and my browsing speed is slow. I'll put a limit of 4-5 MiB/s for example. If the limit is in bits, then I would have to do the calculation... I'm just giving my opinion, not speaking for everyone else, of course. :)

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@ngosang commented on GitHub (May 30, 2016):

qBittorrent it's not a network tool to measure the link bandwidth.
When you copy some file from one location to another you can see the speed in MB/s and when you download something n your web browser the same. When you copy/download a 10 MB file at 1MB/s its easy to estimate 10s as remaining time. If you see 8Mbps you have to do the math...

Related #5158.

@ngosang commented on GitHub (May 30, 2016): qBittorrent it's not a network tool to measure the link bandwidth. When you copy some file from one location to another you can see the speed in MB/s and when you download something n your web browser the same. When you copy/download a 10 MB file at 1MB/s its easy to estimate 10s as remaining time. If you see 8Mbps you have to do the math... Related #5158.

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (May 30, 2016):

First of all the name of this is project is qBitTorrent, not qTorrent.
Secondly I initially thought "yet another user you wants KB instead of KiB".
Then I saw that you actually want Kbps. Talk about alienating users even more. qBittorrent is a a type of downloading manager. I haven't seen any downloading manager display this type of units as a default.
Your main argument is that it is hard to know what limit to put(in bytes) when you know your line speed in bits per second. Well it isn't that hard. Why? Your line speeds are fixed more or less. So you do once the calculation from bps to bytes and then you know your theoretical max in KB/s or MB/s and accordingly all other limits.

@sledgehammer999 commented on GitHub (May 30, 2016): First of all the name of this is project is q**Bit**Torrent, not qTorrent. Secondly I initially thought "yet another user you wants KB instead of KiB". Then I saw that you actually want Kbps. Talk about alienating users even more. qBittorrent is a a type of downloading manager. I haven't seen any downloading manager display this type of units as a default. Your main argument is that it is hard to know what limit to put(in bytes) when you know your line speed in bits per second. Well it isn't that hard. Why? Your line speeds are fixed more or less. So you do once the calculation from bps to bytes and then you know your theoretical max in KB/s or MB/s and accordingly all other limits.

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@don4of4 commented on GitHub (May 31, 2016):

@sledgehammer999 With all due respect, sir, clearly you spent about as much time proofreading what you wrote as you did reading my comments.

Secondly I initially thought "yet another user you wants KB instead of KiB".
Then I saw that you actually want Kbps

No, I was suggesting USING SI UNITS: Mbps and/or MB/s (etc.) for transfer speed limits, as well as for display on transfer speeds. My justification for such an option is well supported.

Talk about alienating users even more....

These software products either use Mbps/Kbps or MB/s/KB/s:

wget
Google Chrome
FileZilla
Mozilla Firefox
uTorrent
Safari

Ergo, 95%+ of all "typical user" downloading happens in SI units. It is qBitTorrent which I would say is "alienating users."

Oh, and just to be clear:

Your main argument is that it is hard to know what limit to put(in bytes) when you know your line speed in bits per second.

It isn't, you have it completely wrong... 1000 mbps is 125 MB/s, and that is an EASY calculation. You can't tell me what 125 Mb/s is in KiB/s (as qBitTorrent requires) without a calculator.

@don4of4 commented on GitHub (May 31, 2016): @sledgehammer999 With all due respect, sir, clearly you spent about as much time proofreading what you wrote as you did reading my comments. > Secondly I initially thought "yet another user you wants KB instead of KiB". > Then I saw that you actually want Kbps **No, I was suggesting USING SI UNITS:** Mbps and/or MB/s (etc.) for transfer speed limits, as well as for display on transfer speeds. My justification for such an option is well supported. > Talk about alienating users even more.... These software products either use Mbps/Kbps or MB/s/KB/s: - wget - Google Chrome - FileZilla - Mozilla Firefox - uTorrent - Safari **Ergo, 95%+ of all "typical user" downloading happens in SI units.** It is qBitTorrent which I would say is "alienating users." Oh, and just to be clear: > Your main argument is that it is hard to know what limit to put(in bytes) when you know your line speed in bits per second. It isn't, you have it completely wrong... 1000 mbps is 125 MB/s, and that is an EASY calculation. You can't tell me what 125 Mb/s is in KiB/s (as qBitTorrent requires) without a calculator.

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jun 8, 2016):

Yes, you're right I didn't read it with great attention. And I did a mistake for the name too. The correct capitalization is qBittorrent.

It isn't, you have it completely wrong... 1000 mbps is 125 MB/s, and that is an EASY calculation. You can't tell me what 125 Mb/s is in KiB/s (as qBitTorrent requires) without a calculator.

No I can't tell you the exact number. But if you require an exact number then you need to take a calculator for MB too. I mean that you'll need converting between 1000 and 1024 so you can be much more precise on your limits. If you don't need much precision then half-assing it with MB is the same half-assing with MiB.

1000 mbps is 125 MB/s, and that is an EASY calculation.

I don't think dividing 1000 by 8 is an easy calculation for most people.

@sledgehammer999 commented on GitHub (Jun 8, 2016): Yes, you're right I didn't read it with great attention. And I did a mistake for the name too. The correct capitalization is `qBittorrent`. > It isn't, you have it completely wrong... 1000 mbps is 125 MB/s, and that is an EASY calculation. You can't tell me what 125 Mb/s is in KiB/s (as qBitTorrent requires) without a calculator. No I can't tell you the exact number. But if you require an exact number then you need to take a calculator for MB too. I mean that you'll need converting between 1000 and 1024 so you can be much more precise on your limits. If you don't need much precision then half-assing it with MB is the same half-assing with MiB. > 1000 mbps is 125 MB/s, and that is an EASY calculation. I don't think dividing 1000 by 8 is an easy calculation for most people.

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@adrianvg commented on GitHub (Dec 19, 2016):

Could we have a choice of using either unit?
Most torrent clients I use offer that.
By all means, use IEC-units as the default setting, but please let the end user decide what he or she wants to see in terms of network speed units.

@adrianvg commented on GitHub (Dec 19, 2016): Could we have a choice of using either unit? Most torrent clients I use offer that. By all means, use IEC-units as the default setting, but please let the end user decide what he or she wants to see in terms of network speed units.

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@don4of4 commented on GitHub (Dec 20, 2016):

The dev's for this project are stuck in their ways. The standard unit for (over the line) physical data transfer is SI (base 10), but they don't want to hear it.

A good read:
https://wiki.ubuntu.com/UnitsPolicy

Correct basis

Use base-10 for:

network bandwidth (for example, 6 Mbit/s or 50 kB/s)

disk sizes (for example, 500 GB hard drive or 4.7 GB DVD)

Use base-2 for:

RAM sizes (for example, 2 GiB RAM)

For file sizes there are two possibilities:

Show both, base-10 and base-2 (in this order). An example is the Linux kernel: "2930277168 512-byte hardware sectors: (1.50 TB/1.36 TiB)"

Only show base-10, or give the user the opportunity to decide between base-10 and base-2 (the default must be base-10).

@don4of4 commented on GitHub (Dec 20, 2016): The dev's for this project are stuck in their ways. The standard unit for (over the line) physical data transfer is SI (base 10), but they don't want to hear it. A good read: https://wiki.ubuntu.com/UnitsPolicy > ### Correct basis > **Use base-10 for:** > > * network bandwidth (for example, 6 Mbit/s or 50 kB/s) > * disk sizes (for example, 500 GB hard drive or 4.7 GB DVD) > > **Use base-2 for:** > * RAM sizes (for example, 2 GiB RAM) > > **For file sizes there are two possibilities:** > > * Show both, base-10 and base-2 (in this order). An example is the Linux kernel: "2930277168 512-byte hardware sectors: (1.50 TB/1.36 TiB)" > * Only show base-10, or give the user the opportunity to decide between base-10 and base-2 (the default must be base-10). > ```

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@adrianvg commented on GitHub (Dec 20, 2016):

Too bad, because I really like qBittorrent, it's both goodlooking and lean.
It shouldn't be to much of a hassle to implement the choices and giving the end-users what they request, seeing as many other torrent clients offer it.
No prob though, looking to move to Transmission instead...

@adrianvg commented on GitHub (Dec 20, 2016): Too bad, because I really like qBittorrent, it's both goodlooking and lean. It shouldn't be to much of a hassle to implement the choices and giving the end-users what they request, seeing as many other torrent clients offer it. No prob though, looking to move to Transmission instead...

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@0rkaM commented on GitHub (Oct 9, 2018):

I know this is old, but it start to be really a pain in the ass, every time I update I have to re-set the limits and redo three level calculation to figure out the exact number to put int and most of the time some mistakes are done in the way.
I work managing IT/IS and SI is the standard for every transmission (which used to be Baud Kb/s or Mb/s) and data capacity; the IEC KibiBytes/KiB and company are only for memory and file sizes (which used to be called just B, KB, MB, etc.)
Now I understand the Kibi-etc. invention/convention to cater clarity to the novices and uninitiated, but is should only be used where it need to be, like where KB, MB, GB was in the JEDEC... and not for transmission speed.

@0rkaM commented on GitHub (Oct 9, 2018): I know this is old, but it start to be really a pain in the ass, every time I update I have to re-set the limits and redo three level calculation to figure out the exact number to put int and most of the time some mistakes are done in the way. I work managing IT/IS and SI is the standard for every transmission (which used to be Baud Kb/s or Mb/s) and data capacity; the IEC KibiBytes/KiB and company are only for memory and file sizes (which used to be called just B, KB, MB, etc.) Now I understand the Kibi-etc. invention/convention to cater clarity to the novices and uninitiated, but is should only be used where it need to be, like where KB, MB, GB was in the JEDEC... and not for transmission speed.

deekerman commented

2026-02-21 17:15:39 -05:00

Author

Owner

@ppoutine commented on GitHub (Dec 3, 2018):

With torrent speeds, the limiting factor is your ISP. Everyone's ISP gives bandwidth in Mbps, right? So why not Mbps?

@ppoutine commented on GitHub (Dec 3, 2018): With torrent speeds, the limiting factor is your ISP. Everyone's ISP gives bandwidth in Mbps, right? So why not Mbps?

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@hrxn commented on GitHub (Dec 3, 2018):

Well, if you know your ISP's bandwith in Mbps, you also know what you get in MiBps. And if not, it's a fixed number anyway, you only ever have to find out once. I don't get it. How would that change or rather improve the day-to-day usage of the program?

Oh, and by the way, part of the reason why ISPs state the bandwidth in Mbps is simply marketing. Because the number looks greater.

@hrxn commented on GitHub (Dec 3, 2018): Well, if you know your ISP's bandwith in Mbps, you also know what you get in MiBps. And if not, it's a fixed number anyway, you only ever have to find out once. I don't get it. How would that change or rather improve the day-to-day usage of the program? Oh, and by the way, part of the reason why ISPs state the bandwidth in Mbps is simply marketing. Because the number looks greater.

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@Seeker2 commented on GitHub (Dec 3, 2018):

8 bits to a BYTE only assumes no overheads.
TCP/IP networking has overheads.
BitTorrent has its own overheads on top of that.
Bad BitTorrent settings combinations (read: most any YouTube "best BitTorrent settings" video) can make overheads far worse.

A good "rule of thumb" is 10 bits of bandwidth to get 1 BYTE of a file...and even that is being extremely frugal with the bandwidth due to SYN-ACKs and other unavoidable overheads.

@Seeker2 commented on GitHub (Dec 3, 2018): 8 bits to a BYTE only assumes no overheads. TCP/IP networking has overheads. BitTorrent has its own overheads on top of that. Bad BitTorrent settings combinations (read: most any YouTube "best BitTorrent settings" video) can make overheads far worse. A good "rule of thumb" is 10 bits of bandwidth to get 1 BYTE of a file...and even that is being extremely frugal with the bandwidth due to SYN-ACKs and other unavoidable overheads.

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@ppoutine commented on GitHub (Dec 3, 2018):

Trust me, I'm not here stanning for the Comcast marketing department, it's just irrelevant why they use Mbps; the point is that they do use Mbps. Everyone who knows their speed already knows it in Mbps.
And it's not just greedy ISPs that use base-10 for network bandwidth; as we can see above, it's also everyone else - Ubuntu, Mozilla, etc.

How would that change or rather improve the day-to-day usage of the program?

Like most people I fiddle around with my speed limits pretty rarely. Thus I'm unlikely to always remember the two conversions (upload and download Mbps to KiB/s) in addition to the usual conversions (Mbps to MBps/KBps, since all my other programs such as Firefox use base 10 units). Never mind trying to figure out a KiB/s speed if I'm not hitting my speed limits; then I'm trying to mental-math some other number of KiB/s into a unit I can intuitively understand and either it's an easy divisor of my overall speed limit (still an extra step) or I'm typing it into google. By the time I've memorized at least my upload and download, maybe I've switched ISPs, or switched to ethernet, or made some other change.

So using the standard units, either Mbps or KBps/MBps, improves day-to-day usage because it reduces the amount of times I have to type into Google "1234 KiBps to Mbps". Aligning these units with all the other contexts in which users are getting network bandwidth data is a pure positive for the user experience. To be honest, I think this question is framed backwards; when considering using non-standard units like KiB/s it should really be "how do KiB/s improve the user experience", not the other way around.

A good "rule of thumb" is 10 bits of bandwidth to get 1 BYTE of a file...and even that is being extremely frugal with the bandwidth due to SYN-ACKs and other unavoidable overheads.

I'm not sure I understand, do you mean that bandwidth limits set in qbittorrent do not apply to packet headers / overhead?

@ppoutine commented on GitHub (Dec 3, 2018): Trust me, I'm not here stanning for the Comcast marketing department, it's just irrelevant why they use Mbps; the point is that they do use Mbps. Everyone who knows their speed already knows it in Mbps. And it's not just greedy ISPs that use base-10 for network bandwidth; as we can see above, it's also everyone else - Ubuntu, Mozilla, etc. > How would that change or rather improve the day-to-day usage of the program? Like most people I fiddle around with my speed limits pretty rarely. Thus I'm unlikely to always remember the two conversions (upload and download Mbps to KiB/s) in addition to the usual conversions (Mbps to MBps/KBps, since all my other programs such as Firefox use base 10 units). Never mind trying to figure out a KiB/s speed if I'm not hitting my speed limits; then I'm trying to mental-math some other number of KiB/s into a unit I can intuitively understand and either it's an easy divisor of my overall speed limit (still an extra step) or I'm typing it into google. By the time I've memorized at least my upload and download, maybe I've switched ISPs, or switched to ethernet, or made some other change. So using the standard units, either Mbps or KBps/MBps, improves day-to-day usage because it reduces the amount of times I have to type into Google "1234 KiBps to Mbps". Aligning these units with all the other contexts in which users are getting network bandwidth data is a pure positive for the user experience. To be honest, I think this question is framed backwards; when considering using non-standard units like KiB/s it should really be "how do KiB/s improve the user experience", not the other way around. > A good "rule of thumb" is 10 bits of bandwidth to get 1 BYTE of a file...and even that is being extremely frugal with the bandwidth due to SYN-ACKs and other unavoidable overheads. I'm not sure I understand, do you mean that bandwidth limits set in qbittorrent do not apply to packet headers / overhead?

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@hrxn commented on GitHub (Dec 4, 2018):

What are you talking about? Mozilla use the IEC units in their browser for displaying download progress, etc.

Like it should be, for end user applications or application layer tasks in general.

@hrxn commented on GitHub (Dec 4, 2018): What are you talking about? Mozilla use the IEC units in their browser for displaying download progress, etc. Like it should be, for end user applications or application layer tasks in general.

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@don4of4 commented on GitHub (Dec 4, 2018):

Note that firefox displays MB/s, which is wrong. It should be MiB, but they chose not to fix it).

I'd like to point out, again, that the international standard for line rate is SI units.

Any network engineer is going to prefer SI units, because SI units is what all the equipment and line speeds are set to. As will any user who knows they have a XX mbps internet connection. Again, there is a reason someone setting policy on Cisco and Juniper routers must use SI...

@don4of4 commented on GitHub (Dec 4, 2018): _Note that firefox displays MB/s, which is wrong. It should be MiB, but [they chose not to fix it](https://bugzilla.mozilla.org/show_bug.cgi?id=106618))._ **I'd like to point out, again, that the international standard for _line rate_ is SI units.** Any network engineer is going to prefer SI units, because SI units is what all the equipment and line speeds are set to. As will any user who knows they have a XX mbps internet connection. Again, there is a reason someone setting policy on Cisco and Juniper routers must use SI...

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@adrian-vg commented on GitHub (Dec 4, 2018):

Well, if you know your ISP's bandwith in Mbps, you also know what you get in MiBps. And if not, it's a fixed number anyway, you only ever have to find out once. I don't get it. How would that change or rather improve the day-to-day usage of the program?

Oh, and by the way, part of the reason why ISPs state the bandwidth in Mbps is simply marketing. Because the number looks greater.

Mbps is a de facto standard used most everywhere, and I'm talking end-user perspective now.
It might not be the best solution, but it's the most widespread one. Just about everybody can relate to it, right?

So why fight it? Why has this become such a big discussion?
Makes no sense IMHO.

@adrian-vg commented on GitHub (Dec 4, 2018): > Well, if you know your ISP's bandwith in Mbps, you also know what you get in MiBps. And if not, it's a fixed number anyway, you only ever have to find out once. I don't get it. How would that change or rather improve the day-to-day usage of the program? > > Oh, and by the way, part of the reason why ISPs state the bandwidth in Mbps is simply marketing. Because the number looks greater. Mbps is a de facto standard used most everywhere, and I'm talking end-user perspective now. It might not be the best solution, but it's the most widespread one. Just about everybody can relate to it, right? So why fight it? Why has this become such a big discussion? Makes no sense IMHO.

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@hrxn commented on GitHub (Dec 4, 2018):

@hrxn commented on GitHub (Dec 4, 2018): ![firefox-dl-progress](https://user-images.githubusercontent.com/12064918/49441920-3afd5180-f7c8-11e8-91ba-8f24dbb269b4.png)

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@Seeker2 commented on GitHub (Dec 4, 2018):

The bandwidth limits applied in qBT do not apply to packet headers / overhead, at least the TCP/IP networking parts. At best it can estimate them assuming everything works perfectly, minimal overheads, and no packet loss.

Even having a high half open limit, encryption forced, DHT+PEX+LSD enabled, with a very busy torrent can have 1000+ incoming peer+seed connections per minute that eats up a bit of bandwidth due to all the round trip encrypted handshakes, PEX and HAVE piece lists, and disconnects.

Changing the MTU for a network card can also have an effect on bandwidth used. BitTorrent protocol even has variable packet size for uTP based on latency, ironically making throughput lower in the very cases where there's low total upload bandwidth available.

Then there's wifi connections...and the unreliability of that which can totally change how much bandwidth (at least as measured at the computer) it takes to send or receive 1000 BYTES of a torrent file. qBT may have no way of knowing what's happening there except indirectly through uTP's latency+bufferbloat measurements.

In short, any reports by qBitTorrent of bandwidth usage in bits per second is likely to be wrong...often by greater than the difference between 1000 BYTES and 1024 BYTES.

@Seeker2 commented on GitHub (Dec 4, 2018): The bandwidth limits applied in qBT do not apply to packet headers / overhead, at least the TCP/IP networking parts. At best it can estimate them assuming everything works perfectly, minimal overheads, and no packet loss. Even having a high half open limit, encryption forced, DHT+PEX+LSD enabled, with a very busy torrent can have 1000+ incoming peer+seed connections per minute that eats up a bit of bandwidth due to all the round trip encrypted handshakes, PEX and HAVE piece lists, and disconnects. Changing the MTU for a network card can also have an effect on bandwidth used. BitTorrent protocol even has variable packet size for uTP based on latency, ironically making throughput lower in the very cases where there's low total upload bandwidth available. Then there's wifi connections...and the unreliability of that which can totally change how much bandwidth (at least as measured at the computer) it takes to send or receive 1000 BYTES of a torrent file. qBT may have no way of knowing what's happening there except indirectly through uTP's latency+bufferbloat measurements. In short, any reports by qBitTorrent of bandwidth usage in bits per second is likely to be wrong...often by greater than the difference between 1000 BYTES and 1024 BYTES.

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@Hammerfest commented on GitHub (Jan 26, 2020):

Yep, the only program I have ever used not to follow standards for displayed rates to match all the other standards used to display rates...

@Hammerfest commented on GitHub (Jan 26, 2020): Yep, the only program I have ever used not to follow standards for displayed rates to match all the other standards used to display rates...

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@ghost commented on GitHub (Apr 22, 2020):

Just found this and have to agree. It's not user friendly when I have to do an internet search to figure out how to set limits in qBittorrent. I use speedtest to determine download/upload speed and get results in Mbps. How do I find 80% percent of that speed in KiBs? Maybe qBittorrent can supply a calculator in the app for this conversion?

If the developers have a reason for this then they should take the time to educate users about the advantages of using KiB/s. Personally I had never heard of KiB/s until using qBittorent, but I am older.

For Posterity:
Link to calculator

How many Mbps in 1 KiB per s? The answer is 0.008192.
We assume you are converting between megabit/second and kibibyte/second.
You can view more details on each measurement unit:
Mbps or KiB per s
The main non-SI unit for computer data rate is the bit/second.
1 bit/second is equal to 1.0E-6 Mbps, or 0.0001220703125 KiB per s.
Note that rounding errors may occur, so always check the results.

1 Mbps to KiB per s = 122.07031 KiB per s
2 Mbps to KiB per s = 244.14063 KiB per s
3 Mbps to KiB per s = 366.21094 KiB per s
4 Mbps to KiB per s = 488.28125 KiB per s
5 Mbps to KiB per s = 610.35156 KiB per s
6 Mbps to KiB per s = 732.42188 KiB per s
7 Mbps to KiB per s = 854.49219 KiB per s
8 Mbps to KiB per s = 976.5625 KiB per s
9 Mbps to KiB per s = 1098.63281 KiB per s
10 Mbps to KiB per s = 1220.70313 KiB per s

@ghost commented on GitHub (Apr 22, 2020): Just found this and have to agree. It's not user friendly when I have to do an internet search to figure out how to set limits in qBittorrent. I use speedtest to determine download/upload speed and get results in Mbps. How do I find 80% percent of that speed in KiBs? Maybe qBittorrent can supply a calculator in the app for this conversion? If the developers have a reason for this then they should take the time to educate users about the advantages of using KiB/s. Personally I had never heard of KiB/s until using qBittorent, but I am older. For Posterity: [Link to calculator](https://www.convertunits.com/from/Mbps/to/KiB+per+s) > How many Mbps in 1 KiB per s? The answer is 0.008192. > We assume you are converting between megabit/second and kibibyte/second. > You can view more details on each measurement unit: > Mbps or KiB per s > The main non-SI unit for computer data rate is the bit/second. > 1 bit/second is equal to 1.0E-6 Mbps, or 0.0001220703125 KiB per s. > Note that rounding errors may occur, so always check the results. ``` 1 Mbps to KiB per s = 122.07031 KiB per s 2 Mbps to KiB per s = 244.14063 KiB per s 3 Mbps to KiB per s = 366.21094 KiB per s 4 Mbps to KiB per s = 488.28125 KiB per s 5 Mbps to KiB per s = 610.35156 KiB per s 6 Mbps to KiB per s = 732.42188 KiB per s 7 Mbps to KiB per s = 854.49219 KiB per s 8 Mbps to KiB per s = 976.5625 KiB per s 9 Mbps to KiB per s = 1098.63281 KiB per s 10 Mbps to KiB per s = 1220.70313 KiB per s ```

deekerman commented

2026-02-21 17:15:40 -05:00

Author

Owner

@ghost commented on GitHub (Apr 22, 2020):

@don4of4 Thanks for the conversion method!

Probably not... The conversion is non-trivial.

First the user needs to convert 40 megabit/s (mbps) to megabyte/s (MB/s). 40/8 -> 5 MB/s

Then the user needs to convert that to byte/s. 5*10^6 -> 5e6 byte/s

Next the user need to divide by 1024 to convert byte/s to Kilobibyte/s. 5e6/1024 -> 4882.8125 KiB

@ghost commented on GitHub (Apr 22, 2020): @don4of4 Thanks for the conversion method! > Probably not... The conversion is non-trivial. > > 1. First the user needs to convert 40 megabit/s (mbps) to megabyte/s (MB/s). 40/8 -> 5 MB/s > 2. Then the user needs to convert that to byte/s. 5*10^6 -> 5e6 byte/s > 3. Next the user need to divide by 1024 to convert byte/s to Kilobibyte/s. 5e6/1024 -> 4882.8125 KiB >

Rows
Columns

Use SI Units (not IEC units) for Data Transfer Rates #4331

Would it be fair to say that users should at least see the SI rate next to the IEC rate and/or be able to set speed limits with the SI units they are used to using?

Correct basis