What's new

GT-AX6000 - Severe Wifi latency spikes and intermittent disconnects

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

VincentS

New Around Here
Hi everyone,

I have been searching the forums the last week to find an answer to this problem i am facing. I have been unable to actually resolve this issue as of now and was hoping that asking directly would steer me in the right direction of solving this.

I have two GT-AX600 routers set-up. One as main router with Merlin (latest stable) installed (i am unsure if this is a merlin related issue that is why i am not posting it there) and the other GT-AX6000 is stock and set-up as an AIMesh node.

My wired internet stability is perfectly fine. When i run a continuous ping i get between 4-8ms on average.

Wireless however is an entirely different situation. I get a serious latency spike very couple of minutes on my MacBook or SteamDeck device. I have been running pings on these as well and these latency spikes go up to 2000ms and even brief timeouts or disc/reconnects. I noticed these issues when i had several video conferences just freeze intermittently. See example below of an actual timeout.

Code:
64 bytes from 142.250.179.142: icmp_seq=42 ttl=118 time=7.304 ms
64 bytes from 142.250.179.142: icmp_seq=43 ttl=118 time=6.486 ms
64 bytes from 142.250.179.142: icmp_seq=44 ttl=118 time=7.292 ms
64 bytes from 142.250.179.142: icmp_seq=45 ttl=118 time=6.109 ms
64 bytes from 142.250.179.142: icmp_seq=46 ttl=118 time=6.921 ms
64 bytes from 142.250.179.142: icmp_seq=47 ttl=118 time=7.046 ms
Request timeout for icmp_seq 48
64 bytes from 142.250.179.142: icmp_seq=48 ttl=118 time=1030.910 ms
64 bytes from 142.250.179.142: icmp_seq=49 ttl=118 time=29.827 ms
64 bytes from 142.250.179.142: icmp_seq=50 ttl=118 time=7.632 ms
64 bytes from 142.250.179.142: icmp_seq=51 ttl=118 time=8.893 ms
64 bytes from 142.250.179.142: icmp_seq=52 ttl=118 time=8.457 ms
64 bytes from 142.250.179.142: icmp_seq=53 ttl=118 time=9.192 ms
64 bytes from 142.250.179.142: icmp_seq=54 ttl=118 time=7.368 ms
64 bytes from 142.250.179.142: icmp_seq=55 ttl=118 time=8.387 ms
64 bytes from 142.250.179.142: icmp_seq=56 ttl=118 time=7.790 ms
64 bytes from 142.250.179.142: icmp_seq=57 ttl=118 time=7.815 ms

Schermafbeelding 2022-09-22 om 16.08.28.png


Things i have tried:

  • Several resets and or reboots
  • I have been over all the wireless settings and turned off every setting in the professional tab that i have seen people suggest you turn off: Airtime Fairness, Multi-User MIMO, OFDMA/802.11ax MU-MIMO, 802.11ax/ac Beamforming, Universal Beamforming, Enable WMM APSD
  • Changed the wifi channels to the least crowded ones available (also no DFS channels)
When looking at the system log i do not see any strange events or messages popping up around the time of these spikes. There are always a lot of association and dissociation messages from devices in the log, but nothing that points to the significant latency that is occuring.

I am really not sure what next steps there are to take from here.

Thank you for your time.
 
Last edited:
Small update: I have turned off Smart Connect. This seems to make the issue a lot less prevalent. The lag spikes seem significantly lower (100-150ms) and less frequent. However there are still time-outs while pinging. These also seem to be occurring less. I have not yet changed the ssid's for the 2,4 and 5ghz networks. Could splitting them completely help in any way? Maybe it is a steering issue?

Does anyone have any idea as to what might be causing this issue?
 
Last edited:
Small update: I have turned off Smart Connect. This seems to make the issue a lot less prevalent. The lag spikes seem significantly lower (100-150ms) and less frequent. However there are still time-outs while pinging. These also seem to be occurring less. I have not yet changed the ssid's for the 2,4 and 5ghz networks. Could splitting them completely help in any way? Maybe it is a steering issue?

Does anyone have any idea as to what might be causing this issue?

I doubt it is a settings issue... a default minimal configuration should generally work like your LAN.

How far apart are your nodes? If you turn OFF the node, does the problem persist when using the router AP?

Any other close transmitters nearby like cordless peripherals, WiFi Direct APs in printers, media devices?

OE
 
I doubt it is a settings issue... a default minimal configuration should generally work like your LAN.

How far apart are your nodes? If you turn OFF the node, does the problem persist when using the router AP?

Any other close transmitters nearby like cordless peripherals, WiFi Direct APs in printers, media devices?

OE
Hi OzarkEdge! Thanks for your reply and suggestions. So from what i gather you don't think splitting the bands would help prevent this issue any further?

My nodes are pretty far apart one is in the downstairs hallway and the other in the attic. They are connected by cable set to '2,5 wan first' as backhaul setting. I am not sure about other transmitters close-by. Maybe the smart meter from our gas/electricity company?

I can't really pin-point a specific interval when this issue happens.

I have turned off the attic AP and ran another 1000 package ping run an still had a couple of 100+ ping packets.
 
I've had a go trying to replicate this and connecting to the GT-AX6000 directly via wifi the average delay was 3ms with the largest outlier being 8ms. Connecting via an AIMesh node (RP-AX56) the average increased to just 4ms, a few more outliers around 11-12ms and a single 45ms.
So something is amiss!
 
What else is running on this router? Custom scripts?
Yes matter of fact i am. I am running a script that makes the router work with the dutch KPN IPTV network. Instructions for this are on the dutch tweakers.net website that i frequent.

The scripts are here: https://gathering.tweakers.net/forum/list_message/63414488#63414488

I am personally not familiar enough with networking to fully understand what these do except make it work! (it does work)

Last issue i encountered myself was that i can not switch the AP to 'Ethernet backhaul mode' because then it will go offline and not be available.

I've had a go trying to replicate this and connecting to the GT-AX6000 directly via wifi the average delay was 3ms with the largest outlier being 8ms. Connecting via an AIMesh node (RP-AX56) the average increased to just 4ms, a few more outliers around 11-12ms and a single 45ms.
So something is amiss!

Thanks for testing! Unfortunately your latency does seem to be a lot better. Man this is really frustrating. Wired connection is just perfectly fine.

Also to clarify the pinging i am doing above is from a laptop through terminal to google.com and then the ping is between 8ms and 16ms with outliers to 100-200ms.

When i ping the laptop directly from the router with the network tools the average ping is 4ms with outliers going up to 9ms.
 
Last edited:
Hi OzarkEdge! Thanks for your reply and suggestions. So from what i gather you don't think splitting the bands would help prevent this issue any further?

I don't think so. Smart Connect is band steering that occurs before the client connects to a WLAN/band. Your client is already connected when you are pinging Google and experiencing delays.

However, if you are not using Smart Connect, you should define different SSIDs. You are not actually splitting anything... you always have separate bands, separate WLANs... you are just naming them the same (Smart Connect enabled) or different (Smart Connect disabled). When you name them the same, clients display them as one, but they are still two WLANs (of the same name).

And then connect your client to only one SSID and try the ping test again... maybe your client is reconnecting needlessly to the same/different WLAN of the same name, causing the ping delay.

My nodes are pretty far apart one is in the downstairs hallway and the other in the attic. They are connected by cable set to '2,5 wan first' as backhaul setting.

Side note: My recent experience with the node Backhaul Connection Priority suggests Auto is good enough.

I am not sure about other transmitters close-by. Maybe the smart meter from our gas/electricity company?

Probably too far away/weak to matter, if on the same frequencies.

I can't really pin-point a specific interval when this issue happens.

I have turned off the attic AP and ran another 1000 package ping run an still had a couple of 100+ ping packets.

I'd want to know how the standalone router with minimal configuration performs. Perhaps something on the test client... perhaps your ISP network. You'll need to change and rule things out somehow.

And ping something else... a mail server on your ISP network or something else not too far away.

OE
 
Last edited:
I don't think so. Smart Connect is band steering that occurs before the client connects to a WLAN/band. Your client is already connected when you are pinging Google and experiencing delays.

However, if you are not using Smart Connect, you should define different SSIDs. You are not actually splitting anything... you always have separate bands, separate WLANs... you are just naming them the same (Smart Connect enabled) or different (Smart Connect disabled). When you name them the same, clients display them as one, but they are still two WLANs (of the same name).

And then connect your client to only one SSID and try the ping test again... maybe your client is reconnecting needlessly to the same/different WLAN of the same name, causing the ping delay.



Side note: My recent experience with the node Backhaul Connection Priority suggests Auto is good enough.



Probably too far away/weak to matter, if on the same frequencies.



I'd want to know how the standalone router with minimal configuration performs. Perhaps something on the test client... perhaps your ISP network. You'll need to change and rule things out somehow.

And ping something else... a mail server on your ISP network or something else not too far away.

OE

I have not been able to do any further testing the last couple of days. Whilst working from home redoing the entire network is not really something that will be appreciated. So to get things straight. I remove the node. Factory reset the merlin router. Do a fresh install with the bare minimum settings to get the internet working. Then recheck if my wireless connection is more stable.
 
I have not been able to do any further testing the last couple of days. Whilst working from home redoing the entire network is not really something that will be appreciated. So to get things straight. I remove the node. Factory reset the merlin router. Do a fresh install with the bare minimum settings to get the internet working. Then recheck if my wireless connection is more stable.

Starting from scratch may help to isolate the issue. It can also help set things straight after too many firmware updates/setting changes to establish a baseline before further troubleshooting of the real issue.

Reset FAQ
Reset button/webUI Restore/node removal - clears settings in NVRAM; reboot restores fw defaults from CFE (fw defaults)
Hard Reset via WPS button/webUI Restore+Initialize - also clears data logged in /jffs partition (fw defaults+clear logs)

o Remove node from AiMesh to Reset, wait
o Restore+Initialize root node to Hard Reset, wait
o Configure root node from scratch; do not Restore from .cfg file

Some other observations...

If you do not use Smart Connect, you should define different SSIDs per band and then connect clients to the preferred SSID/band. You can experiment with and without SC to see how your clients behave... just have to define additional connections on the clients... more of a pain on dumb IoT clients. I don't think SC is causing your latency issue once the client is connected.

You said you are unable to use Ethernet Backhaul Mode without losing your wired node. This suggests your wired backhaul is not working correctly. And WiFi is being used for wireless backhauls and is being deprived from your clients. Maybe your AiMesh is fluttering back and forth between wired and wireless backhaul, upsetting wireless client comms. This needs to be investigated.

The wired backhaul should be working like a normal Ethernet segment (router LAN to node WAN); Ethernet Backhaul Mode should be enabled to turn OFF the wireless backhauls; and the node Backhaul Connection Priority will default/fix to 'WAN only'. I would pull the attic node and connect it to the router with a known good Ethernet patch cable and try to enable Ethernet Backhaul Mode.

OE
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top