qBittorrent
qBittorrent copied to clipboard
qbittorrent
Option to show speeds in bps
Please provide the following information
qBittorrent version and Operating System
4.1.7 on Xubuntu 20.04
If on linux, libtorrent-rasterbar and Qt version
QT not installed (no output on command qtdiag nor qmake --version) libtorrent-rasterbar 1.1.13-1.1build2
What is the problem
There is no option to display speed in either bytes or bits per second, with either SI or IEC prefixes.
Currently, speeds are always displayed in bytes per second with IEC prefixes (MiB/s, KiB/s, ...).
What is the expected behavior
Option to display speed in either bytes or bits per second, with either SI or IEC prefixes.
Steps to reproduce
N/A
Extra info(if any)
N/A
EDIT (@FranciscoPombal): edited OP for clarity based on the ensuing discussion.
Yes. And I see you've linked this wishlist bug-report within the discussion of #5326. I guess the correct etiquette would be to delete this bug-report and post my opinion as a comment on 5326?
FWIW, this is why I use BiglyBT on Windows - you have that option to set your preferred units. I'd use BiglyBT on (x)ubuntu but not well maintained and not correctly launching, at this time.
Cache and RAM are measured in IEC bytes (binary prefix, KiB, MiB, ...), so storage should use the same units (though RAM is often erroneously advertised using SI prefixes when referring to IEC-prefix amounts). Thus, storage manufacturers are just wrong in using SI bytes (they do it for marketing anyway) when the other components of the memory hierarchy use IEC bytes. FYI Windows, in its infinite wisdom, uses IEC bytes but displays SI prefixes.
Since storage is best measured in IEC bytes, it follows that IEC bytes per second is the most useful and relevant unit for a file transfer program.
However, network speed is measured in bits per second, and in a file transfer program, a file comes from, well, the network. Bit is the fundamental unit of information, despite the "8 bit byte" being a de-facto standard. So there is some merit in allowing network speed to be displayed in bits per second as an option. I'm considering this issue report as a feature request for that.
https://github.com/qbittorrent/qBittorrent/issues/5326 is different: it is a request for a change rather than a feature request for an additional option.
As you might guess, given this reasoning, my opinion is that SI ("8 bit") bytes (decimal prefix, KB, MB, ...) and their corresponding speed units are useless.
Thanks for the reply! Understood that this is a request, not a bug, therefore not closed.
My preference is purely based on opinion. I could argue that it is backed up by a certain amount of precedence and tradition, in that network speed and network hardware is measured and sold in bits per second and use base 10, so it isn't /just/ our ISPs today that like to see small units to give big values. My first 56K modem did in 1999. My AC1900 Wi-Fi card does today. I think that goes back to the advent of computer networking.
Irrelevant, but interesting: Living in the UK, there's a tradition and precedence for imperial measurements, but a law that states most things for sale must show its mass or dimensions in metric, if not both. Clothing sizes, draught beer, cider and perry, and milk in returnable bottles may be sold in imperial. This causes confusion and (for political or patriotic reasons) people will refute that metric or imperial exist and feel angry or threatened when they see the unit they don't like! I see the beauty and simplicity of metric, but I still order beer by the pint. That's twenty percent bigger than a US pint, mind.
I've found (and changed) the option in Steam to show speeds in bits. No idea if they're using base 2 or base 10.
Until someone gets the entire networking industry to change to IEC units, there will always be an argument for showing the speed in bits, in relation to the network's capabilities, not the file being downloaded. It is always nice to have both. I feel that with torrents, when the speed of a download can be so variable, it is more useful, to me, to see it in bits. I don't look at download speed in browsers since it is almost always at my ISP's cap, 110mbps (about 13MiB/s) and only varies when the serving website is under load. My upload speed is 10 mbps or 1.19 MiB/s. FTTC with copper co-ax over the last 100 metres or less.
This exercise has taught me two things - this is the first time I've ever been bothered to calculate my ISP's speed in IEC, and also, I read that audio and video data rates are in SI, when you're talking about the quality of an mp3, for example.
I totally agree that it's much better to use bps. Right now to know how much bandwidth qBittorrent is using I have to be converting their units to bps, I know what the bandwidth in bps of my internet connection is, it's the unit all ISPs use to offer their connections. And if I make a measurement of my real Internet speed on any website of this type the units are also shown in bps. But if I want to put limits to the speed of qBittorrent I have to be using a unit converter. I don't understand this decision to use a non-standard type of unit. Perhaps it would be better to allow the user to choose the units he wants to use.
Forgetting the whole IEC vs SI debate... (My vote would be just leave it all as IEC to keep code changes minimal, the numbers won't be that far off.)
I would also like to see something like just a simple checkbox in the menu to display network values as bits (vs the default of bytes).
The config files would remained untouched and always configured in their current KiB format.
The only place where additional checks would be needed is when adjusting bandwidth through the menus (either globally or per-torrent or wherever else the option may exist), a choice would have to be made to either leave it as-is (always show KiB) or do some conversion back & forth to match the user preference (more work and greater chance to introduce bugs).
Showing speeds in bits per second implies a level of precision that qBitTorrent simply doesn't have.
Cache and RAM are measured in IEC bytes (binary prefix, KiB, MiB, ...)
Yes, because they naturally come in powers of two because of binary addressing.
so storage should use the same units
No, storage comes in arbitrary sizes, and so should be measured in decimal units like kB, MB, GB.
A 10,000 byte file is most logically represented as "10 kB", just as a 2,000,000,000,000 byte drive is best represented as "2 TB".
In SI, the different prefixes are easy to convert between, allowing for easy estimations like "how many 100 MB files will fit in this 2 GB partition". IEC units require doing calculations when converting between prefixes.
2 TB = 2,000 GB = 2,000,000 MB
2 TiB != 2,000 GiB != 2,000,000 MiB
This is why SI prefixes based on 1000 are used in the metric system that most people are familiar with from everyday life.
Thus, storage manufacturers are just wrong in using SI bytes
No, they are correct in using SI bytes, which is the most logical units to use for sizes that are arbitrary.
(they do it for marketing anyway)
No, they don't. It really irks me as an engineer when people repeat this urban legend about drive companies using standard engineering units and claiming they're being "intentionally deceptive", just because Microsoft uses the same units in a non-standard way. Drive manufacturers measured this way since before Microsoft even existed, and I don't believe anyone ever intended it to be deceptive or did it for marketing reasons.
FYI Windows, in its infinite wisdom, uses IEC bytes but displays SI prefixes.
Windows is wrong, and is the ultimate source of all this confusion.
macOS and Ubuntu correctly measure file sizes using SI prefixes, and software like qBittorrent should, too.
Since storage is best measured in IEC bytes
No, storage is best measured in SI bytes.
it follows that IEC bytes per second is the most useful and relevant unit for a file transfer program.
No, SI bytes should be used for file sizes, and SI bytes per second should be used for file transfer.
As you might guess, given this reasoning, my opinion is that SI ("8 bit") bytes (decimal prefix, KB, MB, ...) and their corresponding speed units are useless.
They are the most logical units to use for file sizes, storage capacities, and network rates. (And the standard says that kilobytes are written "kB", not "KB".)
See 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).
Someone said:
...just leave it all as IEC to keep code changes minimal, the numbers won't be that far off.
That is not true. My connection speed is approximately 930 Mbps (Mbit/s). This is the unit displayed by any speed measurement web/app. I have to convert this unit to KiB. It's the only unit allowed to limit speed in qBittorrent.
930 Mbit/s = 113525 KiB/s
I think the numbers are quite far apart.
The conversion to the most optimal unit should be done by qBittorrent. And yet the speeds in options/shown should be standard for this "Mbit/s" and "Kbit/s".
The changes in the code to make a unit conversion is minimal and yet it would allow us to use more user friendly units.
@endolith
You raise some valid points, and I think I might be convinced that SI should be the default.. I did not know about https://wiki.ubuntu.com/UnitsPolicy#Correct_basis, and it was an interesting read. It made me realize I may be too biased by my own workflows and use cases for my reasoning to be fair about this matter:
- Alice does not know much about computers. She is familiar with the SI prefix system (1 kg = 1000 g, 1 km = 1000 m). She quickly understands that 1 kB is 1000 bytes.
As another similar example, suppose you have 10 files 10 KiB each; this is not the same number of bytes as 1 MiB / 10, but most users would probably expect it to be.
- Bob uses Ubuntu and Windows. He wants to see the same numbers for file sizes in Nautilus as in Windows Explorer so that he can simply compare them. Therefore, Nautilus needs to display the file sizes in base-2.
This is somewhat of a contrived example, since it's Windows' fault, but it highlights the importance of choice and consistency:
macOS and Ubuntu correctly measure file sizes using SI prefixes, and software like qBittorrent should, too.
We both agree that Windows is wrong, and that SI should use xB and IEC should use xiB. Windows should absolutely label the units correctly. But, in my opinion, users should always be offered the choice between SI or IEC, even if SI is the default.
No, they don't. It really irks me as an engineer when people repeat this urban legend about drive companies using standard engineering units and claiming they're being "intentionally deceptive", just because Microsoft uses the same units in a non-standard way. Drive manufacturers measured this way since before Microsoft even existed, and I don't believe anyone ever intended it to be deceptive or did it for marketing reasons.
My point is that it just looks like they "look the other way". They know that Windows (the most used desktop operating system by end-users) mislabels storage units. So why haven't they fought that all this time? They know RAM bytes are measured in IEC, but despite this they refuse to report the IEC-equivalent capacity in the packaging. They just print 1 TB = 10¹² bytes in small lettering somewhere in the box (which is enough to be technically considered not deceptive), and leave end-users to find that and do the conversion themselves. But maybe I'm just paranoid about them making a profit out of this mess...
They know that Windows (the most used desktop operating system by end-users) mislabels storage units. So why haven't they fought that all this time? They know RAM bytes are measured in IEC, but despite this they refuse to report the IEC-equivalent capacity in the packaging. They just print
1 TB = 10⁹ bytesin small lettering somewhere in the box (which is enough to be technically considered not deceptive), and leave end-users to find that and do the conversion themselves.
Maybe you meant 1 GB = 10⁹ bytes? Anyone who has 1 (or more!) TB of RAM in a single computer probably has more money than sense. (See Linus Tech Tips on YouTube for examples.)
Hard Drives are the classical example of deceptive capacity marketing, partially due to their still-imperfect nature. Example: A HDD's theoretical raw capacity may be equal or slightly greater than 4 TiB, but due to small manufacturing defects on that particular HDD might have slightly less available than 4 TiB. Microsoft's disk formats (NTFS in particular) uses >10% of the capacity, so the usable capacity as far as Windows sees it might only be 3.9 TB/3.5 TiB.
Maybe you meant 1 GB = 10⁹ bytes?
I actually wanted 1 TB = 10¹² bytes :)
Anyone who has 1 (or more!) TB of RAM in a single computer probably has more money than sense. (See Linus Tech Tips on YouTube for examples.)
Not sure where I implied a scenario where one would have 1 TiB of RAM (or close to it), or how this is relevant.
Hard Drives are the classical example of deceptive capacity marketing, partially due to their still-imperfect nature. Example: A HDD's theoretical raw capacity may be equal or slightly greater than 4 TiB, but due to small manufacturing defects on that particular HDD might have slightly less available than 4 TiB. Microsoft's disk formats (NTFS in particular) uses >10% of the capacity, so the usable capacity as far as Windows sees it might only be 3.9 TB/3.5 TiB.
Sorry, but this is simply wrong. You are misunderstanding the situation. Do you seriously think filesystem metadata would occupy >400 GB (>10% of 4 TB) under any circumstance? I mean NTFS is not perfect, but Microsoft did not make such terrible mistakes when designing it. Plus, if anything, drives actually technically come with more capacity than advertised, but it is not accessible. This is by design, it is overprovisioning to protect you for when sectors go bad. This is transparent to the user and they never claim this extra capacity can be normally used. SSDs make use of this technique to an even greater extent. You'd be surprised by the amount of flash overprovisioning a modern SSD contains..
I guess I misread here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc781134(v=ws.10)?redirectedfrom=MSDN "To prevent the MFT from becoming fragmented, NTFS reserves 12.5 percent of volume by default for exclusive use of the MFT." ...which seems more than 10%.
But the next sentence clarifies: "This space, known as the MFT zone, is not used to store data unless the remainder of the volume becomes full."
SSDs may tend to have overprovisioning, often by a significant margin (like 25%)...but as far as I know HDDs typically do not, which may result in slight capacity differences (typically <1%) for HDDs even of the same brand and rated size.
I think this is going in other directions than the main reason for this petition: Option to show speeds in bps
Microsoft nor the measurements used for hard disks are relevant here so please focus.
uTorrent can be set up to split the speeds into payload and overheads (as far as it's aware of the overheads).
Showing bits per second is more likely to be compared to an internet connection's max speed, so qBitTorrent would need to include at least estimates of its overheads as well.
I think this is going in other directions than the main reason for this petition:
Option to show speeds in bpsMicrosoft nor the measurements used for hard disks are relevant here so please focus.
Indeed. Apologies for that on my part. At the end of the day, regardless of our opinions it is perfectly legitimate to request the option to switch between IEC/SI prefixes and bytes/bits per second.
I have marked all other comments discussing the merits of IEC vs SI and bytes vs bits as "off topic", so they don't clutter the thread as much. I have also slightly edited the OP for clarity.
As always, a PR is welcome for implementing such options.
Really want to show them as Mbps or at least MB/s; It simpler and we can set limits easier that way; So my proposals are:
- At main program windows far right down :arrow_lower_right: show speeds with an icon flat design
and 
- Set global or 2nd limits in one of two mentioned units. Put a decimal separator when entering
Really want to show them as Mbps or at least MB/s; It simpler and we can set limits easier that way;
Yes! Since any reasonable internet connection is marketed in Mbps (megabits per second) or Gbps (for fast fiber lines)...might as well have an option in qBitTorrent to report speeds that way.
MB/s (MegaBytes/second) is helpful too, since file sizes are reported that way. (Well, besides Microsoft confusing MebiBytes with MegaBytes.)
Ideally the option should exist, even if the default is MiB/s. 😊
Although MiB is mainly used for determining file size calculations, it would be nice to have both options when determining network calculations.
This suggestion is on the table for more than 3 years. Is it a problem to add just a few lines of code and make many customers happy?
I've seen this feature mentioned as a really missed in qBittorent on multiple forums, not only here.
Just hoping in here to carry on the discussion. I see potential thread and this is to be continued.
Same here, basically every software that makes you download things show the download speed in bps, I don't see why qBittorrent isn't letting us show it like that. I feel like it's so much easy to implement honestly
Please please add this option. Windows Task Manager > Performance shows in Mbps. So does all my network equipment, my internet provider, etc. Thanks!!
I would love to see my speed in Mbps also. It just makes since as it lines up with all my other displays.
This is a necessary feature, now Steam has switched to displaying download speed in this form, please add the feature
Lots of interest for this feature. There was an attempt in #15261 but it went stale. Anyone want to jump in and spearhead this ?
Wow I'm surprised this isn't an option. I was thinking this would be a simple thing to add.
Probably not new. The way I managed to do it was by using VueTorrent, as there's a simple check to convert it.
