News HWBOT annulliert Benchmark-Rekorde mit Windows 8

Böse Zungen könnten nun behaupten das ggf. auch Intel damit etwas zu tun hat?! ;-) Aber soweit würde ja niemand gehen...
 
xuserx schrieb:
Probleme die eigentlich keine Probleme sind aber dazu aufgebauscht werden.

Sowas Grundlegendes wie die Zeitmessung zu vergeigen ist halt irgendwie peinlich.
 
Die Zeitmessung wurde ja auch nicht vergeigt. Windows 8 nutzt statt der "veralteten" Technologie RTC eben HPET. Dafür, dass irgendwelche Benchmarks noch RTC verwenden kann MS nichts.
 
Ich denke, die Schuld auf Software zu schieben ist falsch. Letztendlich muß sich die Software auf die Hardware verlassen. Wenn sich die Software also auf Software-Timer verläßt, ist das eben abhängig vom Takt.

Wenn die Software sich auf Hardware-Timer verläßt, gibt es immer noch das Problem, das Ende des Timerzyklusses bei hoch ausgelasteten Systemen zu erkennen, da Interrupts verzögert sein können.

Da müßte man schon spezielle Hardware haben, um genaue Zeitmessung zu ermöglichen und ein PC ist eben nur bedingt echtzeitfähig.
 
MusicJunkie666 schrieb:
Die Zeitmessung wurde ja auch nicht vergeigt. Windows 8 nutzt statt der "veralteten" Technologie RTC eben HPET. Dafür, dass irgendwelche Benchmarks noch RTC verwenden kann MS nichts.

Natürlich wurde die Zeitmessung vergeigt. Die gleichen Programme nutzen unter Windows 7 genauso RTC und dort tritt das Problem nicht auf.
 
Aber wenn das Problem bei AMD nicht auftritt, kann ja nicht nur die Software Schuld sein... Egal ob Bench oder OS...
 
Das ist ein INTERNER deal zwischen MS und Intel, um Win8 Verkäufe zu pushen :king::evillol::evillol:
wundern würde mich in unserer zeit sowieso gar nichts mehr, was in die richtung abzielt.

mfg
 
Zuletzt bearbeitet:
Computerbase schrieb:
Der Fehler konnte angeblich mit Intel-Prozessoren zurück bis zur Sockel-775-Plattform reproduziert werden
Ist zwar unwichtig aber man hätte es auch nicht weiter reproduzieren können als be dem Sockel 775 da es nach meinen Wissens keine Sockel 478 CPU gibt womit die Finale Windows 8 Version läuft, da NX-Bit benötigt wird.
 
CD schrieb:
Sowas Grundlegendes wie die Zeitmessung zu vergeigen ist halt irgendwie peinlich.
Naja, daran ist aber weder der CPU Hersteller noch MS schuld sondern der User der absichtlich seine Hardware außerhalb der Spezifikation betreibt.
Also Wayne?

(Selbst wenn man eine -K CPU kauft und nach den Vorgaben von Intel über das ZX8 UEFI den Multi hochsetzt, tritt der Fall nicht ein. Hier ist schon von einem ganz besonderen Fall die Rede, die ein User wissentlich durchführt und dabei auch bei -K oder -BE CPUs außerhalb der Spezifikation gerät)
 
Zuletzt bearbeitet:
kurz gesagt, und somit sind hwbot vergleiche völlig wertlos, weils immer einen weg geben wird, zu betrügen
 
tarrabas schrieb:
[
herrlich, da ja win8 so sicher sein soll. wo sind basti und o_o nun und verteidigen bis aufs blut ihr bestges os der welt? *sfg

Nur falls du den Artikel nicht gelesen hast: in dem Artikel geht es um das TPM- Modul. Win8 ist dabei Nebensache.
 
aber kann es dann nicht zu fehlern kommen wenn man win 8 in verbindungen mit servern betreibt und win8 zeitlich hinterherhinkt?
 
Wenn du deine Server-CPU übertaktest, möglich.
Xeons werden i.d.R. aber nicht übertaktet und mit AMD- CPUs scheint das Problem soweit ich weiß nicht aufzutreten.

Im normalen Betrieb merkt man von diesem "Fehler" niemals etwas. Im Gegenteil, die Zeitmessung wurde sogar verbessert.
 
promashup schrieb:
Ist das nicht selbsterklärend? Eine Lücke, in diesem Fall die Tatsache, dass das Verändern der BLCKs die Windowszeit verändert, wodurch Benchmarks verändert und somit quasi durch Betrug Benchmarks verbessert werden können.
Ach so. Jede technische Eigenschaft eines Betriebssystem mit dem sich ein Betrug durchführen lässt ist nun eine Betrugslücke? Hab ich wieder was dazu gelernt. :freak:

Das sich die Zeit beschleunigt und verlangsamt ist übrigens völlig normal und hat auch seinen Sinn.
http://www.mathpirate.net/log/2010/03/14/temporal-mechanics-changing-the-speed-of-time/
http://www.mathpirate.net/log/2010/03/20/temporal-mechanics-changing-the-speed-of-time-part-ii/

Zeitmessung ist halt nicht so trivial und dass das auch mal sensibel auf Spielereien am BCLK reagieren kann ist durchaus nachvollziehbar. Das ist ja auch kein normaler Zustand in dem ein PC Arbeitet. Ertstartet mit einem BCLK und mit dem wird er dann auch betrieben. Der sollte sich während des Betriebs eigentlich nicht mehr ändern.
Wer seinen PC außerhalb dieser Spezifikationen betriebt darf halt nicht mehr mit einem einwandfreien laufenden Betriebssystem rechnen. MS kann ja nicht jeden Sonderfall durchtesten, den sich irgend ein Übertakter vielleicht mal einfallen lässt.
 
Zuletzt bearbeitet:
noxon schrieb:
Ach so. Jede technische Eigenschaft eines Betriebssystem mit dem sich ein Betrug durchführen lässt ist nun eine Betrugslücke? Hab ich wieder was dazu gelernt. :freak:
Die Anführungszeichen sollten den Neologismus kennzeichnen. K.A. ob es das Wort so überhaupt gibt. Dennoch erfüllt es imho seinen Zweck.
 
Artikel-Update: Der Übertakter Christian Ney hat mit Hilfe eines Entwicklers des Tools CPU-Z eine Lösung für das Problem unter Windows 8 gefunden. Der Parameter „useplatformclock“ muss im Boot Configuration Data Editor (bcdedit) auf „yes“ gestellt und damit aktiviert werden. Diese Funktion ist laut Neys Untersuchungen bei AMD-Systemen standardmäßig aktiv, bei Intel-Systemen fehlt der Parameter hingegen gänzlich und wird somit als inaktiv („no“) behandelt. Durch das Hinzufügen und Aktivieren des Parameters wird das Problem behoben.

Da sich die Echtzeituhr unter Windows 8 vergleichsweise leicht manipulieren lässt, sieht HWBOT weiterhin davon ab, neue Benchmark-Ergebnisse, die mit Windows 8 erzielt wurden, anzuerkennen. Auf die Entdeckungen von Christian Ney reagierte das Overcklocking-Portal damit, dass künftig auch Ergebnisse von AMD-Systemen mit Windows 8 ausgeschlossen sind, wie in einem Update der ursprünglichen Meldung erklärt wird.
 
Zurück
Oben