EA8500
DD-WRT v3.0-r40459 std (07/30/19)
Linux 4.9.186 #350 SMP Mon Jul 29 01:29:28 CEST 2019 armv7l
No Reset
switch / ovpn server / samba share ext4
Uptime 7:29
working ok
#
WNDR3700v4
DD-WRT v3.0-r40459 std (07/30/19)
Linux 3.18.140 #48646 Tue Jul 30 05:52:50 +04 2019 mips
No Reset
switch / ovpn server / samba share ext4
Uptime 11:29
working ok
#
WRT160NL
DD-WRT v3.0-r40459 std (07/30/19)
Linux 3.10.108-d8 #16640 Tue Jul 30 03:52:49 +04 2019 mips
switch / samba share
Reset & reconfig.
Got rid of the stupid USB SanDisk flash drive that has the built-in 1st partition as a read-only like a CD ROM.
Using a good/much better 16GB USB flash drive and that made all the goofy dmesg go away.
all good
Joined: 08 May 2018 Posts: 14246 Location: Texas, USA
Posted: Wed Jul 31, 2019 0:49 Post subject:
bdg2 wrote:
Weird.
Why isn't changeset 40459 showing in the timeline yet?
My guess is it wasn't pushed to the main repo prior to compiling the builds, or rather, svn / trac was not updated. I just did an svn update, and it's there in the local repo. BUT, I was trying to 'fix' something and well... it's going to take a few days to get that machine back
I'm convinced that windows 8.1 & 10 have the crappiest wired network stack there is... some days I get good bufferbloat scores on the wired machine, other days it looks like this. I have given up on trying to tweak it.
Nothing I have tweaked seems to change it.
And I have spent countless hours making tweaks. Long and short is I think it's both the NIC and Windows 8.1
Perhaps it could be that MTU settings on the router are not getting applied the right way, but that's not a priority for BS at this time...nor is it serious enough.
https://svn.dd-wrt.com/ticket/6710 _________________ FORUM RULES
I'm convinced that windows 8.1 & 10 have the crappiest wired network stack there is... some days I get good bufferbloat scores on the wired machine, other days it looks like this. I have given up on trying to tweak it.
Nothing I have tweaked seems to change it.
And I have spent countless hours making tweaks. Long and short is I think it's both the NIC and Windows 8.1
Perhaps it could be that MTU settings on the router are not getting applied the right way, but that's not a priority for BS at this time...nor is it serious enough.
https://svn.dd-wrt.com/ticket/6710
its not windows 10, its BS builds for alpine & ipq806x, theres a problem in the kernal with qos latency in k4.x. txqueuelen does absolutely nothing for me (and it overrides gui setting anyway for some routers, manually forcing in ifconfig doesnt stick well but still has no effect).
what was the qos settings used?
when i try BS builds again on r7800 i go from this https://www.dslreports.com/speedtest/52546187 (entered is 320mbps/15.6mbps)
to something similar to urs (ethernet/wifi dont matter, and cpu load is far higher too creating artificial throughput limits) _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Routers: TP-Link TL-WR841n v7.2
Upgrade: via web
Firmware: v3.0-r40459 std (07/30/19)
Kernel: 3.10.108-d8 #16672 Tue Jul 30 04:26:18 +04 2019 mips
Previous: 40134
Mode: Access Point
Reset: No
Errors:
- random reboot, strangely when router is idle.
- more than 100% CPU load in router status page.
Joined: 18 Mar 2014 Posts: 12916 Location: Netherlands
Posted: Thu Aug 01, 2019 13:22 Post subject:
Router Model: Netgear R7800
Firmware Version: DD-WRT v3.0-r40459 std (07/30/19)
Kernel Version: Linux 4.9.186 #361 SMP Mon Jul 29 00:26:38 CEST 2019 armv7l
Upgraded from: DD-WRT v3.0-r40439 std (07/26/19)
Reset: No not this time
Status: Up and running for 8 hours, basic setup as Gateway, static leases, OpenVPN client (on PIA) with Policy Based Routing up and running, 2,4GHz, 5Ghz USB storage NAS and OpenVPN server working
Resolved:
1. VPN works with QoS enabled (I did not test that extensively)
2. Pushed DNS servers from VPN provider are now used, if you do not want that, add the following to the Additional Config of the VPN client:
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Thu Aug 01, 2019 15:08 Post subject:
tatsuya46 wrote:
its not windows 10, its BS builds for alpine & ipq806x, theres a problem in the kernal with qos latency in k4.x. txqueuelen does absolutely nothing for me (and it overrides gui setting anyway for some routers, manually forcing in ifconfig doesnt stick well but still has no effect).
what was the qos settings used?
For Q.o.S. I've been sticking to HTB and FQ since it seems to yield the most consistent results during testing. I've spent countless hours playing with the various options and this seems best for me on comcast 150/10 (180/12 over-provisioned). I know you swear by HTB & PIE. For me, they all yielded nearly the same performance. Did Kong's HTB fix ever make it into BS commits? And since I am on the R9000 cpu usage never spikes like it does on the R7800; quad core vs dual... It really does make a difference.
I'll see if I can find my results from the 2019 May & June builds, but when I tried running KongPro (OpenWRT) on the R7800 I had the same craptastic results on the wired side...lot's of added latency. And I was running cake. It was this fact, and the lack of QAM256 on 2.4ghz, that I reverted back to my R9000 using dd-wrt.
I can try and load up the R7800 with the 7-11-19 release to demonstrate the issue when I have more time this weekend to prove the point.
Is it possible that Linux has crap drivers for the IPQ8065 & QCA8337 chips used on the R7800 & R9000? I assume that both OpenWRT and DD-WRT have access to the most recent drivers and that BS has "even better" drivers available/implemented with his special NDA's?
Can you point me to the "fix" that Kong uses to make latency lower than BS builds? I would think that if we can provide some data/empirical results to BS in a well formatted way- he'll commit the "fix" Kong uses in his builds. I know BS has implemented some changes on the R9000 based on data I sent him in the past.
...And perhaps some of the issue is that BS doesn't have "gig" speed available to corroborate our reports and his "lab" testing isn't revealing the "real world" results some of us are posting... I would be hesitant to implement changes too... I know it's frustrating, and I'm sure you've provided proof... I think we'll get to the bottom of this eventually, but for sure it's plaguing OpenWrt too. _________________ FORUM RULES
