True, but I just back-tracked to see that SFE is included in this device's config in DD-WRT and it would be interesting to see what the impact of enabling vs. disabling it would be. There are probably plenty of issues with hardware drivers that have not been addressed - mostly IRT DD-WRT in general. I have noticed that some of the stock firmware code was different IRT DD-WRT, but not IRT upstream kernel commits.
Joined: 08 May 2018 Posts: 14208 Location: Texas, USA
Posted: Thu Sep 23, 2021 14:10 Post subject:
I already alluded to shortcut forwarding engine (SFE) in newer releases. Test whatever you want. You chimed in as I was editing my previous post, anyway.
kernel-panic69 wrote:
True, but I just back-tracked to see that SFE is included in this device's config in DD-WRT and it would be interesting to see what the impact of enabling vs. disabling it would be. There are probably plenty of issues with hardware drivers that have not been addressed - mostly IRT DD-WRT in general. I have noticed that some of the stock firmware code was different IRT DD-WRT, but not IRT upstream kernel commits. But again, we're talking about a device whose stock firmware includes a Linux 2.4 kernel vs a custom firmware that includes a patched Linux 3.2 kernel. I can almost guarantee you that the hardware drivers have code differences, most likely.
I would go as far as making an attempt at doing a special build with DD-WRT's Linux 2.4 or 2.6 kernel for this device, but it would take longer than it's worth, most likely. That, and anything I would share would get me in trouble because it would violate the GPL. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
i would be limited to GUI settings or telnet commands. if any ideas or recommended methods to try.
kernel-panic69 wrote:
I already alluded to shortcut forwarding engine (SFE) in newer releases. Test whatever you want. You chimed in as I was editing my previous post, anyway.
kernel-panic69 wrote:
True, but I just back-tracked to see that SFE is included in this device's config in DD-WRT and it would be interesting to see what the impact of enabling vs. disabling it would be. There are probably plenty of issues with hardware drivers that have not been addressed - mostly IRT DD-WRT in general. I have noticed that some of the stock firmware code was different IRT DD-WRT, but not IRT upstream kernel commits. But again, we're talking about a device whose stock firmware includes a Linux 2.4 kernel vs a custom firmware that includes a patched Linux 3.2 kernel. I can almost guarantee you that the hardware drivers have code differences, most likely.
I would go as far as making an attempt at doing a special build with DD-WRT's Linux 2.4 or 2.6 kernel for this device, but it would take longer than it's worth, most likely. That, and anything I would share would get me in trouble because it would violate the GPL.
Software NAT needs a lot of CPU resources.
Therefore it is weird to run an additional unnecessary second NAT on a router with a 180Mhz CPU.
This is exactly the opposite of performance
what do you mean...second nat? im not running a second nat on ddwrt. nor wireless as i just explained its a wired test. wiresless wouldnt be running if ddwrt isnt booted.
the issue happens during boot. before the ddwrt boots up.
the WAN port on the ddwrt is connect to a network with internet that is totally separate has a different ip range and only to provide internet.
i found it odd that the pc on the lan port of ddwrt router is given an ip from the other network via the wan port of the ddwrt router while its rebooting.
which is like bypassing the ddwrt router
ho1Aetoo wrote:
ho1Aetoo wrote:
Software NAT needs a lot of CPU resources.
Therefore it is weird to run an additional unnecessary second NAT on a router with a 180Mhz CPU.
This is exactly the opposite of performance
you have linked up the dd-wrt router via the WAN Port
and the router certainly also not configured as WAP
of course there is a second NAT running on the dd-wrt router, the traffic goes through the CPU, maybe there is even a second firewall running
i dont see how this has anything to do with the issue. the ddwrt router has no idea its behind another router it just sees the internet on that port. it makes no difference as i have already explained using the stock dlink firmware runs at full speed no issue in the exact same layout
and that just a (unnecessary) double NAT - as I have already written several times
i have the exact same setup running stock same dlink300. no speed issues at all
maybe you should just buy a router that meets your expectations
i already have other routers, as i already said this is about finding the issue not an excuse to buy another router. running at half the stock speed wired is more then just "and old router" issue
the DIR-300 obviously doesn't do it and it's not hard to find a cheap router that has at least 50Mbit WAN/LAN throughput
if anything ddwrt just cant do it, and no one knows why.... the stock dlink can do it just fine.
if anything ddwrt just cant do it, and no one knows why.... the stock dlink can do it just fine.
Stock Firmware uses CLOSED SOURCE code.
What this means is that this is code not shared with the general public and is made availible only to the manufacture that made it.
dd-wrt firmware uses OPEN SOURCE code.
This means this is code that is made open to the general public but may not perform as well the stock firmware.
Since you do not understand why we keep recommending you to buy a better router I will tell you.
The reason why we keep recommending you to buy a better router is because it will have a slightly faster CPU And memory to handle dd-wrt firmware itself.
Stock firmware is no issue for these routers because the manufacture had literally EVERYTHING to make it as light and as fast as possible.
DD-WRT firmware has issues with these sorts of things because the dd-wrt developers do not have everything they need to get it working on the same level as stock firmware.
So at the end of the day, Stock Firmware and dd-wrt firmware do trade blows with eachother on what they can do.
Think of it this way.
Manufacture stock Firmware strengths are SPEED FOCUSED. Features and Functionality come second.
dd-wrts firmware, in my own observation, is FEATURES/FUNCTION focused first, Speed focused second.
The reason why dd-wrt is slow is because the developers do not have the same tools and code to bring it up to the same level of WAN speed as the manufactures stock firmware.
dd-wrt would be as fast as manufactures stock firmware if it had the same tools and code as the manufacture of that device but it does not.
i can understand that, but not that its more then half as slow as the stock on the wired tests.
i would expect to see high cpu load or something to back your claim that its because a slow cpu, but as i said before i think its a config mismatch issue causing the problem.
i only want to verify what it is.
further to that, the first firmware wiki says to flash 2008 has a more stable speed then anything after it which leave me to think a setting issue.
Gameman Advanced Kid wrote:
tgvrfcedx wrote:
if anything ddwrt just cant do it, and no one knows why.... the stock dlink can do it just fine.
Stock Firmware uses CLOSED SOURCE code.
What this means is that this is code not shared with the general public and is made availible only to the manufacture that made it.
dd-wrt firmware uses OPEN SOURCE code.
This means this is code that is made open to the general public but may not perform as well the stock firmware.
Since you do not understand why we keep recommending you to buy a better router I will tell you.
The reason why we keep recommending you to buy a better router is because it will have a slightly faster CPU And memory to handle dd-wrt firmware itself.
Stock firmware is no issue for these routers because the manufacture had literally EVERYTHING to make it as light and as fast as possible.
DD-WRT firmware has issues with these sorts of things because the dd-wrt developers do not have everything they need to get it working on the same level as stock firmware.
So at the end of the day, Stock Firmware and dd-wrt firmware do trade blows with eachother on what they can do.
Think of it this way.
Manufacture stock Firmware strengths are SPEED FOCUSED. Features and Functionality come second.
dd-wrts firmware, in my own observation, is FEATURES/FUNCTION focused first, Speed focused second.
The reason why dd-wrt is slow is because the developers do not have the same tools and code to bring it up to the same level of WAN speed as the manufactures stock firmware.
dd-wrt would be as fast as manufactures stock firmware if it had the same tools and code as the manufacture of that device but it does not.
Have you tried flashing suggested firmware that actually did get you faster firmware speeds?
If so, maybe you can share that, brainslayer can go back and take a look at it and see about getting this fixed. If possible. _________________ For people who are new to the dd-wrt forums >> http://www.catb.org/~esr/faqs/smart-questions.html#rtfm
barryware wrote:
It takes a "community" to raise a router..
Internet Connection 1
Some Techicolor modem > Linksys WRT3200ACM
Internet connection 2
Ubiquiti Powerbeam Gen 2 > Netgear R9000
Official (but not really) dd-wrt General Discussion element/matrix chat
this guy is trolling - complete waste of time
we have told him all this several times and what we tell him is completely ignored
the guy has 80-90% sirq and now claims again he has no exorbitant high load ^^
best to ignore all his topics and posts
I have also written several times what the problem is
ho1Aetoo wrote:
I think that's a problem with the ar2313 network driver. It just seems to have terrible speeds when receiving packets. If you look at "top" while doing a large transfer, you will get near 100% in software interrupts. I cannot get more than about 20 Mbit/s if it goes through software.
but hey! let's just ignore that and write 100x that the stock firmware is faster (like on 90% of the routers) and claim it's just a simple setting and not a CPU and driver problem
and by the way, the quote is from openwrt - so no pure dd-wrt problem - but a general problem with the opensource drivers
...you could configure the router (as already written 10 times) also as WAP and do without the unnecessary double NAT
then at least the problem with the cable speed would be solved
because then LAN traffic flows only over the Swicht fabric and not through the CPU - but hey! let's just ignore that too
