I haven't called my ISP, but all research I've done from people who have the same modem say that's the case.
So if that is the case, I doubt you're going to make any headway on your issue until you can get the cable modem configured in bridge mode.
you need sqm on whatever links are congested. If your wired link to your ISP (on
eth1) is congested, it will have problems no matter how you are connected to the
router (wired or wireless). This is why we need to test wired and get that
working first.
When you are wireless, you have two network hops, the wireless hop to the
router, and the connection to the Internet from the router (via eth1)
so your traffic to/from the Internet will still be going through eth1 and be
affected by this config.
So what do you want me to do @dlang ?
As the OP said, wired access will never be used in production, so I'm not sure how productive a wired test will be...
Then there is this...wireless is turned on at the router, and the cable modem.
The OP cannot get access to the cable modem GUI to turn it off.
while it's not ideal, you should be able to operate with the router as-is.
your new router should provide DHCP/DNS/etc for your internal network and it ill
use the cablemodem for it's access to the outside world
This extra level of indirection is going to mean that you will have to set the
inbound numbers lower to make things work well (sacrificing some bandwidth to
get more stability)
it sounded like you had some settings that gave you reasonably good results,
right?
If so, use those settings and see what's happening with wifi connections
David Lang
What do you mean by "see what's happening with wifi connections"?
wired tests eliminate any problems caused by the wireless link, and since any
wireless tests go through the same Internet link as the wired tests, if you
start off by doing all your tests wirelessly, you don't know if you need to look
at fixing your wireless connection or your upstream connection.
If you start off doing wired tests to work on and fix your upstream connection,
then when you test through wireless, you know that you don't have upstream
connection problems and only have to look at wifi issues.
you started off complaining about performance when you were using wifi.
It sounds like you've got some parameters that work fairly well for your wired
tests, and have significantly improved things for you.
So leave those improvements in place and test over wifi to see if things have
gotten better since your original tests.
I already tried, my bufferbloat is still extremely bad.
If bufferbloat is good when on a wired connection, and bad on wifi, you need to
look over your wifi environment.
and when you say 'bufferbloat is bad' what do you mean, what are you looking at
to determine that it's bufferbloat vs other problems.
what channels are in use by other people near you? what channels are you using?
unfortunantly the chipset you have doesn't have airtime fairness available yet,
that would probably help a lot
how many people/devices do you have on the wifi network? what sort of bandwidth
is in use when you are doing the test?
David Lang
Under normal circumstances, I would agree.
I'm not convinced the wired connection is set up correctly.
I would not rely too heavily on DSL Reports tests...they have been noted on the forums there that they are not always reliable.
See the Quick Test from bufferbloat.net -
https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bufferbloat/#a-quick-test-for-bufferbloat
Other Network Performance and Latency Tools -
A couple of tools for doing continuous pings -
Linux - MTR
Windows - WinMTR
Web based -
Hi jwoods
I would not rely too heavily on DSL Reports tests...they have been
noted on the forums there that they are not always reliable.
Do you have a link for that forum post? All other methods are less novice-friendly so it would be good to check and confirm this reliability issue.
But in short anything that fully saturates a long in combination with a latency probe will do. So multiple wget downloads, or a single one from a capable server combined with a ping -c 500 8.8.8.8
But then one needs to look at the ping output without additional help....
I've seen them on the feedback forum.
An easy to use test that I have been recommending is this one on Sourceforge...
Hi there,
On option dual-dsthost/dual-srchost - I've found that the default
triple isolation for individual connection generally works better in
fighting bufferbloat.
While I do not doubt your data point, I do doubt that this is generally true. In any way, please post an issue to sch_ cake's GitHub page (dtaht is the GitHub account IIRC).
The drawback being that you don't get bandwidth
faireness across host, but rather fairness across individual connection
i.e. whoever has most connections has advantage in getting more
bandwidth.
This is not what triple-isolate actually offers, it still takes the end-host IP addresses into account, but unlike the dual modes it tries to balance fairness between internal and external IP addresses, and often it works quite well, but it is harder to predict how it will behave as compared to properly set up Dual-Isolation and hence I try to recommend the dual modes. And if your observations from above is true, I would advocate for fixing the dual modes ;).
The mode you describe, simple per-flow fairness is called either flow or flows (can not look right now).
While dual-dsthost/dual-srchost settings seems to split bandwidth
fairly across hosts but I've found that if I simultaneously run one
throughput demanding application and one latency sensitive application
on the same host, bufferbloat issue resurface
This is not how it is supposed to be, as the dual modes first do per-IP-fairness and then do per-flow fairness for all flows for each IP address independently. If this does not work it is a bug that should be fixed; especially since triple-isolate uses a similar approach...
(running throughput
demanding application on a different host, however, does not cause
latency issue on the latency sensitive application.)
Now that is nice to hear. Are you sure you tried dual-dst/srchost and not far/srchost, without the dual- prefix, as the observed behavior does fit the non dual host isolation modes? I guess you did, but just to highlight the differences for other readers I believe it was worth asking.
Do you know if there's a way to ensure fairness for streams/connections
within the same host?
Nominally dual-dsthost on the Internet-ingress direction and dual-srchost on the Internet-ingress direction; for a NATed link with sqm on the actual wan interface you also need to add the Nat keyword to both directions, otherwise there will only be one IP address bisible, the router's external one, and the set up dual modes will regress to a, computationally more expensive than necessary, fow mode
Best Regards
Thanks, but that is a bit too coarse 
I guess I will need to do a bit of searching.
So the dslreports tests excels in that it offers quite a number of configuration options and also gives a pretty decent textual detaled output that can help figuring out issues with the tests itself, while most other speedtests I encountered do not even reveal how many concurrent flows they used during the test (this includes the sourceforge test). Also the dslereports speedtest gives visual representations of the bandwidth over time as well as the result of the latency probes, so in my book beats all other commonly used speed tests, so I really need to research the reliability issue...
The Sourceforge test gives some pretty detailed results at the end when clicking on View Details.
I don't rely on one test source.
In the end, regardless of what test is used, I would take accuracy over options and output any day.
I typically do as well, but I want to see and evaluate the lack of accuracy report first before jumping to conclusions. Especially since you did not observe this yourself but only relayed information from a forum post, and 3rd hand information is sufficient to raise flags, but not enough to declare that speedtest unreliable. So far for me it worked reasonably well and the results compared well to flant rrul/rrul_cs8 runs of around the same times, so for me it seems to work okay (but that in itself is also not proof that it is issues free for everybody).
I guess what I want to say is, I take your report serious, but reserve judgement until I did some research.
Best Regards
I have experienced significant fluctuations in their results.
I use more than one test source, and they rarely agree with DSLReports.
I look for consistency.
Sounds like a good plan.