Erste Produktnamen der EPYC-CPUs mit 3D V-Cache tauchen auf

[HWL News Bot]

Der 3D V-Cache ist die nächste Innovationsstufe, die AMD zündet. Auf den L3-Cache der Chiplets kommen ein bis vier oder gar acht Lagen weiterer SRAMs und schon kann der Cache des Prozessors auf das Vielfache ausgebaut werden. Erstmals sprach AMD zur Computex Anfang Juni über entsprechende Pläne, nannte und zeigte in diesem Zusammenhang aber nur Ryzen-Prozessoren der 5000-Serie. Da gerade Spiele von einem Cache mit höherer Kapazität (bis zu einem gewissen Rahmen) profitieren (AMD spricht von 10 bis 15 %), dürften dies mit die ersten Prozessoren sein, bei denen der neuen 3D V-Cache zum Einsatz kommt.
... weiterlesen

 

[Richard88]

4gb on chip memory, noch ne aktuelle igpu und das teil läuft crysis.

 

[tonythebuilder]

Nur 4 GB, dass wird noch mehr.

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

 

[tackleberry]

Welchen Einfluss dürfte das auf die Performance in verschiedenen Anwendungen haben? Angenommen gleiche IPC und gleicher Takt? ETA?

 

[Don]

Welchen Einfluss dürfte das auf die Performance in verschiedenen Anwendungen haben? Angenommen gleiche IPC und gleicher Takt? ETA?

Genau das AMD ja für einen Ryzen 9 5900X gezeigt. Beide bei 4 GHz und die CPU mit dem 3D V-Cache war in Spielen im Schnitt um 15 % schneller.

Wann die nun kommen, tja das ist die große Frage.

 

[Case39]

Genau das AMD ja für einen Ryzen 9 5900X gezeigt. Beide bei 4 GHz und die CPU mit dem 3D V-Cache war in Spielen im Schnitt um 15 % schneller.

Wann die nun kommen, tja das ist die große Frage.

Kommen die noch für AM4?

 

[Don]

Kommen die noch für AM4?

Davon gehe ich aktuell aus, ja.

 

[Holt]

Welchen Einfluss dürfte das auf die Performance in verschiedenen Anwendungen haben? Angenommen gleiche IPC und gleicher Takt? ETA?

Doe Kerne dürften ja die gleichen sein, da der Takt der EPYC Kerne ja vor allem durch die Leistungsaufnahme begrenzt wird und das zusätzliche SRAM auch Strom braucht, wird der Takt im Zweifel also eher geringer als höher sein, wobei natürlich die Frage ist wie viel davon durch zwischenzeitliche Verbesserungen der Fertigung aufgefangen oder gar überkompensiert werden kann. Damit wird es sehr davon abhängen, welche Anwendung es ist bzw. wie stark diese von dem RAM Durchsatz abhängt. Schau Dir Reviews von den Desktop Broadwell an, die hatten mit dem eDRAM eine Art L4 Cache und zugleich eine bessere Architektur als die Haswell Vorgänger, aber weniger Takt als der 4790K und waren eben manchmal langsamer, aber manchmal auch deutlich schneller, sogar schneller als ihre Skylake Nachfolger. Bei Anwendungen wo diese Desktop Broadwell CPUs von ihrem eDRAM profitiert haben, werden wohl auch die EPYC und RYEN von dem großen L3 Cache profitieren, während Anwendungen / Benchmarks bei denen ihnen ihr eDRAM nicht geholfen hat, wohl auch noch vom zusätzlichen L3 Cache profitieren werden.

Dann ist da noch die Frage der Latenz, je größer ein Cache ist, umso aufwendiger und damit normalerweise auch langsamer wird dessen Verwaltung, es muss ja geschaut werden ob die Daten da drin sind und auch hier wird man schauen müssen, wie es da konkret aussieht, aber potentiell könnte auch dies dafür sorgen, dass bestimmte Anwendungen sogar langsamer laufen. Bei Caches kann man eben nicht pauschal sagen, dass viel auch viel hilft, dies kann sein, muss aber nicht.

Genau das AMD ja für einen Ryzen 9 5900X gezeigt. Beide bei 4 GHz und die CPU mit dem 3D V-Cache war in Spielen im Schnitt um 15 % schneller.

Spiele dürfte für EPYC aber eher weniger relevant sein.

Davon gehe ich aktuell aus, ja.

Vermutlich dürften sie recht zeitnah mit Alder Lake kommen. Ich würde vermuten, dass AMD sie kurz vorher bringt, wenn man davon ausgeht damit besser als Alder Lake abschneidet, zumindest in Spielen und eher kurz danach, wenn man befürchtet die Performancekrone an Alder Lake zu verlieren. Einfach um dann wieder im Gespräch zu sein und zu zeigen, dass man aufgeholt und den Rückstand verkleinert hat. Es wäre nämlich peinlich die neuen CPUs zu bringen, die vermutlich fast ein Jahr durchhalten müssen um kurz darauf von Alder Lake überholt zu werden und dies ist dann der Eindruck der bleibt bis die Nachfolger viele Monate später kommen.

Die Kapazität des HBMs könnte im Zweifel größer sein, als die des 3D V-Caches, dafür ist dieser als erweiterter L3-Cache deutlich schneller, hat geringere Latenzen und dürfte effizienter sein.

Das wird man abwarten müssen, es wird jedenfalls mal wieder richtig spannend, da beide Hersteller gezwungen sind sich richtig anzustrengen und erstmal keiner mehr in der Lage sein dürfte, sich auf seinem Vorsprung auszuruhen, da der andere schon mit der nächsten Generation wieder vorne sein könnte und dies ist für uns Kunden sehr gut.

 

[Holzmann]

Vermutlich dürften sie recht zeitnah mit Alder Lake kommen. Ich würde vermuten, dass AMD sie kurz vorher bringt, wenn man davon ausgeht damit besser als Alder Lake abschneidet, zumindest in Spielen und eher kurz danach, wenn man befürchtet die Performancekrone an Alder Lake zu verlieren. Einfach um dann wieder im Gespräch zu sein und zu zeigen, dass man aufgeholt und den Rückstand verkleinert hat. Es wäre nämlich peinlich die neuen CPUs zu bringen, die vermutlich fast ein Jahr durchhalten müssen um kurz darauf von Alder Lake überholt zu werden und dies ist dann der Eindruck der bleibt bis die Nachfolger viele Monate später kommen.

Denke auch das AMD ALD erst erscheinen lässt und je nach Performance dann entweder nur mit XT CPUs mit mehr Takt oder falls nötig eine TOP 5900x refresh CPU mit 3d Cache bringen wird.

 

[DragonTear]

Wär schon cool wenn diese Technik noch auf AM4 kommen würde. Wäre dann sogar ein Upgrade von Zen 2 wert. Aber glaube ich nicht so ganz.

 

[Don]

Spiele dürfte für EPYC aber eher weniger relevant sein.

Die Frage die gestellt wurde war, welches Leistungsplus der 3D V-Cache in Anwendungen bietet. Bisher hat AMD nur Zahlen zu Spielen gezeigt und diese haben ich genannt. Natürlich kann das für anderen Anwendungen (HPC, Datenbanken, etc.) auch noch anders aussehen. Das Spiele für EPYC interessant sind, hat ja keiner gesagt

 

[Holt]

Bisher hat AMD nur Zahlen zu Spielen gezeigt

Und deswegen dürfte die Antwort für DragonTear sein, dass es wohl anzunehmen ist, dass auch AM4 CPUs mit dem 3D Cache kommen werden.

 

[cypher_botox]

Ich behaupte, daß es im im ersten News-Beitrag hier im HWL schon hieß "5000er Ryzen mit V-Cache zum 21Q4 hin für Endanwender" (frei zitiert).
Wenn es nicht hier war, dann auf Golem.

 

[Kalorean]

Das Spiele für EPYC interessant sind, hat ja keiner gesagt

Das stimmt natürlich. Aber wann hat es Holt jemals interessiert, was jemand gesagt oder gefragt hat?

 

[Shevchen]

Oh ja, erst einmal neue Technologie schlecht reden, wenn sie nicht aus dem richtigen Lager kommt. Die ermüdende Diskussion spare ich mir hier einfach mal und gehe direkt auf die Technik ein:

Schneller Cache hat abhängig vom Code viele Vorteile. Wie immer gilt im Serverbereich: Hochspezialisierte Anwendungen (wie zum Bleistift Training neuronaler Netze) - was nicht so einfach auf den 0815-Gamer übertragbar ist. Ein Plus von 15% durch weniger Vorhersage-Fehler und dem Ausbleiben der langen Strecke über den RAM ist natürlich schon mal eine Ansage und entsprechend will man an diesem Aspekt auch weiter optimieren.

Der Cache als Stack hat Vor- und Nachteile:
Vorteile:
1) Das freie Stacking gibt Flexibilität
2) Auf Grund eines spezialisierten Cache-Fertigungsprozesses ist der Stack effizienter, als es zusammen mit CPU-Silizium zu verarbeiten. Dafür gibt es spezielle Lithografiemethoden, wie man Cache effizienter in Reinform belichtet, als die Mischform mit Logikeinheiten
3) Auf Grund der in (2) gesparten Fläche und Energie, ist der Prozess und das Ergebnis sehr effizient
4) Ist näher dran an der Logik als HBM - ergo geringere Latenzen (was man beim Cache unbedingt haben will)
Nachteile:
1) Rüstkosten - Um das ganze Ding zum Laufen zu bringen ist natürlich eine gewisse Vorlauf- und Entwicklungszeit notwendig. Die ist aber offensichtlich schon abgeschlossen
2) Je mehr Teile, desto höher die Gefahr eines Defektes. OC wird damit wohl kaum möglich sein, da die Kette nur so stark ist wie das schwächste Glied. Den Cache zu übertakten ist zwar möglich, aber synchron bedeutet auch, dass der schlechteste Chip den Takt angibt. Ist bei Servern wohl weniger ein Problem, aber benötigt trotzdem besseres Binning aller Komponenten
3) Hitzeempfindlichkeit: Da dürften die OC-Enthusiasten wohl eine neue Schicht Parameter zum spielen haben. Generell kann auch der Cache instabl werden, wenn man diesen zu weit tritt. Die Frage ist an der Stelle, wie weit man diesen treten kann, wenn die CPU auf Vollast läuft. Die oberste Schicht ist wohl am empfindlichsten und somit sind zu viele Stacks für Gamer wohl gar nicht soooo gut

Unterm Strich: Obs nun 12%, 15% oder 25% mit OC sind - nehme ich gerne mit. Sollte nicht eine letzte Revision von Zen 3 mit V-Chace für AM4 kommen? Das wird dann wohl für ein paar Jahre halten.

 

[easy1991]

Wär schon cool wenn diese Technik noch auf AM4 kommen würde. Wäre dann sogar ein Upgrade von Zen 2 wert. Aber glaube ich nicht so ganz.

Wird zu 100% auf am4 kommen , ist immer noch Zen 3 nur mit mehr Cache

 

[Kalorean]

Für die kommenden TRs ist damit aber wohl eher nicht zu rechnen, oder?

 

[Holzmann]

Für die kommenden TRs ist damit aber wohl eher nicht zu rechnen, oder?

So wie es aussieht nicht:

Threadripper 5000 mit 64 Zen-3-Kernen: Launch angeblich erst im November

Der für Leaks bekannt Youtuber „Moore’s Law is Dead“ hat in einem neuen Video Details zu den kommenden Threadripper-5000-Prozessoren zusammengefasst.

www.pcgameshardware.de

 

[Kalorean]

Mhm. Mal sehen, inwieweit sich das dann auf AM4 konkret noch auswirken wird.

 

[Mr.Mito]

Ich will endlich (Preis)infos zu den AM4 CPUs. Wenns einen sehr saftigen Aufschlag hat kann ich gleich einen 5900x nehmen und "muss" nicht mehr warten.

 

[fdsonne]

Oh ja, erst einmal neue Technologie schlecht reden, wenn sie nicht aus dem richtigen Lager kommt. Die ermüdende Diskussion spare ich mir hier einfach mal und gehe direkt auf die Technik ein:

Schneller Cache hat abhängig vom Code viele Vorteile. Wie immer gilt im Serverbereich: Hochspezialisierte Anwendungen (wie zum Bleistift Training neuronaler Netze) - was nicht so einfach auf den 0815-Gamer übertragbar ist. Ein Plus von 15% durch weniger Vorhersage-Fehler und dem Ausbleiben der langen Strecke über den RAM ist natürlich schon mal eine Ansage und entsprechend will man an diesem Aspekt auch weiter optimieren.

Wer redet denn irgendwas schlecht? Siehst du Gespenster?

Und natürlich bringt Cache Vorteile, das liegt in der Natur der Sache. Dennoch sollte man die Kirche bisschen im Dorf lassen. Gerade in AMDs MCM Konstrukt bringt der Cache verhältnismäßig viel, weil alles was bildlich "nach" dem Cache kommt, über ne arg limitierte und weite Strecke geschubst wird. Die IF ist im Verhältnis zu anderen Angeboten von Mitbewerbern vielleicht nicht langsam - aber gemessen an dem, was innerhalb so einem CCD abgeht, ist das ne ultra lahme Ente.
Auch halte ich es für absolut unsinnig die Caches aller CCDs zu addieren. Das ergibt technisch nämlich keinen Sinn, da der Prozessor so nicht arbeitet. Das ist also ne reine Marketingzahl da mit "GB" zu argumentieren. Jeglicher Zugriff auf Cache anderer CCDs MUSS über die lahme IF. Und wozu sollte man den Umweg gehen wollen? Das ergibt keinen Sinn, da der Traffic vom CCD über die IF zum IO Die geschickt wird - dort kann er auch in den RAM abbiegen. Die IF als Falschenhals in der Mitte limitiert so drastisch, dass ein IF Link zwischen einem CCD und dem IO Die nichtmal in der Lage ist, Read und Write die Bandbreite von zwei Memory Channel auszufahren. Bei Epyc existieren schon derer acht. Es ist also hinten wie vorn genug "Bumms" vorhanden, nur in der Mitte lahmt es sehr stark.

Logisch, dass man jetzt diese "Mitte" durch Maßnahmen immer mehr aus dem Fokus versucht zu nehmen. 3+x so viel Cache auf der CCD Seite bedeutet am Ende eben auch viel weniger Zugriffe über die lahme IF.

Was man klar dazu sagen muss - die Aussage "bringt so und so viel Prozent Performance" ist eigentlich falsch rum. Cache bringt NIE Performance. Cache hilft, theoretisch vorhandene Performance weniger stark einknicken zu lassen, wenn Flaschenhälse eben limitieren. Das mag erstmal nach Krümelkackerei ausschauen - ist aber ungemein wichtig für das Verständnis der Leistungsentfaltung. Denn zu viel Cache bringt am Ende auch keine Vorteile mehr, eben weil dann andere Faktoren anfangen zu deckeln. Je nach Workload. Bei Games bspw. hilft der Cache sehr stark die Zugriffe über die IF zu limitieren, denn Berechnungen der Frames müssen irgendwo auch Daten zwischenspeichern und auf gespeicherte Daten zugrifen. Aber aller Cache der Welt hilft nicht, wenn man bspw. das Konstrukt zwingt, über die IF sprechen zu müssen. Bspw. wenn man sagen wir nen 12C Dual CCD Prozessor nutzt und der Task zu breit ist um auf einem CCD laufen zu können, weil er bspw. acht Threads auf Last fährt. Hier sinkt dann der Anteil der Skalierung, da der Traffic eh über die IF muss. Bisschen kommt dennoch an, weil Speicherzugriffe ja dennoch abgepuffert werden und damit auch mehr Luft für den anderen Traffic in der IF existiert.


Intel wird mit Sapphire Rapids wahrscheinlich in ähnliche "Probleme" laufen. Aktuell ist nur bisschen unbekannt, wie viel Speed da in den Interconnects steckt. Augenscheinlich wird das mehr wie die IF Links bei Milan aktuell bieten können. Die Frage ist halt, wie viel mehr. Ggf. könnte es sogar gewollt sein Umwege über diese Verbindungen zu gehen - wenn die Links breit genug sind. IdR skaliert allerdings auch der Verbrauch an Energie mit der Geschwindigkeit solcher Interconnects. Ob AMD die IF drastisch in der aktuellen Form hätte verschnellern können, ist fraglich. Bei Rome und Milan kommt da 70-90W allein auf den "Rest" hinter den Cores. Man hat sich sogar dazu entschieden, "Writes" in den RAM, also Traffic vom CCD in den RAM zu kastrieren auf halben Speed - u.A. des Verbrauchs wegen. In wie weit man das aber feiern muss für einen Umstand, den man sich selbst auferlegt hat? Ja das wissen wohl nur die Fans

 

[Shevchen]

Denn zu viel Cache bringt am Ende auch keine Vorteile mehr,

IBM hat vor nicht allzu langer Zeit ein neues Cache Konzept vorgestellt, wo L2 gleichzeitig als L3 benutzt werden kann und der eigentlich Kern-Private Bereich für andere Kerne weiterverwendet werden kann. Mit einem kompletten Die als Cache über der CPU wir man wohl ein ähnliches Prinzip verwenden. So lange die erhöhte Latenz auf Grund der verlängerten Zugriffszeit in der Summe kleiner ist, als die statistisch durch RAM-Zugriffe notwendigen "langen Strecken" zu gehen haben wir einen Vorteil.

Zum Thema IF-Link: Ja, der IF-Link (ich denke, der basiert noch auf PCIe 4.0) hat Limitationen, welche aber auch auf Grund der Sockeleigenschaften begründet ist. Zu Zen 1 Zeiten hat niemand bei AMD damit gerechnet, den AM4 Sockel so weit zu treiben, wie er heute getrieben worden ist. Der vorteil ist, dass wir den AM4 Sockel so schön lange verwenden konnten - mit dem Nachteil, dass zwischendurch trotzdem ein neues Mainboard notwendig wurde, weil die BIOS-Chips zu klein dimensioniert waren. So ein X370 Board mit 32MB BIOS-Chip war dann doch eher eine absolute Ausnahme. (Obwohl man in gewissen OC-Foren modifizierte BIOS-Versionen bekommt, die dann einfach den Chip enthalten, den man gerade fährt - natürlich ohne Garantie)

Mit dem neuen Sockel sollte diese IF-Problematik deutlich reduziert werden. Es stellt sich natürlich noch die Frage nach der optimalen Signallaufzeit, das PGA und LGA durchaus unterschiedliche Widerstände haben (Hab mal gehört, PGA soll einen besseren SNR haben - ist aber auch schon 10 Jahre her) und wie weit man Sachen wie DDR5 und PCIe 5 noch treten kann. Innerhalb des Chips sollte man den IF aber noch um einige Faktoren aufbohren können.

Die Writes wurden btw nicht wegen dem Verbrauch skaliert, sondern weil der Link nicht voll duplex war. Man musste sich also entscheiden, welche Lanes hinten dran stehen lässt und das waren eben die Writes. Für Voll-Duplex hätte man 2 Lanes mehr gebraucht.

 

[Latiose]

Also das gillt nur für cache limitierende anwendung. Was ich schade finde ist das mehr cache mehr strom braucht. Entweder geht die cpu mit dem takt runter oder der stromverbrauch weiter hoch. Habe das Problem 2 sachen gleichzeitig umwandeln und dann noch was kopieren bzw verschieben, schwups geht die cpu auslastung stark nach unten. Hier bringt in dem fall kein caches der welt was bei der cpu. Oder wenn wenig ram bandbreite benötigt wird, dann bringt auch mehr caches wenig. Da würde dann das ganze durch nen niedrigern cpu takt alles aufgefressen. Die rzyen 9 cpus haben weniger l1 und l2 caches als die core i9 7xxx,9xxx 18 kerner. Stört der Anwendung nicht. Also ist diese szenario total unbandbreiten mäsig. Ich hoffe das mehr an cache stört den zen 4 cpus nicht. Warum weil ich ja auf den cpu takt angewiesen bin und nicht auf die bandbreite. Bin gespannt welche auswirkung es in meinem fall so wäre bze eintritt

 

[Yasha]

Habe das Problem 2 sachen gleichzeitig umwandeln und dann noch was kopieren bzw verschieben, schwups geht die cpu auslastung stark nach unten.

Mal aus Neugier, welche CPU nutzt du dafür? Sofern du mit Umwandeln nur Videos umwandeln meinst, habe ich nämlich das gleiche hier oft am Laufen. Mir ist aber dabei noch nie aufgefallen, dass die CPU sich dann heruntertaktet. Deswegen habe ich es gerade mal aus Neugier nachgestellt und geschaut, was der CPU-Takt macht.

Zweimal Handbrake und zwei verschiedene Filme. Beide haben h.264 sollen auf h.265 beide auf der gleichen alten Sata SSD. Also Handbrake zweimal gestartet und dann versucht eine 7GB Film Datei von der Sata SSD auf die M2 Evo zu schieben. Der CPU-Takt blieb unbeeindruckt bei 4050Mhz. Der Datentransfer lief mit etwas über 400MB. Ich nehme an, dass wäre dann so nachgestellt, wie du es gemeint hast, oder?

Normal habe ich es bei mir öfters so laufen, dass zweimal Handbrake läuft und dann noch zig andere Sachen auf die SSD geschrieben und gelesen werden. Bei mir kackt die SSD dann regelmäßig ab und Daten werden nur noch mit 2 bis 3 MB von A nach B kopiert. Aber der CPU ist das immer egal.

 

[Latiose]

Ok das ist wirklich merkwürdig das es nur bei mir ist.Ich habe nen Ryzen 9 5950x mit CPU Boost weil ja im Bios alles auf Default ist wo es dann auf hinauf mit 4,1 ghz geht.

DIe ganzen Aufnahmen liegen auf dem Netzlaufwerk.Sind also mit dem höchsten (fast was geht) ausgestattet und ist ein 1 gbit Leitung.
Nun ich gehe her und lasse die dann direkt dort und wandle damit um.Mein Tool heißt Xmedia Recode. Zwei gleichzeitig ist kein Problem.Landet alls auf die NVME SSD.Das habe ich dann wieder ins Netzlaufwerk kopiert. Dabei brach dann die CPU Auslastung auf 25 % herunter.Sobald verschieben zu ende war ging die CPU Auslastung wieder richtung 100 % hoch.
Ich dachte es wäre die SSD schuld gewesen,was es ja eben nicht ist.
Beim Ram weis ich ja das ich da Probleme habe.Sobald ich da 2933 oder das was die Rams können 3600 mhz hoch gehe,dann sinkt der CPU Takt auf 3,9 bzw 3,8 ghz herunter. Darum bleibt am ende also weniger Leistung übrig.Der Stromverbrauch steigt von 128 Watt auf 132 Watt.Die Leistung bleibt jedoch auf der Strecke.
Ich habe nen Gskill Ram also einen teuren ,hochwertigen. Könnte aber die Timings verbessern. Dies hatte ich jedoch schon mal probiert und es hat sich nix an der Leistung getan. Ich dachte Timings seien beim Ram wichtig. Es scheint aber der Software egal zu sein.
Ich wandle alles in H264 um.Also Mpeg 2 Ts ist Eingangs Format mit 50 Halbbilder. Alles in 720x576 und die von mir spezielle Settings.Diese sind nicht besonders hoch.
Ich habe die beste Bildqulität mit beste Geschwindigkeit gewollt.Darum mache ich sowas wie MP3 als ton. Sobald ich aber die Tonspur kopiere oder in MP2 so wie es beim Fernsehen ausgestrahlt wird ausgewählt hatte ,kam beim Windows Media Player kein Ton mehr aber Bild dafür.
Mp2 oder kopieren würde das Umwandeln sehr viel mehr beschleunigen. Denn wenn sie schon so schlecht ist,dann spielt dies ja keine Rolle mehr weil da hilft auch kein AAC Ton spur mehr was wenn man es als Mpeg 2 Ton Spur vorliegen hat.

Aber das mit den nur 25 % CPU Auslastung wegen des kopierens finde ich wirklich blöd.So kann man ja kein Platz mehr schaffen.Habe ja nur ne 512 Gb SSD.

 

[Yasha]

Keine Ahnung wie Xmedia Recode genau arbeitet. Aber hast du schon mal geguckt, ob das Netzlaufwerk nicht eher das Problem ist? Wenn er zweimal konstant die Daten einliest und du dann auch wieder über das Netzwerk draufschreiben willst. Könnte es sein, dass die Daten zum Codieren einfach nicht mehr schnell genug nachkommen und die CPU-Auslastung deswegen herunter geht. Wenn keine Daten mehr reinkommen, kann er nichts mehr umwandeln

Nur so als Idee.

 

[Latiose]

ja stimmt das ist was dran. In dem Fall würde ja mehr Cache de CPU auch nix mehr helfen.Gut dann ist nur noch ein Problem ,nämlich das mit dem Arbeitsspeicher.Das ist ja unabhängig von dem Netzlaufwerk.Weil das immer so ist sobald der mal steigen tut also der Ramtakt so.