Wired speed doesn't pass 100mbps

That's what I mentioned, given that PPPoE is a mandatory part of the equation; so mt7621 will be significantly better than the tl-wdr4300, but not at full capacity either.

Ah, I missed that he was using PPPoE. Then you can expect to max out at around 600-700/400-500 I'm afraid. x86 does sound like the better option in that case.

The 1Gbit connection will be able to SLAM packets into your router's queue far faster than the router will handle forwarding them. 1500 byte packets * 1000 packets for typical queue length * 8 bits/byte / 100Mbps = 120ms best case latency. I personally have experienced 800ms latency on a gigabit link with QoS turned off. With a gigabit connection if you aren't running some kind of queue management the slow interactive experience is HIDEOUS and you absolutely CAN NOT use any kind of VOIP, like forget it, the first time someone starts to watch a netflix video your audio cuts out for 3 seconds.

so, queue management is absolutely required for a gigabit router. Given that, even the best consumer routers really don't do well. Maybe an ARM based solution, but then the price is basically the same as the first x86 solution I posted.

for now, I'm not getting 1gbps with the isp's router, I'd suffice with 800~ with the router I have.
I think that with the vendor's fw, I might be able to get to that.

Gives example performance with significantly more powerful routers, Netgear Nighthawk etc. A lot of the performance measures are really gamed by the router manufacturers. Sure, you can maybe push a gigabit through using iperf on one connection but when you have say 5 different devices each watching videos each opening up and tearing down new connections every few seconds, even high end consumer routers much faster than yours only really give 200-400 Mbits reliably. An example of how that matters is say updating a linux install as it downloads hundreds of individual .deb files. The x86 is pushing 700+ under all conditions.

It's fine to say you can't afford to get an x86, lord knows life is expensive :wink: but just have realistic expectations for what you will get, which is something like 100-200 mbits reliably with bufferbloat control that you will need because your router will be an enormous bottleneck compared to the ISP equipment.

If you're talking about WAN->LAN speeds -- it's because there's no hardware NAT support in LEDE.

There has been some development in that area recently here: Hardware NAT For LEDE and there was another thread which title escapes me now.

Have you tried using gwlim's Fast Path build?

It probably will not give you 1 Gbit/s NAT transition. However, the SFE kmod should improve your speeds. I recommend using the Sept. 2017 build for the moment, which is based off of LEDE 17.01.2.

Nobody suggested using top to see how CPU/interrupt saturated the router is getting? :wink:

I agree with checking to see if the eth interface isn't reverting to 100mb, or some other slowing problem. I have a PC, that would connect at 1Gb, but never moved data past 270mb. Tried a lot of settings, drivers, never fixed that. Other desktop, no problem for full speed. Checking the load (amount of idle time left) should help determine if you're running out of CPU, or it's some network issue.

I have the Archer C7 for example, stock FW, 1GB wire speed thru, due to HW accelerator. With LEDE you lose that, will do 400-500mb without it. If you want SQM, or other CPU hungry feature, routing to Wi-Fi, etc... of course things slow down.

Since you aren't using SQM, you could try Fast-Path, (it won't work with it) and likely gain a lot of performance. Again, top will let you know how loaded it's getting. OTOH, for aforementioned reasons maybe you could try evaluating if you get better 'goodput' use performance at 200-300mbit under SQM, vs faster without.

Like JonP said, running top is a good idea to know what exactly is going on with the CPU under different loads and speeds put on the router.

I have SQM working with Fast-Path on my TL-WR1043ND V3. I put SQM on the LAN interface vs the WAN interface and switched the ingress and egress to account for the inward facing interface. Without Fast-Path, SQM on the WAN interface, speeds maxed out at ~130-140Mbps on the TL-WR1043ND V3. With Fast-Path and SQM on the LAN interface I am able to achieve my speeds of 95% of my connection and control my bufferbloat and maintain lower latency. The only downside is it will limit your LAN to LAN speeds to the speed of smallest value of either ingress or egress. It's easily worked around for large LAN to LAN transfers by temporarily disabling the instance.

You might be able to work around the fastpath thing even better as follows (from a design that worked in a different thread).

Create a veth device pair and bridge the veth into your lan

ip link add type veth
ip link set up dev veth0
ip link set up dev veth1
brctl addif br-lan veth1

Now, give veth0 a LAN ip address and route all your LAN traffic there.

ip addr add 192.168.1.254 dev veth0

and route all your wan traffic through veth0 towards the bridge:

ip route add default via veth0 table 1000
ip rule add iif WANIFGOESHERE table 1000 prio 1000

and put sqm on veth0

LAN to LAN transfers should go direct through the bridge and have nothing to do with sqm, but all the traffic routed to or from the WAN will go through a sqm queue and then through whatever fastpath.

This is just a sketch of the basic idea so you'll have to work out the testing details yourself, including setting up the firewall rules properly. However note that this also lets you control dscp marks in your iptables rules because packets first go through iptables and then hit sqm at the veth0 interface, and that can let you do diffserv profiles in both directions.

thanks for all your suggestions, after some consideration, I've decided to move the media mount from the router to the htpc and install the vendor's fw on the router.
that should give me what I wanted, e.g. ~1 gbps support and no need to migrate the media to ntfs.
whats left is to do is to export the media via nfs as it was before, this I can do without much of a problem.

again thanks for all the help.

If it's not too much trouble would you post a dslreports speed test after you get the vendor firmware up? Just interested to see how it does.

well, just tried to flush it via the ui and I got a format unknown or error like that.
I need to find the exact way how to revert to stock fw

Might need to TFTP it or something. There are a bunch of details, including the need to strip certain parts of the factory file on the old wiki: https://wiki.openwrt.org/toh/tp-link/tl-wdr4300

Follow the tutorial on the TP-Link forums...

Rename the stock firmware file wdr4300v1_tp_recovery.bin

That thread and the wiki link I posted above both suggest that you might need to strip the factory firmware in some way before it really works. @daggs read carefully, I really don't know what is needed. The TFTP instructions are probably correct at least, but I'm not sure if the stripping instructions on the old openwrt wiki are still valid with current firmwares etc.

I have used the TP-Link forum tutorial successfully on Archer C7 v2's.

Others on the LEDE forum have used it successfully for other TP-Link models.

With the raw firmwares from tp-link? or with the stripped ones from the post #7 on that thread? or something else?

http://forum.tp-link.com/showthread.php?81462-How-to-recovery-the-router-when-you-bricked-it&p=186550&viewfull=1#post186550

Raw firmware from TP-Link...

If you can find the correct model and version on FriedZombie, it can be flashed through the web GUI.

ok, the method worked but the router reboots always.
I suspect that it is because I have the special il router and I tried to flush it to the latest us fw.
anyone knows how I can do that?