[384.12_Alpha - builds] Testing all variants.

[RMerlin]

wouldn't it be better to pause until the date has changed or a big timeout has passed (i.e 2 minutes) ? (current bypass with scripts is to wait until system year is at least 2019)

Better than what? I'm currently relying on an nvram flag that gets set by ntpd itself, you can't get any more reliable than that.

Checking the system date is a bad idea, as the default start date changes between models/firmware versions. Scripts should all rely on the nvram flag being set rather.

 

[FTC]

Better than what? I'm currently relying on an nvram flag that gets set by ntpd itself, you can't get any more reliable than that.

Checking the system date is a bad idea, as the default start date changes between models/firmware versions. Scripts should all rely on the nvram flag being set rather.

I see. Thought by your previous explanation that you had set a fixed pause, not one controlled by a variable set by ntpd sync. I agree that your solution is much more robust than my proposed one then.

 

[Nigel Jones]

Earlier I posted that I saw a performance regression between the original alpha 1 (g2) and alpha 1a (g4). Since then I've done a few more tests

The symptom was significantly lower downloads from ISP - down from around 380 Mbps to 150 Mbps

* I did a full factory reset - zero customizations. This made no difference
* I went back to an earlier firmware level - I found I had to go back to 384.11 to get it to 'stick'. Still getting 384/36 Mbps there
* Again going to alpha1 g4, and alpha2 g6 resulted in speeds around 150/37 at best - sometimes the download drops into the double digits
* CTF is enabled in both cases
* Earlier I did have some QOS controls active - for the recent tests these were disabled (as with a factory reset, and also with restored data)
* The CPU is not maxing out - between 1/3 and 1/2 on average across both cpus
* The 5Ghz-1 channel (running in the 40+ range) is normal speed, it is the 5Ghz-2 channel (running in the 100+ range) that is bad. Changing channels didn't help, and a scan shows nothing else in the 100+ range locally.
* Swapping the SSIDs keeps the problem with the 5Ghz-2 band
* Ethernet is not affected
* Nothing untoward I could see in the logs
* I repeated this loop of going back to earlier firmware, then reapplying about 3 times - with the same results each time.

I can only conclude that the latest AC3200 code has a performance problem with 5Ghz-2.

 

[FTC]

FWIW, previously with AC86U, & now with AX88U, Ntp issue:

My workaround is to use an IP address for ntp (IPv4 only, an IPv6 address doesn’t work, despite me having IPv6 available); & not enter anything as secondary ntp.
Using a domain name, or entering anything (ip, or domain) as secondary ntp, virtually guarantees I won’t get wan access after a reboot.

Using the workaround, I still sometimes get the problem, but a single further reboot usually fixes it. YMMV.

Great alternate bypass. It makes sense... I am in fact using a DNS service which is not 'optimal' in terms of speed, but provides a family filter that I find useful. Guess it may be contributing to the delay also (finding the ntp server address by name may be costing my router a precious time at boot).

 

[laracroftonline]

alpha 2 got me lots of disconnects.

 

[maxbraketorque]

Earlier I posted that I saw a performance regression between the original alpha 1 (g2) and alpha 1a (g4). Since then I've done a few more tests

The symptom was significantly lower downloads from ISP - down from around 380 Mbps to 150 Mbps

* I did a full factory reset - zero customizations. This made no difference
* I went back to an earlier firmware level - I found I had to go back to 384.11 to get it to 'stick'. Still getting 384/36 Mbps there
* Again going to alpha1 g4, and alpha2 g6 resulted in speeds around 150/37 at best - sometimes the download drops into the double digits
* CTF is enabled in both cases
* Earlier I did have some QOS controls active - for the recent tests these were disabled (as with a factory reset, and also with restored data)
* The CPU is not maxing out - between 1/3 and 1/2 on average across both cpus
* The 5Ghz-1 channel (running in the 40+ range) is normal speed, it is the 5Ghz-2 channel (running in the 100+ range) that is bad. Changing channels didn't help, and a scan shows nothing else in the 100+ range locally.
* Swapping the SSIDs keeps the problem with the 5Ghz-2 band
* Ethernet is not affected
* Nothing untoward I could see in the logs
* I repeated this loop of going back to earlier firmware, then reapplying about 3 times - with the same results each time.

I can only conclude that the latest AC3200 code has a performance problem with 5Ghz-2.

Nice analysis. So the issue is tied to the 5 GHz-2 band? Did you try manual channel assignment? I don't think the AC3200 is DFS band capable, but if it is, try setting the channel to something outside this band.

 

[maxbraketorque]

FWIW, previously with AC86U, & now with AX88U, Ntp issue:

My workaround is to use an IP address for ntp (IPv4 only, an IPv6 address doesn’t work, despite me having IPv6 available); & not enter anything as secondary ntp.
Using a domain name, or entering anything (ip, or domain) as secondary ntp, virtually guarantees I won’t get wan access after a reboot.

Using the workaround, I still sometimes get the problem, but a single further reboot usually fixes it. YMMV.

Do you mean adding an entry into the second NTP server field?

 

[Nigel Jones]

Nice analysis. So the issue is tied to the 5 GHz-2 band? Did you try manual channel assignment? I don't think the AC3200 is DFS band capable, but if it is, try setting the channel to something outside this band.

Yes it seems to be 5-2 only. I did try manual or a few channels, but didnt notice any difference. All the channel options for 5-2 are DFS in Europe.

I'll experiment some more with the wifi settings on 5-2 to see if I can determine more precisely where the flaw is .... I presume new broadcom drivers have caused the regression

 

[maxbraketorque]

.... I presume new broadcom drivers have caused the regression

Yep, I'd bet on that based on your observations. Submit a ticket to ASUS after a bit more verification?

 

[maxbraketorque]

alpha2 working fine on all three of my AC86Us for the last few days. The routers are writing a bit more info to the syslog than under 384.11_2, but nothing appearing to be an error. The only suspect class of entry is:

2019-06-04 06:55:29 // debug // router.asus.com // 192.168.xxx.xxx // daemon // dnsmasq // reducing DNS packet size for nameserver 127.0.1.1 to 1280

These show up periodically. No obvious effect on name resolution.

 

[Nigel Jones]

A further update on the AC-3200 regression.

I've gone through checking different 5Ghz-2 channels again, and pretty much changed every single advanced wireless setting, and I cannot regain normal speeds on 5Ghz-2.
I'm not sure I have the bandwidth to try stock firmware currently.
Any other 3200 users with connections > 250 Mbps or so that might like to try and see if they can confirm my observations?
I'm not really impacted since I can stick to 5Ghz-1 .

 

[skeal]

alpha2 working fine on all three of my AC86Us for the last few days. The routers are writing a bit more info to the syslog than under 384.11_2, but nothing appearing to be an error. The only suspect class of entry is:

2019-06-04 06:55:29 // debug // router.asus.com // 192.168.xxx.xxx // daemon // dnsmasq // reducing DNS packet size for nameserver 127.0.1.1 to 1280

These show up periodically. No obvious effect on name resolution.

This may be due to your log level preferences.

 

[Swistheater]

Earlier I posted that I saw a performance regression between the original alpha 1 (g2) and alpha 1a (g4). Since then I've done a few more tests

The symptom was significantly lower downloads from ISP - down from around 380 Mbps to 150 Mbps

* I did a full factory reset - zero customizations. This made no difference
* I went back to an earlier firmware level - I found I had to go back to 384.11 to get it to 'stick'. Still getting 384/36 Mbps there
* Again going to alpha1 g4, and alpha2 g6 resulted in speeds around 150/37 at best - sometimes the download drops into the double digits
* CTF is enabled in both cases
* Earlier I did have some QOS controls active - for the recent tests these were disabled (as with a factory reset, and also with restored data)
* The CPU is not maxing out - between 1/3 and 1/2 on average across both cpus
* The 5Ghz-1 channel (running in the 40+ range) is normal speed, it is the 5Ghz-2 channel (running in the 100+ range) that is bad. Changing channels didn't help, and a scan shows nothing else in the 100+ range locally.
* Swapping the SSIDs keeps the problem with the 5Ghz-2 band
* Ethernet is not affected
* Nothing untoward I could see in the logs
* I repeated this loop of going back to earlier firmware, then reapplying about 3 times - with the same results each time.

I can only conclude that the latest AC3200 code has a performance problem with 5Ghz-2.

If you have a usb 3.0 device plugged into your router make sure you have set it to function as usb 2.0 under the administrator page, also able to be changed when you select the device itself. These have been known to cripple 2.4ghz performance

 

[RMerlin]

There are conflicts between the 382 blobs and the 384 GPL. I need to implement kludges to bridge the two together - these kludges aren't implemented yet in the latest build.

Sent from my P027 using Tapatalk

 

[Nigel Jones]

There are conflicts between the 382 blobs and the 384 GPL. I need to implement kludges to bridge the two together - these kludges aren't implemented yet in the latest build.

If you think that could explain the AC3200 issues that's great to hear! Just wanted to check there wasn't something missed and feed back

 

[Nigel Jones]

If you have a usb 3.0 device plugged into your router make sure you have set it to function as usb 2.0 under the administrator page, also able to be changed when you select the device itself. These have been known to cripple 2.4ghz performance

It's only my 5Ghz-2 that's crippled -- actually I rarely use 2.4. Have set to USB3 but did try USB2 for a test - no difference . Always good to share ideas though . thanks. (and refer I think to merlin's latest reply)

 

[RMerlin]

If you think that could explain the AC3200 issues that's great to hear! Just wanted to check there wasn't something missed and feed back

Hard to predict the exact impact, some of it is subtle.

Basically, the 382 code uses different model identification numbers, so the 382 binary blobs running on 384 code can end up executing code intended for a different model. The most visible impact is LED control not working properly. I haven't looked at the AC3200 specifically, I'm using the AC87U for 382-related development.

 

[Nigel Jones]

Hard to predict the exact impact, some of it is subtle.

Basically, the 382 code uses different model identification numbers, so the 382 binary blobs running on 384 code can end up executing code intended for a different model. The most visible impact is LED control not working properly. I haven't looked at the AC3200 specifically, I'm using the AC87U for 382-related development.

Funny you mention that. Though my LEDs are disabled in the settings, they are active.

When you think you've addressed any 382 funnies I'd be happy to test any build/alpha etc. Also as a sw dev I can build/debug with some tips if needed (just rarely enough time!)

Your work is much appreciated especially in trying to keep the 382/384 hybrids working

 

[TheOldMan]

My RT-AC86U has not been factory resetted since 384.5. I'm using 384.12_a2 and it is still doing it's job. That's a lot of dirty upgrades, eh?

 

[Zastoff]

My RT-AC86U has not been factory resetted since 384.5. I'm using 384.12_a2 and it is still doing it's job. That's a lot of dirty upgrades, eh?

Same here Did a factory reset back on 384.5 also