Because Kong is out i did try the latest BS build on Netgear r7800 and was fully disappointed. The cake is not optimized for speed and i have up to 300mbs only out of my 570mbs ISP speed. The BS bufferbloat here is normally B compare to A and A+ on new Kong OpenWRT _________________ Netgear R7800
Posted: Thu Sep 05, 2019 15:07 Post subject: Re: TPlink router won't accept new upgrades
yaecon wrote:
I want to upgrade my TPlink router WD841N v9 from r40890 to r40900. Router is alive and works. However after choosing the proper upgrade file and clicking on UPGRADE nothing happens, message "UPGRADING ..." stays there for ever.
I've tried another WR841N v9 router and noticed this problem still exists with version r40900. Furthermore it appears that the SAVE and APPLY button do not work properly.
thats the bug on web gui
try r40863 cz on 940v6 web flash work ok
after upgrade to r40890 web flash cannot use upgrade to r40900
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Thu Sep 05, 2019 16:18 Post subject:
vit5421 wrote:
Because Kong is out i did try the latest BS build on Netgear r7800 and was fully disappointed. The cake is not optimized for speed and i have up to 300mbs only out of my 570mbs ISP speed. The BS bufferbloat here is normally B compare to A and A+ on new Kong OpenWRT
we need a QoSWRT to start up.. years and years of broken ipq806x latency.. _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
I tried CLI flashing, but that does not help. It looks like the image is too big for the dir615c1
Code:
root@DD-WRT2:/tmp# wget ftp://ftp.dd-wrt.com/betas/2019/09-04-2019-r40900/dlink
-dir615c1/dir615c1-firmware.bin
Connecting to ftp.dd-wrt.com (185.84.6.100:21)
dir615c1-firmware.bi 100% |********************************| 3780k 0:00:00 ETA
root@DD-WRT2:/tmp# write dir615c1-firmware.bin linux
Image too big for partition: linux
linux: Invalid argument
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Thu Sep 05, 2019 17:49 Post subject:
kernel-panic69 wrote:
tatsuya46 wrote:
we need a QoSWRT to start up.. years and years of broken ipq806x latency..
So when can we expect your first test build?
its technically been done already (kong), which is why its so irritating to see his already completed work, absent since its supposedly "already in the source" _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Thu Sep 05, 2019 19:11 Post subject:
tatsuya46 wrote:
kernel-panic69 wrote:
tatsuya46 wrote:
we need a QoSWRT to start up.. years and years of broken ipq806x latency..
So when can we expect your first test build?
its technically been done already (kong), which is why its so irritating to see his already completed work, absent since its supposedly "already in the source"
So, you have no local working copy or the source tree or development environment set up?
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Thu Sep 05, 2019 20:10 Post subject:
kernel-panic69 wrote:
tatsuya46 wrote:
kernel-panic69 wrote:
tatsuya46 wrote:
we need a QoSWRT to start up.. years and years of broken ipq806x latency..
So when can we expect your first test build?
its technically been done already (kong), which is why its so irritating to see his already completed work, absent since its supposedly "already in the source"
So, you have no local working copy or the source tree or development environment set up?
no if i knew linux alien language/code it would be done already. i say its supposedly already in source cause thats what kong told BS when he asked him, and BS told me that, *shrug*
k3.18 would probably fix all this.. and it cant be that terrible being eol since a ton of routers are still using it (and older kernals) _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Fri Sep 06, 2019 0:43 Post subject:
tatsuya46 wrote:
no if i knew linux alien language/code it would be done already. i say its supposedly already in source cause thats what kong told BS when he asked him, and BS told me that, *shrug*
k3.18 would probably fix all this.. and it cant be that terrible being eol since a ton of routers are still using it (and older kernals)
Joined: 21 Jan 2017 Posts: 1782 Location: Illinois Moderator
Posted: Fri Sep 06, 2019 3:11 Post subject:
MomenMamdouh wrote:
Builds from r40723 to r40900 are considered bad firmwares on TP-Link Archer C7 v2, because of enabling QoS settings will cause random reboots, and make the router unusable.I hope someone would create a ticket for that
How fast is your ISP speed? C7 and A7 seem to only be good to about 130-140mbps when using Q.o.S. otherwise you need to disable qos and turn on SFE.
Also, don't bother using cake or fq_codel_fast...not enough CPU to get much over 85-100mbps before you max out the cpu/soc.
HTB & Pie will get you up to about 135-140mbps down without maxing out the cpu/soc.
This is from extensive testing today on a A7v5 all day. with no crashes 40900. Not sure what soc the c7v2 has.
A7v5: CPU Model Qualcomm Atheros QCA9563 ver 1 rev 1.0 (0x1150)
CPU Cores1
CPU Features MIPS32r1 MIPS32r2 MIPS16
CPU Clock 775 MHz (seems overclocked from what I find on wikidevi having this at 750) _________________ FORUM RULES
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Fri Sep 06, 2019 5:21 Post subject:
msoengineer wrote:
MomenMamdouh wrote:
Builds from r40723 to r40900 are considered bad firmwares on TP-Link Archer C7 v2, because of enabling QoS settings will cause random reboots, and make the router unusable.I hope someone would create a ticket for that
How fast is your ISP speed? C7 and A7 seem to only be good to about 130-140mbps when using Q.o.S. otherwise you need to disable qos and turn on SFE.
Also, don't bother using cake or fq_codel_fast...not enough CPU to get much over 85-100mbps before you max out the cpu/soc.
HTB & Pie will get you up to about 135-140mbps down without maxing out the cpu/soc.
This is from extensive testing today on a A7v5 all day. with no crashes 40900. Not sure what soc the c7v2 has.
A7v5: CPU Model Qualcomm Atheros QCA9563 ver 1 rev 1.0 (0x1150)
CPU Cores1
CPU Features MIPS32r1 MIPS32r2 MIPS16
CPU Clock 775 MHz (seems overclocked from what I find on wikidevi having this at 750)
c7 is a tplink version of dlink dir-862L, with qca9558 @ 720mhz _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Fri Sep 06, 2019 6:41 Post subject:
msoengineer wrote:
tatsuya46 wrote:
c7 is a tplink version of dlink dir-862L, with qca9558 @ 720mhz
C7v5 and A7v5 are identical too, except for flash layout.
HTB & Pie work best on the C7v5/A7v5 on my comcast 180/12 line. I would imagine the same on the slightly slower 9558.
are you seeing random reboots Tatsuya?
i havent moved from the builds in my signature yet, everytime a release is made i see more qos related commits on svn, going to wait till they slow down before i poke BS with every stick i can find _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers