[Bug Report / Feature Request] Realtek RTL8821CE: Periodic 1-2s ping spikes

[Oleksandr2032]

Subject: [Bug Report / Feature Request] Realtek RTL8821CE: Periodic 1-2s ping spikes every ~34s due to firmware-level background scanning and LPS/IPS (Ignoring Windows WlanSvc settings)

To: HP Support Community / HP Driver Engineering Team / Realtek Software Team
Request: Please escalate this directly to the Realtek Windows driver engineering team.

Device Specifications:
Manufacturer: HP
Model / System Family: HP Notebook (103C_5335KV HP Notebook)
SKU: P3S95EA#ACB
Motherboard: HP 81F0 (Version: 63.53)
BIOS: Insyde F.50 (Dated: 11/20/2020)
Network Adapter: Realtek RTL8821CE 802.11ac PCIe Adapter
Hardware IDs: PCI\VEN_10EC&DEV_C821&SUBSYS_831A103C&REV_00
OS: Windows 11 Insider Preview (Build 26300, 64-bit)
Driver Versions Tested: 2024.0.8.146 and 2024.0.8.108
1. Issue Summary
The Realtek RTL8821CE adapter experiences severe network latency spikes (from 2ms up to 2000-2800ms) exactly every ~34 seconds. This periodic freeze breaks real-time applications (online games like CS 1.6, VoIP, etc.).

2. Technical Root Cause Analysis (Windows)
Extensive diagnostics confirm that the issue is caused by the driver's firmware-level background scanning and power-saving mechanisms (LPS/IPS), which bypass Windows OS networking controls.

DPC/ISR Verification: During the spikes, CPU usage, DPC Time, and Interrupt Time remain at 0%. This proves the issue is not CPU starvation but the radio module leaving the channel or entering a low-power state.
OS-Level Override: Disabling Windows background scanning via netsh wlan set autoconfig enabled=no and setting ActiveBgScan=0 in the WlanSvc registry does not stop the spikes. This proves the scanning/power-saving is initiated by the Realtek firmware, not Windows.
SmartScan Overwrite: Setting SmartScanChnlNum to 0 in the registry temporarily stops the spikes, but the driver automatically overwrites it back to 36 upon adapter restart.
3. Linux Precedent & Official Driver Fix (rtw88)
This is not a hardware limitation. The root cause of these spikes is known to be related to the chip's firmware behavior, but it has been successfully resolved in software in the official Linux driver.

In the official Realtek Linux driver (rtw88, maintained by Ping-Ke Shih), similar periodic latency spikes on RTL8821CE were traced to aggressive firmware power-saving states—specifically LPS (Leisure Power Save) and IPS (Idle Power Save)—as well as background roaming scans. The Linux community and maintainer addressed this by exposing parameters to disable these states or adjusting the logic so the firmware does not freeze the radio channel during active connections. In newer versions of the rtw driver, these ping spikes are no longer present.

This proves that the Windows driver team can implement a similar fix to prevent the firmware from triggering these LPS/IPS/Scan freezes every ~34 seconds.

4. Current Workaround (Windows Registry Tweaks)
To achieve a stable 2ms ping with 0 spikes on Windows, users must manually edit hidden registry keys (which perfectly mirror the LPS/IPS logic fixed in Linux) under:
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0002

RegROAMSensitiveLevel = 127 (Disables firmware roaming scans)
bFwCtrlLPS = 0 (Disables Leisure Power Save)
bLeisurePs = 0 (Disables Leisure Power Save)
bLowPowerEnable = 0 (Disables low power mode)
Scan_IPSEnable = 0 (Disables Idle Power Save scanning)
5. Feature Request / Ask to Realtek Engineers
Modifying the registry is complex and risky for average users. Furthermore, the driver should not aggressively override user settings. We kindly request that Realtek:

Port the scanning/power-save logic fixes from the official Linux rtw88 driver to the Windows driver to prevent these firmware-induced freezes.
Add an explicit "Gaming Mode" or "Ultra-Low Latency Mode" toggle in the Advanced tab of the adapter properties, which would automatically apply the LPS/IPS/Scan workarounds mentioned above.
Thank you for your time and for forwarding this to the appropriate engineering team.

[Oleksandr2032]

UPDATE: Additional evidence from the official Linux driver repository

I want to emphasize that this behavior is NOT isolated to this specific HP laptop model. I have personally reproduced these exact ~34-second ping spikes on three different routers, and the Linux kernel commit history confirms this is a fundamental issue with the Realtek RTL8821CE firmware/driver logic that affects various machines.

For reference, here is one of the specific commits in the official Realtek Linux driver (rtw88) where the maintainer (Ping-Ke Shih) had to patch the LPS (Leisure Power Save) logic to fix network latency and packet delays caused by the firmware:

Commit: github.com/pkshih/rtw/commit/b0034a2e415603daa1cf00363b407cc145bbcd31

(Note: There are multiple similar commits in the rtw history addressing LPS/IPS and background scan-induced latency).

This commit proves that the firmware aggressively enters low-power states (LPS), causing the radio module to freeze momentarily. In Linux, this was fixed by adjusting the driver logic. In Windows, the only way to achieve the same stable result is to manually disable these hidden power-saving states via the registry keys I listed above (bFwCtrlLPS, bLeisurePs, etc.).

I strongly request that the HP/Realtek Windows driver engineering team review this Linux commit and port a similar logic fix to the Windows driver, or at least expose a "Gaming/Low-Latency" toggle in the Advanced adapter properties.

[Paul_Tikkanen]

I recommend you try this driver which is the latest one:

Version 2024.10.231.0 

sp172538.exe

[Oleksandr2032]

Hi Paul,

Thank you for the suggestion. I appreciate your help.

I have conducted a rigorous scientific experiment with the driver you provided (Version 2024.10.231.0 / sp172538.exe). The results definitively prove that the new driver does not fix the issue. Below is the full technical report.

Testing Methodology
To ensure a fair test, I performed the following steps:

Reverted ALL workarounds to factory defaults (Roaming Aggressiveness=Medium, LPS/IPS=ON, WlanSvc Autoconfig=ON, TCP Timestamps=Enabled, Network Throttling=10, RSC=ON, NetBIOS=ON, DNS=Auto).
Installed driver 2024.10.231.0 (sp172538.exe).
Rebooted the PC to ensure a clean driver load.
Ran a 7-minute continuous ICMP monitor (450ms interval, 869 samples) pinging the local gateway (192.168.1.1) and a remote game server (91.211.118.105) in parallel.

Results with Default Settings + New Driver (2024.10.231.0)
The periodic latency spikes have returned on default settings. While I did not encounter the massive 1-2 second spikes (2000ms+) in this specific 7-minute window, the periodic 100-168ms spikes were consistently present. In fast-paced online games, these 100-168ms freezes occurring every ~47 seconds completely break the gameplay experience.

Gateway (192.168.1.1):

Average: 10.74 ms
Maximum: 168 ms
Spikes >100ms: 29
Timeouts: 0
Game Server (91.211.118.105):

Average: 13.94 ms
Maximum: 167 ms
Spikes >100ms: 1
Timeouts: 0
Spike pattern analysis (9 spike-events over 7 minutes):

Spikes occurred in bursts of 2-5 consecutive packets (106-168ms each).
Average interval between spike-events: 47.1 seconds (range: 38-65 seconds).
This is the exact same firmware roaming/LPS scanning signature documented previously.

Results with Registry Workarounds Applied
After applying the hidden registry tweaks (detailed below), I ran the same 7-minute test.

Gateway (192.168.1.1):

Average: 2.59 ms
Maximum: 44 ms
Spikes >100ms: 0
Game Server (91.211.118.105):

Average: 13.88 ms
Maximum: 53 ms
Spikes >100ms: 0
Jitter (Std Dev): 2.25 ms
Timeouts: 0
Zero spikes over 7 minutes. The adapter maintains a rock-solid 2-3ms ping to the gateway.

Registry Workarounds Applied
All parameters are under:
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0002

Root Cause Fixes (Firmware Scanning & Power-Save):

Roaming Aggressiveness (RegROAMSensitiveLevel): Changed from 75 (Medium) to 127 (Disable) — This stops firmware roaming scans.
bFwCtrlLPS: Changed from 1 (ON) to 0 — Disables Leisure Power Save.
bLeisurePs: Changed from 2 (ON) to 0 — Disables Leisure Power Save.
bLowPowerEnable: Changed from 1 (ON) to 0 — Disables low-power mode.
Scan_IPSEnable: Changed from 1 (ON) to 0 — Disables Idle Power Save scanning.
Additional adapter properties set via Advanced Tab / Power Management:

Roaming Aggressiveness: 1. Disable
Preferred Band: 3. 5G first
Transmit Power: 5. Highest
Wake on Magic Packet: Disabled
Wake on Pattern Match: Disabled
ARP/NS/GTK Offload for WoWLAN: Disabled
Multi-Channel Concurrent: Disabled

DPC/ISR Verification
During spike events on default settings, CPU usage, DPC Time, and Interrupt Time all remain at 0%. This proves the latency is caused by the Realtek radio module physically leaving the channel (firmware scan) or entering a low-power state, not by CPU starvation.

This is not a hardware limitation. The official Realtek Linux driver (rtw88, maintained by Ping-Ke Shih in the pkshih/rtw repository) has addressed similar periodic latency spikes on Realtek chips by patching the LPS (Leisure Power Save) and background scanning logic so the firmware does not freeze the radio channel during active connections. This proves that the Windows driver team can implement a similar fix.

The driver version 2024.10.231.0 does not resolve the periodic ping spikes. The root cause remains the firmware-level LPS/IPS power-saving and background roaming scan mechanisms that bypass Windows OS controls.

I kindly request that this data be escalated to the Realtek Windows driver engineering team. The fix should either:

Port the LPS/IPS and scanning logic fixes from the Linux rtw88 driver to Windows.
Add an explicit "Gaming Mode" or "Ultra-Low Latency Mode" toggle in the Advanced adapter properties that applies these workarounds automatically.
This would save thousands of users from having to manually edit the registry to achieve a stable connection.

Thank you for your time and for escalating this to the engineering team.