Yea for that it is march=24kc so you are fine.
Edit.
WNDR4300v1,wndr3700v4 is mips74kc
https://wiki.openwrt.org/toh/hwdata/netgear/netgear_wndr4300_v1
https://wiki.openwrt.org/toh/hwdata/netgear/netgear_wndr3700_v4
Please make sure you get the architecture correct because this uses march=
I am 100% sure if you don't use the correct march it will bootloop
AR9344 IS MIPS74kc
Please make sure I am correct
wow, okay. i thought it was mips24kc because of the package line. im glad it was failing. even though, if these bootloop i think it can be fixed. thanks to their recovery mode.
wndr3700v4: CPU0 revision is: 0001974c (MIPS 74Kc)
wndr4300v1: CPU0 revision is: 0001974c (MIPS 74Kc)
i confirm these two, thank you so much.
The package line is because LEDE developers optimize for mip24kc (mtune) so they do
ARCH:=mips
BOARD:=ar71xx
BOARDNAME:=Atheros AR7xxx/AR9xxx
FEATURES:=usbgadget
CPU_TYPE:=24kc
SUBTARGETS:=generic nand mikrotik
It will work on any mips32r2 but all the package have "24kc" inside even though it is actually not
Ok uploaded try and see
2 Likes
Wireless speed indeed increased very much, thank you for your work!
1 Like
i just wanted to report back. i didn't test the build you posted but after using the correct branch mine compiled fine (both wndr3700v4 and wndr4300v1) along side my own patches and it seems to be working just fine 
so i just wanted to thank you for your work and i hope this gets taken upstream! 
(after some more testing, of course) 
Model NETGEAR WNDR3700v4
Processor Atheros AR9344 rev 2
Architecture MIPS 74Kc V4.12
Firmware Version LEDE Reboot 17.01-SNAPSHOT r3442-5b0b27eb48 / LuCI lede-17.01 branch ( Trunk )
Kernel Version 4.4.71
Thu Jun 22 05:08:19 2017 kern.alert kernel: [ 31.210290] fast-classifier: starting up
Thu Jun 22 05:08:19 2017 kern.alert kernel: [ 31.214512] fast-classifier: registered
1 Like
I try on my router, but Lan and WLAN down and up constantly when I connect the Wan port, I flash the sysupgrade for the wdr4300v1, updated from the BarrierBraker.
And works only when i reboot and disconnect the Wan port.
I'm wary of running patches which haven't been submitted/included in master tree. Any idea when those patches will be included?
2 Likes
Of course you will have issues.
Barrier Breaker is too old to sysupgrade to lede 17
You have to redo your config
1 Like
Can you post some instructions how to add Fast Path feature without all your other patches? I keep my WDR3600 as closer to defaults as it can be.
2 Likes
Tried to test the C7v2 build but 5G doesn't work. I could see the modules load. 2.4G wireless speed remains same.
1 Like
You chose the wrong frequency not every band on 5G is usable and you need to wake up the interface sometimes the config goes nuts
For mips74kc it is able to do wireless nat at fullspeed already, is those weaker SoC like AR9132 that benefits from this.
The crux of Fast Path is IF YOU HAVE GIGABIT FIBRE fast path can give you gigabit speeds.
If your subscription is 10Mbps this is not going to give you magic.
Can you read up on networking first?
1 Like
Ok thanks for your work, I've already done all the settings, I'll try again later.
i'm back again. i wanted to report for the wndr4300v1 build that i compiled. it's also up and seems to be just fine thank you @gwlim
Hostname LEDE
Model NETGEAR WNDR4300
Processor Atheros AR9344 rev 2
Architecture MIPS 74Kc V4.12
Firmware Version LEDE Reboot 17.01-SNAPSHOT r3442-5b0b27eb48 / LuCI lede-17.01 branch ( Trunk )
Kernel Version 4.4.71
[ 31.152727] fast-classifier: starting up
[ 31.156954] fast-classifier: registered
+1 for that request.
I briefly looked at the code including the "patch LEDE" script and got lost after noticing the need for installing java, disabling several routers, minifying js and css files, adding L7 protocols etc., which things do not look relevant for the fast-path implementation itself.
1 Like
Java is for CSS compression and JS optimization using closure and yui compressor
L7 stuff have been remove.
Just trace the commits using mips24kc repo
Anyone has any Free Packet Per Second Test tools?
You need to benchmark this to be scientific about this
I don't know why a lot of LEDE pple here don't do benchmark at all.
Never mind looks like I have to do everything myself
Pushing UDP MSS limit to 512 bytes gives 260/280 Mbits/sec
Calculate packet per second
(27010001000)/(5128)=66kpps
Pushing TCP MSS Limit to 536 bytes gives 300/330 Mbit/sec
(31510001000)/(536)=73.5kpps
Still pretty damn slow
As an illustration this is Mikrotik benchmark table using the SAME exact CPU AR9344
2 Likes
After using your firmware with the patch, the wireless throughput just increased drastically. Before when using samba, speed is 500kB/s for 2.4ghz 20mhz, 1.5mB/s for 5ghz 20mhz and 2.5mB/s for 5ghz 40mgh. Using your firmware, the speed nearly doubled. Thank you for your hardwork！
2 Likes
Ok after adjusting some defines I got 410Mbps at 536bytes MSS
So calculation
(41010001000)/(536*8)=95.6kpps
This is on AR9344 mips74kc
Much better!
On LAN to LAN if we limit MSS to 536 bytes
performance is about 850Mbps
So
(85010001000)/(536*8)=198kps per second
This is the upper limit
If we refer to the Mikrotik table this is about right.
This is single host to host testing and we can see the limit is already reached.
If the switch can be optimized to exceed the limit of single host to host testing then it will be perfect.
A lot of optimizations are still required!
Since Bridging layer is on top of Routing layer
If we improve the bridging performance routing will benefit as well