:strip_icc():strip_exif()/u/13062/crop5e0cde80e7d91_cropped.jpeg?f=community)
Ik loop al een tijd aan tegen haperende 4K-playback in Kodi op de Xiaomi TV Box S (3rd Gen, Amlogic S905X5M, Google TV 14, build UKG3.250826.001.V816.0.11.0.UZFAABX). Na flink wat meten blijkt het geen netwerk- of adapterprobleem te zijn, maar iets in de box zelf. Ben benieuwd of anderen dit kunnen reproduceren.
Als de verzender grote blokken schrijft (2 KB of meer) kan de box kan TCP-verkeer alleen met ~15 Mbit/s ontvangen. Met blokken van 1 KB haalt dezelfde verbinding 150 Mbit/s. Zenden vanaf de box gaat gewoon met 360 Mbit/s, UDP is foutloos tot 90 Mbit/s. Het gedrag is identiek over twee verschillende USB-ethernetadapters (TP-Link UE300/RTL8153 en StarTech USB31000S/AX88179) en over de ingebouwde Wi-Fi.
iperf3, server op de box, bekabeld:
- -l 1024: 151 Mbit/s
- -l 4096: 13-20 Mbit/s
- -l 4096 -R (box zendt): 362 Mbit/s
- UDP 50M met 1514-byte frames: 0% verlies
- -l 4096 -M 536 (kleinere segmenten): 3,7 Mbit/s, dus erger
Over Wi-Fi hetzelfde beeld: 58 Mbit/s met 1 KB, 8 Mbit/s met 4 KB, 170 Mbit/s omgekeerd.
Wat ik heb getest: LSO aan/uit, routerpoort op 100M en 1G, flow control aan/uit (0 fouten, 0 drops op de poort, alle frames verlaten de router), twee adapters, Wi-Fi, MSS-clamping. Factory reset gedaan, er zijn geen updates beschikbaar.
Een wireshark capture laat (als het traag is) 27% retransmissies en RTO-stalls van 300 ms zien. Opvallend patroon: van elke reeks opeenvolgende segmenten komt het eerste aan, de rest gaat voor ~50% verloren. In de snelle 1 KB-run heeft elk segment de PSH-flag, in de trage 4 KB-run niet. Dat ruikt naar een GRO-probleem in het TCP-ontvangstpad van de kernel (5.15.196-android14-11). Zonder root niet te bevestigen.
Om dit te reproduceren heb ik de Free iPerf3 client gebruikt, dan vanaf iets anders in het netwerk:
iperf3 -c <box> -l 1024 -t 5 en daarna iperf3 -c <box> -l 4096 -t 5.
Als die twee een factor 5-10 verschillen, zie je hetzelfde.
Iemand die hier iets zinnigs over kan zeggen of hoe op te lossen?
Als de verzender grote blokken schrijft (2 KB of meer) kan de box kan TCP-verkeer alleen met ~15 Mbit/s ontvangen. Met blokken van 1 KB haalt dezelfde verbinding 150 Mbit/s. Zenden vanaf de box gaat gewoon met 360 Mbit/s, UDP is foutloos tot 90 Mbit/s. Het gedrag is identiek over twee verschillende USB-ethernetadapters (TP-Link UE300/RTL8153 en StarTech USB31000S/AX88179) en over de ingebouwde Wi-Fi.
iperf3, server op de box, bekabeld:
- -l 1024: 151 Mbit/s
- -l 4096: 13-20 Mbit/s
- -l 4096 -R (box zendt): 362 Mbit/s
- UDP 50M met 1514-byte frames: 0% verlies
- -l 4096 -M 536 (kleinere segmenten): 3,7 Mbit/s, dus erger
Over Wi-Fi hetzelfde beeld: 58 Mbit/s met 1 KB, 8 Mbit/s met 4 KB, 170 Mbit/s omgekeerd.
Wat ik heb getest: LSO aan/uit, routerpoort op 100M en 1G, flow control aan/uit (0 fouten, 0 drops op de poort, alle frames verlaten de router), twee adapters, Wi-Fi, MSS-clamping. Factory reset gedaan, er zijn geen updates beschikbaar.
Een wireshark capture laat (als het traag is) 27% retransmissies en RTO-stalls van 300 ms zien. Opvallend patroon: van elke reeks opeenvolgende segmenten komt het eerste aan, de rest gaat voor ~50% verloren. In de snelle 1 KB-run heeft elk segment de PSH-flag, in de trage 4 KB-run niet. Dat ruikt naar een GRO-probleem in het TCP-ontvangstpad van de kernel (5.15.196-android14-11). Zonder root niet te bevestigen.
Om dit te reproduceren heb ik de Free iPerf3 client gebruikt, dan vanaf iets anders in het netwerk:
iperf3 -c <box> -l 1024 -t 5 en daarna iperf3 -c <box> -l 4096 -t 5.
Als die twee een factor 5-10 verschillen, zie je hetzelfde.
Iemand die hier iets zinnigs over kan zeggen of hoe op te lossen?
A software developer is someone who looks both left and right when crossing a one-way street.
Dé antenne-innovatie voor de korte golf