Page 2 of 2

Re: 1.11.0.x gargoyle-ispy 2019-October-09 18

Posted: Mon Oct 14, 2019 5:54 pm
by pmerrill
Yes, I did review all of those but unfortunately, they do not help in answering my question. Given that Gargoyle uses OpenWrt, any improvements in performance will generally be down to changes to OpenWrt.

I notice that the recent release of Gargoyle bumped OpenWrt to 18.06.4. This is fine but what I really want to know is are there any performance changes included in 18.06.4 over 18.06.2 that improve the performance of Archer C7 V2?

From my initial review it seems the only way I can determine this is to review all the closed defects in the release and assess whether any of these may impact performance. A very long and daunting task.

I've looked at this https://openwrt.org/releases/18.06/notes-18.06.4 but it's too high level. I see there is a kernel update with a number of security patches but whether there are any performance improvements, I can't tell.

It would really be nice to know for each release generally what the improvements are, at least at a high level. It could even be just a list of 6 or 7 areas that could be "ticked" to provide some flavor of the release (e.g., security, performance, new functionality, etc).

Re: 1.11.0.x gargoyle-ispy 2019-October-09 18

Posted: Mon Oct 14, 2019 8:08 pm
by ispyisail
Based on experience hardware hardly ever gets faster with newer software/firmware.

Get faster more powerful hardware is your solution

p.s. I understand OpenWRT is always faster than Gargoyle. If speed is you bottom line use OpenWRT. I understand the extra features in Gargoyle slow it down.

Sounds like the Bathurst car race, you can conserve fuel, save the tires or go fast but you can't do all three at the same time. :)

Re: 1.11.0.x gargoyle-ispy 2019-October-09 18

Posted: Mon Oct 14, 2019 9:43 pm
by pmerrill
Thanks for the insights. Good logic as well. I have tried raw OpenWRT but I find the UI and setup overly complicated compared to Gargoyle. I also had problems getting a few things to work at all, so opt to stay with Gargoyle.

Faster hardware is a good solution. At the present time what's the fastest hardware that supports Gargoyle? I would not include a dedicated PC in that mix as I don't really have the space.

Re: 1.11.0.x gargoyle-ispy 2019-October-09 18

Posted: Tue Oct 15, 2019 1:43 am
by RomanHK
pmerrill wrote:At the present time what's the fastest hardware that supports Gargoyle?
If you look at what you have (Archer C7 v2), I recommend 2x CPU core - like Linksys or something similar. Here's a comparison table from Linksys for inspiration: https://oldwiki.archive.openwrt.org/toh ... d_hardware

Re: 1.11.0.x gargoyle-ispy 2019-October-09 18

Posted: Tue Oct 15, 2019 5:38 am
by ispyisail
Linksys WRT32X AC3200

or

Turris Omnia

I think you will get better support with the Linksys WRT32X

Re: 1.11.0.x gargoyle-ispy 2019-October-09 18

Posted: Tue Oct 15, 2019 6:34 am
by RomanHK
Here it is worth mentioning that Turris Omnia may cause minor problems when flashing (in my case, for example) and it is good to have a serial cable with you ;) .

Re: 1.11.0.x gargoyle-ispy 2019-October-09 18

Posted: Tue Oct 15, 2019 7:59 am
by pythonic
Not supported by official builds yet but the ipq806x architecture offers an alternative to mvebu (Linksys WRT series). The experimental 1.11.0 build has been run on the Netgear R7800, R7500v2 & D7800, Linksys EA8500 and TP-Link Archer C2600 that I'm aware of. I've also run Lantis' preliminary 1.13.x build on the E8500.

Re: 1.11.0.x gargoyle-ispy 2019-October-09 18

Posted: Tue Oct 15, 2019 1:26 pm
by RomanHK
I have a minor problem that seems to persist. Today I reset the router to default and started this version again without maintaining the settings. When installing the SQUID proxy server package (gpkg install squid), this requires the library:

Code: Select all

ERROR: Dependency libstdcpp of package squid cannot be found, trying to update your package lists
I found the library to be found here: http://downloads.openwrt.org/releases/1 ... /packages/

This target is written in /etc/opkg/distfeeds.conf and is not in /etc/opkg.conf. When I run the gpkg update command, the targets from the /etc/opkg/distfeeds.conf directory will not load :( .

Code: Select all

BusyBox v1.28.4 () built-in shell (ash)

------------------------------------------------------------------
|            _____                             _                 |
|           |  __ \                           | |                |
|           | |  \/ __ _ _ __ __ _  ___  _   _| | ___            |
|           | | __ / _` | '__/ _` |/ _ \| | | | |/ _ \           |
|           | |_\ \ (_| | | | (_| | (_) | |_| | |  __/           |
|            \____/\__,_|_|  \__, |\___/ \__, |_|\___|           |
|                             __/ |       __/ |                  |
|                            |___/       |___/                   |
|                                                                |
|----------------------------------------------------------------|
| Gargoyle version 1.11.X   | OpenWrt 18.06 branch               |
| Gargoyle revision 4c123f43| OpenWrt commit 90f6af5             |
| Built October 10, 2019    | Target  mvebu/turris               |
------------------------------------------------------------------
root@Gargoyle:~# ls /tmp/opkg-lists
gargoyle                          openwrt_18.06-SNAPSHOT_packages
gargoyle_kernel_specific          openwrt_18.06-SNAPSHOT_routing
openwrt_18.06-SNAPSHOT_base       openwrt_18.06-SNAPSHOT_telephony
root@Gargoyle:~#

Re: 1.11.0.x gargoyle-ispy 2019-October-09 18

Posted: Wed Feb 19, 2020 3:38 am
by Lantis
Just to round this out and include the information where it belongs:

In such a case the recommendation is that the user compiles a custom firmware, as the repository you suggested is not guaranteed (and is often not ever) compatible with Gargoyle because it is kernel dependent.

Gargoyle has its own kernel dependent repository included, but in this case does not include the required library.

You can try adding it, but it is not included because it does not work reliably by default. This is intended behaviour, not an oversight.