That is what I do. The script in startup is running the show. See what your bufferbloat looks like now.
good for my download, first time I have under 40ms but still some problem with upload
1 Like
Iād try 8Mbit on the upload side. Moving from gigabit LAN to 10mbps is rough on bufferbloat.
# Shape egress traffic to 8 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 8Mbit burst 1Mb
tc qdisc add dev eth0 parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default
when I change something in local start up , after save, I have to restart something like I did with sqm ?
/etc/init.d/sqm restart
I like that script in my startup script (/etc/rc.local) so that when the router powers up or when I upgrade the settings are loaded.
Restart being - briefly unplug the power cord or hit the power button.
You can run those commands in a shell for testing and skip the restart (wait to āget it rightā before you put it in your startup script)
to be sure it is running, what code I need to put in ssh? instead of restart the router, sorry for my questions 
IM learning
thanks
I havenāt played much with the statistics modifier. At a minimum you should see good dsl reports results. Here is the write up on the tc command -s feature:
1 Like
last thing, the configuration you gave me as start up script, I see : ''eth0'' it is ok even if on my router '' overview Gui'' I see '' Device:** Software VLAN: "eth0.2" ??
still problem to control bufferbloat on upload....idea?
I tried 9,8 and 7 mbps as upload, maybe some tweaks?
Try a lower burst rate on the upload side. Your ISP probably doesnāt like sudden bursts of 1Mbit and is giving you some lag.
# Shape egress traffic to 7 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 7Mbit burst 100k
tc qdisc add dev eth0 parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default
If 7 works you could try 8 or 9. 
Weird, i made the changing and lost wifi after reboot.
I removed your code and wifi is back, weird cause with the other script earlier, the wifi was ok
I made a typo - the last line say nssfq_codel - Iāve edited it above.
1 Like
still not easy, maybe worse
thanks for your time btw..
Yikes. Iām out of tricks. The tc script is using all the fq_codel defaults - not sure if adjusting the quantum or those subtle tweaks are going to help much.
Iād try the combo of burst and rate that gives you the best results or Iād consider not running SQM. Maybe someone else has some ideas for special combos that work well.
1 Like
Someone in another post said that, maybe it could help my case... I have 10 mbps upload?
if your upstream bandwidth is 10Mbps, cap it with NSS Qdisc as well, or your buffer float will also be affected.
The rate is your cap. Iād experiment with higher and lower rates (even 10mbps).
Make sure when you change settings that you are deleting the settings or restarting your router (you canāt add devices on added devices)
tc qdisc del dev eth0 root
Use this to check your current settings:
tc qdisc show dev eth0
Iād set your burst to 500kbit or 1mbit.
9 was your best, maybe 8.5 with a smaller burst will be a happy spot.
# Shape egress traffic to 8.5 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 8500kbit burst 500kbit
tc qdisc add dev eth0 parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default
How about you size the burst such that it can be cleared in, say 1millisecond (as starting value), so at 10 Mbps, that would be 10Mbps/1000 -> 10 Kbps, or 100Kbps to allow for 10ms?
The point is that after admitting a burst to the device driver, the next packet will have to wait for the full burst to have been transmitted, and if burst is set too high that might already allow for nasty latency spikes....
That makes sense. I agree his burst should be lower. 1mbit had a nasty spike.
so burst at 500kbit, would be better than 1mbit?
I will in few minutes.
btw, with that : tc qdisc del dev eth0 root I thought it would wipe my rc.local script, but it is not. in ssh, yes, but in rc.local the script was still there...
1 Like
It just wipes the current settings. It does not change what is in rc.local (when you wipe the settings - what is in rc.local wonāt be loaded until next time you restart).
500kbit means that if you āempty out the bucketā youāll lose ~50ms (a little more than that) at your speed limit as per @moeller0 calculations above. Hope it gets you good results!