Unitymedia Fritz Box 6490 + TP-Link TLSG1005D = Packetverlust?

[EL3CTRiC]

Hi,

in der Suche bin ich schon auf ein paar Dinge gestoßen die mein Problem betreffen allerdings habe ich keine Lösung gefunden.

Zum Netzwerkaufbau:

FritzBox 6490 (400/"20") 1. LanKabel Cat 5e geht in den Switch 1000mbit/100mbit TP Link: TL SG1005D - davon ab:

XboxOne
TV
PC

Nun das Problem: Spielt meine Freundin an der Xbox z.B. Overwatch und ich am PC ne Runde CS, kann ich einen Loss von max 5% im netgraph ablesen, dieser bleibt dann immer zwischen 1 und 3%.

Da ich nicht richtig weiß ob es vielleicht der Switch oder die Box ist wollte ich fragen ob es hier eine Einstellung gibt die ich übersehe. Ein ping -t auf google über 3 min gibt nicht einen Verlust, daher bin ich etwas ratlos ob es nicht vielleicht sogar an UM liegt.

Danke für eure Tipps.

 

[addicted]

kann ich einen Loss von max 5% im netgraph ablesen

Also, dieses netgraph verwirrt mich ein wenig:

netgraph is the graph based kernel networking subsystem of FreeBSD.

(https://en.wikipedia.org/wiki/Netgraph)
Das wird nicht sein, was Du meinst.
Um zu beurteilen, was das anzeigt, müsste man wissen, was das ist und wie das arbeitet.

 

[kev_sei]

Der Netgraph ist auf Counterstrike bezogen. Dort kann man mit einem Consolenbefehl "net_graph 1" sich verschiedene daten im Spiel anzeigen lassen.

Zu deinem Problem:

Den Loss haben zur Zeit viele. Das liegt an CS bzw deren Server. Die Anbindung scheint zur Zeit nicht die beste zu sein. Also würde ich ersmal sagen, dass es nicht an deinem Netzwerk liegt.
Du kannst ja mal neben Matchmaking auch mal Faceit oder anderes testen. Dort solltest du diese Probleme nicht haben.

Habe auch ab und an auf Servern 1-5% Loss aber hauptsächlich nur im MM.

 

[EL3CTRiC]

Danke, FaceIt werde ich einmal ausprobieren. Komisch ist nur das bei Overwatch an der Xbox das gleiche zu beobachten ist, hier kommt die Warnung oben rechts das ein Verlust vorhanden ist, bei BF1 ist es das selbe, wobei es hierbei eindeutig an den Servern und Netcode liegt.

Gibt es möglichen den Paketloss richtig zu testen? Also nicht nur über CMD?

 

[addicted]

Gibt es möglichen den Paketloss richtig zu testen? Also nicht nur über CMD?

"Richtig"?

1. Wenn Du in der Commandline den ping Befehl verwendest, werden ICMP Pakete gesendet. Die Spiele verwenden idR UDP. Das sind andere Protokolle, die vom Netz durchaus anders behandelt werden (können).
2. Packetloss kannst Du nur feststellen, wenn Du genau weißt, welche Pakete ankommen sollen - d.h. erstens kann das nur der Empfänger feststellen, und zweitens muss dann entweder ein exaktes Timing für die Pakete bekannt sein, oder sie müssen numeriert sein.
3. Packetloss bei Echtzeitanwendungen kann neben dem Netz auch am Endgerät liegen, z.B. bei Paketen in festen Zeitabschnitten (wie bei Telefonie), wenn der Sender oder Empfänger überlastet sind, dann werden die Pakete nicht schnell genug gesendet oder verarbeitet und letztlich verworfen, weil sie zu alt sind.

Ich glaube iperf kann auch Loss anzeigen. Du brauchst logischerweise eine Gegenstelle im Netz.

 

[tq1199]

Gibt es möglichen den ...

UDP-Pakete kannst Du z. B. auch mit nping (gibt es auch für Windows; ... und wireshark statt tcpdump) über das Internet übertragen/senden und am Ziel zählen/auswerten. Z. B.:

Quelle:

<i>
</i>:~$ sudo nping -c 9 --udp --delay 1s -g 3456 -p 8878 46.###.###.##
Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2017-02-22 10:00 CET
SENT (0.0298s) UDP 192.168.178.21:3456 > 46.###.###.##:8878 ttl=64 id=19202 iplen=28
SENT (1.0303s) UDP 192.168.178.21:3456 > 46.###.###.##:8878 ttl=64 id=19202 iplen=28
SENT (2.0317s) UDP 192.168.178.21:3456 > 46.###.###.##:8878 ttl=64 id=19202 iplen=28
SENT (3.0332s) UDP 192.168.178.21:3456 > 46.###.###.##:8878 ttl=64 id=19202 iplen=28
SENT (4.0345s) UDP 192.168.178.21:3456 > 46.###.###.##:8878 ttl=64 id=19202 iplen=28
SENT (5.0356s) UDP 192.168.178.21:3456 > 46.###.###.##:8878 ttl=64 id=19202 iplen=28
SENT (6.0373s) UDP 192.168.178.21:3456 > 46.###.###.##:8878 ttl=64 id=19202 iplen=28
SENT (7.0379s) UDP 192.168.178.21:3456 > 46.###.###.##:8878 ttl=64 id=19202 iplen=28
SENT (8.0392s) UDP 192.168.178.21:3456 > 46.###.###.##:8878 ttl=64 id=19202 iplen=28
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 9 (252B) | Rcvd: 0 (0B) | Lost: 9 (100.00%)
Nping done: 1 IP address pinged in 9.07 seconds

Ziel:

<i>
</i>:~ $ sudo tcpdump -c 9 -eni eth0 udp port 3456
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:00:08.555402 xx:xx:xx:79:72:xx > yy:yy:yy:62:3c:yy, ethertype IPv4 (0x0800), length 60: 37.**.**.***.3456 > 46.###.###.##.8878: UDP, length 0
10:00:09.556343 xx:xx:xx:79:72:xx > yy:yy:yy:62:3c:yy, ethertype IPv4 (0x0800), length 60: 37.**.**.***.3456 > 46.###.###.##.8878: UDP, length 0
10:00:10.561184 xx:xx:xx:79:72:xx > yy:yy:yy:62:3c:yy, ethertype IPv4 (0x0800), length 60: 37.**.**.***.3456 > 46.###.###.##.8878: UDP, length 0
10:00:11.559152 xx:xx:xx:79:72:xx > yy:yy:yy:62:3c:yy, ethertype IPv4 (0x0800), length 60: 37.**.**.***.3456 > 46.###.###.##.8878: UDP, length 0
10:00:12.561182 xx:xx:xx:79:72:xx > yy:yy:yy:62:3c:yy, ethertype IPv4 (0x0800), length 60: 37.**.**.***.3456 > 46.###.###.##.8878: UDP, length 0
10:00:13.561141 xx:xx:xx:79:72:xx > yy:yy:yy:62:3c:yy, ethertype IPv4 (0x0800), length 60: 37.**.**.***.3456 > 46.###.###.##.8878: UDP, length 0
10:00:14.561176 xx:xx:xx:79:72:xx > yy:yy:yy:62:3c:yy, ethertype IPv4 (0x0800), length 60: 37.**.**.***.3456 > 46.###.###.##.8878: UDP, length 0
10:00:15.561747 xx:xx:xx:79:72:xx > yy:yy:yy:62:3c:yy, ethertype IPv4 (0x0800), length 60: 37.**.**.***.3456 > 46.###.###.##.8878: UDP, length 0
10:00:16.564402 xx:xx:xx:79:72:xx > yy:yy:yy:62:3c:yy, ethertype IPv4 (0x0800), length 60: 37.**.**.***.3456 > 46.###.###.##.8878: UDP, length 0
9 packets captured
9 packets received by filter
0 packets dropped by kernel

 

[gnujuba]

Hast du mal versucht deinen PC mit den LAN Ports der FB direkt zu verbinden statt an den Switch? Falls möglich, Einbauort usw ....

Ich habe seit Beginn meines UM Vertrags Probleme mit der Verbindung eines Switches an die FB6490.
Vor 6.50 konnte ich das Problem, dass bei hoher Last (Webex Session mit Audio und Video) es immer wieder kurz zu Unterbrechungen kommt, reproduzieren.
Jetzt mit 6.50 kommt es beim Spielen immer wieder mal vor, ohne das ich es reproduzieren kann.

Vom Gefühl her wird die Verbindung zwischen FW und Switch kurz neu ausgehandelt, Pings gehen dann so ca. 4 Sekunden verloren.

Meinen PC (Win10) und mein Mac Book (LAN) habe ich daher direkt mit der FB verkabelt.

Das Lustige ist, meine zwei AVM Access Points (1750E und DVB-C, beide als LAN Brücke konfiguriert) verhalten sich am Switch besser.
Verbinde ich die zwei Kollegen mit der FB habe ich ca. 10% Packet Loss.