I’m using the beta firmware for the flint 2 (4.8.99) trying SQM and it seems like the fields in the SQM menu are mapped backwards. The upload field is controlling download and the download field is controlling upload…
Am I crazy or are the SQM menu fields flipped.
For instance when I set upload field to 25Mbps and download field to 420Mbps all my my waveform and speed tests results max out at 25Mbps download??? If I set upload field in the SQM menu to 420Mbps and download to 25Mbps then my speed test and waveform results are 420Mbps+
Something seems backward in the SQM menu can someone take a look at it?
Now I’m wondering if my brume 3 has the same issue but my internet speeds at the home where that is are fiber internet and symmetrical dl/upload speed unlike this home with cable internet and 425dl/25upload speed so that’s how noticed?
Yes, the upload/download field mapping is currently reversed in the current firmware version of SQM.
We are aware of this issue and will fix it in a future official release.
For now, please temporarily configure it in reverse.
Thanks for your understanding.
Well its to technically backwards? I noticed that the SQM is applied to the LAN interface and not the WAN interface. @will.qiu Is this what you mean about later fix, will it be applied to WAN interface in future as LAN is not the correct place to apply this.
In addition I noticed that there is some kind of conversion that takes place when you enter the bandwidth settings which configure SQM in a suboptimal way. e.g. The bandwidth configured in SQM is higher than that configure in the GUI. Also no link-layer adaption for overhead is applied.
In my case on the Brume 3 MT5000 SQM performance is reduced from what the platform should be capable of.
Apply SQM manually using UCI to the WAN interface improves upstream SQM performance considerably as it is now processing it as outbound traffic which better distributes the TX queue across CPU cores. When on the LAN interface the single Rx queue causes a CPU bottleneck that reduces performance.
When on the WAN interface this still occurs but downstream can be disabled to avoid this (as most of the time SQM is used to resolve upstream issues more than downstream)
Because our routers (not just the MT5000) typically support multiple WANs, after careful consideration the product managers and R&D team decided to apply SQM on the LAN interface. This way, when the upstream WAN interface changes, users don’t need to manually adjust settings or run into unexpected issues.
In the GL UI, rates are shown in Mbps, while in LuCI they are shown in Kbps, so the numbers may look different (they are automatically converted between the two units).
The SQM settings in the GL UI are intended to provide a simple, out-of-the-box configuration. For any advanced or more customized use cases, we still recommend configuring and using SQM directly in LuCI.
@will.qiu I have indeed needed to use the CLI, the SQM performance using the default GUI configuration on the LAN interface seriously degraded potential SQM performance due to additional CPU load. Configuring more correctly on the pppoe-wan interface via the CLI offers significant performance improvement and CPU usage reductions.
Regards the Mbps vs Kbps, there seems to be some issue with the conversion? If this is the conversion this should be doing a straight x1000 to take Mbps to Kbps but in fact this is not the case.
567.3828125 Mbps in the GUI converts to 581000 Kbps in the CLI because x1024 has been used to covert incorrectly (This would be used in Mbyte/KByte in storage/data terms but not MBit/KBit in network throughput terms). This causes the values set in the SQM scripts to be higher than they should be.