Ah, ok. If it does indeed, then there is no need.
BTW, I stumbled upon OpenSSL benchmarks on OpenWrt here:
https://wiki.openwrt.org/doc/howto/benchmark.openssl
Would be quite interesting to know how much your build achieves.
Yeah, found that page as well recently. However, I noticed that all C7 benchmarks use 74kc. I'm curious about the difference between 74kc and 24kc in OpenSSL performance. I'll run this benchmark soon on one of my builds for comparison - curious about how it performs as well.
OpenSSL benchmark (compare with non-overclocked C7 on r47187 at https://wiki.openwrt.org/doc/howto/benchmark.openssl):
| MD5 | SHA-1 | SHA-256 | SHA-512 |
| 49479250 | 28028850 | 12735820 | 6318500 |
Anyone interested in benchmarking the stock LEDE firmware for this router?
Cool! Looks good.
Thanks for these timely builds. Just a few thoughts:
-
What about providing a "pure" optimized LEDE-build without tons of extra packages? I realize you primarily focus on your needs and kindly provide the build, yet I see no harm in asking for a more "stripped down". Not so much flash space left with your build. Just a thought, not even a request.
-
I see lots of "fail"-messages which are related to the ath10k-firmware in the kernel log. I don't know how to properly interpret them but I suspect that
36.126145] ath10k driver, optimized for CT firmware, probing pci device: 0x3c.
[ 36.155064] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
[ 36.163057] ath10k_pci 0000:01:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
[ 36.408820] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
[ 36.419708] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 37.221437] firmware ath10k!pre-cal-pci-0000:01:00.0.bin: firmware_loading_store: map pages failed
[ 37.230779] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/cal-pci-0000:01:00.0.bin failed with error -2
[ 37.241300] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 44.490553] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/fwcfg-pci-0000:01:00.0.txt failed with error -2
[ 44.501263] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 44.608503] firmware ath10k!fwcfg-pci-0000:01:00.0.txt: firmware_loading_store: map pages failed
[ 44.619403] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/firmware-5.bin failed with error -2
[ 44.630292] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 44.796712] firmware ath10k!QCA988X!hw2.0!firmware-5.bin: firmware_loading_store: map pages failed
[ 44.805972] ath10k_pci 0000:01:00.0: could not fetch firmware file 'ath10k/QCA988X/hw2.0/firmware-5.bin': -11
[ 44.816130] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/firmware-4.bin failed with error -2
[ 44.826993] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 44.991747] firmware ath10k!QCA988X!hw2.0!firmware-4.bin: firmware_loading_store: map pages failed
[ 45.001007] ath10k_pci 0000:01:00.0: could not fetch firmware file 'ath10k/QCA988X/hw2.0/firmware-4.bin': -11
[ 45.011173] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/firmware-3.bin failed with error -2
[ 45.022035] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 45.187550] firmware ath10k!QCA988X!hw2.0!firmware-3.bin: firmware_loading_store: map pages failed
[ 45.196817] ath10k_pci 0000:01:00.0: could not fetch firmware file 'ath10k/QCA988X/hw2.0/firmware-3.bin': -11
[ 45.403113] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
[ 45.412516] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[ 45.424869] ath10k_pci 0000:01:00.0: firmware ver 10.1.467-ct-_fW-019-60dd7c5 api 2 features wmi-10.x,has-wmi-mgmt-tx,txstatus-noack,wmi-10.x-CT,ratemask-CT crc32 f59d154a
[ 45.443238] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[ 45.453851] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 45.543157] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
is not supposed to be normal, right?
- opkg update yields lots of
Package foo has no valid architecture, ignoring
and
opkh_download: Failed to download foo, wget returned 8
I might very well be doing things wrong. But a quick look at the above posts didn't seem to mention any of my points.
You basically answer this question yourself in #3. This build uses a different arch (74kc instead of 24kc) than the official LEDE firmware for this router, which means the opkg packages won't work. I'd have to compile and maintain a repository of all available packages to make this work. So instead I just compile everything that someome might need into the firmware already. If there is any particular package you're missing, please let me know. Also as long as there is free space we can actually use it. Free space is wasted space, right? 
That's actually normal. It's looking for different file names that don't exist, until it finds and loads the right file (your pasted log ends before you can see that part). See: Archer C7 - QCA9880 Firmwarequestion
Thanks for the quick reply.
As for the free space/included packages: I concur. In a way. 
I thought about tinkering around with some things, including but not limited to python for example. I found it rather interesting to be able to run small scripts on an always-on-device rather than on a machine in my local network. But python is rather bulky. In general, I think I should prefer the stock LEDE firmware for that matter. I just liked the "optimized". I could of course further customize the setup or compile packages myself, but then again I'd probably prefer to start "from scratch" with a base installation.
Also thanks for clarifying the opkg-issues. I somewhat missunderstood the concept of your build. It didn't cross my mind, that there might be differences/incompatibilities with the "arch" since the physical hardware is still the same. But it somehow makes sense now.
Last but not least - thanks for the heads-up on the messages in the kernel log. There are indeed more messages but it wasn't immediately clear that everything is in order. In fact, everything works like a charm, still "failed, failed, failed.." looked rather unnatural.
Good luck with your next builds then. I'm sure I will try some of them before switchting back eventually.
@r00t - Below are two runs of openssl benchmark on a stock 24kc build. The stock build is way ahead of you in sha256 and sha1 and just a tiny bit slower in md5 and sha512. Are you sure there was no load on your device when you were performing the test? I would expect the 74kc build to be a little faster than stock in all tests.
type 1024 bytes 1024 bytes md5 49147.72k 48716.11k sha1 38793.90k 38511.02k sha256 19258.79k 19101.11k sha512 6107.30k 6138.39k
--EDIT--
r00t's numbers for a better comparison:
| MD5 | SHA-1 | SHA-256 | SHA-512 | | 49479.25k | 28028.85k | 12735.82k | 6318.50k |
1 Like
Thank you for sharing your results - this is odd. I just ran the test again on the latest build and am getting the same numbers. When I have more time to work on this firmware I'll have to try different options and move back towards stock build options to figure out what exactly would cause this. You are sure you ran this on an Archer C7 V2, right?
Yes, Archer C7 v2. If I were you I'd keep the 74kc cpu traget, but revert some of the "flags to maximize performance". Also try to build with -O2 or -Os. -O3 is not always faster than -O2 or even -Os.
yes, that, or possibly the 74kc target itself causes slowdowns, or maybe gcc 6.3.
@knizmi: your figures are much higher than previous OpenWrt results
@r00t: if one of your constraint if that packages cannot be installed using opkg, then you probably should pack as many things as possible that fit in flash. But, to prevent slowdowns, ensure that they are disabled by default. Ad-block and maybe openvpn-bypass would be good to have, so end users don't have to use the command line.
Yup, compared to the results posted on https://wiki.openwrt.org/doc/howto/benchmark.openssl I am getting substantially better numbers in sha-1 and sha-256, while r00t is in line with those results. Interesting.
I reran the benchamark again and here is the single-line output to avoid any error on my side:
| r3042 | Qualcomm Atheros QCA9558 ver 1 rev 0 | TP-LINK Archer C7 | MIPS 74Kc V5.0 | 358.80 | 1.0.2k | 48896170 | 38629970 | 17232660 | 6107900 ||
There was a little bit of load on my Archer this time btw as I'm connected to it through an OpenVPN tunnel.
Thanks for taking the time to build this - I have many Archer C7 V2's that I enjoy using LEDE on.
However, with the latest build, it seems 5GHz (ath10k) is broken in some way. I've setup my WiFi settings as normal through LuCI, but my clients never connect to the network (or see the SSID).
I have another Archer C7 with a pre-17 release on it that works as expected.
I did a "scan" in LuCI on the 5GHz interface and that seems to return results, so it's not entirely broke.
Update: 2.4 GHz is also broken. No SSID's I set seem to show up. Wireless appears disabled even enabling it via LuCI
Update 2: Looking at the logs:
Tue Feb 14 01:27:13 2017 daemon.err hostapd: Line 38: unknown configuration item 'ieee80211w'
Remove references to option ieee80211w in /etc/config/wireless. Works.
Thank you, I'll look into this. Weird part is I am running the latest build too and didn't run into this issue. Probably because I preserve settings and /etc/config/wireless gets overwritten with one that doesn't contain ieee80211w.
PS. According to this that happens when you don't use the full version of hostapd. I'll switch from wpad-mini to wpad with the next build to see if that resolves your issue and also provide more wifi options.
Didn't get to the bottom of those performance differences yet. I tried default flags, all sorts of combinations and leaving out the additional flags and even switched back to GCC 5.4 just to make sure. Always with worse SHA-1 and SHA-256 performance than you seem to be getting with the stock build. The stock build is indeed faster in calculating SHA-1 and SHA-256, I verified this just to be sure. Unfortunately it doesn't seem to be easy to figure out the reason. I'll have to do more testing and disassemble by build piece by piece... Thanks again for finding this issue!
1 Like
Stock is built using an (OpenSSL) assembler-optimized patch that is not applied to your builds maybe ?
What happens when you rebuild stock yourself ?
That could be it - I'm just building from trunk without any additional patches. Could you point me to them?
Unfortunately no, I am just conjecturing. Would be good if a LEDE dev could help with this.
Thanks for the current build #tHUmBsuPP:+1:
WiFi won´t come up with the latest build... tested with the 20170213 build