Test Anti-Spectre-Microcode: SSD-Benchmarks zu Verlusten mit Skylake unter Windows 10

@Begu
Sehr viele Server werden gegen Spitzenlasten ausgelegt (1-10% der Betriebszeit) und selbst da strebt man oftmals eher so maximal 50% Systemauslastung an. Im Mittel haben die Kisten also sehr viel "Leistung über". Typischerweise versucht man auch Auslastungszustände über 80% zu vermeiden, da daraus hohe und vor allem inkonsistente Latenzen ergeben. Schlicht weil sich zunehmend Ressourcenzugriffe gegenseitig blockieren.

Andersherum: Server die im Mittel bei 10% Systemauslastung oder weniger herumdümpeln sind recht häufig. Was der Ansatz von diesem Amazon AWS und Microsoft Azure Cloudzeug ist.
 
Wäre jemand so nett und könnte mir beschreiben (oder verlinken), wie ich erkenne, welche Spectre Maßnahmen bei mir bereits installiert sind und wie ich sie wieder entfernen kann?
Ich habe keine Lust, mir ungefragt einen Teil der Leistung rauben zu lassen nur aufgrund einer sehr speziellen Sicherheitslücke.
 
MrFlip0815 schrieb:
"In der Praxis total irrelevant", "nur in Benchmarks messbar" ... Das sind aber eben genau diese Messwerte, die zum Kauf einer bestimmten CPU führen - während eine andere eben nicht gekauft wird. Man sollte nicht mit zweierlei Maß messen.

Exakt. Sonst wird hier auch alles gefeiert, nur weil eine CPU X 5% schneller ist als ihre Vorgänger-Serie. Und nun machen diese Werte, nun als Einbußen, plötzlich ja kaum mehr was aus..Da kann ich mir auch gleich 2 CPU Generationen sparen und abwarten, nur weil dieser Patch so viel frisst.

Habe den Januar Patch bei mir deinstalliert und geblockt. Bevor jemand diese nun weltweit bekannte Sicherheitslücke bei 0815 Nutzern wie uns ausnutzt, hat man wohl eher einen Stealthed Trojaner auf dem Rechner, den kein AV erkennt..
 
Hallo32 schrieb:
Thema Praxistest:

Falls ihr interessante Vorschläge und Beispiele habt, schaue ich mir mögliche Praxistests gerne genauer an.

Habt ihr für After Effects ein Beispiel Projekt, welches für Tests verwendet werden könnte?


ja, aus dem professionellen fotografenalltag:

setup für die frequenztrennung, hochwertigste nachbearbeitungstechnik. fertige aktion für photoshop inkl. nikon d800 raw datei zum bearbeiten. filtereinstellungen sind etwas übertrieben, damit die dicken cpus auch was zu tun haben.

die filter:

median
surface blur
tilt/shift blur (um die aktion etwas zu strecken und noch in ansätzen liquify zu simulieren, das lässt sich nämlich nicht gut in eine aktion packen, achtung teilweise gpu beschleunigt (wie liquify))

https://www.dropbox.com/sh/2jb11sdb49sieoj/AACm-I9JPGhX6cPuxe7VX9Jsa?dl=0

zum vergleich:

meine zwei systeme:

windows 7, photoshop CS6, bereitgestellte d800 raw in aRGB

system 1

i5 2500k @ 4,4 ghz
2x8gb DDR3 1866
crucial mx100 512 gb
r9 270x

5 minuten 10 sekunden

system 2

ryzen 1700x @ 3,9 ghz
2x8gb DDR4 3200 cl14
ocz rd400 512gb
r9 fury

0 minuten 17 sekunden

das bisschen raw export, bild verkleinern und nachschärfen isn photoshop benchmark aus dem kindergarten, der schön im singlecore/software flaschenhals steckt.
 
Zuletzt bearbeitet:
@duskstalker:

0minuten 17 sekunden vs 5min 10s ? Eines von beiden ist ein Tippfehler oder ?
 
Dann ist aber surface blur multithreaded oder ? Das ist der einzige bereich wo ein 1700X deutlich besser abschneiden müsste als ein Sandy...oder ist das wirklich so dramatisch wegen Meltdown/Spectre hier ?
 
MrFlip0815 schrieb:
"In der Praxis total irrelevant", "nur in Benchmarks messbar" ... Das sind aber eben genau diese Messwerte, die zum Kauf einer bestimmten CPU führen - während eine andere eben nicht gekauft wird. Man sollte nicht mit zweierlei Maß messen.

So sind sie halt die Intel-User.

Ein AMD-Ryzen wird nieder gemacht weil 10% langsamer in Benchmarks, aber das man bei Intel jetzt bis zu 40% einbußen hat ist dann plötzlich total irrelevant.
 
mkdr schrieb:
Und wieder ein wertloser Test, da er nur auf High-End durchgeführt wurde. Auf meinem Tablet beträgt der Verlust 60%. Daher werde ich die MC Updates auch blockieren.

Ist das dein Ernst? Das ist ja Wahnsinn :eek:
 
@Duskstalker:
Danke für die infos. Dann kommt der Hauptzeitvorsprung aus dem guten Multithread des Surface Blurs - Sandy hat ja nur 4T Ryzen hat 16T - während die anderen Komponenten hauptsächlich über Single Core gehen (wo eine 4.4GHz Sandy schätz ich mal nicht so viel langsamer sein dürfte als ein 3.9 GHz Ryzen).
Noch dazu mit all der Intel Optimierung in Adobe CS.

Aber gute Idee das mal anhand von sowas zu testen.

Noch besser wäre es die Zeit in "Erledigte Projekte/stunde" oder sowas umzurechnen. Dann hat man auch wieder die übliche "Mehr ist besser" Skala.


Das gibt dann 11.61/h für Sandy und 212/h für Ryzen (oder in %, Sandy = 100%, Ryzen = 1826 %). Hätte da eigentlich maximal einen Faktor 4 erwartet wegen (4vs16T).
Aber krass wie gut hier SMT im Gesamteffekt reinschlägt, weil es ja oft heisst die SingleCore Leistung sei in Adobe oft der limitierende Faktor. Ist also eher eine frage des Workloads ob das zutrifft.
 
Iscaran schrieb:
@Duskstalker:
Danke für die infos. Dann kommt der Hauptzeitvorsprung aus dem guten Multithread des Surface Blurs - Sandy hat ja nur 4T Ryzen hat 16T -

Vermutlich eher aus der OpenCL-Beschleunigung durch die GPU.
 
Wie sind denn die Werte an AMD CPU /APU / Chipsätzen im Vergleich? So mögen es 40% Einbruch random sein, aber wie schnell oder langsam is das nun gemessen an dem was man sonst kaufen kann?

So steht das etwas leer im Raum.
 
Begu schrieb:
Die zwei Sätze wollen einfach nicht in mein Hirn.
Man kauft sich als Serverbetreiber soviel Leistung wie man braucht + x% Reserve für die Zukunft. So etwas wie "Leistung übrig haben" gibt es meiner Ansicht nach nicht..

Man kauft im SMB Bereich einfach einen Server nach Pi mal Daumen Prinzip und in den seltensten Fällen nach festgelegten Leistungswerten. In größeren Unternehmen wird man hingegen kaum Terminalserver und Datenbankserver auf den gleichen Host packen.

In diesem Thema geht es aber um SSD Leistungsverluste! Auch heute noch befinden sich in den wenigsten Servern SSDs und da WO sie sich befinden wären selbst 20% von 500k IOPS lächerlich.

Nur mal so als Beispiel. Die größte VM die sich bei uns im Monitoring befindet ist ein Exchange Server mit knapp 500 aktiven Benutzern. Im Schnitt werden knapp 1000 IOPS angefordert, der größte Wert der jemals in den letzten 90 Tagen erfasst worden ist waren knapp 80k IOPS.

exchange.PNG

Das ist schon weit jenseits von SMB und trotzdem noch immer lächerlich im Vergleich zu dem was moderne SSDs leisten, egal ob mit oder ohne Verluste durch Spectre Updates.
 
Zuletzt bearbeitet:
Krautmaster schrieb:
Wie sind denn die Werte an AMD CPU /APU / Chipsätzen im Vergleich? So mögen es 40% Einbruch random sein, aber wie schnell oder langsam is das nun gemessen an dem was man sonst kaufen kann?

So steht das etwas leer im Raum.

AMD hat mit dem Spectre Patch einen Leistungsverlust von rund 0,5-1% auch bezüglich Lese und Schreibrate laut CB.

Den Spectre 2 Test wollte CB nachschieben, sobald der Patch verfügbar ist.

Edit: Aber um ganz korrekt zu bleiben, sollte selbst mit dem Spectre 2 Patch die Leistung nicht großartig fallen.
Bei Intel kommt schließlich der Leistungsverlust alleine durch Meltdown und dem Spectre 1 Patch Zustande. Der Spectre 2 Patch ändert von der Leistung her nicht mehr viel.
 
Zuletzt bearbeitet:
Da bin ich ja beruhigt, für mein nächstes System.

In der Praxis ergeben sich keinerlei spürbare Unterschiede, für die 860evo 4TB.
Für Zocker wie mich also kein Problem. :-)
 
Iscaran schrieb:
Das gibt dann 11.61/h für Sandy und 212/h für Ryzen (oder in %, Sandy = 100%, Ryzen = 1826 %). Hätte da eigentlich maximal einen Faktor 4 erwartet wegen (4vs16T).

die sandy schneidet hier überpropertional schlecht ab - aber solche extremen auswüchse hatte ich bspw auch bei einem gigapixel panorama - da ging die berechnung ne dreiviertelstunde.
ich hab das gerade mal mit einer dualsocket intel xeon 5520 workstation + nvidia quadro gpu gegengetestet (16 threads, 2.3 ghz) und hier liegen wir bei grob 50 sekunden.

das sandy system verhält sich ansonsten normal, aber die berechnungsdauer dieser aktion ist konstant und wiederholbar schnarchlangsam.

Iscaran schrieb:
Aber krass wie gut hier SMT im Gesamteffekt reinschlägt, weil es ja oft heisst die SingleCore Leistung sei in Adobe oft der limitierende Faktor. Ist also eher eine frage des Workloads ob das zutrifft.

wie gesagt, das sandy ergebnis fällt aus dem rahmen, die sollte eigentlich nicht sooo langsam sein. aber photoshop ist auf beiden rechnern identisch eingerichtet und sandy ist auf allen kernen bei 4,4 ghz zu 100% ausgelastet, kein throttling, kein ram limit. ich weiß nicht wieso das so ist, aber es ist auf meinem einen sandy system reproduzierbar.

was aber definitiv der fall ist: die workload in photoshop entscheidet darüber, welche hardware wie gut abschneidet. intel single core ist nicht das allheilmittel - das sieht nur in jedem benchmark so aus, weil da nichts anderes gemacht wird als raw dateien zu wandeln oder schärfefilter drüberzubügeln, was halt alles singlethread berechnungen sind. ob jetzt 20 oder 24 bilder in einer minute exportiert werden macht für den workflow keinen unterschied - was einen unterschied ausmacht, ist, ob man bei rechenintensiven filtern/aktionen flüssig weiterarbeiten kann oder nicht - und das ist eben nicht der fall bei einer berechnugsdauer von über 20 sekunden - weil dann kann man bei jedem bild erstmal aufstehen und sich nen kaffee holen.

zudem sind ryzen cpus in photoshop in singlethread berechnungen nicht so viel langsamer, wie bspw. 4t vs 16t in multithread abstinken. im schnitt aller aktionen isses unterm strich für photoshop "wurst" ob ryzen oder intel (hauptsache kerne + takt), nur bietet ryzen für andere prof. anwendungen einfach mehr leistung fürs geld als son popeliger 4c/4t.

wenn dann nämlich mal anständig optimierte software ins spiel kommt, wie bspw. capture one, dreht sich das bild komplett. da sind die leistungswerte von lightroom oder photoshop acr n witz dagegen, trotz 5,2 ghz 7700k.
 
xexex schrieb:
In diesem Thema geht es aber um SSD Leistungsverluste! Auch heute noch befinden sich in den wenigsten Servern SSDs und da WO sie sich befinden wären selbst 20% von 500k IOPS lächerlich.

Wieso beziehst Du dich nur auf IOPS? Und was sollen deine allgemein gültigen Aussagen? Das hilft dem Einzelfall auch nicht weiter. Und wie du schön selbst festgestellt hast, "Auf der anderen Seite sind IT Umgebungen zu komplex um sie hier mal eben von einem CB Redakteur auch nur ansatzweise abzudecken"

Um es kurz zu machen, unser Storage Server für Messdaten kotzt regelmäßig im strahl, trotz lwl und NVMe. Die updates nicht zu installieren ist...nein. Die Updates verbessern die Situation aber auch eher nicht.
 
Zuletzt bearbeitet:
Zurück
Oben