PS4 LAG with test results!

[L&LD]

Your testing does not seem to be very systematic. You are creating as many possible bugs as there are in the firmware, I suspect, by jumping back and forth on different firmware forks.

 

[dfran1]

I am trying to fix the no wan after a reboot, not the ps4 at the moment (but it works well now the ps4 that is)
just trying to prove what I have did already test (reproduce the same results) and make sure it was just merlin's builds as it is. This does not take rocket science to prove. Of course the next statement by someone will be "nobody else complains of it". Maybe just maybe my problem is someone elses different problem.

 

[KevTech]

Do you also have a setting at USB Application > 3G/4G?

I have this on the RT-N66U and have Enable USB Modem set to no.

 

[dfran1]

Do you also have a setting at USB Application > 3G/4G?

I have this on the RT-N66U and have Enable USB Modem set to no.

Thank you, It was on, I shut it off and still same problem, I have to hit the WAN apply to get WAN access, but it sounded like it would work. thanks.

 

[dfran1]

Anyone have any Ideas on why I get no WAN until I hit apply after a reboot with merlins firmware?

As far as PS4 lag free settings see this post.
http://www.snbforums.com/threads/dd-wrt-for-rt-ac87r.22421/page-12#post-173031

 

[RMerlin]

Anyone have any Ideas on why I get no WAN until I hit apply after a reboot with merlins firmware?

As far as PS4 lag free settings see this post.
http://www.snbforums.com/threads/dd-wrt-for-rt-ac87r.22421/page-12#post-173031

I don't have the time to dig through your logs because I'm already backlogged with other issues. However there's a chance that one of those issues I've finally tracked down could be related to your boot time issue. Can you give this test build a try?

http://www.mediafire.com/download/rso26r5zb8g9sh8/RT-AC87U_3.0.0.4_378.52_alpha3.zip

Make sure not to confuse that build with the one posted by someone else - this is based on newer development code. The build date on the Sysinfo page should report it was built today, from user merlin@somevalue.

 

[dfran1]

I don't have the time to dig through your logs because I'm already backlogged with other issues. However there's a chance that one of those issues I've finally tracked down could be related to your boot time issue. Can you give this test build a try?

http://www.mediafire.com/download/rso26r5zb8g9sh8/RT-AC87U_3.0.0.4_378.52_alpha3.zip

Make sure not to confuse that build with the one posted by someone else - this is based on newer development code. The build date on the Sysinfo page should report it was built today, from user merlin@somevalue.

!!!!!!THANK YOU it works!!!!

 

[DaveMishSr]

Your testing does not seem to be very systematic. You are creating as many possible bugs as there are in the firmware, I suspect, by jumping back and forth on different firmware forks.

I agree completely with L&LD. If it were me, I would stay with the 1-20-2015 version of DD-WRT which you claim is the most stable of all the firmwares out there and give your router a break for an extended period. Your poor router, after all these hard resets and flashings, it must have had some of its service life used up in a relatively short period of time. NVRAM has a limit on how many times it can be overwritten & formatted IIRC. However, I have no idea what those limitations might be.

 

[dfran1]

I agree completely with L&LD. If it were me, I would stay with the 1-20-2015 version of DD-WRT which you claim is the most stable of all the firmwares out there and give your router a break for an extended period. Your poor router, after all these hard resets and flashings, it must have had some of its service life used up in a relatively short period of time. NVRAM has a limit on how many times it can be overwritten & formatted IIRC. However, I have no idea what those limitations might be.

I am going to stay with the one RMerlin posted here, everything seems to be great, finally!!


edit:
nvram = around 100,000 rewrites before memory begins to deteriorate
http://en.wikipedia.org/wiki/Non-volatile_random-access_memory

 

[RMerlin]

!!!!!!THANK YOU it works!!!!

Cool

The short version:

The Quantenna service takes so much time to start that some other service starts are skipped, so I told the router to wait a LONG time before giving up waiting.

The long version:

Asuswrt uses a notification system to instruct the primary rc daemon. When an applet (for instance the dhcp client) needs to restart a service, it notifies the rc daemon to do so. That daemon can only handle one service at a time, so if there's one already queued for starting, the second request will wait up to a specific amount of time of time, after which it will just skip it if by then it hasn't had a chance to run yet.

When I originally implemented support for the RT-AC87U, I saw that some services were failing to start because the Quantenna service was taking too long to start (as it has to wait for the whole Quantenna firmware to boot). That wasn't really an issue for users because, true pure luck, the failed service actually had another occasion to be started during the boot process.

What I did at the time was increase the default delay from 15 seconds to 30 seconds, which was enough to let those services start (it needed something like 23 or 25 seconds if I recall).

Now for some reason (remember it's all about luck and timing), it was now the firewall that was failing its initial attempt at starting - 30 seconds wasn't enough.

What I did was, I modified the notification system. If a notification gets queued and the Quantenna service isn't flagged as being ready yet, then I automatically bump the wait time from 30 to 90 seconds (more than enough - it needed 45 seconds actually). And if the Quantenna service is already started (or if it's not a Quantenna-based router), then the default wait time is back to 20 seconds (down from my original 30, but still a bit more than Asus's own 15 seconds), to ensure there's no impact on the rest of the router's functionality.

For most users, the firewall start issue didn't cause any problem, since other firmware events were causing the firewall to get started later on. However, it was causing a lot of error messages from miniupnpd, which was then starting before the firewall. That was the particular issue I was researching these past few days, and it led me to suspect that it might be the root cause of your particular problem as well (that would explain why a manual WAN restart worked - the firewall had been started long ago by the time you did that).

Ideally, the whole notification system of Asuswrt would need to be revamped. Tomato's original system wasn't really intended to use with so many related services starting at boot time. What would be needed is a real queue system, where more than one service can sit in the queue. But such changes are beyond the scope of this project, as they would require some major re-engineering of the firmware architecture.

 

[RMerlin]

Your poor router, after all these hard resets and flashings, it must have had some of its service life used up in a relatively short period of time. NVRAM has a limit on how many times it can be overwritten & formatted IIRC. However, I have no idea what those limitations might be.

I'm willing to wager that nobody on these forums flashed their routers more often than I did.

 

[dfran1]

WOW , there is absolutely no VLAN errors anymore either!!
Boy did this fix a lot, people are going to be very happy!! I think this router is (I am going to go on the edge here, a week of test I will know for sure) perfect now with your firmware

 

[ahduck]

Cool

The short version:

The long version:.

This Alpha3 version seems ways better than the 378.51_newqtn.
As I'm using dual wan failover, I always getting DC on my Primary Wan0 causing very frequent internet disruption (like almost every 5mins)

Mar 22 23:00:34 miniupnpd[27876]: shutting down MiniUPnPd
Mar 22 23:00:34 miniupnpd[27947]: HTTP listening on port 49929
Mar 22 23:00:34 miniupnpd[27947]: Listening for NAT-PMP/PCP traffic on port 5351
Mar 22 23:00:39 WAN(0) Connection: WAN was restored.
Mar 22 23:01:20 WAN(0) Connection: ISP's DHCP did not function properly.
Mar 22 23:03:29 miniupnpd[28078]: shutting down MiniUPnPd
Mar 22 23:03:29 miniupnpd[28151]: HTTP listening on port 57350
Mar 22 23:03:29 miniupnpd[28151]: Listening for NAT-PMP/PCP traffic on port 5351
Mar 22 23:03:34 WAN(0) Connection: WAN was restored.
Mar 22 23:11:27 WAN(0) Connection: ISP's DHCP did not function properly.
Mar 22 23:13:26 miniupnpd[28641]: shutting down MiniUPnPd
Mar 22 23:13:26 miniupnpd[28714]: HTTP listening on port 37289
Mar 22 23:13:26 miniupnpd[28714]: Listening for NAT-PMP/PCP traffic on port 5351
Mar 22 23:13:31 WAN(0) Connection: WAN was restored.
Mar 22 23:14:11 WAN(0) Connection: ISP's DHCP did not function properly.
Mar 22 23:16:07 miniupnpd[28846]: shutting down MiniUPnPd
Mar 22 23:16:07 miniupnpd[28918]: HTTP listening on port 49130
Mar 22 23:16:07 miniupnpd[28918]: Listening for NAT-PMP/PCP traffic on port 5351
Mar 22 23:16:12 WAN(0) Connection: WAN was restored.
Mar 22 23:16:47 WAN(0) Connection: ISP's DHCP did not function properly.
Mar 22 23:18:41 miniupnpd[29010]: shutting down MiniUPnPd
Mar 22 23:18:41 miniupnpd[29118]: HTTP listening on port 51632
Mar 22 23:18:41 miniupnpd[29118]: Listening for NAT-PMP/PCP traffic on port 5351
Mar 22 23:18:46 WAN(0) Connection: WAN was restored.
Mar 22 23:23:08 WAN(0) Connection: ISP's DHCP did not function properly.

Thanks Eric..

 

[dfran1]

I am 25 hours in
-no reboot and WAN loss
-no lag on the PS4
-fast usb speeds (tho I did find something with this, been there for a while, but it does do it with official asus and dd-wrt soo...)
-The media server has not disappeared.
-the WIFI to LAN device control has been perfect.
-no wifi loss or drops detected.
So far this firmware is a masterpiece
Thank You Merlin! (I know asus fixed stuff also)
will post back with time results, hopefully everything stays perfect.

 

[bodean]

As a side note. I do not have a PS4, but an XBOX one, and have no lag. However, I noticed on .51 FW, a lot of wifi drops. I have an ecobee 3 thermostat, and 5-6 times a day it looses connection with my wireless sensors that came with it (which are on the 2.4GHz SSID). Also any mobile devices would need to be reconnected. I put this alpha on, and the problem seems to be solved. So something definitely got fixed and has improved over .51 stable release

 

[dpeterson]

Any chance I can go straight to this from .51 Beta without resetting everything?

 

[bodean]

Any chance I can go straight to this from .51 Beta without resetting everything?

Yes


Sent from my iPhone using Tapatalk

 

[VANT]

I don't have the time to dig through your logs because I'm already backlogged with other issues. However there's a chance that one of those issues I've finally tracked down could be related to your boot time issue. Can you give this test build a try?

http://www.mediafire.com/download/rso26r5zb8g9sh8/RT-AC87U_3.0.0.4_378.52_alpha3.zip

Make sure not to confuse that build with the one posted by someone else - this is based on newer development code. The build date on the Sysinfo page should report it was built today, from user merlin@somevalue.

i can say only one word. GREAT !!!!
Now my problem (in this thread with internet acces after restart is gone. Router works pefrect.
Thanks RMerlin for this FW.

 

[dfran1]

I am now 2 days and 30 minutes in and still perfect!!!

Here are my settings, Thanks to dsring for a lot of great info and thanks to RMerlin for a great firmware

WIFI page
-enable IGMP Snooping on 5GHz
-Short Preamble, DTIM Interval @ 1, and Beacon Interval @ 50 on both wireless bands
-Beam Forming is off, both bands

LAN page
- IPTV tab, and enable both IGMP Proxy and IGMP Snooping, and set the DHCP Routes to RFC3442 & Microsoft
- Switch Control Page - NAT Acceleration, Spanning Tree Protocol, and Enable Jumbo Frames to enable (dsring disables NAT Acceleration and Spanning Tree Protocol)

DMZ to ps4

WAN Page
- OpenDNS Family DNS servers (208.67.222.123 & 208.67.220.123)
- set DHCP Query Frequency to Normal (I need this, some do not)
- UPNP Allowed internal & external port range set from 1 to 65535.

NAT Passthrough page
- All options are Enabled


Firewall Page
dsring disables NAT Loopback (I leave it at merlin)

 

[bluepoint]

DMZ to ps4

WAN Page
- OpenDNS Family DNS servers (208.67.222.123 & 208.67.220.123)
- set DHCP Query Frequency to Normal (I need this, some do not)
- UPNP Allowed internal & external port range set from 1 to 65535.

What's the ps4's DMZ setting for if UPnP is enabled?