[GCC 7.2 BUILD] Optimized TP-Link Archer C7 V2 AC1750 LEDE Firmware

Yes, that is correct for all loops, but not necessarily so for some loops. Has to be tried and tested :slight_smile:
I guess that the small size increase would not cause harm.
I do not know if you enabled "-mdspr2", but maybe it is also worth looking at.

I just added this option too and the next build will use it (likely pushing that tomorrow). Thanks again for all your help guys, I learned a thing or two today! :slight_smile: Keep the feedback coming, it's making this a better build.

Maybe you can have a look at the squashfs options as well. Try optimizing blocksize for the device flash size.
Also, if there is enough space, you could actually switch from XZ to LZO which appears to have a better read performance: https://jonathancarter.org/2015/04/06/squashfs-performance-testing/
Block size 256KB looks good. I guess that would mean (much) faster boot times...

+1 for having dnscrypt-proxy in the firmware. I'm having problems installing the package in your build, would love to have it included.

Thanks! Keep up the good work

Also would like to see the source on GitHub for possible usage as a base to customize from.

Thanks for the feedback - I'll add and configure DNSCrypt. Just need to remove the "No config files have been added or modified" statement then I guess. :laughing:

P.S. @deuteragenie using 256KB block size already, it actually was default. Will also stick with XZ for the sake of keeping file size lower - it would only gain a couple of seconds during boot if I were to use LZ4 for instance.

@chuck new build is up, which includes DNSCrypt pre-configured with OpenNIC amongst other small changes.

@deuteragenie and @austinbutler, I just pushed my configs to GitHub as well instead of just the images. Will stick to that in the future.

@r00t already updated from my work using my home VPN and dnscrypt is working fantastic. Thanks for the good work!

1 Like

@r00t Great thanks! For the config files, you may want to look at storing the result of diffconfig on github (instead, or in addition to the full config). That makes it much more understandable what has been added / removed from the default distribution.

For LZ4, I was under the impression that you have still space on flash, so it may not be a bad thing to trade off a bit of that space for speed. The LZ4 decompression is about 4-5 times faster than XZ.

If you stick to XZ, then 256KB makes sense.

Next suggestions from my side :wink: Take a look at:

  • ZRAM
  • Strip

Would also be good to have some basic benchmarking tools, for network, memory and CPU:

  • iperf
  • md5sum
  • ?

PS: Your config files do not make use of -march / -mtune ...

+1 for that. Full .config is burdensome compared to the short diffconfig output. Nice that you already provide the short config.seed that is the diffconfig output.

Ps. If you want to provide full diffs of your source code changes, you might take a look on my community builds. I publish full source diffs with each build.

Not sure about either yet. Stripping libs and kernel would likely causes issues with further customization of my build - it might not include everything a user needs. As for using ZRAM as long as there's still plenty of free memory: I don't know how much sense that would make. But I'll consider both and play around with it.

Yep, could definitely add those if there's a demand for these tools.

How so? I'm using -march=74kc for both CONFIG_TARGET_OPTIMIZATION and CONFIG_DEFAULT_TARGET_OPTIMIZATION - what am I missing?

Thanks, I'll check them out.

  • ZRAM could improve performance even though you have enough RAM available - to be tested of course
  • I suggested to include some basic benchmark tools as your goal is to optimize this device. So I suppose that one needs to be able to measure this distro against other devices/ stock firmware / LEDE default / against the previous release(s) / .... Otherwise, what's the basis for claiming it is faster/optimized ?
  • I think that "-march=mips32r2 -mtune=74kc" is the better construct. In my humble understanding this guarantees compatibility with all mips32r2 processors, but optimize the builds for the 74kc.

Any source that confirms this? Arch wiki's take on this is "The zram kernel module (previously called compcache) provides a compressed block device in RAM. If you use it as swap device, the RAM can hold much more information but uses more CPU. Still, it is much quicker than swapping to a hard drive. If a system often falls back to swap, this could improve responsiveness."

Thanks, I'll look into this some more. Even though just march=74kc should be just as good considering this firmware is meant for only one single type CPU/router.

Don't need any other source than own common sense :slight_smile: That is, if RAM access is (very) slow, then compressing said RAM may improve performance.

But common sense also tells me that the compression and decompression means additional CPU cycles, which could affect performance of OpenVPN and packet processing under high load. Of course this would have to be tested, the results would sure be interesting.

New build will be up shortly.

I just read this explanation on "march/mtune" : http://stackoverflow.com/questions/10559275/gcc-how-is-march-different-from-mtune

You are right that if your goal is performance for this particular device then "march=74kc" is probably best. Apologies for the confusion.

Yep, I'm aware of the differences between -march and -mtune which is why I was using -march. Compiling the new build right now and was sticking to that. And no worries, because of your feedback this build improved by miles already!

Yet another possibility to get better performance. Have a look at using OpenSSL:


Hmm, use OpenSSL for what? This build already uses OpenSSL for uhttpd and OpenVPN for instance.

Ah, ok. If it does indeed, then there is no need.
BTW, I stumbled upon OpenSSL benchmarks on OpenWrt here:


Would be quite interesting to know how much your build achieves.