HPET ist bereits deaktiviert. Wobei es bei Skylake ziemlich egal ist, ob HPET an oder aus ist.
"Could not parse framerate monitoring data" heißt, dass entweder keine Framerate-Daten abgelegt wurden oder die Applikation keine Datei in ihr Verzeichnis schreiben bzw. lesen kann.
Ich habe gerade ein Update für TimerBench online gestellt, das diverse Bugfixes und Feedback enthält: Version 1.3.1
Verbesserungen an der Dokumentation
Zusätzliche Bestätigung vor dem Ändern des QPC Modes
Bugfix für Windows 7 (danke, Diego)
Kompiliert mit der neuesten Version von PresentMon (für die Framerate-Messung)
Nachdem ohnehin kein Hahn nach Benchmark Security kräht, ist die Time Cheating-Funktion momentan aktiviert (Tools => Measure Process => Time Dilatation). Viel Spaß beim Cheaten von so gut wie allen Benchmarks (SuperPi, 3DMark, GeekBench, CineBench, ...)
In-depth: Alle Benchmarks, die QPC auf Windows 7 und höher verwenden sind bei der Auflösung des Timestamps abhängig von der Plattform (HPET, 14,3 oder 24 MHz) und der CPU (TSC, Frequenz ist meist der Base-Multi / 10 MHz). Welche Genauigkeit ist natürlich abhängig von der QPC-Konfiguration (HPET oder TSC). Die Genauigkeit definiert sich aber auch über die Latenz des Timers, also den Zeitraum für das Holen des Timestamps. Bei QPC mit HPET ist diese Latenz (wie TimerBench zeigt) bei modernen Plattformen sehr unterschiedlich.
Insofern kann ein Vergleich zwischen Plattformen von der unterscheidenden Genauigkeit dieses Timers betroffen sein und das wahre Ergebnis der Leistungsmessung verfälschen. Allerdings in so einem geringen Maße, dass es für Normalsterbliche absolut egal ist. Für Messungen bei der Produktentwicklung im Hardware-Bereich schaut es natürlich gleich anders aus und ich behaupte einfach mal - mit den Erfahrungen, die ich mit Intel, ASUS und Co gemacht habe -, dass diverse Mikrooptimierungen an Produkten an dieser Messgenauigkeit scheitern. Aber wer weiß das schon.
Eine andere Sache sind diverse RTC-Timer (timeGetTime, diverse File-Timestamps), die auf alten Systemen im Millisekunden-Bereich voneinander abweichen. Das ist für SuperPi zB natürlich weniger ideal und die Problematik wird hier verschärft.
Alle anderen Benchmarks kann man mit TimerBench selbst nachmessen (Tools => Measure Process ...).
Ich glaub ich muss mich die nächsten Tage mal wieder mit 3DMark Time Spy auseinandersetzen, die ersten zwei Anläufe zu schummeln sind gestern Abend gescheitert, der Score war im Normalbereich auch mit 50% Verzögerung.
Time Spy ist schwieriger, aber möglich. Sind mehrere Prozesse, die man mit einem "Unified Timestamp" gemeinsam abändern muss (mehrere Instanzen von TimerBench müssen geöffnet werden). Ich könnte einen Screenshot posten, der zeigt wie es geht, aber ich denke, dass ich das vorerst mal lassen werde.
Wir könnten dann eine zweite Liste führen, wer am besten schummeln kann Ich hab's eh probiert mit mehreren TimerBench Instanzen, konnte aber die einzelnen Prozess IDs nicht richtig vergeben.
Ich sehe gerade, dass das Dropdown für die Einstellungen beim "Start Timestamp" nicht aktiviert ist. Ohne dieser Funktion lässt sich Time Spy eh nicht knacken, sodass der Score durch die Online-Validierung durchgeht.
Ich werde noch eine Version kompilieren, wenn Interesse besteht.