Lag spikes over 1000ms approximately every 38 seconds

f00n · ‎13-09-2026

Router model : SH32B

Package : 1ghz

Problem : Wifi is causing intermittent lag spikes over 1000ms with request timed out message.

First I should explain I'm computer literate in terms of network engineering and how to fix this kind of issue so I have already gone all around the houses to try and fix it.

I have isolated devices, used compatibility wifi settings, changed WPA between 2/3, ensured I have latest NIC drivers and set them up appropriately. I have ensured all my devices on the network have appropriate power management and network scanning frequency settings including disabling media calls to other devices being disabled. I have also wired into the router directly with a CAT cable. All the time I was doing this I was scanning my wifi and ethernet networks with Wireshark to get comprehensive details about any and all errors or discrepancies. I have tried 3 different AI tools to check the logs and give me potential solutions and none of them have worked except to connect my PC with ethernet where the issue did not occur, proving it's the wifi on the router that is the issue.

A typical lag spike will look like this (or with multiple request time outs and multiple ping lag spikes. Also here is what Claude told me to tell the ISP when I contact them.

If needed I could post my wireshark logs, but they are awful to manually go through. Instead I asked Claude to give me a summary as shown here :

---------------------------------------------------------------------------------------------------------------------

WIFI LATENCY / PACKET LOSS - EVIDENCE SUMMARY
================================================

Setup: Pinging 192.168.1.152 (test PC) -> 192.168.1.254 (router/gateway),
across five separate Wireshark captures taken on different days, under
idle, moderate, and heavy (70,000+ packet video stream) traffic loads.
A sixth capture repeated the same test over wired Ethernet as a control.

BOTTOM LINE: A full packet-loss event occurs roughly every 38-40 SECONDS,
consistently, regardless of traffic load, active devices, or client-side
WiFi driver settings (roaming aggressiveness, fat channel intolerance,
power save - all already ruled out). The same test over Ethernet shows
ZERO loss and sub-10ms latency throughout, which isolates the problem to
the WiFi radio path rather than the router's general software/CPU or the
internet connection itself.

----------------------------------------
LOG 09 - WifiPacketLog_09.txt
----------------------------------------

Latency spikes (reply arrived, but delayed):
Req pkt 3253 -> Reply pkt 3263 | t=297.35s | RTT 1424.7 ms
Req pkt 4062 -> Reply pkt 4089 | t=376.69s | RTT 1213.7 ms
Req pkt 1859 -> Reply pkt 1862 | t=141.15s | RTT 680.7 ms
Req pkt 1857 -> Reply pkt 1858 | t=140.05s | RTT 593.0 ms
Req pkt 2546 -> Reply pkt 2547 | t=217.32s | RTT 378.8 ms
Req pkt 3692 -> Reply pkt 3695 | t=339.32s | RTT 250.6 ms

----------------------------------------
LOG 10 - WifiPacketLog_10.txt
----------------------------------------

Latency spikes:
Req pkt 4365 -> Reply pkt 4367 | t=451.62s | RTT 2241.3 ms
Req pkt 4363 -> Reply pkt 4364 | t=449.37s | RTT 1144.9 ms
Req pkt 4568 -> Reply pkt 4569 | t=490.14s | RTT 1135.3 ms
Req pkt 1318 -> Reply pkt 1319 | t=104.32s | RTT 1056.3 ms
Req pkt 1808 -> Reply pkt 1809 | t=182.84s | RTT 581.6 ms
Req pkt 1316 -> Reply pkt 1317 | t=102.65s | RTT 394.1 ms

----------------------------------------
LOG 11 - WifiPacketLog_11.txt
----------------------------------------

Latency spikes:
Req pkt 36085 -> Reply pkt 36144 | t=297.37s | RTT 1694.1 ms
Req pkt 16386 -> Reply pkt 16430 | t=258.22s | RTT 1660.4 ms
Req pkt 15008 -> Reply pkt 15068 | t=220.18s | RTT 1343.7 ms
Req pkt 158 -> Reply pkt 170 | t= 25.59s | RTT 1144.3 ms
Req pkt 78968 -> Reply pkt 78969 | t=450.75s | RTT 913.5 ms
Req pkt 67300 -> Reply pkt 67304 | t=372.61s | RTT 776.6 ms
Req pkt 70508 -> Reply pkt 70509 | t=412.47s | RTT 630.2 ms

Note: this capture included 71,000+ packets of concurrent heavy video
streaming - the ~38s cycle was unaffected by traffic load.

----------------------------------------
LOG 13 - WifiPacketLog_wifi_13.txt
(after Intel driver update + Roaming Aggressiveness set to lowest)
----------------------------------------

Latency spikes:
Req pkt 5437 -> Reply pkt 5445 | t=755.21s | RTT 4668.5 ms
Req pkt 4537 -> Reply pkt 4547 | t=677.24s | RTT 3707.1 ms
Req pkt 3342 -> Reply pkt 3344 | t=479.23s | RTT 3623.4 ms
Req pkt 4259 -> Reply pkt 4265 | t=638.22s | RTT 3614.6 ms
Req pkt 2102 -> Reply pkt 2107 | t=321.22s | RTT 3227.2 ms
Req pkt 1189 -> Reply pkt 1195 | t=165.22s | RTT 3181.3 ms
Req pkt 1839 -> Reply pkt 1848 | t=279.75s | RTT 1211.7 ms
Req pkt 265 -> Reply pkt 267 | t= 45.22s | RTT 1152.4 ms

----------------------------------------
CONTROL TEST - WifiPacketLog_Ethernet_12.txt (wired connection)
----------------------------------------

Duration: 386.7 seconds
Packet loss: 0 events
RTT: min 0.44ms, median 0.93ms, max 9.33ms
No latency spikes above 10ms

This is the key comparison point: identical ping test, identical router,
only the transport changed - and the periodic loss/spikes disappear
entirely.

----------------------------------------
INTERVAL PATTERN (all WiFi sessions)
----------------------------------------

Full-loss events land almost exactly every 38-40 SECONDS in every
session. Occasional larger gaps are clean multiples of that base
interval (e.g. ~80s, ~117s), meaning the cycle continued but that
particular pass didn't fully drop the packet.

This held constant across idle traffic, moderate traffic, and a
70,000+ packet streaming session, and was UNAFFECTED by:
- Disabling Urban VPN / MetaMask browser extensions
- Disabling DNS-over-HTTPS
- All three Xboxes present, idle, active, or moved to 5GHz
- Latest official Intel WiFi driver
- Roaming Aggressiveness set to lowest
- Fat Channel Intolerant already disabled

----------------------------------------
WHAT I'M ASKING MY ISP TO CHECK
----------------------------------------

1. The GTK (Group Temporal Key) rekey interval on the router - if set
too short, this is a well-documented cause of periodic brief WiFi
disruptions. Requesting it be lengthened or disabled.

2. Whether the 5GHz radio is operating on a DFS channel (typically
52-144) - DFS monitoring behavior can cause periodic connectivity
blips. Requesting a lock to a non-DFS channel (36/40/44/48).

3. Whether a firmware update is pending for the router.

4. If none of the above resolves it: bridge/modem-only mode so I can
use my own router for WiFi, or a replacement unit.

---------------------------------------------------------------------------------------------------------------------

If anyone has any further ideas or could suggest anything I would be most appreciative. My next step is to contact support and I dread getting the old auto-replies and "have you turned it off and on again?" gibberish meant for the layman. No offence to layman types.

Regards.

f00n · ‎13-09-2026

yeah I do see it but as it's further down the list I presumed it was the other neighbour who has EE internet. So that EE-Wifi is a hot spot in range of me?

JimM11 · ‎13-09-2026

@f00n You only have a couple off choices now, one is to contact EE CS and have them take a look at what is going on with your hub, get's very difficult when it is as you THINK only wireless wifi issue, so expect blame to a device on YOUR network causing it, After this EE can test but will not see anything as the Hub is well locked down, but CH100 issue was raised on a post, the OP called EE CS and the fixed it back to CH36, that was a shocker and you would have to ask the poster what is going on with that currently. Will find the LONG post and you can reach out. Post linked and @Kevbell92 is the one.

Smart Hub 7 Pro 5 GHz failure reproduced on two hubs - channel/firmware issue? - Page 4 - The EE Com...

Cannot check or do any testing as Ditched EE back Mar2025 when the FW oops'd the hub back at that period, upped and left. Although it is a Pro Hub, they do go hand in hand with each other a little.

f00n · ‎13-09-2026

Thank you and that's fine. The post was very helpful and inspired me to test the different setups of WPA as the other OP had an issue with authentication. I had a Comp network on 2.5ghz, with 5ghz switched off. That one used WPA2. Then my main 5ghz network (with 2.4ghz switched off) used WPA3 usually, however I had switched it to WPA2-personal after an XBOX update stopped it being able to see the 5ghz network. The only way it could was if I switched the 5ghz network to WPA2-personal. This is strange because the XBOX was capable of seeing and connecting to the 5ghz previously. So I switched to WPA-Personal-Transition and reconnected the XBOX to the 5ghz that way. No request timed out and no large ping spikes currently.

If this is the case, although further time needs to elapse to ensure it, then it seems logical that the encryption type was causing the issue in how it was handling non-WPA3 devices. Possible the cause of all the TCP retransmissions around the time of the spikes. Maybe it was getting stuck in some kind of handshaking issue which affected other devices on the network and caused them to spike or drop connection momentarily. I couldn't say for sure. However I can now go test it with some stress-relieving online gaming whilst it's stable.

Thanks again for rubber ducking with me. Sometimes it takes that external inspiration.

[edit: I just did a netsh wlan show networks mode=bssid and it now shows I'm connected on channel 36. )

XRaySpeX · ‎13-09-2026

If you install Xirrus Wi-Fi Inspector you'll be able to compare BSSIDs to see if EE WiFi is yours or another's.

If you think I helped please feel free to hit the "Thumbs Up" button below.

To phone EE CS: Dial Freephone +44 800 079 8586 - Option 1 for Home Broadband & Home Phone or Option 2 for Mobile Phone & Mobile Broadband

ISPs: 1999: Freeserve 48K Dial-Up > 2005: Wanadoo 1 Meg BB > 2007: Orange 2 Meg BB > 2008: Orange 8 Meg LLU > 2010: Orange 16 Meg LLU > 2011: Orange 20 Meg WBC > 2014: EE 20 Meg WBC > 2020: EE 40 Meg FTTC > 2022:EE 80 Meg FTTC SoGEA > 2025 EE 150 Meg FTTP

JimM11 · ‎13-09-2026

@f00n All i can say is well done, working it all out, and i am a Network Engineer, have seen a lot off strange effect's in my time doing this for 45+ years, nothing in wireless or ethernet phases me at all, but one has to be extremely logical when testing.

You have got it up, stable and working and NOW you do have an idea as to what was throwing it to wobble in such a way, keep all that current in the mind.👍👍

Edit:- Just watch if it jumps back to CH100 and your ping spikes reappear again, just do the Ping test you will see that right away.

JimM11 · ‎13-09-2026

@f00n To let you know, i have 4 Nodes on CH100 160Mhz wide, two nodes on CH36 at 80Mhz wide, and 5 Nodes split across the 2.4Ghz band, all operating on WPA2-Personal, Airports are 25 miles North and South off my home location, but direct in flight path for both, really never get DFS issue's at all but easy to look at and control with the Asus Router's Tri band / Dual band Ap's. Been this way for years and do know what to expect.

f00n · ‎14-09-2026

Thought I would update this. After a few hours the Wifi channel changed itself from CH36 back to CH100 and the spikes came back with a vengeance. Request timed out when it does. I can't switch the channel manually on this router so I guess I will have to phone customer support and see if they can change it. I'd prefer a router where I can set it myself though. Hopefully I can figure out a way to get it to switch again.

JimM11 · ‎14-09-2026

@f00n If you are seeing that effect now, then suspect it may possibly be something that the latest FW patch has introduced, cannot say 100% where my old SH31B version sat Channel wise but would not be surprised if CH100 was there at times, for sure would have spotted such an effect as checked for many speed related posting's such as your's, and as before there is a current CH100 going on with the Pro version although different effect but never thought to ping test it for speed issue.

Also it cannot be 100% ruled out the hub is the issue, takes two devices to test separate to see, one device could have an issue running in CH100 and the other possibly no issues, that is why i always test one at a time two laptops running the same test, have even run them at the same time for a speed test to make sure the Hub share's the throughput load splitting it between them.... Only have a FF500 feed so easy to manage.

None off the current EE hubs allow fixing the 5Ghz channel position to the desired nor splitting the ssid's away so does get a little difficult tracking down what the possible issue is with the Hub. On to EE CS and hopefully Tech support person who is aware or has report of similar issue going on.....

The Hub was slated to be FW updated as per the EE posting, Pro is completed but not one 6+ version has been done or posted up Forum wise so either pulled / delayed or stopped altogether who knows. Old linked pictures, CH100 now in use and CH1 remote PowerLine with a 5Ghz ssid name for the good lady while out gardening or exercising in the garage.

Re: 'Compatible Wifi' issues with new Smart Hub Pro and Smart Wifi Pro - The EE Community

JimM11 · ‎14-09-2026

@f00n Your pics are all cleared, you will need to stick a wifi analyser on a device or switch the hub off to see what the EE WiFi is like, until you know what the MAC address is for it i am NOT going to believe that it is NOT YOURS from the hub transmitting.

Netspot by ETWOK.inc will show you with either the Windows or the Android mobile version.

Edit:- If you need to do packet loss test again just stick the Duration up past the preset off 10 seconds to cover your own time period, the function is to rapidly hammer the upload time cycle, ideal is zero loss but delays are important for the feed back.

See The sample pictures when cleared for viewing, 1 minute wireless wifi connected.

Pic1Pic2