wie groß der Durchsatz je tunnel ist liegt ja nicht nur am gateway sondern an den internetleitungen der betroffen user, wenn du einen bereich hast wo die leute nur 16Mbit Anschlüsse haben können die am Ende auch nichtmehr leisten… ( sorry für die RS Fehler)
Es geht nicht nur um den Durchsatz pro Tunnel, das ganze Gateway lahmt dann einfach.
Nehmen wir z. B. einen VDSL-100 Anschluss. Der performt erst noch super mit Freifunk über das Gateway. Wenn aber durch einen Serverausfall woanders plötzlich die Tunnelanzahl steigt, geht deutlich weniger bis gar nichts mehr.
So was ist ja dann letztlich eine Aufgabe fuer ausgewiesene Linux Performance Troubleshooting Geeks.
An welcher User- oder Kernelland-Ressource skaliert der Kram ab einem bestimmten Punkt nicht mehr ?
In gewissen Grenzen kann man das aber schon vorqualifizieren und bestimmte Fragen stellen:
Mit steigenden n geht die CPU Last rauf oder hoert das dann irgendwann auf ?
Mit sieht es dabei mit dem Verhaeltnis User/SystemCPU aus ?
Gibt es Prozesse/Threads, die fuer sich betrachtet, dauerhaft 100% CPU haben und leider nicht parallelisiert werden koennen ? Meist ist da dann des Pudels Kern.
Ob die SystemCPU steigt haengt zB mit den verwendeten Synchronisationsmitteln zusammen, Wenn der Overhead gross ist, schlagen sich die dann die Koepfe ein um irgendein Semaphor und es werden dauernd n-1 Kontexte aufgeweckt, weil ja gerade wieder was frei geworden ist. Oder ist das besser geloest ?
Und sowas erfordert dann die Mittel, dem Kernel dabei ueber die Schulter schauen zu koennen.
Wir haben kitrace immer unter HPUX verwendet, ich weiss aber dass das Linuxlab das auch fuer Linux verfuegbar gemacht hat (ki == kernel instrumentation), ich habe aber keinen Schimmer, wie distriportabel das mittlerweile ist. .
Vielleicht gibt es aber im Netz aber auch Grundaussagen zur Skalierbarkeit der e.g. l2tp Tunnelhandler ?
Ich kann hier mangels Praxis unter Linux hier nur generische Denkanstoesse liefern.
Hmm, -v?
Denn:
root@ping-ffgt:~# iperf3 -t 60 -i 10 -c 10.255.0.10
Connecting to host 10.255.0.10, port 5201
[ 4] local 10.255.8.118 port 48142 connected to 10.255.0.10 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-10.00 sec 801 MBytes 671 Mbits/sec 88 872 KBytes
[ 4] 10.00-20.01 sec 801 MBytes 671 Mbits/sec 57 535 KBytes
[ 4] 20.01-30.00 sec 828 MBytes 695 Mbits/sec 0 844 KBytes
[ 4] 30.00-40.01 sec 730 MBytes 612 Mbits/sec 105 230 KBytes
[ 4] 40.01-50.00 sec 738 MBytes 620 Mbits/sec 33 184 KBytes
[ 4] 50.00-60.01 sec 694 MBytes 582 Mbits/sec 31 160 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.01 sec 4.48 GBytes 642 Mbits/sec 314 sender
[ 4] 0.00-60.01 sec 4.48 GBytes 642 Mbits/sec receiver
iperf Done.
Setup:
root@ping-ffgt:~# ip addr show dev br0
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 36:a9:da:92:b4:e6 brd ff:ff:ff:ff:ff:ff
inet 10.255.8.118/20 brd 10.255.15.255 scope global br0
valid_lft forever preferred_lft forever
inet6 2001:bf7:1310:10:fd91:9b1:4919:fd51/64 scope global temporary dynamic
valid_lft 86400sec preferred_lft 14400sec
inet6 2001:bf7:1310:10:34a9:daff:fe92:b4e6/64 scope global mngtmpaddr dynamic
valid_lft 86400sec preferred_lft 14400sec
inet6 fd42:ffee:ff12:aff:fd91:9b1:4919:fd51/64 scope global temporary dynamic
valid_lft 86400sec preferred_lft 14400sec
inet6 fd42:ffee:ff12:aff:34a9:daff:fe92:b4e6/64 scope global mngtmpaddr dynamic
valid_lft 86400sec preferred_lft 14400sec
inet6 fe80::34a9:daff:fe92:b4e6/64 scope link
valid_lft forever preferred_lft forever
root@ping-ffgt:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.36a9da92b4e6 no Egw00
Egw00 ist ein L2TP-Tunnel zu gw00 (VM auf, derzeit, dem gleichen Host).
root@gw00:~# brctl show
bridge name bridge id STP enabled interfaces
br-ffgt 8000.063799d0accd no Epingff
bat-ffgt
root@gw00:~# /usr/sbin/batctl -m bat-ffgt if
Egw10: active
Epingff ist die andere Seite von Egw00 auf, eben, gw00. gw00 ist ein Pseudo-Gateway, welches wir für spezielle Anbindungen (nicht über fastd oder Tunneldigger) nutzen. gw00 hängt per L2TP-Tunnel an gw10 (welches, derzeit, auf dem gleichen Host wie gw00 & ping-ffgt läuft):
root@gw10:~# brctl show
bridge name bridge id STP enabled interfaces
br-ffgt 8000.deadbeef0210 no bat-ffgt
root@gw10:~# batctl-ffgt if
ffgt-mesh-vpn: active
Egw02: active
Egw04: active
Egw00: active
root@gw10:~# ip addr show br-ffgt
25: br-ffgt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether de:ad:be:ef:02:10 brd ff:ff:ff:ff:ff:ff
inet 10.255.0.10/20 brd 10.255.15.255 scope global br-ffgt
valid_lft forever preferred_lft forever
inet6 2001:bf7:1310:10::10/64 scope global
valid_lft forever preferred_lft forever
inet6 fd42:ffee:ff12:aff::1:10/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::1cbe:d3ff:fed2:3099/64 scope link
valid_lft forever preferred_lft forever
Dürfte selbsterklärend sein. Fakt ist: ping-ffgt
→ gw10
lief über eine batman-Strecke (gw00
<> gw10
) und lieferte >600 MBit/sec. Heißt: batman kann auch >200 MBit/sec transportieren, auch wenn L2TP involviert ist.
(Oops, Korrektur/Nachtrag: Der Kram ging tatsächlich über’s Netz im DC, denn nur gw10 und ping-ffgt laufen auf dem gleichen Host, gw00 läuft auf einem anderen: Wunder der Wirrtualisierung Aber das zeigt umsomehr, daß auch über batman „fast GBit“ erreicht werden kann.)
Ja, das ist bei uns auch so. Mir wurde gestern noch ein 900 Mbit/s Speedtest einer VM hinter einem virtuellen Knoten bei Hetzner gezeigt. Alles kein Problem.
Das funktioniert aber nur etwa bis 300 Knoten auf einem Gateway, darüber nicht mehr.
Das funktioniert aber nur etwa bis 300 Knoten auf einem Gateway, darüber nicht mehr.
Naja, Jammern auf hohem Niveau, oder? Bei 300 Knoten auf einem über GBit angebundenen Gateway bleiben um und bei 3 MBit/sec pro Knoten. Wenn das nicht gut austariert ist, bleibt doch auch bei den Knoten die Performance auf der Strecke?
Das sage ich mal den Leuten, die in Foren über die die Vorteile von RAM-Parametern (CL…) diskutieren, die sich dann in RL-Benchmarks im unteren einstelligen %-Bereich was ändern.
Aber im Kern heisst es für mich: die Server mit 1G-Interface und 250MBit/s Anbindung sind technisch besser zu nutzen als die mit 1G-Interface und garantierten 500er (plus Burst), weil der Aufpreis nicht sinnvoll genutzt werden kann.
Der Gesamtdurchsatz ist sowieso auf Gigabit mal Anzahl der Nat-IPs gedrosselt. Es geht hier eigentlich mehr darum, auf wie viele VMs man das unterverteilen muss.
Ich hatte es so verstanden, also ob auch das Blech der Limit-Faktor wäre bei Euch in Münster.
Das wissen wir nicht abschließend. In einer Perf-Analyse am Mittwoch, schien es so, als ob die Syncs im Batman der Engpass sind. Aber wir hatten nur Batman 2016.4 auf dem Gateway. Wir wollen nochmal mit einer neueren Version testen.
Was wir wissen ist, dass die Netzwerkanbindung nicht der Engpass ist. Mit Layer-3-Paketen gehen locker 450-500 Mbit/s in beide Richtungen durch eth0. Das sind dann BGP-Tunnel die Gateways ohne direkte FFRL-Anbindung anbinden.
Also im Rahmen der Meßungenauigkeit, ja? Probier’s, wird nicht helfen
Du beziehst Dich auf dem @mpw seine Aussagen (dt. Genitiv-s und Discourse, zwei Welten )?
Also, wenn ich 1000 MBit/sec durch 20 MBit/sec teile, komme ich bei 50 raus. Demnach sollten nicht mehr als 50 Münsterländer Knoten sich einen GBit-Netzzugang teilen müssen (lies: Worstcase einen Host/Hypervisor). Das ist ein Sechstel der 300 Knoten/VM, bei denen scheinbar der Durchsatz auf „150-200 MBit/sec“ einbricht, wobei ja „300 MBit/sec Dauerlast“ auch wieder kein Problem sind?
Ich komme also ehrlich gesagt nicht mehr mit, auf welche Probleme ich mich bei der anstehenden Umstellung von fastd auf l2tp per tunneldigger einstellen muß.
»Durchsatz« im Threadtitel ist Durchsatz vom Client im Freifunk-Netz ins öffentliche v4-Internet?
… weil die Anzahl der v4-IPs des FFRL (wie bei jeder neuen LIR seit Anbruch des letzten /8) ziemlich endlich ist.
Aber wenn ich zu einem 100 MBit/sec-Anschluß nun noch 10 weitere zuschalte, auf denen auch 100 Mbit/sec abgerufen wurden, bin ich bei einem Bandbreitenbedarf von 1100 MBit/sec über das 1000 MBit/sec-Interface.
Lies: ist es tatsächlich die schiere Anzahl – sprich: mit 1 genutzen und 100 Dummy-L2TP-Tunneln ist’s schick, irgendwo zwischen 101 und 300 Dummy-Tunneln kackt der eine genutzte auch ab – oder eher eine Kombination von Tunnelanzahl und (NAT-) Traffic?
Ich hab’ ja schon Pferde kotzen sehen (lies: wc -l /proc/net/tcp ab ca. 10k Verbindungen zu Sekunden langen Freezes auch für andere Prozesse führen — so um 2001 herum), insofern halte ich lustige Effekte ab gewisser Grenzwerte für durchaus möglich. Und >200 Interfaces halte ich für eine nicht alltägliche Anwendung für den Linux-Kern; aber auch die „900 MBit/sec Speedtest“ können eigentlich nicht bei 100 weiteren Tunneln auf dem System zustandekommen, außer die 100 weiteren Tunnel machen eher so gar keinen Traffic?
Was mir aufgefallen ist: meine „iperf3“-Tests über’s Internet (Plusserver <> Hetzner), inkl. NAT (wir NATen lokal, FFRL ist Fallback), werden über die Dauer immer langsamer:
root@ping-ffgt:~# iperf3 -t 60 -i 10 -c tiffany.uu.org ; sleep 5 ; iperf3 -t 60 -i 10 -c tiffany.uu.org
Connecting to host tiffany.uu.org, port 5201
[ 4] local 10.255.8.118 port 40552 connected to 136.243.22.43 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-10.01 sec 596 MBytes 500 Mbits/sec 0 1.34 MBytes
[ 4] 10.01-20.00 sec 502 MBytes 421 Mbits/sec 6 375 KBytes
[ 4] 20.00-30.00 sec 260 MBytes 218 Mbits/sec 5 366 KBytes
[ 4] 30.00-40.00 sec 237 MBytes 199 Mbits/sec 6 284 KBytes
[ 4] 40.00-50.00 sec 238 MBytes 200 Mbits/sec 5 314 KBytes
[ 4] 50.00-60.00 sec 238 MBytes 200 Mbits/sec 5 341 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.00 sec 2.02 GBytes 290 Mbits/sec 27 sender
[ 4] 0.00-60.00 sec 2.02 GBytes 289 Mbits/sec receiver
iperf Done.
Connecting to host tiffany.uu.org, port 5201
[ 4] local 10.255.8.118 port 40556 connected to 136.243.22.43 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-10.00 sec 335 MBytes 281 Mbits/sec 8 280 KBytes
[ 4] 10.00-20.00 sec 237 MBytes 199 Mbits/sec 5 301 KBytes
[ 4] 20.00-30.00 sec 236 MBytes 198 Mbits/sec 5 327 KBytes
[ 4] 30.00-40.00 sec 238 MBytes 200 Mbits/sec 5 354 KBytes
[ 4] 50.00-60.00 sec 234 MBytes 196 Mbits/sec 5 296 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.00 sec 1.48 GBytes 212 Mbits/sec 34 sender
[ 4] 0.00-60.00 sec 1.48 GBytes 212 Mbits/sec receiver
Etwas gewartet.
root@ping-ffgt:~# iperf3 -t 60 -i 10 -c tiffany.uu.org ; sleep 5 ; iperf3 -t 60 -i 10 -c tiffany.uu.org
Connecting to host tiffany.uu.org, port 5201
[ 4] local 10.255.8.118 port 40560 connected to 136.243.22.43 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-10.03 sec 576 MBytes 482 Mbits/sec 2 803 KBytes
[ 4] 10.03-20.00 sec 587 MBytes 494 Mbits/sec 0 1.16 MBytes
[ 4] 20.00-30.00 sec 561 MBytes 471 Mbits/sec 4 730 KBytes
[ 4] 30.00-40.00 sec 282 MBytes 237 Mbits/sec 7 290 KBytes
[ 4] 40.00-50.00 sec 239 MBytes 201 Mbits/sec 5 320 KBytes
[ 4] 50.00-60.00 sec 240 MBytes 201 Mbits/sec 5 351 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.00 sec 2.43 GBytes 347 Mbits/sec 23 sender
[ 4] 0.00-60.00 sec 2.43 GBytes 347 Mbits/sec receiver
iperf Done.
Connecting to host tiffany.uu.org, port 5201
[ 4] local 10.255.8.118 port 40564 connected to 136.243.22.43 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-10.00 sec 356 MBytes 299 Mbits/sec 8 346 KBytes
[ 4] 10.00-20.00 sec 244 MBytes 204 Mbits/sec 6 266 KBytes
[ 4] 20.00-30.00 sec 236 MBytes 198 Mbits/sec 5 291 KBytes
[ 4] 30.00-40.00 sec 236 MBytes 198 Mbits/sec 5 315 KBytes
[ 4] 40.00-50.00 sec 238 MBytes 200 Mbits/sec 5 342 KBytes
[ 4] 50.00-60.00 sec 241 MBytes 202 Mbits/sec 6 266 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.00 sec 1.51 GBytes 217 Mbits/sec 35 sender
[ 4] 0.00-60.00 sec 1.51 GBytes 217 Mbits/sec receiver
iperf Done.
Im LAN hingegen fällt das nicht so dramatisch ab:
root@ping-ffgt:~# iperf3 -t 60 -i 10 -c 192.251.226.115 ; sleep 5 ; iperf3 -t 60 -i 10 -c 192.251.226.115
Connecting to host 192.251.226.115, port 5201
[ 4] local 10.255.8.118 port 41730 connected to 192.251.226.115 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-10.01 sec 684 MBytes 573 Mbits/sec 47 648 KBytes
[ 4] 10.01-20.00 sec 593 MBytes 498 Mbits/sec 27 197 KBytes
[ 4] 20.00-30.00 sec 600 MBytes 503 Mbits/sec 40 194 KBytes
[ 4] 30.00-40.00 sec 533 MBytes 447 Mbits/sec 36 140 KBytes
[ 4] 40.00-50.00 sec 611 MBytes 512 Mbits/sec 40 167 KBytes
[ 4] 50.00-60.00 sec 592 MBytes 496 Mbits/sec 39 187 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.00 sec 3.53 GBytes 505 Mbits/sec 229 sender
[ 4] 0.00-60.00 sec 3.53 GBytes 505 Mbits/sec receiver
iperf Done.
Connecting to host 192.251.226.115, port 5201
[ 4] local 10.255.8.118 port 41734 connected to 192.251.226.115 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-10.01 sec 612 MBytes 513 Mbits/sec 41 160 KBytes
[ 4] 10.01-20.00 sec 579 MBytes 486 Mbits/sec 38 180 KBytes
[ 4] 20.00-30.01 sec 612 MBytes 513 Mbits/sec 41 146 KBytes
[ 4] 30.01-40.00 sec 582 MBytes 488 Mbits/sec 38 182 KBytes
[ 4] 40.00-50.00 sec 547 MBytes 459 Mbits/sec 36 204 KBytes
[ 4] 50.00-60.03 sec 567 MBytes 475 Mbits/sec 38 181 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.03 sec 3.42 GBytes 489 Mbits/sec 232 sender
[ 4] 0.00-60.03 sec 3.42 GBytes 489 Mbits/sec receiver
iperf Done.
Jedenfalls: wenn noch NAT/externes Routing mit reinspielt, sehe ich nicht, wie man das Rätsel lösen will
@wusel, irgendwie fehlen deinen Rechnungen die Gaußkurven. Oder anders ausgedrückt: Du hast nicht verstanden, dass natürlich nicht alle Knoten gleichzeitig genutzt werden.
Probier mal bei Unitymedia in der ganzen Nachbarschaft 400 Mbit/s gleichzeitig abzurufen, natürlich geht das nicht.
Es geht um folgendes: Wenn 500 oder 600 Knoten an einem Gateway hängen, fast alle nichts tun, sollen einige wenige immer noch 20-30 Mbit/s schaffen.
Und das geht derzeit nicht, weil irgendwelche Kernelverwaltungsstacks oder der Tunneldigger oder das Batman oder was weiß ich, damit überfordert sind.
In der Telefontechnik wäre der gesuchte Begriff hier nicht „gauss“ sonder „erlang“.
Also nachdem der L2TP Tunnel aufgebaut ist, läuft sämtlicher Traffic nur über den Kernel Space.
Nur die keep-alive Pakete werden von Tunneldigger in diesem Fall verarbeitet.
D.h. es wird eigentlich nur durch die Implementierung von L2TP, Batman sowie der Hardware Performance ausgebremst.
Wenn es an Tunneldigger liegt dann würde sich das mit häufigen VPN disconnects bemerkbar machen.
500~ VPN Sessions sind schon eine ganze Menge, da kann es gut sein das der Hypervisor auch die Paketflut eindämmt um andere VMs nicht zu beeinträchtigen.
Ich würde das ganze mal auf Bare-Metal testen um genauere Werte zu bekommen
Was heisst denn das: Reicht es zwei Testkisten zu nehmen, einen belasteten Tunnel zwischen beiden zuschaffen und dann unbelastete Tunnel one by one dazu zu bauen und peu a peu zu sehen, dass der Overhead immer groesser wird, nur um den Traffic des einen Tunnels zu stemmen ?
Da muss man dann die richtigen Tools haben, um zu sehen, wo im Kernel die Zeit hingeht.
Irgendwie … ist das alles etwas fischig. Wenn ich von meiner Test-VM – die einen L2TP-Tunnel (handgeklöppelt, kein Tunneldigger) zu einer anderen VM hat, die wiederum im Batman-Netz (batman via L2TP) hängt und über eine 3. VM ins Netz geht – per iperf3 einen Durchsatztest mache, komme ich derzeit auch im LAN nicht über ~460 MBit/sec im Schnitt hinaus. (ping-ffgt <l2tp> gw00 <batman-via-l2tp> gw10 <NAT> LAN).
Und auch bei der Wiederholung des Tests von vor ein paar Tagen – da waren’s 640 MBit/sec – komme ich jetzt auf nur 460 bis 490 MBit/sec.
Was ich sehe ist, daß im Durchleitungsfall „ksoftirqd“ bei ca. 500 MBit/sec schon mal 25% CPU verbrät.
iperf3 von ping-ffgt direkt über ens9 zu gw00 bringt knapp 930 MBit/sec und auf gw00 taucht nur „iperf3“ mit ca. 25% CPU auf (ksoftirqd bleibt unter 1%) — das ist im Grunde nur Bridging, da werden noch keine Pakete groß umgepackt.
„iperf3 -t 60 -i 10“ von ping-ffgt zu gw00 über den L2TP-Tunnel (auf die br-ffgt-IP von gw00) bringt wieder nur knapp 460 MBit/sec, jetzt schlagen jeweils „iperf3“ und „ksoftirqd“ mit 25-30% CPU auf.
Ich würde in L2TP insofern schon ein signifikantes Nadelöhr verrorten; auch zu unserem BGP-Router am Community-IX kommen über den L2TP-Tunnel „nur“ 420 bis 470 MBit/sec zustande, „außenrum“ sind’s 700 bis 750 MBit/sec (beide Seiten sind VMs). (Mal davon ausgehend, daß IN-Berlin, unser Uplink dort, selbst „etwas“ Traffic nutzt, erscheinen die Werte plausibel.)
Zwar „kostet“ L2TP weniger CPU-Overhead als fastd, aber augenscheinlich doch zuviel, um ein GBit vollzumachen? Wobei ich ~50% jetzt doch als etwas zuviel „Verlust“ empfinde?
Ja, aber um wirklich objektiv auf einer Kiste testen zu können, müsstest du die weiteren Tunnel von anderen Maschinen aus aufbauen.
Wo steht die VM? Manche Hoster drosseln diese Tunnel. Zwischen Hetznerkisten intern bei denen im Netz habe ich schon 950 Mbit/s über L2TP inklusive Batman gesehen, da war aber nichts anderes auf den Kisten auch keine anderen Knoten.
Die Hosts (und damit die VMs) stehen lokal im RZ. Filter auf L2TP auf den Switches halte ich für hinreichend unwahrscheinlich. Was sich allerdings geändert hat: die zum Testen verwendeten Hosts haben seit dem 640-MBit/sec-Test weitere VMs, z. T. mit deutlicher (CPU-, Netzwerk-) Last, bekommen. Aber „eigentlich“ sollten sie weit von einem Lastproblem entfernt sein (Summe vCPUs je Host < 50% der vorhandenen Cores).
Das war HW-zu-HW oder schon mit Virtuallisierung dazwischen?
Auf beiden Seiten virtualisiert. Das Gateway war das, wo ich das GRE-Nat ausprobiert habe und das andere war ein virtuelles Gluon und dahinter ein virtuelles Debian, was im Freifunk hängt. War auch nicht nur ein lokaler Speedtest, sondern ein externer von speedtest.net.
Ich habe aber auch schon Erlebnisse gehabt, wo bei 5-600 Schluss war. Hängt vielleicht von der CPU ab oder so.