Unitymedia Intel Puma Plattform

[why_]

Mit meiner 6490 mit 6.50 habe ich zumindest bei dem Forum test keinerlei Schwankungen.
Die Werte erreiche ich bei 10 von 10 Tests.

 

[MartinP_Do]

Fritzbox 6490 UM/NRW, FW 6.50

2Play 100

Download 98.47 Mbit/s
Upload 6.34 Mbit/s
Ping 33.92 ms
Jitter 16.33 ms

 

[F-orced-customer]

Ping 33.92 ms
Jitter 16.33 ms

Das ist relativ hoch für so ne schnelle Leitung.

https://iperf.fr/iperf-download.php#windows
50/2, Connect Box

$ iperf3 -c ping.online.net -p 5209 -u -R
Connecting to host ping.online.net, port 5209
Reverse mode, remote host ping.online.net is sending
[ 4] local 192.168.0.105 port 55653 connected to 62.210.18.40 port 5209
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 136 KBytes 1.11 Mbits/sec 8.080 ms 0/17 (0%)
[ 4] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 3.989 ms 0/16 (0%)
[ 4] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 2.646 ms 0/16 (0%)
[ 4] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 2.056 ms 0/16 (0%)
[ 4] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 6.488 ms 0/16 (0%)
[ 4] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 3.805 ms 0/16 (0%)
[ 4] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 3.707 ms 0/16 (0%)
[ 4] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 2.815 ms 0/16 (0%)
[ 4] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 4.598 ms 0/16 (0%)
[ 4] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 4.205 ms 0/16 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 4.205 ms 0/161 (0%)
[ 4] Sent 161 datagrams
iperf Done.

 

[MartinP_Do]

Ich habe die Vermutung, dass der Ping und der Jitter sich nicht proportional zu einer Erhöhung der Datenrate durch einen teureren Vertrag verbessert.

Mit einem potenten Vertrag wird wohl das Modem das Eine oder andere Mal einen früheren Zeitschlitz bekommen, aber in vollen Segmenten muss eben jedes Modem nicht selten eine gewisse Zeit warten, bis es "dran" ist ...

 

[Andreas1969]

aber in vollen Segmenten muss eben jedes Modem nicht selten eine gewisse Zeit warten, bis es "dran" ist ...

Dann könnte man ja vom Ping / Jitter fast schon die Auslastung, bzw. die ungefähre Anzahl der Modems im Segment ableiten / korrelieren.

 

[MartinP_Do]

aber in vollen Segmenten muss eben jedes Modem nicht selten eine gewisse Zeit warten, bis es "dran" ist ...

Dann könnte man ja vom Ping / Jitter fast schon die Auslastung, bzw. die ungefähre Anzahl der Modems im Segment ableiten / korrelieren.

Eine automatisierte Messung im Tagesgang müsste dann Unterschiede bringen. So lange die Kiddies in der Schule sind, sollte die Segmentauslastung deutlich sinken ...

 

[addicted]

aber in vollen Segmenten muss eben jedes Modem nicht selten eine gewisse Zeit warten, bis es "dran" ist ...

Dann könnte man ja vom Ping / Jitter fast schon die Auslastung, bzw. die ungefähre Anzahl der Modems im Segment ableiten / korrelieren.

Die Anzahl der Geräte kannst Du anhand der DHCP-Replies (bzw. den MAC-Adressen darin) abschätzen*. Die initialen DHCP Replies (wenn das Gerät zum ersten Mal nach einer IP fragt) sind Broadcast und können daher von jedem Teilnehmer im Segment empfangen werden.


* Abschätzen deshalb, weil Geräte, die standardkonform sind und einfach durchlaufen, bereits eine IP haben und diese dann nur erneuern - dabei kommt es nicht zu Broadcasttraffic.

 

[F-orced-customer]

Ja das konnte ich mit iptraf-ng aufm debian router am cisco gut beobachten. Hier ist viel los.

 

[MartinP_Do]

Das wäre ja mal ein Projekt: MAC-Adressen im Segment bei einer Dauermessung über mehrere Wochen "abernten" und wegschreiben.
Da könnte man schon einen ziemlich vollständigen Überblick über sein Kabelsegment bekommen, ohne groß neue Hardware zu benutzen, z. B. einen DVB-C USB-Stick als "segment-sniffer"...

 

[F-orced-customer]

Wer von Euch ist treefiddy?

https://www.dslreports.com/forum/r31122204-SB6190-Puma6-TCP-UDP-Network-Latency-Issue-Discussion~start=6540

 

[F-orced-customer]

Es kommen grad FW updates, behaltet Eure Boxen im Auge:
https://www.dslreports.com/forum/r31122204-SB6190-Puma6-TCP-UDP-Network-Latency-Issue-Discussion~start=6510

Software Version	:	CH7465LG-NCIP-4.50.18.23-4-GA-NOSH

 

[Conan179]

Würde mich nciht wundern, wen der Deutsche Hersteller AVM, vorerst kein update bringt, weil er den patch scon mit der 6.84 verteilt hat.

 

[F-orced-customer]

Weiss wer wie man hier direkt auf postings verlinken kann?
https://www.dslreports.com/forum/r31122204-SB6190-Puma6-TCP-UDP-Network-Latency-Issue-Discussion~start=6540

 

[MartinP_Do]

Die Anzahl der Geräte kannst Du anhand der DHCP-Replies (bzw. den MAC-Adressen darin) abschätzen*. Die initialen DHCP Replies (wenn das Gerät zum ersten Mal nach einer IP fragt) sind Broadcast und können daher von jedem Teilnehmer im Segment empfangen werden.

Kommen denn die DHCP-Replies, die fremde Router auslösen an den inneren Ports des eigenen Routers an?

sudo tcpdump -i eth0 port 67 or port 68 -e -n

... bleibt jedenfalls stumm ...

 

[tq1199]

Kommen denn die DHCP-Replies, die fremde Router auslösen an den inneren Ports des eigenen Routers an?

Ja, die DHCP-replies kommen an. Z. B.:

<i>
</i>:~ $ tcpdump -veni eth0 udp portrange 67-68 | grep -E ''[0-9]\{1,2\}\:[0-9]\{1,2\}\:[0-9]\{1,2\}\.[0-9]\{1,6\}'|Client-Ethernet-Address'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:28:52.427217 ##:##:##:79:##:46 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 391: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 377) Client-Ethernet-Address c8:0e:14:8a:34:xx
11:28:53.275242 ##:##:##:79:##:46 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 391: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 377) Client-Ethernet-Address 34:81:c4:c8:b1:xx
11:29:03.231591 ##:##:##:79:##:46 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 391: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 377) Client-Ethernet-Address 24:65:11:56:0c:xx
11:29:21.482981 ##:##:##:79:##:46 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) Client-Ethernet-Address f4:f2:6d:94:b3:xx
11:29:27.188854 ##:##:##:79:##:46 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 391: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 377) Client-Ethernet-Address 24:65:11:19:d9:xx
11:29:32.177726 ##:##:##:79:##:46 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 391: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 377) Client-Ethernet-Address bc:05:43:bb:2f:xx
11:29:34.218642 ##:##:##:79:##:46 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 391: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 377) Client-Ethernet-Address c0:25:06:1c:15:xx
11:30:13.962983 ##:##:##:79:##:46 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 391: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 377) Client-Ethernet-Address 34:81:c4:d6:6e:xx

 

[MartinP_Do]

Viele AVM-Geräte, 1x Technicolor, sieht irgendwie schlüssig aus.

Bei mir läuft das gerade schon (genau mit Deiner Eingabezeile) seit ca 30 Minuten, ohne dass etwas passiert.
Mal schauen, ob sich bis heute abend etwas fängt ...

Hier habe ich mit einem anderen Tool etwas gefangen

 sudo dhcpdump -i eth0 TIME: 2017-10-08 12:47:30.547 IP: 0.0.0.0 (80:d0:9b:8:40:xx) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) OP: 1 (BOOTPREQUEST) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: bb93ac80 SECS: 0 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 80:d0:9b:08:40:xx:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: .
OPTION: 53 ( 1) DHCP message type 3 (DHCPREQUEST)
OPTION: 50 ( 4) Request IP address 192.168.2.23
OPTION: 57 ( 2) Maximum DHCP message size 1500
OPTION: 60 ( 12) Vendor class identifier dhcpcd-5.5.6
OPTION: 12 ( 24) Host name android-d4xxxxxxxxxxxxxxxx
OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) 33 (Static route) 3 (Routers) 6 (DNS server) 15 (Domainname) 28 (Broadcast address) 51 (IP address leasetime) 58 (T1) 59 (T2)
---------------------------------------------------------------------------

 

[tq1199]

Hier habe ich mit einem anderen Tool etwas gefangen

 sudo dhcpdump -i eth0 OP: 1 (BOOTPREQUEST)
OPTION: 12 ( 24) Host name android-d4xxxxxxxxxxxxxxxx

Ich denke das wird aus deinem WLAN sein (android). Die von UM sehen hier z. B. so aus:

<i>
</i>TIME: 2017-10-08 13:44:42.250 IP: 10.217.252.1 #:#:##:79:##:46) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 1 XID: c45435d3 SECS: 0 FLAGS: 7f80
CIADDR: 46.###.135.##
YIADDR: 46.###.135.##
SIADDR: 85.###.127.10
GIADDR: 10.217.252.1
CHADDR: 24:65:11:05:6e:##:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: .
OPTION: 53 ( 1) DHCP message type 5 (DHCPACK)
OPTION: 54 ( 4) Server identifier 10.217.252.1
OPTION: 51 ( 4) IP address leasetime 3600 (60m)
OPTION: 1 ( 4) Subnet mask 255.255.254.0
OPTION: 43 ( 65) Vendor specific info 687474703a2f2f61 http://a 63732e70726f762e cs.prov. 6b6162656c62772e kabelbw. 64653a373534372f de:7547/ 6c6976652f435045 live/CPE 4d616e616765722f Manager/ 435045732f67656e CPEs/gen 6572696354523639 ericTR69 00 .
OPTION: 3 ( 4) Routers 46.###.###.1
OPTION: 6 ( 8) DNS server 80.69.96.12,81.210.129.4
OPTION: 26 ( 2) Interface MTU 1500

Bekommst Du mit:

<i>
</i>sudo tcpdump -c 30 -veni eth0 arp

eine Ausgabe?

 

[addicted]

Das geht nur an Bridge-Ports (oder natürlich mit Modems). Hinter einer normalen ConnectBox und vergleichbaren Routern bekommt man keine Broadcasts aus dem Docsis-Segment.

 

[tq1199]

Das geht nur an Bridge-Ports ...

Ja, aber nicht im RIP-Modus an Bridge-Ports, ... denn im RIP-Modus ist die FritzBox (oder gleichwertig) das Gateway.

 

[addicted]

Wenn RIP aktiv ist sind es ja auch keine Bridge-Ports mehr. Dass AVM das in der Firmware noch so nennt ist halt falsch

 

[MartinP_Do]

Sieht alles sehr "intern" aus.
Ich denke auch, dass das an einem Router nicht funktioniert...

sudo tcpdump -c 30 -veni eth0 arp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:59:25.563739 c0:ee:fb:4b:c5:14 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.62, length 46
16:59:38.682818 c0:ee:fb:4b:c5:14 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.62, length 46
16:59:40.744420 c8:0e:14:e6:88:ff > 00:19:99:9d:db:6e, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.42 tell 192.168.2.1, length 46
16:59:40.744445 00:19:99:9d:db:6e > c8:0e:14:e6:88:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.2.42 is-at 00:19:99:9d:db:6e, length 28
16:59:54.733807 c0:ee:fb:4b:c5:14 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.62, length 46
17:00:07.843364 c0:ee:fb:4b:c5:14 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.62, length 46
17:00:12.143247 00:19:99:9d:db:6e > 00:10:75:1a:de:03, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.110 tell 192.168.2.42, length 28
17:00:12.143328 00:10:75:1a:de:03 > 00:19:99:9d:db:6e, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.2.110 is-at 00:10:75:1a:de:03, length 46
17:00:20.964081 c0:ee:fb:4b:c5:14 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.62, length 46
17:00:24.864178 c8:0e:14:e6:88:ff > 00:19:99:9d:db:6e, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.42 tell 192.168.2.1, length 46
17:00:24.864203 00:19:99:9d:db:6e > c8:0e:14:e6:88:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.2.42 is-at 00:19:99:9d:db:6e, length 28
17:00:44.085090 c0:ee:fb:4b:c5:14 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.62, length 46

 

[terminal6]

Hallo zusammen,

Ich stehe gerade vor der Entscheidung meine schrottige TC7200 durch eine ConnectBox ersetzen zu lassen. Aber seit ich auf die Puma Thematik gestoßen bin, frage ich mich, ob ich das erstmal besser lassen sollte...
WLAN hab ich inzwischen sowieso anders geregelt (separater AC-Access Point von TPLink), da der Router/Kabel-Anschlussort eh suboptimal liegt. Hab halt das Gefühl, dass die TC7200 einmal im Monat einen Neustart braucht, um sauber zu funktionieren (mal fällt das WebUI aus, mal ist der Datendurchsatz unterirdisch). Hatte das auch schon Anfang 2016, als die ConnectBox rauskam, reklamiert, aber war offenbar nicht penetrant genug, dass UM das lösen wollte.

Ich habe ein paar der genannten Messungen durchgeführt (DSLReports Puma Cable Modem Test, TBB Test und Forum Test) und erhalte gute Ergebnisse ohne Spikes u.ä., s.u.
Bin kein Hardcore-Gamer, aber das scheint ja auch massiven Einfluss auf Ladezeiten von Webseiten zu haben.

Was meint ihr?

Forum: Ping 33.13ms, Jitter 8.93ms

DSLReports

<i>
</i>35ms : x
36ms : xxxxx
37ms : xxxxxxxxxxx
38ms : xxxxxxxxxxxxxxxxxxxxxxxx
39ms : xxxxxxxxxxxxxxxxxxxxx
40ms : xxxxxxxxxxxxxxxxxxxxxxx
41ms : xxxxxxxxxxx
42ms : xxxxxxxxxxxxxxxxxxxxxx
43ms : xxxxxxxxxxxxxxxxxxxxxxxxxxxx
44ms : xxxxxxxxxx
45ms : xxxxxxx
46ms : xxxxxxxxxx
47ms : xxxxx
48ms : xxxxx
49ms : xxx
50ms : xxxx
51ms : xxx
52ms : xxx
53ms : xx
54ms : xx
55ms : x
60ms : xx

 

[F-orced-customer]

Mit der Connect Box musste damit rechnen:

http://www.dslreports.com/tools/puma6

43ms : x
45ms : xxx
46ms : xx
47ms : x
48ms : xxx
49ms : xxx
50ms : xxxx
51ms : xxxx
52ms : xxxxx
53ms : xxxxxxxxxxx
54ms : xxxxxx
55ms : xxxxxxxxxx
56ms : xxxxxxxxxx
57ms : xxx
58ms : xxxxxxxxxx
59ms : xxxxxxxxxx
60ms : xxxxxxxxxxxx
61ms : xxxxxxxxxx
62ms : xx
63ms : xxx
64ms : xxxxxx
65ms : xxxxxxxxxxx
66ms : xxxxxxxxx
67ms : x
68ms : xxxxxxxx
69ms : xx
70ms : xxxx
71ms : xxxxxx
72ms : xx
73ms : x
74ms : x
75ms : xxx
76ms : xx
79ms : x
81ms : xxxx
84ms : x
86ms : x
87ms : x
95ms : x
96ms : x
100 - 149ms :xxxxxxxxxxxxxxx
150 - 199ms :xxxxxxx
250 - 299ms :xx

 

[Conan179]

ich würde die finger weg lassen von der cbox und ne freie kabel fritte hollen.
6590:
36ms : xx
37ms : xxxxxxxxxx
38ms : xxxxxxxxxx
39ms : xxxxxxxxxxxxxxxxxxxxx
40ms : xxxxxxxxxxxxxxx
41ms : xxxxxxxxxxxxxx
42ms : xxxxxxxxxxxxxxx
43ms : xxxxxxxxxxxxxxxxx
44ms : xxxxxxxxxxx
45ms : xxxxxxxxxxxxxxx
46ms : xxxxxx
47ms : xxxxxxx
48ms : xxxxxxxxxxx
49ms : xxxxxxx
50ms : xxxxxxxxxxxx
51ms : xxxxx
52ms : xx
54ms : xx
55ms : x
56ms : x
57ms : xxx
58ms : x
59ms : xxx
60ms : x
62ms : x
63ms : x
67ms : xx

 

[Andreas1969]

Mit der Provider Fritzbox FW 6.50 sieht's auch nicht viel besser aus.

 52ms : x
56ms : xx
57ms : xx
59ms : xx
60ms : xxxxxx
61ms : xxx
62ms : xxxx
63ms : xxxxxxx
64ms : xx
65ms : xxx
66ms : xxx
67ms : xxx
68ms : xxxx
69ms : xxx
70ms : xxx
71ms : xxx
73ms : xx
74ms : x
75ms : xxxx
76ms : xxxxx
77ms : xxx
78ms : xxxxx
79ms : xxxxxxxxx
80ms : xxxxxx
81ms : xxxxxx
82ms : xxxx
83ms : xxx
84ms : x
85ms : xxx
86ms : xxxx
87ms : xxxxxxx
88ms : xx
89ms : xxxx
90ms : xxxx
91ms : xx
92ms : xxxx
93ms : x
94ms : xx
95ms : x
96ms : x
98ms : x
99ms : x
100 - 149ms :xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
150 - 199ms :xxxxxxxx
200 - 249ms :x
250 - 299ms :xx
950 - 999ms :xx