Wireless (2x2 client on 5Ghz channel 36) was a little lower. But I have a few things going on right now at home:
How close to the wire to you set your caps? I am provisioned 125/25, and I am set to 124000 and 24000 in cake. As well I use my own linksys modem, not xinfity provided. Little guy does a pretty good and speedy job with no overhead.
And I just test downloaded on my side, and it went pretty quick. I am wondering is a little reboot on your client might do you some good. Or perhaps maybe you have a little lag in your ISP line (I think you are ATT iirc). Maybe test later tonight when the world quiets down. See if you get back to A's.....
The SQM scripts were updated about 6 days back, I did notice that the dslreports test results had changed for me, assumed I needed to adjust settings(cable), just have not done anything about it as of yet. Did not check the provider website to see as to what improvments had been incorporated.
My caps are close to the wired speed. As I said, not biggie about the buffer bloat change. Am sure a little tweak would fix.
Just ran my simple iperf3 test against the latest wireless drivers. Do not see an improvement, but on the plus side no degrade either. My iperf test is between a windows 10 pro box with a Asus AC56 wireless NIC. Connects at 867mbps as it should. Other end, the server, is connected via gig connection to the router. Server is another windows 10 pro box. Just FYI the server box can dual boot Linux Mint and I get the same speeds. Here is latest run:
D:\Iperf>iperf3 -c 192.168.1.119
Connecting to host 192.168.1.119, port 5201
[ 4] local 192.168.1.171 port 61665 connected to 192.168.1.119 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 20.8 MBytes 173 Mbits/sec
[ 4] 1.00-2.00 sec 22.4 MBytes 189 Mbits/sec
[ 4] 2.00-3.00 sec 22.8 MBytes 191 Mbits/sec
[ 4] 3.00-4.00 sec 22.2 MBytes 186 Mbits/sec
[ 4] 4.00-5.00 sec 22.5 MBytes 189 Mbits/sec
[ 4] 5.00-6.00 sec 22.4 MBytes 188 Mbits/sec
[ 4] 6.00-7.00 sec 22.1 MBytes 186 Mbits/sec
[ 4] 7.00-8.00 sec 22.2 MBytes 186 Mbits/sec
[ 4] 8.00-9.00 sec 22.9 MBytes 191 Mbits/sec
[ 4] 9.00-10.00 sec 22.8 MBytes 192 Mbits/sec
Better then DD-WRT. Have not run against the OEM firmware on the wrt1900acs, but this is faster then the OEM on my wrt1900ac v1, for what that is worth.
[quote="billmy1228, post:187, topic:545, full:true"]
Do not see an improvement, but on the plus side no degrade either.[/quote]
And this is all we can hope for Attempting to read the commits in the driver, seems more related to "survey" and "scanning". More just house keeping, as I assume support for the ACS may have just been a patch type spot fix, to be cleaned up later (which this likely is).
If you would do a us a favor, run it for a bit. And if all seems status quo (as it does over here), drop a quick feedback line in anomeome's PR he posted above. Perhaps if it's solid, we can have it rolled into the "stable" LEDE prior to it's release. Else it may take some time to wait for the release cycles.
Just note that there is no single best qdisc. I have noticed that with both WNDR3700 (ar71xx) and R7800 (ipq806x with dual-core). There are wide differences between performance of qdiscs in different routers and also with wired/wifi. You need to test and try to find the most suitable for you.
E.g. with my R7800 dual-core the default "simple.qos" with fq_codel leaves quite a gap between the set speed limit and realised speed, apparently due to some miscalculation in HTB.
The newest SQM includes "simplest_tbf" to partially solve the problem I found.
Cybrnook requested that I run my iperf3 test for a period of time, in this case 30 minutes, to see if it seems to be pretty consistent. Can report that I saw no real differences in throughput while running iperf3 for the 30 minutes. Seemed to hold pretty steady. Guess the next question is will the new wireless drivers be stable. Only time will tell on that one.
Much appreciated, if you could post your result in a comment here, maybe just a link to your post here, it will give the LEDE dev's a data-point in making a decision as to whether/when to take this latest mwlwifi.
Now you're just confusing me.. as I just loaded the "older" R2.00 (r2885 instead of r2888)....
Anyway to update easily what you just added without a re-flash (i.e. package updates?). If not - no biggie...
Have everything fully up and running now - for kicks - I ran 3 different scenarios for SQM.
Some background - I have ATT Fiber - 1Gbps D/U. Download yields no issues - but upload is where the trouble is with respect to buffer bloat. I found a slight tweak with fq_codel settings on the LLA config that addresses this giving me very good results but have to live with the "loss" of ~ 50-80Mbps Upload speed (which I can live with.. ;))
These are on a wrt3200acm. BTW - I've heavily tested this connection since I got it about a month ago with several different routers:
TPLink AC2600 - decent - but had connectivity issues with one of my laptops - somewhat inconsistent results with the speed (tested stock and current dd-wrt at the time)
Netgear r7000 / X4S - horrible - tested stock, dd-wrt, and lede - simply could not handle the bandwidth (averaged half of my typical D/U speeds on the other routers). I wouldn't recommend either of these routers to anyone that has fiber connectivity.
wrt1900acs / wrt3200acm - best to-date - easily (and consistently) handles the speeds via stock, dd-wrt, lede. I switched to the wrt3200acm because they had it on-sale for cheaper than what I bought the wrt1900acs a few days prior. Of course - the primary issue with the wrt3200acm is the known wireless connectivity issues, however, I seem to be having less issues on these builds (except for the memory crash I noted a few days ago - then I have to reboot).
The bad about the linksys is the stock firmware is horrible from a functionality perspective (which is why I'm looking to these other options...
Thanks again for all of your hard work.. I certainly owe you a drink or six..
All of this flashing/tinkering has gotten me back interested in learning linux/developing for it again and I've been reading up in my spare time and starting to learn how to build these images myself (have VMs setup with build environments, etc., working) - just not to the point where I'm comfortable knowing how everything ties together (yet)...
I do have some ideas on automating the build scripts from hnyman's other builds and may work on those first just to give me insight on how the build processes work, etc. As I get close to completing them - I'll be glad to share to see if you think they are useful or not..
I think in this case ACS refers to "Automatic Channel Selection" and not to *ACS router models.
From looking at the diffs it appears to improve survey support which is a precondition for auto channel selection in hostapd.
That makes much more sense, I noticed and commented on that yesterday:
"And this is all we can hope for Attempting to read the commits in the driver, seems more related to "survey" and "scanning". More just house keeping, as I assume support for the ACS may have just been a patch type spot fix, to be cleaned up later (which this likely is)."
But I never made the correlation of Automatic Channel Selection vs ACS (WRT1900). So I was halfway there Thanks for the clarification. As well, in that regard, driver still seems to be operating fine, however I do not use auto channel select. I manually set 3 and 36. So my testing would likely be irrelevant. However any other user using the new driver would potentially notice (and hopefully have commented by now).
Download link value: 0 [since my d/l connection is solid - I don't want it to adjust via QoS here]
Upload link value: (your max tested/value or possibly tweak it a little lower - [in my case this is set to 1000000])
Under Queue Discipline:
Set discipline as "fq_codel (default"
Queue setup script: simple.qos
Under Link Layer Adaptation:
Which link layer to account for: "ATM: (ADSL, etc.)"
Per Packet Overhead (byte): 44
These settings didn't make much difference on my cable connection (comcast) - but with ATT Fiber - it's significant with respect to the upload buffer bloat...
Can't remember where exactly I got this detail from (otherwise I'd obviously leave the direct link here) - believe I saw it via youtube channel detailing how to address buffer bloat and the guy noted that these settings typically help drastically with DSL / Fiber connections (which he had)...
Currently I don't use it, so don't want to include it (one more thing to fail during compile).
But I suspect that as long as we are on the same Kernel as source (and build bot etc...) then you should be able to download and install packages from LEDE trunk (and the default feeds) and install them yourself. I personally have not tried that, but I don't see why it wouldn't work. We are on the Trunks current Kernel release.
Attempting to read the commits in the driver, seems more related to "survey" and "scanning". More just house keeping, as I assume support for the ACS may have just been a patch type spot fix, to be cleaned up later (which this likely is).
It's a moving target
