Can Qbittorrent display graphically Mib or Mb, (Megabits) vs MiB or Megbytes? Do I just multiply by 8 the current display to get megabits?
thanks!
Speed in bits vs Bytes?
-
Switeck
Re: Speed in bits vs Bytes?
To convert qBitTorrent's speed in Megabytes/second, it's probably closer to multiply by 9-10 to get megabits/second bandwidth use.
Note that doesn't count ACKs and other traffic going the opposite direction!
When downloading at 1 Megabytes/second, roughly 100 Kilobytes/second (1/10th the download) is uploaded the other direction to handle all the torrent communications.
Raw TCP/IP connections using TCP would only have about 2-3% overheads going the other direction, but BitTorrent traffic overheads are often much higher with 5% overheads being the minimal case and seldom seen in practice.
Note that doesn't count ACKs and other traffic going the opposite direction!
When downloading at 1 Megabytes/second, roughly 100 Kilobytes/second (1/10th the download) is uploaded the other direction to handle all the torrent communications.
Raw TCP/IP connections using TCP would only have about 2-3% overheads going the other direction, but BitTorrent traffic overheads are often much higher with 5% overheads being the minimal case and seldom seen in practice.
-
Switeck
Re: Speed in bits vs Bytes?
"Is it possible to switch the display from Bytes per second to Bits per second?"
In theory -- as an estimate, yes.
As precise values, no.
Overheads for BitTorrent traffic can vary immensely from moment-to-moment, depending on the arrival of DHT, PEX, HAVE messages, and many other things.
Packet loss, which is often only determined very indirectly can skyrocket overheads.
Final bits-per-second speeds might be somewhat measurable in terms of "goodput" (useful bits sent+received successfully) ...but only seconds after the fact, due to endpoints such as peers+seeds+trackers responding back with ACK messages and confirmation of data.
The Operating System's networking layers obfuscates/hides just how much wasted bits occur sending/receiving networking packets. Your ISP/s still have to move those bits though. An upstream device such as monitoring software built into a router might be able to get closer to the real bits-per-second costs, but even it can miss extra bit and packet costs from crazy tunneling and short-lived 1-way (traceroutes) to or from distant peers, seeds, and trackers.
Bits vs BYTES doesn't really matter because qBitTorrent v4.1.5 is currently TERRIBLE at per-second speeds, as shown by the saw-toothed speed graphs it generates:
https://qbforums.shiki.hu/index.php/topic,6438.0.html
In theory -- as an estimate, yes.
As precise values, no.
Overheads for BitTorrent traffic can vary immensely from moment-to-moment, depending on the arrival of DHT, PEX, HAVE messages, and many other things.
Packet loss, which is often only determined very indirectly can skyrocket overheads.
Final bits-per-second speeds might be somewhat measurable in terms of "goodput" (useful bits sent+received successfully) ...but only seconds after the fact, due to endpoints such as peers+seeds+trackers responding back with ACK messages and confirmation of data.
The Operating System's networking layers obfuscates/hides just how much wasted bits occur sending/receiving networking packets. Your ISP/s still have to move those bits though. An upstream device such as monitoring software built into a router might be able to get closer to the real bits-per-second costs, but even it can miss extra bit and packet costs from crazy tunneling and short-lived 1-way (traceroutes) to or from distant peers, seeds, and trackers.
Bits vs BYTES doesn't really matter because qBitTorrent v4.1.5 is currently TERRIBLE at per-second speeds, as shown by the saw-toothed speed graphs it generates:
https://qbforums.shiki.hu/index.php/topic,6438.0.html