euwdr3600 wrote:Flash this one from March-26 build without preserving settings on my Tl-WDR3600. So far so good!
Great! But why did I get such a different result (above)?
I started with Gargoyle 1.6.2 on my TL-WDR3600-v1.5
flashed over ethernet (not preserve settings) with gargoyle_1.7.x-ar71xx-generic-tl-wdr3600-v1-squashfs-sysupgrade from ispyisail (above)
set password & timezone
could not set up 3G WAN connection (above)
Weird - maybe I will have another try....
[UPDATE] Nope same result. And getting back to 1.6.2 has been a bit of a mission (flash OK; pwd & timezone OK; load settings -> brick; manual config OK)
Can you help someone else get Gargoyle up and running? TL-WDR3600 : Gargoyle 1.9.0 : NBN FixedWireless
TL-WR1043ND-V2 : Gargoyle 1.8.0 : 3G Huawei E160E
What's the main benefits between the latest release and 1.6.2? 1.6.2 has been performing nicely for me except for a couple of minor points:
> Range is ok but I think it's better with stock
> Getting dual channel n to work seems to be troublesome. I can get some of my devices to connect at 270mbits on stock but can't seem to get more than 70-135 mbits on Gargoyle
Going back to stock is not an option because the stock firewall is crap and gargoyle's is excellent. I can't even set up the rules I have with stock and they are not that complicated.
looking though the logs i found one small error: Tue Apr 21 09:25:37 2015 kern.err kernel: [57838.290000] overlayfs: ERROR - failed to whiteout 'S85webmon_gargoyle'
and ik'm still not 100% sure plugins work fine. I had to reflash and re-install because first time one plugin didn't register, and connecting via ssh i found some issues. When i installed plugins in a different order everything worked fine, so i'll do more testing here.
Your router has a CPU and that CPU has a limit on how much data is can process per second. Almost nothing written on this page will be true if you are trying to exceed the limitations of your router. Quoting Clint Eastwood “A man needs to know his limitations” so know your router's limitations. When you are exceeding your throughput limitation you will see “CPU Load Averages” on the Status screen approach 1.0 and strange unexplained things happening.
This will happen somewhere between 10Mbps and 500Mbps depending on your router and what Gargoyle features you are using. To use Gargoyle you must reduce the download/upload link speeds on your QoS pages so that your CPU never gets near the 1.0 limit even under fully saturated conditions.
Bandwidth monitoring and QoS are the two features that take the most processing for your router. If you turn them off you will get more through put but of course you will lose many of the reasons you are trying to use Gargoyle.
Don't complain on the forum that your router's native firmware gives you better throughput than Gargoyle firmware does. With Gargoyle you are getting features and stability which you do not have with your native firmware. If you cannot achieve the speeds you want get a faster router.
I second ispyisail's comments. I went from a tp-link 1043nd to a tp-link wdr 4300 and there is a big difference in throughput. However, I remember something mentioned that indicated AA was faster than BB for the same configuration, even for a really basic configuration (no firewall rules, no QoS, etc).
The point of this build is that it back ports the speed fixes from the latest Trunk builds to Gargoyle.
It's still a limitation however, both cpu speed and a few other bottle necks (bwmon etc).
https://lantisproject.com/downloads/gargoylebuilds for the latest releases
Please be respectful when posting. I do this in my free time on a volunteer basis.
It's well known that TL-WR4300 is powerful enough - even without HW NAT! - to handle 240Mbit WAN->LAN throughput.
And it's also known that even TL-WR1043v1 should handle that...
That rather alibistic If you cannot achieve the speeds you want get a faster router. statement is becoming quite obsolete with nowadays routers.
How old is that page, BTW?
Please don't get me wrong, I'm not complaining, just discussing.
As I see it, the whole situation is rather about developers not having their own Internet connections fast enough, so that they would face the problem on their own.
You never really care about a problem until it gets your own problem...