I am having a fiber connection 1Gbit .... I only get 300 mbps because of OpenWRT lazy developers to try to workaround this issue. Is very important . Aggravating important. But who cares? The manufactures released a code , a bit dirty , but that's a dev job to make it cleaner as much as they can . But no, who cares? Nobody.

You guys are stuck in 2010 . We are in 2015 where high speeds are so regular. So do something about that. I have an Archer C5 and it's useless on OpenWRT ....is just another 10$ router. When I switch to stock it can see it's value . Stop circlejerking and do something useful . I've been a user of OpenWRT for over 7 years . Now with Archer C5 there is no difference as performance between BB & CC also. So what you guys did actually in this time? To improve the performance ? Like literally give me 1 example of improved performance between BB & CC ? Nothing!  At least concentrate on NAT Hardware Acceleration.

Difference? Yes there is

Stock Firmware:

Chaos Calmer Open WRT:

What developers will do about this? Nothing simple nothing. They will say that a 720 MHZ processor is crap. Nothing more. They won't look at the shit in their yard.

(Last edited by spirymedia on 1 Oct 2015, 19:19)

This is completely unacceptable.

I have the same issue with TP-Link 4300 - with default stock firmware - with vlan tag support malay firmware. I could reach 200/100 on my ftth connection ... so far so good.

I can do the same with 12.09 AA on the same hardware ... no problem.

on BB or CC only reach 120/100 because of what ??? hardware nat missing ... as the hardware is able to almost 800 from wan-to-lan.

(Last edited by ygor.almeida on 2 Oct 2015, 00:28)

Hey there.

I must confess I prepared one hell of a response and it took me quite some time to realize this whole thread was a joke.

But when I came to that conclusion I had a great deal of fun thinking about how stupid my response would have been if sended.

Thank you for that, it realy made me laugh a lot.

Regards,
Stephan.

Hey, we have the same ISP I am on their Hungarian service.

I must admit, the speed through my OpenWRT router is very dissapointing .

(Last edited by Degeneratescum on 2 Oct 2015, 04:02)

Maybe you need to send a fat check to the developers before whipping them.

Or learn to code and/or submit patches/workarounds before whining.

Edit: In here, no one owes anyone anything.

(Last edited by headless.cross on 2 Oct 2015, 07:54)

Well people should be aware what OpenWRT devs can't do and is important.  It can't  be ignored forever. Why ? Well it's simple the speeds and technologies are moving over. Meanwhile OpenWRT its becoming useless ofc due to More Law . I am no developer but I know how an open source projects work out that's why I donate once a year. Well anyway have a good laugh. But this is really an important issue .

Interesting. I have yet to see an Open Source project that is moved forward by users insulting the devs.

(Last edited by metai on 6 Oct 2015, 06:36)

Bitcoin . But whatever. Yeah well kinda OpenWRT devs literally didn't do anything for performance in the last years. I've been using for some time OpenWRT on all routers I ever had.

So yeah ..... really 0 change. But if they want to make a serious change they should get onto this. Else ...no fun as my topic said.

Well then, I guess we have to thank you for your invaluable contribution.

(Last edited by metai on 5 Oct 2015, 03:36)

I think you are making a grave mistake by accusing the devs of not giving a damn. There is a perfectly good explanation on why hardware NAT is not implemented. There is a ticket somewhere, and if I recall correctly the solution used in the stock firmware depends on a binary blob which is full of bugs. So basically, you will run into problems even on stock firmware. There is no way to "clean up" the code like you say, because it's not open source. Your post is ignorant at best, as a long time user of OpenWRT you should be aware of the amazing job the devs do. They might not be the best at focusing on community and documentation, but their code is top notch and they are quite hard at work IMO

As routers become more and more powerful hardware NAT is less of an issue. Look at my answer in your other thread, there is the Netgear R8000 that should be able to do quite high speeds with software NAT.

So OpenWRT is an opensource project, what have you done to contribute to this community and its software? mind you, whining about functions that are not working (yet) does not count...

have you done any research? have you contributed any code? have you even read the forums..? as of now you have a whole 6 posts on this forum...

If you want faster NAT buy more powerful hardware.  Hardware accelerated NAT isn't a good idea.

Maybe it's not clear yet, why this isn't an easy task for a handful of OpenWrt developers: supporting hardware-NAT alone is not enough to speed up anything, that's because the linux networking stack wasn't invented for forwarding packets...

what the router-manufacturers do: they choose a random (most of the time: old and outdated) kernel version, then hack together a "fastpath" networking stack and of cause never release the sources for that... even if we had a source/patch for this, it would never be easy to port it to newer kernel versions or anything...

i mean, you're calling them "lazy developers", but if i look at that 200KB kernel module on my edgerouter-lite (they're using a precompiled proprietary kernel module from the soc vendor, octeon)... i means that's HUGE, they must have spent quite a lot of man-hours to that

(Last edited by nortii on 5 Oct 2015, 14:03)

Here's a relevant ticket: https://dev.openwrt.org/ticket/11779

What's clear is that this subject for some reason attracts furious noobs that absolutely refuse to read any replies they get and instead choose to insult the devs

Oh, I'm not a betting man, but I'd wager that the OP has been active in that ticket a few days ago.

I wouldn't bet against you either

But I have to say the Network Stack of openwrt is going slower with each release.
What happen is that they like to add new daemons and processes with each release so the weak mips processors have to do more context switch between more of them.
In addition I disagree with the claims that hardware NAT is a ugly hack.
The fact is that relying on software implementation is not scalable.
Sure NAT might be fast on Single Client but when you throw in many Clients the number of connections goes up and the NAT performance will drop even harder than a falling rock.
Which is why Linaro is starting a Network Group to implement hardware NAT interfacing with Linux Network stack.

(Last edited by alphasparc on 5 Oct 2015, 15:28)

i don't think so, user space has always lower priority than kernel stuff (e.g. networking), it's the linux networking stack which gets slower

i think the right address to complain (or send feature request to) would be linux-netdev, not openwrt

There was once we narrowed down the NAT performance impact because a new Openwrt Daemon (odhcpd) was listening unnecessarily on network sockets. Killing odhcpd speeds up NAT.

Now I can't even kill any of these process to do testing ubus will restart it quickly.
All these daemon are now using CMake, I am not sure if they produce optimized MIPS binaries.

My repeated testing also reveals that performance is not deterministic, meaning that selection of different packages in binaries produce wildly different performance, I am not sure if the loading of kernel modules at various addresses cause this, can't test this either.

(Last edited by alphasparc on 5 Oct 2015, 15:42)

openwrt is getting slower could we gang up and crowd fund for some work on speeding up openwrt or all just donate to openwrt?

Need better tools to analyse MIPS network processing to improve performance as well as leverage on any HW assisted processing possible we cannot afford to pretend everything that runs well on Intel will run well for other processors.
Unless you want to buy new routers.

I strongly recommend you get involved with developers to support this feature.

Not that I am an expert, but part of the slow down is related to new functionality we have gained. Odhcpd makes native IPv6 connectivity (in the best case) as easy as plugging the wan cable into the openwrt router. Personally that is functionality I am willing to sacrifice a bit bandwidth to. Please also note that hardware NAT as a proposed solution falls short in the AQM department; while it would be nice to achieve higher NAT bandwidth this becomes irrelevant as long as AQM not NAT effectively limits the achievable throughput... Currently it seems that AQM requires a beefy CPU, and once you have that sufficient NAT performance comes as part of the territory. I realize that there is not a general consensus about these trade-offs though...

Best Regards
         M.