It's consistent, has happened everytime I have used it and happened again those three times I gave it a test. It gave me the results below:
Download 131202kbps / Upload 130878kbps
Download131283kbps / Upload 130437kbps
Download 68292kbps / Upload 27936kbps
cat /tmp/qosmate_auto_setup_output.txt
Starting qosmate non-interactive auto-setup...
Stopping qosmate for accurate speed test results...
Stopping service qosmate...
Error: Could not process rule: No such file or directory
delete table inet dscptag
^^^^^^^
Reloading network service...
Detected WAN interface: eth0
speedtest-go is already installed. Using it for the speed test.
Running speed test... This may take a few minutes.
Speed test results:
Download speed: 75.88
92.52 Mbit/s
Upload speed: 31.04
38.43 Mbit/s
QoS configuration:
DOWNRATE: 68292 kbps (90% of measured download speed)
UPRATE: 27936 kbps (90% of measured upload speed)
No gaming device IP added.
Configuration updated. New settings:
option WAN 'eth0'
option DOWNRATE '68292'
option UPRATE '27936'
Auto-setup complete. qosmate has been configured with detected settings.
To apply these changes, please restart qosmate by running: /etc/init.d/qosmate restart
root@routteri:~# service qosmate auto_setup
Starting qosmate auto-setup...
Stopping qosmate for accurate speed test results...
Stopping service qosmate...
Error: Could not process rule: No such file or directory
delete table inet dscptag
^^^^^^^
Reloading network service...
Detected WAN interface: eth0
Do you want to run a speed test or enter speeds manually? [test/manual]
test
This will run a speed test to configure qosmate. Do you want to continue? [y/N]
y
speedtest-go is already installed. Using it for the speed test.
Running speed test... This may take a few minutes.
Speed test results:
Download speed: 74.27
92.03 Mbit/s
Upload speed: 31.60
39.06 Mbit/s
QoS configuration:
DOWNRATE: 66843 kbps (90% of measured download speed)
UPRATE: 28440 kbps (90% of measured upload speed)
Would you like to add a gaming device IP for prioritization? [y/N]
No gaming device IP added.
Configuration updated. New settings:
option WAN 'eth0'
option DOWNRATE '66843'
option UPRATE '28440'
Auto-setup complete. qosmate has been configured with detected settings.
To apply these changes, please restart qosmate by running: /etc/init.d/qosmate restart
root@routteri:~# echo $?
0
If you’re using sqm-scripts with simplest, then HTB is used as the shaper. It’s possible that HTB requires fewer resources than HFSC, and the lower performance of your router might have a greater impact when using HFSC. For example, Cake would require even more resources than both.
Could you quickly share your configuration so we can rule out whether ACK limiting in the download direction is affecting your bandwidth?
cat /etc/config/qosmate
I’ll look into the speed test issue later when I have more time.
It is clearly capped by CPU resources. IF any QoS setting improves over A 150/150 with offload go for it, but I doubt it is likely to get any improvement.
Ok, thanks for the analysis. I knew it's not a power house but I was just wondering why the discrepancy between what I get down and up. I'd happily have the values switched over.
You have to do measurements over NAT,(iperf says 150/150 - enable qosmate, check iperf again and proportionate down) local ones may not represent whats achievable in normal data path.
@sandberg I think what @brada4 means is that auto-setup is not the best method of checking effective bandwidth, because this way your router has to source or sink the data, which loads its CPU, so the measured result does not represent the effective bandwidth you will be getting in normal use. Rather, measure the effective bandwidth using iperf on a machine connected to your LAN.
@Hudra check new PR#35, now OpenWRT 22 derivatives can be supported by deoptimizing dscp | 0x80 into value map as proposed by affected user passing by.
For everyone's information: Once I/we have implemented the changes, there will be a legacy branch in the QoSmate repository, where OpenWrt versions < 23.05 (with nftables) will also be supported.
@sandberg To rule out that ACK rate limiting in the download direction is reducing your bandwidth, please try setting the "ACK Rate" to 0, then run your tests again and let me know if anything changes. If not, I’m afraid your router might not be powerful enough. In that case, I suggest the following options:
Stick with sqm-scripts.
Use QoSmate with HFSC, go through the fine-tuning process, and accept some bandwidth loss. Details: Fine-Tuning Process (Optional).
Upgrade to a newer device.
Regarding your issues with the auto-setup: I looked into it and discovered a small bug that likely crept in during recent code optimizations. The auto-setup function checks which speed test tool is installed. If none is found, it installs either speedtest-go or python3-speedtest-cli based on available space.
When using speedtest-go (which was your case), the parser was capturing both lines of the speedtest output, leading to an invalid format in the output file. I’ve added a head -n1 command to capture only the first speed value, which matches the expected format for the UI. So this issue should now be fixed after updating to the latest version.
IIUC qosmate defaults to copyiung the egress DSCP mark to the conntrack database and then to ingress packets of the same connection/flow. This means these will affect which of cake's priority tins a packet will land up in.
If you configure wash for ingress then inside your lan you will only see DSCP 0 for packets coming from the internet, which might or might not be what you want.
If you configure wash for egress your ISP is not going to see your internal DSCPs but just CS0, it really depends on your ISP what is better, but often all CS0 is preferred by end users, but only you can know/test on your own link.
Please show the packet capture... packets coming from your router and not the internet might still be marked, only traffic that goes through cake will be washed... so what shaper are you using cake or HFSC?
Now, I am really confused about what you are running and what you are seeing ;).
Maybe help me out and show me:
a) the output of tc -s qdisc (so I can see the active cake confoiguration and also whether some other shapers might be active).
b) a bit of your packet caputers that show packets on your br-lan with unexpected DSCP values.
What do you mean with this? That you see CS6/7 on packet captures or that you have packets in cake's Voice tin?