News HWBOT annulliert Benchmark-Rekorde mit Windows 8

Vivster schrieb:
Lesen. Das Problem tritt nur bei Änderungen am Basistakt(BCLK) auf und für gewöhnlich ändert man daran als gewöhnlicher Übertakter nichts bis sehr wenig.

Naja 3% liegen wohl überall drinne.... 5-7% bei guten Boards und normaler Kühlung.

Aber im prinzip will man ja nicht schneller sondern langsamer werden! also BCLK runter! und beim runter gehen gibts wohl nur das Software limit. Wobei ich keine ahnung hab wo das liegt.. bei 100? Ich habs auf meinem P9x79pro nie versucht.
 
pmkrefeld schrieb:
Worauf ich hinaus wollte, ist dass man sich Sicherheitslücken erlaubt, die wenn ausgenutzt richtig Schaden anrichten können, das sollte man nicht unterschätzen.
Um den BCLK unter Windows zu ändern braucht ein Programm Ring0 Privilegien. Und wenn es die hat, kann es noch viel schlimmere Dinge anstellen, als das.
Dieses "Problem" also alles, aber keine Sicherheitslücke.
Das was du in deinem vorherigen Post abgelassen hast ist einfach Blödsinn.

Betroffen sind ja sowieso nur ne Hand voll Leute.
Die, die wirklich wettbewerbsmäßig OC betreiben werden sowieso via BIOS übertakten, und nicht unter Windows.
 
Grantig schrieb:
Betroffen sind ja sowieso nur ne Hand voll Leute.
Die, die wirklich wettbewerbsmäßig OC betreiben werden sowieso via BIOS übertakten, und nicht unter Windows.
Trotzdem sollten Benchmarks, die auf Systemen erstellt wurden, die diese, wenn auch selten genutze, "Betrugslücke" nutzen, aus den Rankings ausgelassen werden, um den seriösen Vergleich aufrecht zu erhalten.
 
Für die paar Wenigen, die mit viel Aufwand Benchmark-Rekorde in Win 8 ehrlich und ohne Betrugsabsicht erstellt haben, ist das jetzt natürlich bitter. Aber dann haben sie schon einen Grund, das ganze nochmal mit Win 7 zu wiederholen, eigentlich ist doch der Weg das Ziel, ne? ;)


Aber wtf wer kommt denn hier drauf, dass das eine Sicherheitslücke für Server sein soll? Wie will denn jemand bei einem Server die Base Clock im laufenden Betrieb ändern? Wenn er das schafft, dann hat er sowieso vollen Zugriff auf die Kiste, und kann "Besseres" damit anstellen, als ein bisschen am Takt rumzuschrauben!
 
@etheReal

Alles krasse würde auffallen. Aber die Backups Strategie z.B. von Unternehmen so zu stören kann zu Milliarden verlusten führen je nach Unternehmen also ist da schon eine Gefahr da. Aber es stimmt natürlich viele laufen erst gerade mit Win 7 daher sehe ich dies nicht sooo kritisch.
 
pmkrefeld schrieb:
Ja, genau so wie die Java-Sandbox darauf ausgelegt ist nicht aus ihr raus zu können. Worauf ich hinaus wollte, ist dass man sich Sicherheitslücken erlaubt, die wenn ausgenutzt richtig Schaden anrichten können, das sollte man nicht unterschätzen.

Mag ja sein, aber hier ist es eine Hardware-Sache. Wenn der Taktgeber keine on-the-fly Änderungen zulässt dann geht das eben nicht. Außerdem ist das extremes Low-Level bei dem man davon ausgehen kann, dass er korrekt funktioniert.
 
@Grantig

Ich habe nie gesagt, dass man den BCLK je nach belieben ändern kann, sondern geschildert was passieren würde wenn sich jemand dieses "Verhalten" zunutze macht, ich wollte vor allem daran erinnern dass in vielen Umgebungen wo auch Win8 läuft die Zeitgenauigkeit das A und O darstellt. Mir ist wohl zugegebenermaßen entglitten dass man hier ohne Kernel-Zugriff nicht viel machen kann durch die ganzen OC Programme die heutzutage das OC'en im laufendem Betrieb ermöglichen. So wie ich die Kommentare hier lese reicht es wohl nicht den Baseclock zu ändern, sondern "im laufenden Betrieb" ändern was es zusätzlich entkräftet, vllt ist es dann wohl doch nicht so schlimm, dennoch würde ich davon nicht absehen das ganze als Sicherheitslücke zu bezeichnen.
 
etheReal schrieb:
Aber wtf wer kommt denn hier drauf, dass das eine Sicherheitslücke für Server sein soll? Wie will denn jemand bei einem Server die Base Clock im laufenden Betrieb ändern? Wenn er das schafft, dann hat er sowieso vollen Zugriff auf die Kiste, und kann "Besseres" damit anstellen, als ein bisschen am Takt rumzuschrauben!

precision 0.001 us, tolerance 500 ppm (mein NTP), Zeit ist extrem wichtig gerade bei Verschlüsselung usw. Oft ist das bessere das, was einem etwas sonst unmögliches ermöglicht.
 
Das ist ein echt peinlicher Fehler, der ins Jahr 1998 gehört und nicht ins Jahr 2013.
 
Ist es nicht.

Man schraubt im laufenden Betrieb so am Takt rum, wie es nicht gedacht war. Wenn dabei dann Fehler wie diese auftreten, ist das die Schuld des Users.
 
PaladinX schrieb:
Das Problem soll aber laut HWBOT auftreten, wenn der BLCK im laufenden Betrieb geändert wird (also beispielsweise Overclocking per Software). Nicht wenn man fix übertaktet und der Rechner normal gestartet wird. Habsch grad heute mittag in einem anderen Forum gelesen.

nur BLCK oder auch der Multi ?
 
Zuletzt bearbeitet:
1.) Also ich würde das nicht als so belanglos für den Normalverbraucher abtun. Ein PC Uhr hat im Normalfall eine Abweichung von ca. 1 Sekunde am Tag bzw. ein Unterschied von 100MHz vs. 100,001MHz Basistakt. Ich bin mir nicht sicher, ob die Generierung des Taktsignals so stabil ist, als dass die Abweichungen so gering sind. Klar bei einem PC ist das egal, weil sicher der sowieso nach dem nächsten Neustart wieder synchronisiert, aber bei Servern, die auf der selben Technologie basieren und üblicherweise vielleicht 1x im Jahr neu gestartet werden, denke ich schon, dass die Abweichung größer sein kann.
Weiters ist die Frage, ob das Phänomen auch auftritt, wenn man Windows herunter fährt, was bei Windows 8 ja nur ein Abmelden inkl. Ruhezustand ist und wieder neu bootet. Hier könnte ich schlimmsten Fall ja sogar ein Wechsel der CPU dazwischen liegen. Gerade bei Hestellern wie ASUS, die die Anwender ja mit diversen OCing Features vergewaltigen, die automatisch den Takt um ein paar MHz anheben, sehe ich das als sehr bedenklich an. Genauso kritisch sehe ich vernetzte Anwendungen wie z.B. Online Spiele, wo die Clients dann eventuell asynchron laufen.

2.) Wie soll das mit den Benchmarks denn weiter gehandhabt werden. Momentan lässt sich Windows 8 verbannen, aber das ist ja keine Dauerlösung, wenn nichts am Problem selbst geändert wird. Sollen in 10 Jahren immer noch keine Betriebssysteme nach Windows 7 zugelassen werden? Das macht ja sämtliche Prime95 Validierungscodes hinfällig.

3.) Ich habe so etwas vor ca. 10 Jahren bei einem Freund schon einmal erlebt. Der hatte dasselbe Phänomen aber gleich um ca. den Faktor 2 bei seinem Notebook. Damals sind die Energiesparfeatures von Intel noch in den Kinderschuhen gesteckt und immer im Batteriebetrieb sind die Spiele langsamer geworden. Ich vermute das war ein ähnliches Problem, nur eben mit Windows XP. Die Uhrzeit war meines Wissens nach jedoch nicht betroffen.
 
@andr_gin
Zu 1: Wer sagt, dass Server nicht zwischendurch auf die aktuelle Zeit gestellt werden? Sie werden ja regelmäßig gewartet, da fällt es irgendwann schon auf, wenn die Uhr ein paar Minuten falsch geht.

Zu 2: Das Problem ist, dass einige (alle?) Benchmarkprogramme auf die Echtzeituhr (real time clock, kurz RTC) setzen. Windows 8 ist einen Schritt weiter und verwendet einen Hochpräzisions-Timer (HPET), der im Grunde eine weiterentwickelte RTC darstellt. Windows bzw. Microsoft kann nichts dafür, dass einige Programme auf obsolete Technologien aufsetzen. Und Windows bzw. Microsoft kann auch nichts dafür, dass die RTC nicht mehr gleichmäßig läuft, wenn am Takt geschraubt wird. Das entzieht sich völlig der Kontrolle des Betriebssystems.

Zu 3: Wie kommst du darauf, dass es das selbe Problem wie damals war, wo da doch laut deiner Aussage gar nicht der Zeitgeber daran Schuld hatte? Bei mir lief zB Unreal Tournament 2003 auch mal wesentlich zu schnell. Warum? UT2003 + Linux + AMD Cool'n'Quiet waren zusammen nicht kompatibel. Man musste C'n'Q abschalten, damit das Spiel wieder in normaler Geschwindigkeit ablief. Der Zeitgeber (RTC) hatte damit genau gar nichts zu tun.


So wie ich das sehe, ist es eher ein User-Problem. Er pfuscht in den Takteinstellungen rum und wundert sich dann auch nicht, dass dabei der Rechner nicht mehr richtig funktioniert. Aber klar, wahrscheinlich ist sogar die NSA daran Schuld, wenn man sich das nur lange genug einredet.
 
Zuletzt bearbeitet:
promashup schrieb:
Trotzdem sollten Benchmarks, die auf Systemen erstellt wurden, die diese, wenn auch selten genutze, "Betrugslücke" nutzen, aus den Rankings ausgelassen werden, um den seriösen Vergleich aufrecht zu erhalten.
Betrugslücke. Was zum Teufel soll das denn sein?


e-Laurin schrieb:
Zu 1: Wer sagt, dass Server nicht zwischendurch auf die aktuelle Zeit gestellt werden? Sie werden ja regelmäßig gewartet, da fällt es irgendwann schon auf, wenn die Uhr ein paar Minuten falsch geht.
Genau darauf verlässt sich Windows eigentlich auch. Es geht davon aus, dass es die Uhrzeit in regelmäßigen Abständen von einer Quelle bekommt und die Systemzeit wird dann leicht beschleunigt oder verlangsamt bis die korrekte Uhrzeit erreicht wurde.
Somit vermeidet man, dass die Uhrzeit einfach mal ein paar Sekunden vor oder zurückspringt, was zum Teil fatale Konsequenzen nach sich ziehen kann, wie man zum Beispiel an Linux gesehen hat.
Deswegen wird die Uhrzeit in Windows halt nur beschleunigt oder verlangsamt, solange sich die Zeitkorrektur in Grenzen hält. Nur bei großen Änderungen springt die Uhrzeit schlagartig um.

Kurzzeitig schneller oder langsamer laufende Uhren in Windows sind also nicht immer gleich ein Fehler. Das kann auch nur heißen, dass die Uhrzeit umgestellt wurde.

In diesem Fall mit der Übertaktung scheint es aber wirklich so zu sein, als ob die interne Zeitmessung nicht mehr vernünftig funktioniert und deswegen die Uhr langsamer läuft.
 
Zuletzt bearbeitet:
Hat das einen Einfluss auf Online Spiele die QueryPerformanceCounter und QueryPerformanceFrequency benutzen? (http://msdn.microsoft.com/en-us/library/windows/desktop/ee417693(v=vs.85).aspx )
Das wäre wirklich problematisch...auch für Missbrauch (cheater)

Wenn man in CPU-Z den BCLK wert anschaut so ist dieser nicht immer konstant auf 100Mhz (zumindest meiner).
Mit "spread spectrum" im Bios enabled zeigt es zB. 99.77Mhz an. Nach der Komma Stelle schwankt der Wert.
Dann ist natürlich wieder die Frage wie genau dieses Tool ist.
 
Die beiden API-Methoden liefern auf Multi-Core-Systemen keine stabilen Ergebnisse. Ich glaube eher nicht, dass man sie verwendet, wenn permanent exaktes Timing gebraucht wird.
 
@e-Laurin
Würde es etwas daran ändern wenn man nur einen CPU Kern aktiviert?
Was wären die alternativen timer für online spiele die auf UDP-Pakete basieren?

Ich habe ein sync Problem mit einem Spiel, seit dem ich meine PC-Hardware erneuert habe. Obwohl ich bei den Spielservern einen sehr guten ping(20-40) habe, fühlt sich das Spiel wie 200ping an. Je mehr Zeit im Spiel vergeht desto schlimmer wird es mit laggs und Verzögerungen.
 
> Würde es etwas daran ändern wenn man nur einen CPU Kern aktiviert?
Nein. Dein Link sagt das auch. Diese Methoden kommen ebenfalls nicht (durch Stromsparmodi) mit variabel getakteten Kernen klar.

> Was wären die alternativen timer für online spiele die auf UDP-Pakete basieren?
RTC und HPET. Wobei man eher auf HPET setzen sollte; es scheint als will man damit die RTC ablösen. Mit Netzwerkverbindungen hat das übrigens nichts zu tun.

Wenn bei dir ein Spiel nach einer gewissen Zeit ruckelt, so kann das viele Gründe haben. Bei Surpreme Commander beispielsweise ist die KI so mies programmiert, dass sie nach einer halben Stunde jeden Rechner in die Knie zwingt. Es könnte aber auch sein, dass deine CPU überhitzt und dann throttled, also runtertaktet. Und dann ruckelt es plötzlich. Wie gesagt, es gibt viele Gründe.
Mach am besten einen eigenen Thread auf, wo du deine Probleme beschreibst.
 
noxon schrieb:
Betrugslücke. Was zum Teufel soll das denn sein?
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.
 
Artikel-Update: Nach weiteren Untersuchungen stellte HWBOT fest, dass das Problem offenbar auch von der eingesetzten CPU abhängt. Der Fehler konnte angeblich mit Intel-Prozessoren zurück bis zur Sockel-775-Plattform reproduziert werden. Auf den getesteten AMD-Plattformen sei die „Zeitverschiebung“ jedoch nicht aufgetreten. Eine Grafik veranschaulicht die bisherigen Erkenntnisse.

[Bilder: Zum Betrachten bitte den Artikel aufrufen.]

Inzwischen hat sich Futuremark in einer Pressemitteilung zu dem Thema geäußert. Der finnische Entwickler der bekannten 3DMark-Reihe erkennt das Problem an und will eigene Untersuchungen anstellen. Zudem soll nach technischen Mitteln gesucht werden, um eine mögliche Nutzung dieses „Exploits“ aufzudecken und somit die Integrität der 3DMark Hall Of Fame zu wahren.
 
Zurück
Oben