Minor GUI Issue

[sbsnb]

Not sure if this is Asus or Merlin, but probably Asus.

In the QoS GUI, the Upload Bandwidth and Download Bandwidth boxes are labeled with Mb/s (megabits per second) labels.

If you enter 50 in those boxes qos_ibw=51200 and qos_obw=51200.

50 Mb/s generally means 50000 kb/s. I don't think there's an ISP anywhere in the world that is deflating their speed numbers by using Mibits in place of Mbits. For example, you're Comcast and your DOCSIS system supports a maximum theoretical transfer speed of 100,000,000 bits per second. Do you market that as 95 Mb/s or 100 Mb/s? As far as I know it's universally marketed as 100 Mb/s, but if I enter 100 here QoS is going to act like my speed is 104,857,600 bits per second (or 102,400,000 b/s, it's not clear). That might explain why people generally are having to enter speeds 5% below their tested speed (e.g., 95 in this case), because it's converted internally into 99,614,720 bits per second.

 

[ColinTaylor]

Coincidentally I had the same conversation with John about this with his fork about a year ago . He ended up correcting some of the pages in his fork:

374.43_28E5j9527  (31-October-2017) ARM SDK
* CHANGED: traffic: use 1000 bits/Kbit instead of 1024 per telecom standard

374.43_28E4j9527  (28-October-2017) ARM SDK
* CHANGED: qos: use 1000 bits/Kbit instead of 1024 per telecom standard

Just FYI here is the start of the conversation I had with John back then. Note that John's fimware has the option to switch between Mbps and kbps, I don't know whether Merlin's does as well.

The 1k=1000 rule isn't new, it's always been that way for the telecommunications industry. So, for example, a Gigabit Ethernet card is 1,000,000,000 bps. If your ISP says your speed is 10Mbps they mean 10,000,000 bps. It was only programmers that started using 1k=1024 because that's what was convenient for them when addressing memory.

To that end, when talking base 1024, the IEC created the new prefixes Ki, Mi, Gi, etc. See also https://en.wikipedia.org/wiki/Binary_prefix#Data_transmission_and_clock_rates

So it is 1024 that is the "new" standard and with it new prefixes (but they're only used in certain circumstances ).

Anyway, as a programmer I tend to instinctively think in binary. And as many network tools are written by programmers and not telecoms engineers I'm always suspicious of what number base they are using. speedtest.net's help page says it's results are in 1000's (as it should be) and it gives some example figures that back this up. (I'm still not convinced one way or another whether that's true.)

But getting back to the case in hand, what about tc? Fortunately it's easy to find out by looking at the output of the show command. And there's even an -iec option to display the results in 1024 instead of the default of 1000!

Compare the output of these 2 commands:

tc class show dev br0 | grep htb
tc -iec class show dev br0 | grep htb

So, if I set the download bandwidth to 100,000 kbps the webUI displays this as 97.656 Mbps, but look at the tc output

class htb 2:2 root rate 100Mbit ceil 10240Mbit burst 2000Kb cburst 2000Kb
class htb 2:2 root rate 97656Kibit ceil 9765Mibit burst 2000Kb cburst 2000Kb

If I then put in 100 Mbps the webUI converts this to 102400 kbps behind the scenes, and then issue the same tc commands:

class htb 2:2 root rate 102400Kbit ceil 10240Mbit burst 2Mb cburst 2095360b
class htb 2:2 root rate 100000Kibit ceil 9765Mibit burst 2Mb cburst 2095360b

So it is clear from this that tc is using base 1000 by default.

 

[RMerlin]

It's not that simple, since the firmware uses 1024 in various places. Changing this particular instance would break other things elsewhere. Consistency is more important here.