Bandwidth web

[logicog]

This PR is on top of PR #147 and provides the Web Interface for controlling the bandwidth

[vDorst]

Testing both BW pr's.
I can enable it in the web but not disabling it.

cmd is send bw in 2 off
But that seems not to be accepted.
It return this usage message.

usage: bw [in|out|status] <port> [<hexvalue>|off|drop|fc]

Also status is not working.

> bw status
usage: bw [in|out|status] <port> [<hexvalue>|off|drop|fc]

[logicog]

Fixed the underlying PR and rebased to latest main.

[vDorst]

thanks, but it seems to break when

Reproduce

• Enable port 1
• kbit: 100
• fc: don´t care
  Apply the value.

Commands send:

bw in 1 03e8
bw in 1 drop
bw out 1 off

• Refresh the page
  You see that the bandwidth value jumps back to 62
• Try to change the bandwidth value with by typing or arrow-buttons next to the value.
  It changes back every second.

bandwidth.json:

[{"portNum":6,"iLimited":0,"iBW":"0fffff","iFC":1,"eLimited":0,"eBW":"0fffff"},{"portNum":1,"iLimited":1,"iBW":"00003e","iFC":1,"eLimited":0,"eBW":"0fffff"},{"portNum":2,"iLimited":0,"iBW":"0fffff","iFC":0,"eLimited":0,"eBW":"0fffff"},{"portNum":3,"iLimited":0,"iBW":"0fffff","iFC":1,"eLimited":0,"eBW":"0fffff"},{"portNum":4,"iLimited":0,"iBW":"0fffff","iFC":1,"eLimited":0,"eBW":"0fffff"},{"portNum":5,"iLimited":0,"iBW":"0fffff","iFC":0,"eLimited":0,"eBW":"0fffff"}]

[logicog]

thanks, but it seems to break when

I think I know what is going on. The web-page is a bit more complex than some of the other controlling pages as it even takes changes done in the CLI into account while the web-page is open. It polls the bandwidth status constantly and updates the page until you start editing one of the ports. It seems it does not catch all the ways one can start editing, namely clicking into the bandwidth number field. At one point I thought about that, but then forgot to implement it, as it is a bit more complicated than when you start by checking the Limit checkbox. I'll fix this.

[logicog]

I fixed the above and rebased. There was another bug which made the display of the Flow Control state incorrect.

[vDorst]

I see that after refresh using 'F5', changing the bandwidth issue is still there.
Is that easy to fix?

[logicog]

I see that after refresh using 'F5', changing the bandwidth issue is still there. Is that easy to fix?

I don't think there is much that can be done. We need state to be recorded somewhere, and it is in the browser while you edit the configuration. If you reload clearing the cache, it also clears the state. But I doubt CTRL-F5 is common when using a such a front-end. This is more part of stress-testing it.

[logicog]

I rebased to main and cleaned up the commits.

[vDorst]

SFP in limited to 20000 kbit

rene@ws ~> iperf3 -c 192.168.10.20
Connecting to host 192.168.10.20, port 5201
[  5] local 192.168.10.33 port 47602 connected to 192.168.10.20 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   512 KBytes  4.19 Mbits/sec   80   14.1 KBytes       
[  5]   1.00-2.00   sec   256 KBytes  2.10 Mbits/sec   54   14.1 KBytes       
[  5]   2.00-3.00   sec   384 KBytes  3.15 Mbits/sec   54   14.1 KBytes       
[  5]   3.00-4.00   sec   256 KBytes  2.10 Mbits/sec   46   19.8 KBytes       
[  5]   4.00-5.00   sec   256 KBytes  2.10 Mbits/sec   46   12.7 KBytes       
[  5]   5.00-6.00   sec   384 KBytes  3.14 Mbits/sec   47   12.7 KBytes       
[  5]   6.00-7.00   sec   256 KBytes  2.10 Mbits/sec   48   12.7 KBytes       
[  5]   7.00-8.00   sec   256 KBytes  2.10 Mbits/sec   61   14.1 KBytes       
[  5]   8.00-9.00   sec   384 KBytes  3.15 Mbits/sec   55   14.1 KBytes       
[  5]   9.00-10.00  sec   256 KBytes  2.09 Mbits/sec   44   14.1 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  3.12 MBytes  2.62 Mbits/sec  535            sender
[  5]   0.00-10.00  sec  2.88 MBytes  2.41 Mbits/sec                  receiver

On RJ45 same limit 20000 kbit

iperf Done.
rene@ws ~> iperf3 -c 192.168.10.20
Connecting to host 192.168.10.20, port 5201
[  5] local 192.168.10.170 port 41874 connected to 192.168.10.20 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  2.88 MBytes  24.1 Mbits/sec    1   99.0 KBytes       
[  5]   1.00-2.00   sec  2.25 MBytes  18.9 Mbits/sec    0    120 KBytes       
[  5]   2.00-3.00   sec  2.50 MBytes  21.0 Mbits/sec    0    130 KBytes       
[  5]   3.00-4.00   sec  2.12 MBytes  17.8 Mbits/sec    0    139 KBytes       
[  5]   4.00-5.00   sec  2.38 MBytes  19.9 Mbits/sec    1    112 KBytes       
[  5]   5.00-6.00   sec  2.25 MBytes  18.9 Mbits/sec    1   94.7 KBytes       
[  5]   6.00-7.00   sec  2.12 MBytes  17.8 Mbits/sec    0    110 KBytes       
[  5]   7.00-8.00   sec  2.50 MBytes  21.0 Mbits/sec    0    123 KBytes       
[  5]   8.00-9.00   sec  2.25 MBytes  18.9 Mbits/sec    0    136 KBytes       
[  5]   9.00-10.00  sec  2.25 MBytes  18.9 Mbits/sec    2    113 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  23.5 MBytes  19.7 Mbits/sec    5            sender
[  5]   0.00-10.05  sec  22.8 MBytes  19.0 Mbits/sec                  receiver

On RJ45 same limit 20000 kbit but without FC

Connecting to host 192.168.10.20, port 5201
[  5] local 192.168.10.170 port 57126 connected to 192.168.10.20 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   512 KBytes  4.19 Mbits/sec   97   17.0 KBytes       
[  5]   1.00-2.00   sec   640 KBytes  5.24 Mbits/sec   56   8.48 KBytes       
[  5]   2.00-3.00   sec   640 KBytes  5.24 Mbits/sec   48   12.7 KBytes       
[  5]   3.00-4.00   sec   640 KBytes  5.24 Mbits/sec   46   12.7 KBytes       
[  5]   4.00-5.00   sec   384 KBytes  3.15 Mbits/sec   37   12.7 KBytes       
[  5]   5.00-6.00   sec   512 KBytes  4.19 Mbits/sec   47   12.7 KBytes       
[  5]   6.00-7.00   sec   512 KBytes  4.19 Mbits/sec   41   12.7 KBytes       
[  5]   7.00-8.00   sec   768 KBytes  6.29 Mbits/sec   55   12.7 KBytes       
[  5]   8.00-9.00   sec   640 KBytes  5.24 Mbits/sec   44   12.7 KBytes       
[  5]   9.00-10.00  sec   512 KBytes  4.19 Mbits/sec   48   12.7 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  5.62 MBytes  4.72 Mbits/sec  519            sender
[  5]   0.00-10.00  sec  5.38 MBytes  4.51 Mbits/sec                  receiver

I had not expected that without FC the bandwidth limiting is so off.

[vDorst]

Set 200000 in egress in web interface.
cmd = bw out 5 30d40

But after refresh it shows 3200000.

> bw status 5
ingress: disabled
egress: enabled: 0x030d400

strange that 20000 is just fine.

[logicog]

I had not expected that without FC the bandwidth limiting is so off.

There are really a lot of retries. In my experiments the number was much lower. Maybe 10-20 retries per 1 second interval on 2.5GBit Ethernet slowed down to 4 MBit. This will depend a lot on the driver of the NIC and also TCP settings, such as the amount of back-off when a packet is dropped. FC is incredibly important for good performance when the network path has not everywhere the same bandwidth.

[logicog]

strange that 20000 is just fine.

There is a bug in the parser for hex-numbers. It works only when the hexadecimal number has an even number of digits. 30d40 has 5 digits and does not work. I noticed this at the beginning when testing and wanted to fix this either in the web-interface or in the parser, but forgot. Setting 030d40 would work. Will look into it tomorrow.

[logicog]

I decided to fix the bug at the root and corrected atoi_hex so that it now correctly parses hex numbers with an odd number of digits. BTW: I am sure this took about 10 times longer than fixing the javascript to add a leading 0 when there was an odd number of digits in the conversion result of the number to hex.

[vDorst]

Thanks for fixing my mistake in that code.... fixes 7e729c6