I have sqm setup following the guide in the documentation. Unfortunately it has not fixed my bufferbloat issues. I would post a report here but dslreports for some reason is not measuring bufferbloat (the area is just blank??)
So to test I just put up a download that maxes my connection then ran some ping tests and launched a few online games. The pings were horrendous, literally unplayable! Here is the setup
Connection - dsl
Modem sync speeds - 3550kbps down/ 640 kbps up
Speed test - 2.97mbps down / 0.56mbps up
Modem - billion 7800 xl
Router - tp link wdr 4300 v1 (using latest lede firmware)
I wasn't able to get bridge mode to work on the modem so I just connected it as is to the router. Followed the guide instructions for using cake model and piece of cake. 44 byte overhead etc all that for dsl.
Not getting good results
I tried limiting from 95% of my speed all the way down 50% but it still didn't help. I also tried different queue systems like fq codel, simplest qos and all other combinations available there. Also tried using a different overhead setting number.
There is no difference in using any of them. I have also tried using it on an interface other than the wan, but it really screws up the router hard (speed gets limited to like 0.55mbps download. It's weird)
Ah, let's see, maybe I can help undertsand what is going on.
I would need the following pieces of information:
tc -d qdisc
tc -s qdisc
which ISP you are using.
Weird, you culd try to run their command line interface (see https://www.dslreports.com/forum/speedtestbinary) to see how this works. (Side note on mobile browsers the bufferbloat plots do no show up at all, but will do with a desktop browser or if "request desktop site" is selected (firefox)) But just post a link to your dsl reports never the less it might help diagnosing why the bufferbloat plots seems missing...
This effectively means you are running under a double NAT situation, not ideal, but also not a real deal breaker (if your primary modem router allows to configure port redirects that is).
Well at 50% it really really should; how did you assess that it does not work?
I would really recommend pice_of_cake/layer_cake for your use case.
Overhead too small will cause residual bufferbloat, especially with small packets, overhead to big will simply decrease your available bandwidth. Unfortunately setting the overhead to low can be masked by setting the shaper a bit lower...
Not really, the shaper really affects an interface's ingress (called downloading in the GUI) and egress (uploading in the GUI) configuration, but that direction is only aligned with internet down- and uploading on the wan interface, on all internally facing interfaces (LAN/WLAN) the interface directionality is reversed in relation to the internet; the 0.55 Mbps seem to match your upload speed from the speedtest with the shaper on the wan interface so probably reflects your egress shaper setting.
Let's see whether we can actually fix your situation...
I tried my own testing again, put up a download, youtube video, download from phone and that really bogged the internet down hard. Web pages were taking forever to load. Here is a shot of the graph when it was slow
I think i know whats the problem here, but not sure of the solution.
The speedtests never seem to push towards the modem sync speed. Which is why the bufferbloat appears to be low there showing the A rating. However if i put up downloads and start doing more bandwidth demanding things on other devices also, the speeds look like they reach almost near the modems sync speed as seen in the screenshot. This is where the internet really slows down to a crawl.
So one thing to consider is that your link is really slow, sending a packet upstream takes around:
1000 * (32538) / (6401000) = 21.2 ms
and on downstream:
1000 * (32538) / (35501000) = 3.8 ms
so on a fully loaded link (in both directions) you will see an average latency under load increase of >= 25ms. SQM can not really do wonders if there is a chronic bandwidth under supply...
That looks pretty dire, especially the uplink; I guess just having a single flow on the uplink is just painful...
But mostly the quality score "F" seems cause for concern.
I have a hunch that per-interal-host-IP isolation might help a bit by at least trying to isolate the individual hosts a bit better (but with your up- and downlinks you can expect no wonders...)
Indeed the line is very slow, which is why I want to squeeze out what little performance I can to keep it as smooth as can be.
Would you be able to answer what is sending the connection into overdrive? I have clear rules set to limit it to 2900kbps but if you look at the performance screen shot it is going well over the limit. Something is perhaps overriding it?
That should give you per-internal-IP isolation which should be a bit easier to understand than the default triple-isolate. Also, if you have not already done so, follow the instructions on https://github.com/moeller0/ATM_overhead_detector/blob/master/ATM_overhead_detector.m to empirically deduce the real overhead on your link (please post the two resulting images here in this thread).
One more question, to your knowledge is your ISP using PPPoE or PPPoA?
Once we have the overhead accounted for correctly, I would propose to try to up the egress rate up to 99% of the modems sync rate (which will work unless your ISP also uses a shaper at the BRAS/BNG level) and then iteratively try to figure out a decent downstream shaper setting.
I have done the first part for /etc/config/sqm:, but i am not sure of the atm overhead detector you are talking about. There are so many lines of command and lingo i have never heard of. I am not sure what to do
Ah sorry, I linked to one of the code files accidentally, I had intended to link to https://github.com/moeller0/ATM_overhead_detector which should give reasonable instructions on how to accomplish the measureents instead. Maybe that will be actually useful.
Okay, that already restricts potential values for the overhead...
That is important. When packets need to be re-sent due to line errors, there is severe latency. Also the speed is uncertain. It's never going to work very well. Raw speedtests (direct to the modem with no other usage) should show the rate you are subscribed for.
Yeah I have tried many settings for the overhead thing. There is no difference.
If I put a download on it just kills the internet pretty much. Is there possibly a setting within the firmware to automatically detect downloads and make sure that it doesn't use more than 90% of the bandwidth?
Oh, then there is something wrong, underestimating the overhead (and/or overestimating the bandwidth) should increase the measurable bufferbloat under saturating loads noticeably; but I guess since you already suffer from bufferbloat nothing would change from your perspective (maybe the underlaying root cause of the observed bufferbloat).
But @jwoods seems to be on to something, how about you have a look in your modems error counters before ans after an extensive speedtest. By the way both of your speedtests show an extreme number of retransmits that might explain the observed behaviour somewhat. Does your ISP use G.INP by any chance?
I dont think so, thats a type of line profile isn't it?
On that subject, do you think my line profile could have an affect? Internode lets me use different profiles from their website letting me choose how i want to use it. They range from "very reliable" to "very fast" and also some "low latency" profiles. They also come in ADSL or ADSL2+ types.
I currently use ADSL2+ low latency. Low latency profiles turn off interleaving. Could that be an issue?