Home Wi-Fi Latency Spikes on 2.4GHz: Neighbor AP Interference and Moving to Channel 1

Intermittent latency spikes on a home Wi-Fi connection are frustrating because the internet itself may be fine while calls, downloads, and page loads still stall. This note walks through a case where a MacBook on 2.4GHz kept hitting latency spikes of several hundred milliseconds. The cause turned out not to be faulty hardware but interference from a neighbor’s access point on the same 2.4GHz channel. You will see how a side-by-side comparison with a second device isolated the problem, how a controlled test confirmed it, and why moving the router to channel 1 resolved it. The measurement method and the reasoning behind each step are included so you can apply the same approach to your own network.

Summary

The source of the repeated internet latency spikes observed on the MacBook was not a device defect. It was interference from a neighbor’s access point on 2.4GHz channel 11. Cross-validation came from two sources: a simultaneous comparison with a Mac mini on 5GHz, and a controlled test in which the Mac mini was forced onto the same 2.4GHz channel 11, reproducing the spikes under the same conditions. The fix was to change the router’s 2.4GHz channel from 11 to 1.

Key Data

Measurement Setup

• Router: SK Broadband GW-HF611R (NAT mode, 192.168.45.1). SK Broadband is a South Korean internet service provider.
• Separate SSIDs: SK_2204_5G (5GHz, 80MHz, channel 157) and SK_2204_2.4G (2.4GHz, 20MHz)
• Mac mini: not on Ethernet, connected over Wi-Fi en1, initially on 5GHz channel 157
• MacBook: Wi-Fi en0, initially on 2.4GHz channel 11
• Measurement tool: a custom script, measure_wifi.sh (~/Projects/wifi-monitor/bin/measure_wifi.sh)
  • Runs every 1 minute and measures the gateway and 1.1.1.1 separately with ping -c 5 -W 3000
  • Records RSSI, noise, SNR, channel, bandwidth, loss, min, avg, max, and stddev
  • Output: ~/Projects/wifi-monitor/logs/wifi_metrics.csv (KST timestamps)

Step-by-Step Measurements

Stage	Time (KST)	Device	Band/Channel	RSSI	SNR	gateway avg/stddev	internet avg/stddev/max	Notes
Initial state	Before 10:51	Mac mini	5GHz ch157	-72	15~18	2.7 / 0.2 ms	5 / 0.3 / 7 ms	Completely flat
Initial state	10:52:41	MacBook	2.4GHz ch11	-57	22	663 / 108 ms	384 / 47 / 456 ms, loss 20%	Severe spikes
Control test (5G off)	After 11:15	Mac mini	2.4GHz ch11	-62	21	5.615.5 / 4.810.3 ms	14.716.7 / 8.810.4 ms	Moving the Mac mini from 5G to 2.4 also produced spikes
After restoring 5G	11:25~26	Mac mini	5GHz ch157	-70	15~18	2.5~2.7 / 0.2 ms	5.15.4 / 0.20.4 ms	Immediately recovered to the original state
Late ch11	11:26:49	MacBook	2.4GHz ch11	-51	26	8.5 / 8.5	52.6 / 83.2 / 218.7 ms	Still spiking despite better RSSI
After fix	11:30 onward	MacBook	2.4GHz ch1	—	—	—	—	Under observation (separate report)

Neighboring AP Scan (2.4GHz, MacBook View)

Channel	AP count	Strong-signal neighbors	Assessment
ch1	0 direct conflicts, adjacent ch2/3/4 at 20MHz	None	Best choice (target channel)
ch6	1 direct + ch4 40MHz full overlap	—	The 40MHz signal on ch4 occupies ch4~8 entirely → worst case
ch11 (initial)	2 direct conflicts	-51dBm (stronger than our -55)	Neighbor AP occupies the same channel with a stronger signal

Total Nearby APs

• 2.4GHz: 6 APs (MacBook view), 6 APs (Mac mini view)
• 5GHz: 8 APs (MacBook view), 3 APs (Mac mini view)
• Typical congestion for a dense urban apartment building

Non-Overlapping Channel Layout (2.4GHz)

• At 20MHz, only three channels do not overlap: 1, 6, and 11.
• A single 20MHz AP radiates interference up to two channels away on each side.
• A 40MHz AP occupies four channels on each side. For example, a 40MHz AP on channel 4 covers channels 2 through 6.

Insights

Why the MacBook Alone Looked Like the Problem

• The Mac mini, connected to the same router over 5GHz, showed a perfectly steady stddev of 0.2 ms in simultaneous observation.
• This ruled out the router-to-ISP segment: if the Mac mini was healthy, the ISP link and the router’s external path were healthy.
• The problem was therefore limited to the wireless link between the MacBook and the router.
• Moving the MacBook to 5GHz would have resolved the issue, but with the door closed, 5GHz reach drops. That constraint was the author’s own condition, so the plan was to keep 2.4GHz and change only the channel.

Disproving the “Weak Signal Falls Back to 2.4GHz” Hypothesis

• The initial hypothesis was that the MacBook was dropping to 2.4GHz because its signal was weak.
• Measurements showed the MacBook’s RSSI at -54 to -58 dBm, far stronger than the -70 dBm threshold for falling back to 5GHz.
• The drop to 2.4GHz was therefore not a fallback. It was more likely the router’s band steering logic or the MacBook’s prior connection history.

RSSI Alone Is Misleading

• The MacBook’s RSSI of -54 to -58 looked better than the Mac mini’s -70 to -72.
• However, the gateway stddev was 10 to 108 ms on the MacBook versus 0.2 ms on the Mac mini, meaning the Mac mini was 100 to 500 times more stable.
• Signal strength is not quality. A 2.4GHz link can show a healthy RSSI and still suffer retry storms from congestion and interference.
• For diagnosis, jitter (stddev) and maximum latency are far more useful than RSSI.

Design Principles of 2.4GHz Channels

• Almost every home in the world uses one of channels 1, 6, or 11.
• The key variable is therefore not whether a neighbor is on your channel, but whether a neighbor on the same channel has a strong signal.
• When a neighbor’s signal is equal to or stronger than yours, CSMA/CA contention for the shared medium becomes asymmetrically unfavorable to you.

Reusing the Diagnostic Method

• Logging every minute (including jitter) and comparing two devices on the same router is a standard way to separate router, ISP, and device causes.
• If one device on the same router is healthy, that is strong evidence that the ISP and the router’s external path are not the cause.
• An older logging setup that only recorded five-minute averages structurally missed spikes: it observed 5 seconds out of every 5 minutes, leaving 98% of the time blind. Logging every minute with min, max, and stddev is essential.

Fix and Response

Immediate Action (Completed)

1. In the SK GW-HF611R admin page, go to Advanced Settings → Wi-Fi → 2.4GHz settings, and change channel 11 → 1.
2. Save and reboot. The MacBook reconnected automatically and was confirmed on channel 1.
3. The verification report is generated separately (wifi-monitor/bin/verify_ch1_effect.sh, one-time run through launchd).

Ongoing Monitoring

• wifi-monitor runs every minute on both the MacBook and the Mac mini.
• Every day at 09:00 KST, a report on the previous day’s quality is automatically sent to a Discord automation channel.
• When an issue occurs, the corresponding CSV file serves as evidence when dealing with the ISP technician or customer service.

Long-Term Recommendations

• If 5GHz coverage drops past a door, add one 5GHz repeater or mesh node beyond the door. A wired backhaul is best.
• If the MacBook’s location changes often, move the router itself to the center of the home.
• If more IoT devices need 2.4GHz, consider a dedicated 2.4GHz SSID for IoT devices.

Evidence for the ISP Technician Visit (Scheduled Tuesday, April 28, 2026, 10:00)

• The cause has already been identified as interference in the home’s wireless segment (overlapping neighbor APs).
• Emphasize that the ISP’s external line and the router hardware are not the problem, citing the simultaneous healthy Mac mini 5GHz record.
• Items to show the technician:
  1. The key data table in this document
  2. Measurements from ~/Projects/wifi-monitor/logs/wifi_metrics.csv
  3. The before-and-after comparison report for the channel 11 → 1 change (output of the verify script)
  4. Additional requests to raise: whether the router firmware is up to date, band steering configuration logs, and a recommendation on router placement

Sources

• SK Broadband GW-HF611R admin UI: http://192.168.45.1 (internal network)
• Wi-Fi 2.4GHz non-overlapping channel layout: IEEE 802.11-2016 standard
• macOS system_profiler SPAirPortDataType scan data (/tmp/wifi_scan_macbook.txt, /tmp/wifi_scan_macmini.txt)
• Raw measurement CSVs: MacBook ~/Projects/wifi-monitor/logs/wifi_metrics.csv, Mac mini mac_mini@macmini:~/Projects/wifi-monitor/logs/wifi_metrics.csv
• Monitoring script version: measure_wifi.sh 2026-04-24 revision (1-minute interval, -W 3000, KST timestamps, min/max/stddev included)

Bottom Line

The MacBook’s latency spikes were caused by a neighbor’s access point occupying the same 2.4GHz channel 11 with a stronger signal, not by faulty hardware or the ISP. The Mac mini on 5GHz stayed flat through the same period, and forcing it onto channel 11 reproduced the spikes. Moving the router’s 2.4GHz channel to channel 1, the cleanest option in the scan, is the change the evidence supports. Judge a Wi-Fi link by its jitter and maximum latency, not by its signal strength.