[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[fink.nottle]

@fink.nottle If you post the output of the following command we might be able to spot something.

nvram show | grep qos | sort

I'd also suggest that you change the default settings on DSLReports. Try testing from a single server that is closest to you, No. download streams = 3, No. upload streams = 1, enable Don't Geo-locate and Port 80 only.

I found that quite often the default settings will choose bad servers with poor response times, this gives variable and inaccurate results.

@ColinTaylor

With QoS disabled and the settings you recommended:

size: 42467 bytes (23069 left)
qos_ack=on
qos_addr_err=4
qos_burst0=
qos_burst1=
qos_bw_rulelist=
qos_default=3
qos_enable=0
qos_fin=off
qos_ibw=81920
qos_ibwopt=1
qos_icmp=on
qos_inuse=9
qos_irates=100,100,100,100,100,0,0,0,0,0
qos_method=0
qos_obw=8192
qos_orates=80-100,10-100,5-100,3-100,2-95,0-0,0-0,0-0,0-0,0-0
qos_orules=
qos_overhead=0
qos_r2q=
qos_reset=0
qos_rst=off
qos_rulelist=<Web Surf>>80>tcp>0~1536>0<HTTPS>>443>tcp>0~1536>0<File Transfer>>80>tcp>1536~>3<File Transfer>>443>tcp>1536~>3
qos_rulenum_x=0
qos_sched=2
qos_sfql=1
qos_sticky=1
qos_syn=on
qos_type=0



After enabling QoS (100/10 Mbps), and same settings in dsl test

size: 42461 bytes (23075 left)
qos_ack=on
qos_addr_err=2
qos_burst0=
qos_burst1=
qos_bw_rulelist=
qos_default=3
qos_enable=1
qos_fin=off
qos_ibw=102400
qos_ibwopt=1
qos_icmp=on
qos_inuse=9
qos_irates=100,100,100,100,100,0,0,0,0,0
qos_method=0
qos_obw=10240
qos_orates=80-100,10-100,5-100,3-100,2-95,0-0,0-0,0-0,0-0,0-0
qos_orules=
qos_overhead=0
qos_r2q=
qos_reset=0
qos_rst=off
qos_rulelist=<Web Surf>>80>tcp>0~1536>0<HTTPS>>443>tcp>0~1536>0<File Transfer>>80>tcp>1536~>3<File Transfer>>443>tcp>1536~>3
qos_rulenum_x=0
qos_sched=2
qos_sfql=1
qos_sticky=1
qos_syn=on
qos_type=0





I do think that with your settings, the bufferbloat looks a bit better in the dsl test. However, from a basic ping test while saturating download and upload, I still see that pings go up from ~12ms to > 50 ms when download is saturated (which is also what the dsl test shows). The upload is bit better behaved now. Even while saturating the upload channel, pings remain < 30 ms from what I can tell.

 

[xanadew]

can anyone point me to the directions to upgrade firmware from 20e9? not sure if I have to erase nvram and start over when upgrading, thanks.

 

[Gravityz]

Ehhhh. first page of this thread

you can upgrade from the fork version 20e9 to 22E3 without erasing anything.
just make sure you select the right firmware for your router

can anyone point me to the directions to upgrade firmware from 20e9? not sure if I have to erase nvram and start over when upgrading, thanks.

 

[ColinTaylor]

@fink.nottle Well those results look a lot better (i.e. consistent).

I can't see anything obviously out of place with your settings. When you do the speed test, if you click on the Results button you should see a "Grades" chart. Mine looks like this:

As an experiment try setting your bandwidth to 50/5 to see if that has a significant effect on things.

But honestly, I think any improvement is likely to come from your ISP upgrading their network.

 

[john9527]

I can't see anything obviously out of place with your settings. When you do the speed test, if you click on the Results button you should see a "Grades" chart. Mine looks like this:

@fink.nottle
I also don't see anything obviously wrong. One suggestion, might be to change the download percentages under priorities for the Low and Lowest priorities. I use 80% for Low and 50% for Lowest.

One other hint on DSL speedtest. When you go to the results page Colin mentions, if you click on Downloading or Uploading, you can see the individual samples taken during the test. Many time, there will be a single measurement that is out of place skewing the results. I'm still not sure if that is real or is an artifact of their test/network.

 

[fink.nottle]

@fink.nottle Well those results look a lot better (i.e. consistent).

I can't see anything obviously out of place with your settings. When you do the speed test, if you click on the Results button you should see a "Grades" chart. Mine looks like this:View attachment 8260
As an experiment try setting your bandwidth to 50/5 to see if that has a significant effect on things.

But honestly, I think any improvement is likely to come from your ISP upgrading their network.

@ColinTaylor , @john9527

So I had a look at the detailed results (it's a clickable link in my previous post), and it sort of confirms the observations. i.e. Pings are affected by download saturation, whereas upload saturation is a lot better. It looks like the QoS takes a while to react to download saturation. The trend in the bar graph looks like the pings progressively reduce with samples. Any way to make the reaction faster ?

These are the links again for reference:
Before: http://www.dslreports.com/speedtest/8851620
After: http://www.dslreports.com/speedtest/8852149

John, I'll try your recommended settings later today. I'll also try tomato, which I remember works well, but I'll confirm again. I don't mind digging into the code a bit, but is it possible to replicate tomato's behaviour on the fork ?

 

[john9527]

John, I'll try your recommended settings later today. I'll also try tomato, which I remember works well, but I'll confirm again. I don't mind digging into the code a bit, but is it possible to replicate tomato's behavior on the fork ?

Sorry, no. Different implementation. And tomato's implementation for ARM isn't also applicable to the MIPS based routers.

Just as a comment. Download is always the most difficult. You are trying to control something you really don't have control over (the server that is sending the data). A lot of it depends on the infrastructure of your ISP, which isn't always consistent even between nodes of the same ISP.

 

[john9527]

I pointed it out because on prev versions, any changes on this page resulted in 20% increments...guessing this change is because of dnscrypt.

No dual wan here and redirect setting is never which is default I believe. How about a full soft reboot for changes? I think it takes the same amount of time for that counter anyways...but I know it's a dirty fix for something non reproducible at your end

The 'timer' is just a fixed value entered into the webui. It was set at a ridiculously low 5 sec....so the ui would come back much sooner than the work was actually finished. The value I chose resulted in about a 50% reduction in time vs a reboot for ARM routers, MIPs is actually a bit faster. I made a change for the next release to dynamically set the time based on the normal reboot time.

I agree, with adguard dns it was a whole different level, the router would tell me wan was up but ddns couldn't update and neither could I access any website after making changes to any settings on the page. Fixed only after 2 reboots. Since then switched to dnscrypt.fr and eu servers.

I managed to recreate the situation you saw once...ui showing WAN down but it's actually up. Also when WAN down with no dns. I got it by enabling DNSSEC when I wasn't using a DNSSEC enabled DNS server. I've added a hint and popup help to the webui for DNSSEC to remind folks not to enable DNSSEC if not using DNSSEC servers.

 

[sbailey4]

Thanks, that worked just fine. Does future updates need to be installed using the recovery tool as well, or is that a one time "fix"?

Its a one time fix if you load the 380.x codebase. Any previous codebase you can downgrade normal way. Also upgrades are all fine going forward too. Just when going back from 380.x to something earlier is when this comes into play.

 

[john9527]

Its a one time fix if you load the 380.x codebase. Any previous codebase you can downgrade normal way. Also upgrades are all fine going forward too. Just when going back from 380.x to something earlier is when this comes into play.

@BuTTuS
Or said another way.....
Once on this fork (V18 or later), you can load any code, earlier or later, via the normal gui (do a factory reset after if it's other than another level of this fork)
If you load ASUS 380.3xxx or Merlin 380.60 or later, you will need the Recovery Tool to return to this fork (or any code earlier than those)

 

[Trebuin]

Good Morning John,
I think I made some headway, but not 100%. The issue may have been created by the master router. I ended up changing around some channels & restarting the router. I'm up 10 hours so far, & tonight will be the test that usually causes crashes. BTW, I just got this code:


Jan 13 12:59:58 RT-AC66R user.warn kernel: jffs2_flush_wbuf(): Write failed with -5
Jan 13 12:59:58 RT-AC66R user.notice kernel: Recovery of wbuf succeeded to 00700000
Jan 13 12:59:58 RT-AC66R user.notice kernel: Write of 1067 bytes at 0x00738f4c failed. returned -5, retlen 0
Jan 13 12:59:58 RT-AC66R user.notice kernel: Not marking the space at 0x00738f4c as dirty because the flash driver returned retlen zero

This happened right after I logged in. Any thoughts?

 

[john9527]

This happened right after I logged in. Any thoughts?

Ouch....looks like a hardware problem. Either flash or your power supply is going bad. If your router is around 2 years old, it seems that's when the increasing failure rate on the power supplies starts.

 

[Trebuin]

Ouch....looks like a hardware problem. Either flash or your power supply is going bad. If your router is around 2 years old, it seems that's when the increasing failure rate on the power supplies starts.

So if my router is vintage 2010 or 11, I'm screwed? Do you think this had to do with the reboots?

 

[john9527]

So if my router is vintage 2010 or 11, I'm screwed? Do you think this had to do with the reboots?

Not necessarily screwed....and yes, it could have to do with the reboots. My first step if I were you, would be to order a replacement PS from Amazon. They are pretty inexpensive and it would get that off the table as a possible problem.

 

[Trebuin]

Not necessarily screwed....and yes, it could have to do with the reboots. My first step if I were you, would be to order a replacement PS from Amazon. They are pretty inexpensive and it would get that off the table as a possible problem.

Would you recommend any brand or have a link with the correct tip size? Looking at these two:

https://www.amazon.com/dp/B004YIFOPK/?tag=snbforums-20

https://www.amazon.com/dp/B002UF648A/?tag=snbforums-20

 

[john9527]

Would you recommend any brand or have a link with the correct tip size?

Don't have any personal experience, but here's a post from someone who had good luck with a pwr+
http://www.snbforums.com/threads/rt-ac66u-increased-stability-after-replacing-power-supply.26326/

Seems like it may be this one on Amazon
https://www.amazon.com/dp/B00EMO9R5E/?tag=snbforums-20

 

[Trebuin]

Thanks. If I remember right, the voltage has to be exact, but the amps is the max the brick will supply. As they get old, that value drops and if the router needs near the max, that would explain the corruption. I'll have it by Sunday & let you know what happens.

Don't have any personal experience, but here's a post from someone who had good luck with a pwr+
http://www.snbforums.com/threads/rt-ac66u-increased-stability-after-replacing-power-supply.26326/

Seems like it may be this one on Amazon
https://www.amazon.com/dp/B00EMO9R5E/?tag=snbforums-20

 

[Gravityz]

is there a way to reset QOS statistics.
From the packet rate count i can tell if QOS is working or not but if you download a lot, which in my case has a low priority then the piechart does not reflect the priorities

when it can be reset you can see from scrap if things are working or not.

 

[john9527]

is there a way to reset QOS statistics.
From the packet rate count i can tell if QOS is working or not but if you download a lot, which in my case has a low priority then the piechart does not reflect the priorities

when it can be reset you can see from scrap if things are working or not.

I'll add a 'Reset' button to my todo list....in the meantime, log into the router and enter
/tmp/qos stop
/tmp/qos start

 

[Gravityz]

nice.
thanks, never to old to learn.

I'll add a 'Reset' button to my todo list....in the meantime, log into the router and enter
/tmp/qos stop
/tmp/qos start