For some reason, PPPoE has a massive CPU overhead in OpenWRT (even though it's a relatively simple protocol). With no software flow offload (which is a requirement for SQM to even do anything), I cap out at 600-700 MBit. That is WITHOUT sqm.
PPPoE requires to diassamble all received packets and reassembly with changed header fields and the PPPoE header removed from the ethernet payload. That requires deeper packet processing than plain forwarding.
My son upgrades his games (menay GB) from steam and I have only 300 MBps.
When he is downloading we not realized of it because downloading speed from steam here is quite low, too low in fact it takes quite long to download a game.
It surprised me that you could download games at speedn near 1Gbps.
I thinks steam uses downloading from peers, I am not sure, and that may be the reason downloading speeds can vary a lot from region to region.
Or may be they do not distribute their servers well across the globe.
I have substituted the ISP functions by my RT3200.
The ISP router now acts simply as a bridge (well it does telephony too) and fowards all data traffic to my RT3200 that is configured with PPoE in its wan interface.
There is the possibility to use the ISP router to connect PPoE in its external interface and configure the RT3200 with a fix IP in its WAN interface and use DMZ to pass all data traffic to it.
Would it be a better aproach and let RT3200 to be less busy?
My RT3200 does not seem to be busy right now, with 300 MBps it seems to be quite free, but if it is a better solution, meanwhile I continue using the ISP router and don't eliminate it...
Enabling packet_steering and installing & enabling irqbalance did the job Same speeds as previously on hardware flow offload, but now purely on software flow offload This device really is a beast!
I can confirm too that hw offloading is crashing the router after a while. But the good news is AFAIK there is active development here including LAN-WLAN offloading which currently takes a big hit on the CPU.
Are there any known failures of "packet_steering"? Just asking as hw-offloading tooks some days to find the source of the problem. (And if there are none: why is only 1 cpu used by default?)
It's 71MB out of 75MB Available (as in: free) space for the overlay. The fact that 75MB - 200kB != 71MB is due to UBIFS overhead and reserved blocks. So LuCI shows the free space correctly.
You actual read-only rootfs (squashfs on /dev/root) got 11MB.
As things are dynamically sized, the read-only rootfs can be up to ~100MB, so you still got some megs for overlay read-write storage.
I've gone through this thread. I just go the belkin variant. This replacing an ap not router. at the moment i have it in stock firmware and getting nice speed. on 1 gig transfer getting 70/megs a second. i picked up another on the way off ebay for low price. that i may use for router. If i have something wrong with following, please let me know.
Best practice would be to follow daniel's guide on git and do full backup first.
if i do that and then try the non ubi route by flashing kernel then ssh to install non ubi image. since device is a/b layout like android phone, will i still be able to go back to stock easily by force boot to other partition ?
if i go ubi route, again following guide on the git, can i then go back to stock by a full write back of the backup done beforehand.
I had the same debate as you did. I am using 3 of the e8450 as just dumb access points(got them as a great ebay score!)
First off, these are a great piece of hardware for the money. I set mine up with stock firmware as they were just going to be dumb access points.the stock firmware was terrible. I decided that openwrt was a better option and just decided to go the UBI direction making full backups.
The important thing is to read the guide a few times and follow it to the letter. If you do that it goes without a hitch. I had all 3 fully backed up and converted in 30 minutes. The thing is, why would I ever go back to stock?
So far openwrt on these has been very stable and these perform great as cheap AX access points.
thanks, for the reply. yes i have never seen stock firmware with so few options. i hesitated because of really good speeds i was getting. plus i had serveral tp-link c2600 units and always had wifi problems in openwrt. (atheros chipsets). so that is why for the ap i am hesitant. i separate the wireless from my router and use a separate ap, mostly because of the problems i had with the c2600's crashing. i have another coming from ebay and i will likely go the ubi route on that. thanks again