The first patch
wget https://github.com/openwrt/openwrt/pull/1950.patch
git am 1950.patch
rm 1950.patch
Second:
Edit target/linux/mvebu/cortexa9/target.mk, delete /tmp and old configuration .config. Buildroot will pick up the changes automatically next time your run make menuconfig.
Do I do wget https://github.com/openwrt/openwrt/pull/1950.patch from /openwrt in uduntu? Will doing a git pull over rite the patch? What do I do when Editing target/linux/mvebu/cortexa9/target.mk,?
Yes, the patch goes into the root of openwrt.
You change the line in target/linux/mvebu/cortexa9/target.mk that says CPU_SUBTYPE:=vfpv3 to CPU_SUBTYPE:=neon. Don't expect wonders but it usually gives you at least a little speed boost, it depends on your workload.
Household gigabit fiber connections are beginning to become a problem with existing routers.
I've been thinking about changing my router to eg. Pc Engine APU2 router, which already has a lot more power compared with consumer routers. https://www.pcengines.ch/apu2.htm
Thanks diizzy I will let you know how I go on.
WRT3200ACM can handle Gbit so no point in changing routers (without SQM which most likely isn't needed at such speeds). I'd probably look at the Asrock iBOX-R1000M, iBOX-V1000M or the UP-Boards if I needed something small and x86 at the moment.
Diizzy Building now. Will doing a git pull over rite the patch?
No, it's not merged (that process seems quite slow these days)...
While at it, you can change GCC to 8.3.0 and binutils to 2.32 which may (most likely) improve things additionally. Works fine on my ARM and MIPS boxes and I think davidc502 is also going this route.
Hi diizzy could you pleas explain how to do that?
Can you use make menuconfig to choose GCC version? If not, you should.
it seems to me that if your CPU is not pegging, then special compilation hacks etc are not going to help.
if you set up cake and run a speed test while watching output of top -d 1 what does CPU idle percent look like?
The point is to use cake SQM. The router can do the 300mbit connection fine without SQM, but running http://www.dslreports.com/speedtest at her place resulted in +100+ ms ping times. I'm trying to get consistent low latency, even if it comes at the expense of slightly higher throughput.
so what speed works? try 150, if that works try 225, if that works try 260...
at what point does it work? also watch the top output and let us know how low does idle percent drop?
I suspect you will find that the issue is something to do with your ISP lying to you about your real speed or otherwise providing lousy service aimed at maximizing just one number: the results from their affiliate speed test sites
After changeing the line to CPU_SUBTYPE:=neon
my build craps out. I will try again.
Is it possible that a congested DOCSIS connection is causing this? I don't mean to hijack this thread but I have had a similar problem with SQM on my DOCSIS connection where after a certain speed the bufferbloat gets really bad but the router CPU isn't pegged.
right, the local link could be easily oversold, but it wouldn't explain if you are able to get high download without cake and then not with cake.
That's about what is expected. For one, there is a need to leave some reserve capacity for high-priority traffic, so the bulk exchanges used in the speed test are not allowed to fully saturate the line. Alos, an AQM will keep TCP congestion widows (cwnd) pretty small (double-digits), whereas an unmanaged line allows humongous cwnd of 1500 and even more. RTT's of over a second for those crazy huge cwnd mean tons of latency for the latency measurement pings.
Look a the 'server view' section of the detailed report to see the cwnd and RTT's. Lower RTT and smaller cwnd are better for overall real-world throughput.
Remember, on the Internet, a 'speed' test is a measure of capacity, not velocity.
Cable industry gets it right with DOCSIS 3.1
Looks like the light bulb came on with the goal of 0% of retransmitted packets across their cable networks. Wish all other types or Internet connections would require some type of TCP/IP RFC standard that would resolve the bufferbloat issue. Know that OpenWrt 18.06.2 r7676-cddd7b4c77 / LuCI openwrt-18.06 branch (git-19.020.41695-6f6641d) / SQM - cake - piece_of_cake.qos has done the job of resolving my bufferbloat issue on my Frontier 150/150 FIOS connection.
DOCSIS 3.1 https://www.macobserver.com/tips/mgg-answers/docsis-3-1-xfinity/
Solve Bufferbloat Problems with a DOCSIS 3.1 Modem
Dave HamiltonDave Hamilton
@DaveHamilton
Jan 15th, 2018 11:44 AM EDT | MGG Answers
Question:
Phil asks, “Comcast/XFINITY has raised their rental fee to $11/month and I’m going to buy a new modem. Should I buy DOCSIS 3.0 or is there a good reason to buy DOCSIS 3.1 today?”
Answer:
At this point, if you’re buying a modem for Xfinity I would go with a DOCSIS 3.1 modem, for sure. Not only does it future-proof you for if/when you want to get Gigabit service, it also gives you the new DOCSIS-PIE queue management that’s mandated to be in all DOCSIS 3.1 modems, even when they’re running DOCSIS 3.0 connections. DOCSIS-PIE is mandated by Cable Labs for DOCSIS 3.1 modems (and later) because it effectively solves that upstream bufferbloat problem which plagues all pre-DOCSIS 3.1 modems.
This makes a HUGE difference, and means you no longer have to think about solving Bufferbloat with WAN QoS management in your router.
Comcast has had DOCSIS 3.1 active for over a year now but they never bothered enabling AQM. So even with a DOCSIS 3.1 modem I still get +2000ms of bufferbloat. I doubt Comcast will ever bother setting it up because why would they care if your connection is bloated when most of their subscribers don't have another ISP choice at their address.
Well Comcast stated that they have started to roll out DOCSIS across the nation. This started back in December of 2015.... Comcast begins rolling out DOCSIS 3.1-based gigabit home Internet By Todd Ogasawara on December 29, 2015 at 11:08 am https://www.extremetech.com/extreme/220025-comcast-begins-rolling-out-docsis-3-1-based-gigabit-home-internet
Now I do not have Comcast at this time however have a number of people I know in the Portland (OR) / Vancouver (WA) metro area that have run tests and they do not seem to have a bufferbloat issue on their connections. It would look as if they have updated the equipment in this area. So if someone updated the cable modem if they rent from Comcast, or have a newer one they own themself (which is what I advise people to do) they should get these better results.
As far as we know the egress aqm PIE is mandatory for all DOCSIS 3.1 modem's, and on by default, so unless your ISPs actively diasables this there should be upstream AQM on your link. Could I convince you to run a speedtest according to the recommendations in https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 with all AQM/SQM in your router disabled? I expect to see very little* bufferbloat in the egress direction, while the download might still be terrible.
*) If I recall correctly the PIE latency target is something along the lines of 20ms, so I would expect latency under load in upload direction to be 20-40ms higher than during idle periods (but note that this might be initially swamped by the leftover download packets in the upstream buffers that first need to be sent before the return latency probes are not delayed anymore by this resudue from the download test).