1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › CleverKabel 100 - Surfen mit bis zu…

100/2,5 Mbit/s? Nicht für TCP/IP!

  1. Thema

Neues Thema Ansicht wechseln


  1. 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: Youssarian 29.06.09 - 11:30


    Ein TCP/IP-Paket hat eine maximale Größe von 1500
    Byte und eine minimale Größe von 40 Byte. Der Emp-
    fänger eines solchen Pakets muss seinen Empfang
    bestätigen, also für jedes empfangene TCP/IP-Paket
    auch ein TCP/IP-Paket versenden.

    Unter optimalen Umständen erhält man ausschließlich
    Pakete mit 1500 Byte Umfang und versendet ausschließ-
    lich Pakete mit 40 Byte. Es ergibt sich ein Verhält-
    nis von 37,5:1. Kabel BW bietet 40:1, geht also
    selbst über das nur theoretisch Machbare hinaus.
    Und dabei ist noch nicht ein einziges Nutzbyte hoch-
    geladen! Denn wenn während eines performanten Down-
    load wagen sollte, parallel etwas hochladen zu wol-
    len, dann bleibt der Download faktisch stehen.

    Nein, Ihr Golemschen, das kann man nicht mit
    "Surfen mit bis zu 100 MBit/s" überschreiben,
    denn "Surfen" setzt immer noch TCP voraus.

  2. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: notan 29.06.09 - 11:39

    Zuerst das Protokoll verstehen, dann rumrechen.

    IP-Pakete können auch größer als 1500 Byte sein, am Ethernet werden die dann fragmentiert übertragen, außerdem muss man nicht jedes Paket einzeln bestätigen, das dürfen auch ein paar auf einmal sein.

    Wenn man netto nicht auf 100 MBit kommt, wird's nicht am TCP/IP-Protokoll liegen.

  3. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: ffo 29.06.09 - 12:02

    notan hat recht... :D du hast mir das schreiben erspart

    :-( dabei war ich schon fast fertig

  4. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: 9live-Moderator 29.06.09 - 12:38

    Zwar stimmt Deine Rechnung nicht, aber es heisst ja auch nur "BIS ZU" 100 Mbit.

    Dieses "BIS ZU" hat schon viele DSL-Kunden böse überrascht, da sie eine weit langsamere Leitung hatten, als vom Provider versprochen.

    Ich selber teste Leitungen gerne mit entsprechenden Websides, ob denn der IDEALFALL auch möglich ist. (www.wieistmeineip.de oder www.speedtest.net)
    Generell ist es jedoch fast egal, wie schnell die eigene Leitung ist, da viele Downloadserver (Treiber oder Updates von Programmen) ohnehin eine Upload-Begrenzung haben und selbst bei 100Mbit/sek nur lächerliche 300Kb/sek liefern.
    Da liegt der Flaschenhals oft auf der anderen Seite!

  5. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: /mecki78 29.06.09 - 12:40

    Youssarian schrieb:
    -------------------------------------------------------
    > Unter optimalen Umständen erhält man
    > ausschließlich
    > Pakete mit 1500 Byte Umfang und versendet
    > ausschließ-
    > lich Pakete mit 40 Byte. Es ergibt sich ein
    > Verhält-
    > nis von 37,5:1. Kabel BW bietet 40:1, geht also
    > selbst über das nur theoretisch Machbare hinaus.

    Das setzt voraus das jeglicher Traffic im Internet TCP/IP ist. Wenn ich z.B. einen Radiostream per UDP empfange, dann muss ich da gar nichts zurücksenden außer ganz selten mal ein Paket, dass ich noch da bin (weil sonst kann der Streaming Server aufhören mir Daten zu senden). Ich muss aber bei weiten nicht jedes einzelne UDP Paket bestätigen. Es gibt auch eine Menge Dienste die synchron arbeiten, d.h. einer sendet nur und einer empfängt nur und das in einer Tour ohne dass der Empfänger selber dauernd senden muss. Gerade eben bei "Broadcasting" (nicht Broadcasting Pakete, sondern eben Audio/Video Streaming - oder bei Messaging, also Video/Audio Chats). Theoretisch auch bei Spielen, wobei da sendet man natürlich auch in einer Tour und empfängt in einer Tour, beides aber UDP und somit total unabhängig voneinander.

    Klar ist das Verhältnis deutlich zu niedrig, auch da gebe ich dir absolut Recht! Aber man kann trotzdem was sinnvolles damit anfangen. Es ist nicht so dass man sagt es wäre vollkommen sinnlos, weil man die 100 MBit/s nie ausschöpfen kann. Das kann man schon, nur halt eben schwer mit den 0815 Surferprotokollen für Leute die denken Internet == WWW und nichts anderes.

    Davon ab ist es technisch falsch, dass ich jedes empfangen TCP Segment bestätigt werden muss! Wenn mir ein Sender 5 zusammenhängende Segmente schickt und ich alle 5 erhalten habe und ich das 5te bestätige (ein ACK auf 5 Datenpakete), dann gelten alle 5 als bestätigt.

    Siehe hierzu:
    http://de.wikipedia.org/wiki/Transmission_Control_Protocol

    "Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind. Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen. Fehlt zum Beispiel das TCP-Segment 3, weil es verlorengegangen ist, so kann er nur die 1 und die 2 bestätigen, 4 und 5 jedoch noch nicht. Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal. Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente."

    5 ist hier nur eine Beispielzahl. Im Prinzip darf der Sender mir so viele TCP Segmente schicken wie in meinen TCP Puffer passen (der wird beim Verbinden ausgehandelt) und ich kann alle Pakete in diesem Puffer mit nur einem einzigen ACK bestätigen.

    Jedes einzelne Segment muss ich nur dann bestätigen, wenn ich nie mehr als ein Segment auf einmal fehlerfrei in meinem Puffer habe. Aber wenn die Leitung so grottenschlecht ist, dass das so abläuft, dann ist sie eh nicht zu gebrauchen um damit effektiv surfen zu können.

    /Mecki

  6. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: /mecki78 29.06.09 - 12:41

    9live-Moderator schrieb:
    -------------------------------------------------------
    > Zwar stimmt Deine Rechnung nicht, aber es heisst
    > ja auch nur "BIS ZU" 100 Mbit.

    Das ist irrelevant. Was an seiner Rechnung nicht stimmt ist dass man nicht jedes einzelne TCP Paket bestätigen muss. Ein Rechner kann mir bei einer TCP Datengröße von 1460 Byte und einem lokalen TCP Puffer von 32 KB bis zu 22 TCP Pakete schicken, die ich *ALLE* mit einen einzigen Ack von 40 Byte Größe bestätigen kann.


    /Mecki

  7. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: /mecki78 29.06.09 - 12:52

    notan schrieb:
    -------------------------------------------------------
    > IP-Pakete können auch größer als 1500 Byte sein,
    > am Ethernet werden die dann fragmentiert
    > übertragen,

    IP Fragmentierung ist was sehr schlechtes. Es ist unperformant, es ist ungesichert, macht vielen Home Routern Probleme und auch wenn es bei IPv4 noch öfters vorkommt sagt IPv6 eigentlich dass man wann immer möglich drauf verzichten sollte (außerdem muss hier der lokale Rechner fragmentieren, Router dürfen nicht mehr und weil IPv6 keine Fragmentierung im Header vorsieht, muss noch ein extra Fragment Header eingefügt werden, was das ganze noch langsamer macht und der Protokoll Overhead weiter erhöht).

    In der Praxis wird TCP immer so lange die MTU einer Verbindung runterschrauben, bis nichts mehr fragmentiert wird. Das nennt sich MTU Path Discovery und ist eigentlich mittlerweile Standard. Also darauf würde ich echt nicht bauen.

    > außerdem muss man nicht jedes Paket
    > einzeln bestätigen, das dürfen auch ein paar auf
    > einmal sein.

    DAS ist der springende Punkt. Bei einer TCP Socket Größe von 32 KB (mittlerweile Standard, viele Systeme nutzen die TCP Extension um sogar noch viel größere Puffer anzulegen) kann ein System, das pro TCP Paket 1460 Byte Daten versendet, etwa 22 Pakete direkt hinter einander raushauen und wenn alle 22 durchkommen, dann reicht ein EINZIGES Ack um alle 22 auf einmal zu bestätigen. Mehr als eines wird nur gebraucht wenn Pakete verloren gehen oder korrupt ankommen. Und selbst wenn von den 22 eines verloren ging, dann reichen in der Regel 2 Acks. Das erste bestätigt alle Pakete /bis/ zum verloren gegangenen. Dann warte der Rechner bis das neu gesendet wird und wenn das nun korrekt war und alle anderen danach auch korrekt waren, dann kommt ein zweites Ack dass alle restlichen bestätigt. Und jedes dieser Acks ist trotzdem nur 40 Byte groß.

    TCP ist zwar ein schwieriges, recht kryptisches Protokoll und es wird einen nicht immer gleich klar warum es manchmal so komplex arbeitet, aber es ist ein recht geniales Protokoll und die Genialität zeigt sich eben darin, dass es selbst über Leitungen mit enormer Fehlerrate, niedriger MTU, hoher Latenz oder wie hier, sau schlechten Upload, trotzdem zur Höchstform auflaufen kann, weil es sich an alle diese Gegebenheiten automatisch anpassen kann. Die Macher haben da wirklich versucht an alles zu denken. Leider, weil es so komplex ist, ist es eben nicht immer optimal implementiert (viele TCP Stacks unterstützen nicht alle Features, oder nicht korrekt, können nicht alle Extensions und haben Sicherheitsprobleme). Aber dafür haben wir ja UDP, was gar keine Acks braucht und womit man theoretisch ja auch die 100 MBit/s ausschöpfen könnte (Video- oder Audiostreaming).

    /Mecki

  8. 9000

    Autor: mtu 29.06.09 - 13:16

    meine MTU is hier auf 9000 (jumob) eingestellt und nun ?

  9. wird nicht jedes paket einzeln bestaetigt

    Autor: wird nicht jedes paket einzeln bestae 29.06.09 - 13:31

    wird nicht jedes paket einzeln bestaetigt


    steht nirgendswo in der spec. haengt auch von drueberliegenden protos ab und deren robustheit.

    ausserdem gips noch udp, da wird garnix bestaetigt.


    erstmal basics lernen dann rumtrollen.

  10. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: Loki Wotan 29.06.09 - 13:44

    > ...
    > Aber dafür haben wir ja UDP, was gar keine Acks
    > braucht und womit man theoretisch ja auch die 100
    > MBit/s ausschöpfen könnte (Video- oder
    > Audiostreaming).

    Richtig. Man darf nicht Protokolle und Verbindungen vermischen. Wenn ich surfe, dann nutze ich HTTP als Anwendungsprotokoll, das zwar meistens auf TCP als Transportprotokoll aufsetzt, aber nicht notwendigerweise. UDP ist eine mögliche Alternative, die ohne Ack auskommt. Diese Protokolle basieren auf Internetprotokollen wie IP4 oder IP6, diese wiederum Netzprotokollen wie Ethernet oder PPP. Wenn ich maile verwende ich SMTP statt HTTP, bei Dateitransfer FTP, bei Zeitsynchronisation NTP, ...

    Es gibt auf jeder Ebene verschiedene Protokolle, die von Faktoren wie Anwendung oder auch Hardware abhängen. Man kann es sich nicht so einfach machen und sagen, dass eine Verbindung nicht ausgenutzt werden kann.

    Wer sich dafür interessiert, der kann eine gute Einführung in der Wikipedia finden, aber man sollte lieber die englische nehmen und nicht die deutsche. Die Artikel dort sind sehr unvollständig und vermitteln daher eher falsches Wissen.

    PS: IP Fragmentation kann mit IP4 nicht vermieden werden, da durch die Nutzung verschiedener Netze (Ethernet, verschiedene Drahtlosnetze, ...) verschiedene MTU vorhanden sein können. IP6 versucht das zu vermeiden indem es vorher die minimale MTU auf der gesamten Strecke ermittelt. Das gleiche kann Path MTU discovery machen. Es basiert aber auf ICMP, welches von vielen Firewalls geblockt wird.

  11. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: anonymous23543543534 29.06.09 - 14:39

    wie kontolliert man das verhalten
    oder ist das automatisch abhängig von der buffergröße?

    was sind da die entsprechenden befehle für linux?

    > > außerdem muss man nicht jedes Paket
    >
    > einzeln bestätigen, das dürfen auch ein paar
    > auf
    > einmal sein.
    >
    > DAS ist der springende Punkt. Bei einer TCP Socket
    > Größe von 32 KB (mittlerweile Standard, viele
    > Systeme nutzen die TCP Extension um sogar noch
    > viel größere Puffer anzulegen) kann ein System,
    > das pro TCP Paket 1460 Byte Daten versendet, etwa
    > 22 Pakete direkt hinter einander raushauen und
    > wenn alle 22 durchkommen, dann reicht ein EINZIGES
    > Ack um alle 22 auf einmal zu bestätigen. Mehr als
    > eines wird nur gebraucht wenn Pakete verloren
    > gehen oder korrupt ankommen. Und selbst wenn von
    > den 22 eines verloren ging, dann reichen in der
    > Regel 2 Acks. Das erste bestätigt alle Pakete
    > /bis/ zum verloren gegangenen. Dann warte der
    > Rechner bis das neu gesendet wird und wenn das nun
    > korrekt war und alle anderen danach auch korrekt
    > waren, dann kommt ein zweites Ack dass alle
    > restlichen bestätigt. Und jedes dieser Acks ist
    > trotzdem nur 40 Byte groß.

  12. Re: 9000

    Autor: /mecki78 29.06.09 - 15:33

    mtu schrieb:
    -------------------------------------------------------
    > meine MTU is hier auf 9000 (jumob) eingestellt und
    > nun ?

    Dann hast du Jumbo Frames im lokalen Netz, aber Jumbo Frames kommen nicht weit im Internet. Was hier passiert wenn du nicht TCP benutzt ist dass dein Internet Router (der, der dein lokales Netz an's Internet anbindet) diese Pakete aufspalten muss (fragmentieren). Er erzeugt dann so ca. 6 Pakete draus, sendet alle einzeln und die Gegenstelle muss sie wieder zusammen bauen. Das Problem ist aber das viele billige Home Router damit nicht zurecht kommen, dass es keinen Resend Algorithmus gibt (geht nur ein Paket verloren, werden alle empfangenen Fragmente weggeworfen!) und dass der IP Standard hart festlegt, dass alle Fragmente in einem Zeitraum von einer Sekunde ankommen müssen (was bei einer Satellit Verbindung mit Latenzen von über einer Sekunde alleine vom Nutzer bis zum Netz leicht zum Problem werden kann).

    Bei TCP hingegen wird meistens MTU Path Discovery benutzt. D.h. TCP sitzt im IP Paket das Flag "Don't fragment", dann darf dein Router es nicht fragmentieren. Der wird es dann wegwerfen und zurückmelden "Packet too big". Daraufhin wird TCP die MTU halbieren, auf 4500 und das Paket wieder senden. Gleiches Ergebnis. Dann wird es auf 2250 halbieren. Wieder gleiches Ergebnis. Dann auf 1125, das wird gehen. Alle zukünftigen Pakete an die gleiche IP werden dann nur 1125 groß sein, auch wenn du 9000 eingestellt hast.

    Bei UDP kann dein Internet Router auch Packet too Big antworten, dass muss dann aber die Software, die das Paket gesendet hat selber regeln. Die meisten UDP Programme werden daher von Haus aus nie Pakete erzeugen, die nicht in 1500 Byte passen (meist weniger, wer weiss was da an extra Protokollen drauf kommt, meist nur 1000 Byte oder so). Laut IPv4 Standard ist nur garantiert dass ein Paket bis 576 Byte immer gesendet werden kann ohne Fragmentierung.

    Von deinen Jumboframes wirst du nur im lokalen Netz was haben, nur da wird TCP die vollen 9000 ausnutzen und es wird auch kein Packet too big kommen. Alles was in das öffentliche Internet geht wird mit Sicherheit kleiner sein. Starte doch mal einen Netzweranalyser (z.B. Wireshark, ist kostenlos) und lass den mal alle HTTP Pakete abfangen, dann geh mal zu Google.com und schau mal wie groß die Pakete sind, die deinen Rechner verlassen.

    Die MTU ist keine harte Grenze und keine "muss Option". Die MTU sagt lediglich dem Protokoll darüber "Also größer als ... kann ich nicht versenden". Das zwingt aber kein Protokoll diese Größe auch nur im Ansatz zu benutzen. *Kleiner* darf ein Paket immer sein.

    /Mecki

  13. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: /mecki78 29.06.09 - 16:01

    anonymous23543543534 schrieb:
    -------------------------------------------------------
    > wie kontolliert man das verhalten
    > oder ist das automatisch abhängig von der
    > buffergröße?

    Das kann man einstellen auf deinen Rechner. Dein Rechner sendet dann die Puffergröße beim Start einer TCP Verbindung an die Gegenstelle, damit die weiß wie viele Daten sie schnell und auf einmal an dich senden kann bis dein Puffer voll ist. Danach sendet sie erst dann wieder Daten, wenn dein Rechner den Empfang der vorherigen Daten bestätigt hat.

    TCP kann in seiner ursprünglichen Form maximal Puffer bis 64 KB. Das war damals mehr als genug. Mit heutigen Hochgeschwindigkeitsnetzen und Monsterservern ist das nicht mehr so ganz ideal. Daher gibt es eine TCP Extension. Das ganze nennt sich Window Scaling:

    http://www.ietf.org/rfc/rfc1323.txt

    Damit lässt sich der Puffer bis auf 1 GB (!!!) erweitern. Was wohl für jede Anwendung mehr als genug ist :-D

    Allerdings funktioniert das ganze nur, wenn beide Seiten die Extension beherrschen, was nicht zwingend erforderlich ist (ist optional), aber viele Geräte können damit umgehen. Wenn du einen Puffer von 256 KB einstellst, dann wird dein Rechner versuchen diese Extension zu benutzen. Sollte die Gegenstelle das nicht können, dann wird dein Rechner eben einen kleineren Wert benutzen (z.B. eben nur 64 KB).

    > was sind da die entsprechenden befehle für linux?

    Kuckst du z.B. hier (per /proc Filesystem)
    http://www.oser.org/~hp/bsyII/node45.html
    oder hier (per sysctl - zum Punkt Linux scrollen):
    https://www.bsdwiki.de/Internetverbindung_beschleunigen

    Interessant ist vielleicht die Frage, warum es einen Min, einen Default und einen Max Wert gibt.

    Wenn eine Applikation einen neuen TCP Socket aufmacht, dann wird dort immer zuerst der Default Wert gesetzt. Jetzt ist es aber so, dass ein Programm die Puffergröße selber bestimmen kann, das ist programmatisch möglich (viele Programme machen das allerdings nicht). Sollte ein Programm das versuchen, dann wird der Aufruf einen Fehlern liefern wenn es weniger Puffer setzen will als der MIN Wert oder mehr Puffer als der MAX Wert (d.h. das Programm darf den Puffer größer und kleiner machen, aber nur solange es sich innerhalb der MIN/MAX Grenzen bewegt). Daher die drei Werte.

    /Mecki

  14. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: Youssarian 29.06.09 - 16:32

    /mecki78 schrieb:

    > Das setzt voraus das jeglicher Traffic im Internet
    > TCP/IP ist. Wenn ich z.B. einen Radiostream per
    > UDP empfange,

    Wenn ich ím Betreff schreibe, dass das nichts für
    TCP/IP sei, dann setzt dies nicht voraus, dass jeg-
    licher Traffic per TCP/IP transportiert wird, son-
    dern lediglich, dass ich von TCP/IP spreche und
    eben nicht von UDP.

    > Davon ab ist es technisch falsch, dass ich jedes
    > empfangen TCP Segment bestätigt werden muss!

    Das war der Kardinalfehler in meiner Rechnung,
    stimmt.

  15. Re: 100/2,5 Mbit/s? Nicht für TCP/IP!

    Autor: loepppel 29.06.09 - 22:01

    9live-Moderator schrieb:
    -------------------------------------------------------
    > Ich selber teste Leitungen gerne mit
    > entsprechenden Websides, ob denn der IDEALFALL
    > auch möglich ist. (www.wieistmeineip.de oder
    > www.speedtest.net)

    http://www.heise.de/netze/Online-Speedtests-im-Test--/artikel/139815

    Denen sollten man auch nicht "vertrauen" ;-)

    > Generell ist es jedoch fast egal, wie schnell die
    > eigene Leitung ist, da viele Downloadserver
    > (Treiber oder Updates von Programmen) ohnehin eine
    > Upload-Begrenzung haben und selbst bei 100Mbit/sek
    > nur lächerliche 300Kb/sek liefern.
    > Da liegt der Flaschenhals oft auf der anderen
    > Seite!


  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Limbach Gruppe SE, Heidelberg
  2. MITTELDEUTSCHER RUNDFUNK Anstalt des öffentlichen Rechts, Leipzig
  3. WERTGARANTIE Group, Hannover
  4. Information und Technik Nordrhein-Westfalen (IT.NRW), Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-58%) 24,99€
  2. (-78%) 7,99€
  3. 4,32€
  4. 29,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Star Wars Jedi Fallen Order im Test: Sternenkrieger mit Lichtschwertkrampf
Star Wars Jedi Fallen Order im Test
Sternenkrieger mit Lichtschwertkrampf

Sympathische Hauptfigur plus Star-Wars-Story - da sollte wenig schiefgehen! Nicht ganz: Jedi Fallen Order bietet zwar ein stimmungsvolles Abenteuer. Allerdings kämpfen Sternenkrieger auch mit fragwürdigen Designentscheidungen und verwirrend aufgebauten Umgebungen.
Von Peter Steinlechner

  1. Star Wars Jedi Fallen Order Mächtige und nicht so mächtige Besonderheiten

Google Stadia im Test: Stadia ist (noch) kein Spiele-PC- oder Konsolenkiller
Google Stadia im Test
Stadia ist (noch) kein Spiele-PC- oder Konsolenkiller

Tschüss, Downloads, Datenträger und Installationsroutinen: Mit Google Stadia können wir einfach losspielen. Beim Test hat das unter Echtweltbedingungen schon ziemlich gut geklappt - trotz der teils enormen Datenmengen und vielen fehlenden Funktionen.
Von Peter Steinlechner

  1. Google Stadia Assassin's Creed Odyssey bis Samurai Showdown zum Start
  2. Nest Wifi Googles Mesh-Router priorisiert Stadia
  3. Spielestreaming Google stiftet Verwirrung über Start von Stadia

Ryzen 9 3950X im Test: AMDs konkurrenzlose 16 Kerne
Ryzen 9 3950X im Test
AMDs konkurrenzlose 16 Kerne

Der Ryzen 9 3950X ist vorerst die Krönung für den Sockel AM4: Die CPU rechnet schneller als alle anderen Mittelklasse-Chips, selbst Intels deutlich teurere Modelle mit 18 Kernen überholt das AMD-Modell locker.
Ein Test von Marc Sauter

  1. Zen-CPUs AMD nennt konkrete Termine für Ryzen 3950X und Threadripper
  2. Castle Peak AMDs Threadripper v3 sollen am 19. November erscheinen
  3. OEM & China AMD bringt Ryzen 3900 und Ryzen 3500X