Netzwerk · Diagnose · PowerShell

Windows-Netzwerk-Diagnose: So findest du Latenz-Killer auf deinem System

Bevor du optimierst, musst du wissen wo es hakt. Mit diesen Bordmitteln findest du es heraus.

🕐 ca. 7 Minuten Lesezeit · Jörn Walter · IT-Service Walter

Hohe Ping-Zeiten, stockende RDP-Sitzungen, laggy Gaming – die Ursachen können vielfältig sein. Bevor du blind Einstellungen änderst, solltest du wissen was genau auf deinem System die Latenz verursacht. Windows bringt alle notwendigen Werkzeuge dafür mit – du musst sie nur kennen.

In diesem Artikel zeige ich dir Schritt für Schritt wie du mit PowerShell und eingebauten Windows-Tools Latenz-Killer identifizierst – und was du dann damit machst.

Schritt 1: Baseline messen – ping mit Timestamps

Der erste Schritt ist immer eine Baseline. Du brauchst einen Referenzwert bevor du irgendetwas änderst.

# Kontinuierlicher Ping mit Zeitstempel – 60 Messungen
1..60 | ForEach-Object {
    $result = Test-Connection -ComputerName 8.8.8.8 -Count 1 -ErrorAction SilentlyContinue
    $time = Get-Date -Format “HH:mm:ss”
    if ($result) {
        Write-Host “$time RTT: $($result.ResponseTime) ms”
    } else {
        Write-Host “$time TIMEOUT” -ForegroundColor Red
    }
    Start-Sleep -Seconds 1
}

Was du suchst: Jitter – also Schwankungen zwischen den Messungen. Eine RTT die zwischen 5 ms und 45 ms springt ist ein deutliches Zeichen für ein Latenz-Problem auf Treiber- oder Stack-Ebene.

Richtwerte:
LAN <1 ms, Internet DSL ~10–30 ms, Internet Glasfaser ~5–15 ms. Jitter >10 ms im LAN = Problem.

Schritt 2: NIC-Einstellungen auslesen

Viele Latenz-Killer verstecken sich in den erweiterten Netzwerkadapter-Einstellungen. Mit PowerShell kannst du alle auf einmal auslesen:

# Alle erweiterten NIC-Einstellungen anzeigen
Get-NetAdapterAdvancedProperty | Select-Object Name, DisplayName, DisplayValue | Format-Table -AutoSize
# Nur die latenzrelevanten Einstellungen filtern
Get-NetAdapterAdvancedProperty | Where-Object {
    $_.RegistryKeyword -match “EEE|RSS|RSC|FlowControl|InterruptModeration|Coalescing|Buffers”
} | Select-Object Name, DisplayName, DisplayValue, RegistryValue | Format-Table -AutoSize

Folgende Einstellungen sind Latenz-Killer wenn sie aktiv sind:

Einstellung	Problem-Wert	Auswirkung
Energy-Efficient Ethernet	Enabled	10–100 µs Aufwach-Delay bei jedem Paket nach Pause
Interrupt Moderation	Enabled / Adaptive	CPU-Interrupts werden gebündelt → unregelmäßige Latenz
Packet Coalescing	Enabled	Pakete werden gesammelt und verzögert weitergegeben
Flow Control	Rx & Tx Enabled	PAUSE-Frames frieren gesamten Port kurz ein
Receive Buffers	<512	Paketdrop unter Last → Retransmission → Latenzspitzen

Schritt 3: TCP-Stack-Status prüfen

Der globale TCP-Stack hat ebenfalls Einstellungen die die Latenz beeinflussen:

# Globale TCP-Einstellungen anzeigen
netsh int tcp show global
# Offload-Einstellungen (RSS, RSC, PCF)
Get-NetOffloadGlobalSetting | Select-Object ReceiveSideScaling, ReceiveSegmentCoalescing, PacketCoalescingFilter
# Congestion-Algorithmus prüfen
Get-NetTCPSetting -SettingName Internet | Select-Object CongestionProvider, EcnCapability

Wenn CongestionProvider auf CUBIC steht und EcnCapability auf Disabled – das ist der Windows-Standard und einer der häufigsten Latenz-Gründe in lokalen Netzwerken.

Schritt 4: Delayed-ACK und Nagle-Algorithmus prüfen

Zwei Registry-Einstellungen die kaum jemand kennt, aber massive Auswirkungen auf die Latenz haben:

# TcpAckFrequency und TcpNoDelay für alle NICs prüfen
$NICs = Get-NetAdapter -Physical | Select-Object DeviceID, Name
foreach ($nic in $NICs) {
    $path = “HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$($nic.DeviceID)”
    $ackFreq = (Get-ItemProperty $path -Name TcpAckFrequency -EA SilentlyContinue)?.TcpAckFrequency
    $noDelay = (Get-ItemProperty $path -Name TcpNoDelay -EA SilentlyContinue)?.TcpNoDelay
    Write-Host “$($nic.Name): AckFreq=$ackFreq NoDelay=$noDelay”
}

Problem erkannt wenn:
TcpAckFrequency = nicht gesetzt (Delayed ACK aktiv = bis zu 200 ms Verzögerung) oder TcpNoDelay = nicht gesetzt (Nagle-Algorithmus aktiv).

Schritt 5: Bufferbloat erkennen

Bufferbloat ist wenn große Netzwerkpuffer zwar Paketverlust verhindern, aber dafür die Latenz massiv erhöhen. So testest du es:

# Ping während Last – Bufferbloat-Test
# 1. In einem Terminal: Datei-Download starten (z.B. Windows Update)
# 2. In zweitem Terminal gleichzeitig pingen:
ping 8.8.8.8 -t
# Wenn RTT unter Last von 10 ms auf 200+ ms springt = Bufferbloat

Alternativ: dslreports.com/speedtest hat einen eingebauten Bufferbloat-Test der dir direkt einen A–F Grade gibt.

Gefunden – und jetzt?

Wenn du mit den obigen Schritten Latenz-Killer auf deinem System identifiziert hast, gibt es zwei Wege:

🔧 Manuell beheben

Einzelne Einstellungen gezielt ändern – sinnvoll wenn du nur ein spezifisches Problem beheben willst und verstehst was du tust.

⚡ Automatisch optimieren

Der ISW TCP Optimizer Pro behebt alle bekannten Latenz-Killer automatisch – mit Registry-Backup und vollständigem Before/After-Report.

📋 Checkliste: Was du geprüft haben solltest

Baseline-Ping mit Jitter-Messung
NIC-Einstellungen: EEE, Interrupt Moderation, Flow Control, Buffers
TCP-Stack: Congestion Provider, ECN, RSS, RSC, PCF
Registry: TcpAckFrequency, TcpNoDelay pro NIC
Bufferbloat-Test unter Last