Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 61, views: 24.593 •

HWBot, een van de grootste verzamelpunten van overklokresultaten en competities, heeft Windows 8 in de ban gedaan. De resultaten die met Microsofts nieuwste besturingssysteem behaald worden, zouden niet betrouwbaar zijn.

De betrouwbaarheidsproblemen van benchmarkresultaten met Windows 8 hebben de website doen besluiten alle voorgaande overklokrecords met dat besturingssysteem te schrappen. Overklok- en benchmarkresultaten die onder Windows 8 gedraaid zijn, worden niet meer in de lijsten opgenomen. De reden daarvoor is de kans dat de resulaten niet correct zijn. Bij ondergeklokte systemen zou de interne tijdmeting van Windows 8 niet kloppen, wat tot incorrectie leidt. Dat kan misbruikt worden om betere resultaten te publiceren bij overklokcompetities of in de rankings.

Dallas rtc-chipHet probleem bij Windows 8 zit in de real-time clock, of rtc. Het systeem gebruikt dat kloksignaal als interne referentie om de tijd bij te houden. Wanneer het systeem op de standaardkloksnelheid loopt, klopt de interne rtc-tijd, maar wanneer het systeem wordt ondergeklokt, wordt ook de rtc trager. Als het systeem niet met internet verbonden is, wordt dit niet gedetecteerd en gecorrigeerd; bij overklokken worden netwerkverbindingen vaak uitgeschakeld voor een kleine prestatiewinst. Bij een lagere interne kloksnelheid kan een benchmark meer frames per 'seconde' genereren, omdat een 'seconde' dan langer duurt.

Bij een test werd de baseclock van een Windows 8-systeem zes procent ondergeklokt, waarna bleek dat alle benchmarks beter scoorden, meestal met hetzelfde verschil van zes procent. Daarbij scoorden niet alleen fps-benchmarks beter, maar ook benchmarks als Prime95. Om die reden wordt geen enkel testresultaat dat met Windows 8 werd behaald meer toegelaten in de HWBot-database.

Bij Windows 7 en eerdere versies is het onderklokken geen probleem. Dan wordt de hardwarematige rtc gebruikt. Bij Windows 8 wordt die hardware-rtc niet gebruikt, omdat niet alle platforms waarop Windows 8 moet draaien van een hardwarematige rtc voorzien zijn. Tot een eventuele oplossing voor het probleem is gevonden, wordt onderzocht wat met oude en nieuwe resultaten gedaan wordt.

Reacties (61)

HWBot heeft helemaal gelijk!

Ik heb hetzelfde, als ik de Multiplier omhoog gooi dan raporteert W8 correct, maar als je met de FSB gaat klooien draait hij volgens W8 nog stock...

Edit: kan iemand mij vertellen wat hier offtopic is?

[Reactie gewijzigd door kuusj98 op 19 augustus 2013 13:18]

Dat is toch altijd zo? Onder elk OS?
Quote : "Bij Windows 7 en eerdere versies is het onderklokken geen probleem. Dan wordt de hardwarematige rtc gebruikt. Bij Windows 8 wordt die hardware-rtc niet gebruikt, omdat niet alle platforms waarop Windows 8 moet draaien van een hardwarematige rtc voorzien zijn."

Het zal wel aan mij liggen, maar ik snap die logica dus niet. Ik bedoel; Windows 7 systemen beschikken wellicht ook niet allemaal over een hardwarematige RTC en functioneren wel goed. Het is toch helemaal niet nodig dat dit een probleem veroorzaakt bij Windows 8 ?

Ziet er wat mij betreft uit alsof Microsoft de zoveelste blunder is begaan met Windows 8...

Zelfs Linux "underclocked" mijn laptop ook als ik geen rekenintensief werk aan het doen ben. Evengoed blijft alles probleemloos werken.

[Reactie gewijzigd door Titan_Fox op 19 augustus 2013 13:16]

Ik had dit niet bij W7 HP op exact hetzelfde systeem, ik kan mij wel vinden in de "mening" van HWBot.
Windows 7 draait alleen op laptops en desktops. Windows 8 kan op telefoons, tablets etc etc etc draaien.
Windows 8 is (nog) niet echt geschikt voor telefoons.
Dat het er niet geschikt voor is, zegt niet dat het er niet op *kan* draaien. Waarom zou je Windows RT niet op een telefoon kunnen installeren met dezelfde SoC erin als een tablet waar officieel Windows RT draait? (even daar gelaten dat de drivers voor het andere scherm van de telefoon en andere apparatuur er ook zijn, of gemist kunnen worden).

Naast dat delen Windows en Windows Phone sinds WP 8 ook de NT kernel. En aangezien RTC support me toch wel iets lijkt wat in de kernel zit, maakt het waarschijnlijk ook niks uit of het nou Windows 8 of WP8 is wat op die ene smartphone draait qua RTC.

Afgezien van dat is of iets wel of niet ergens voor geschikt is ook weer een mening, mijn mening is bijv. dat Windows eigenlijk *helemaal nergens* voor geschikt is }>
Windows RT en Windows 8 is niet hetzelfde OS he. Windows RT is dan wel gemaakt voor ARM, maar Windows 8 niet, en dit bericht gaat over Windows 8.

Dat gezegd, de Motorola RAZR i heeft wel een x86 processor, namelijk de Intel Atom Medfield, technisch zou het mogelijk moeten kunnen.
[quote](even daar gelaten dat de drivers voor het andere scherm van de telefoon en andere apparatuur er ook zijn, of gemist kunnen worden).[quote]
Juist dat ontbreekt allemaal op W8 RT.
Geen ondersteuning voor telefoon functies (bellen, gebeld worden, SMS'sen, sms ontvangen, MMS enz) en ook geen ondersteuning voor verbidingen met telefoon netwerk (GSM) functies. En geen ondersteuning voor kleine schermen.
Windows Phone 8 draait op de Windows 8 kernel.
Windows 8 is (nog) niet echt geschikt voor telefoons.
Windows Mobile deelt de exact zelfde kernel van het besturingssysteem als de desktop versie van Windows 8, de interface staat niet gelijk aan of iets ergens geschikt voor is of niet.

Volgens mij komt deze bug overeen met het feit dat Windows 8 een hele hoge DPC Latency heeft van minimaal al 1000 waardoor audio regelmatig kraakt of stoort, redelijk irritant...
Ik bedoel; Windows 7 systemen beschikken wellicht ook niet allemaal over een hardwarematige RTC en functioneren wel goed. Het is toch helemaal niet nodig dat dit een probleem veroorzaakt bij Windows 8 ?
Kennelijk bevatten alle Win7 systemen wel een hardwarematige RTC, anders was de OS code op dit punt natuurlijk niet veranderd. Misschien dat het hier gaat om de nieuwe generatie Win8 tablets oid?
Zijn Windows 8 tablets dan over / onder te klokken ? Is dat HWBot niet hoofdzakelijk voor lap- en desktops ? Daarbij; zo'n RTC-chip kost maar een paar cent. Waarom die dan niet in bepaalde Windows 8 hardware zit kan ik niet begrijpen eerlijk gezegd.

[Reactie gewijzigd door Titan_Fox op 19 augustus 2013 13:13]

Zijn Windows 8 tablets dan over / onder te klokken ? Is dat HWBot niet hoofdzakelijk voor lap- en desktops ?
Aangezien Win8 op x86 hardware draait zie ik niet in waarom dat niet kan. Verder: het gaat om de architectuur van Windows die gemaakt is met meer platformen in gedachte dan alleen maar desktop en laptop systemen. Kennelijk is daarin de keuze gemaakt om niet te vertrouwen op een hardware RTC, maar door alles altijd softwarematig te doen (consistentie over meerder platformen).
En daar plukken ze dus nu de vruchten van. Rotte vruchten, wel te verstaan.

Is het nooit bij Microsoft opgekomen dat er een goede reden voor was dat die hardwarematige RTC-chips al sinds de eerste computers worden gebruikt ?

Naar mijn mening is een hardwarematige klok (mits van goede kwaliteit) nauwkeuriger dan een softwarematige. Tenslotte zal die software-RTC ook constant gesynchroniseerd moeten worden via internet.
Vind dit wel een beetje een overtrokken reactie. Als ik het bron artikel goed interpreteer dan is deze issue alleen te reproduceren wanneer je na het booten software matig een andere BLCK instelt dan dat deze tijdens het booten was. Dit is een situatie die bij 99% van de gebruikers nooit zal voorkomen en enkel een paar overclockers raakt waarbij de hardware out of spec draait. Ik weet niet over MS (of welke andere partij) verantwoordelijkheid moet nemen als iemand zijn hardware laat draaien op een officieel niet ondersteunde wijze.

Ook lijkt het niet op alle platforms voor te komen. Met Haswell is het reproduceerbaar in de HWbot thread over dit artikel, met AMD trinity lijkt er echter geen issue te zijn daar er in dezelfde thread op HWbot resultaten worden behaald met trinity die niet veranderen afhankelijk van de BLCK, wat weer zou betekenen dat het geen 100% Windows 8 issue is, maar mogelijk een Windows 8 + Intel issue.

Ik denk dat dit eerst verder uitgetest moet worden voordat er eventuele "schuldigen" aangewezen moeten worden, of dat het enkel ligt aan feit dat mensen hardware out of spec draaien.
Ik weet niet over MS (of welke andere partij) verantwoordelijkheid moet nemen als iemand zijn hardware laat draaien op een officieel niet ondersteunde wijze.
Ik vraag me überhaupt af of MS dit wel in het achterhoofd had toen ze ervoor kozen de hardware RTC in de ban te doen. De condities zijn nogal zeldzaam. Ik denk eerlijk gezegd dat MS gewoon met een fix gaat komen, want timing is nogal een essentieel onderdeel. En uiteraard gaat het MS daarbij niet om deze benchmarks, dat is gewoon een ongelukkig gevolg wat het aan het licht bracht.

[Reactie gewijzigd door .oisyn op 19 augustus 2013 14:37]

juist voor consumenten apparatuur maakt het vrijwel niets uit dat een seconde precies een seconde duurt. Sterker nog, over het algemeen lopen vrijwel alle op het stroomnet gebaseerde klokken niet perfect simpelweg omdat ze gebaseerd zijn op de 50hz van het stroomnetwerk.

Als je een computer nodig hebt waar een seconde excact een seconde is dan investeer je in hardware die betrouwbaar is en daar op getest is, en dan zal je waarschijnlijk ook geen consumenten os gebruiken en minstens onderzoek hebben gedaan of het os dat je gebruikt secondes betrouwbaar genoeg kan weergeven.

Ik vind het helemaal geen rare zet van microsoft. Voor consumenten is een rtc gewoon niet belangrijk behalve voor dat kleine groepje overclockers waarbij nu slechts de weergave van overclockresultaten niet betrouwbaar is.
Ik kan me niet voorstellen dat het deel van de markt wat overclockt en waarbij er competitie is door de resultaten online te posten nou zo groot en dus belangrijk is. Voor de rest is de tijdsweergave met een pc nauwkeurig genoeg, zeker indien de klok regelmatig via het internet wordt gesynchroniseerd.

Daarnaast is de klok betrouwbaar genoeg indien er niet wordt overgeclockt en zijn mensen die over of underclocken nu op de hoogte en weten zij dus dat ze als ze een meer betrouwbare klok willen ze vaker zullen moeten syncen.
win8 is niet alleen consumenten, er zijn ook pro versies en de server versies worden er op gebaseerd.
toegegeven dat die niet overclocked worden, maar zonder hardwarematige RTC zou Ik toch minder blij zijn als Ik een professionele W8 bak zou hebben draaien
Ik denk dat het niet zozeer te maken heeft met het al dan niet aanwezig zijn van de RTC bouwsteen. Ik vermoed, als ik het artikel zo interpreteer, dat Win8 de RTC gebruikt zoals ook Linux die gebruikt:

Linux initialiseert de OS-tijd met de RTC bij het opstarten van het OS. Daarna werkt Linux de OS tijd bij door op min of meer geregelde tijdstippen een klokpuls counter van de processor op te vragen. Dit heeft een veel hogere resolutie dan de RTC.

Bij het afsluiten van het systeem wordt de OS tijd teruggeschreven naar de RTC.

Nadeel (?) hiervan is dat het OS nauwkeurig moet weten hoeveel tijd er tussen de opeenvolgende klokpulsen zit. Ik denk dat bij Win8 daar de schoen wringt.
Ziet er wat mij betreft uit alsof Microsoft de zoveelste blunder is begaan met Windows 8...

Zelfs Linux "underclocked" mijn laptop ook als ik geen rekenintensief werk aan het doen ben. Evengoed blijft alles probleemloos werken.
Waarom de zoveelste blunder?
Er staat toch nergens dat Windows 8 niet probleemloos werkt bij het "underclocken"? Het systeem blijft gewoon functioneren, de benchmark is echter niet betrouwbaar aangezien het systeem voor de interne klok is aangepast en de benchmark daar (nog) geen rekening mee houd.
als de interne clock niet gelijk is aan de echte tijd zal die steeds verder afwijken naarmate een systeem langer aanstaat en zo files een foute tijd meegeven.
Het zal wel aan mij liggen, maar ik snap die logica dus niet. Ik bedoel; Windows 7 systemen beschikken wellicht ook niet allemaal over een hardwarematige RTC
Jawel, dat is namelijk een standaaardonderdeel van de x86 architectuur. Het probleem is dat Windows 8 ook op non-x86 hardware draait.
Volgens mij is dit probleem makkelijk op te lossen, als je in de bios gewoon je HPET aanzet en deze via Windows forceert dan heb je volgens mij geen last meer van het feit dat de tijd niet meer klopt.
De RTC in windows is hardstikke inaccuraat, een tijd terug had ik mijn pc alleen op de Windows RTC staan (HPET uit). Gevolg om de zoveel tijd disconnects bij Diablo 3, chat out of sync en ook bij Supreme Commander constant out of sync.
De normale setting van Windows is dat hij het gemiddelde van beide pakt. Wat je beter kan doen is gewoon HPET forceren in Windows, bespaard je een hoop problemen ;).

Als je HPET wil forceren:
http://www.neowin.net/forum/topic/1075781-tweak-enable-hpet-in-bios-and-os-for-better-performance-and-fps/

Edit: Blijkbaar is de default setting van Windows 7 dat hij om de zoveel tijd synced met de hardware matige timer, in Windows 8 gebeurt dit dus helemaal niet (belachelijk).

[Reactie gewijzigd door Sp3ci3s8472 op 19 augustus 2013 14:58]

W8 nog minder populair bij tweakers. Ik denk dat MS wel met een oplossing komt, al zal dit niet hoog op hun lijstje staan
Nou ja, ik denk dat als je (net als mij) niks met Windows 8 te maken wilt hebben, het onbreken van fatsoenlijke ondersteuning voor de hardware-RTC geen wezenlijk verschil zal maken in je beslissing om voor een ander besturingssysteem te kiezen.

Het is gewoon één van de vele dingen waaraan ik me zou (kunnen) storen. Op een gegeven moment is die lijst zo lang dat het niet meer uitmaakt of er nog meer mankementen op komen te staan.
W8 nog minder populair bij tweakers.
? Ik kan me zo voorstellen dat de benchmarks, en zeker voor Q4 2013 en verder, in een aantal gevallen gebruik kunnen gaan maken van DirectX 11.2 om de nieuwste/mooiste games op huidige high-end PC's te laten zien.

Aangezien je voor DX11.2 toch zeker Windows 8 nodig gaat hebben, lijkt me het een deadlock-situatie te worden als zowel Microsoft als HWBot (of andere benchers) hier geen verandering in willen aanbrengen.
Een beetje slimme jongen die de RTC zo kan instellen dat je die zelf kan bepalen kan er dus voor zorgen dat hij op papier hele hoge records neerzet (al is er dan in de praktijk niets van waar).

Wel slecht dat het op deze manier door het OS gedaan wordt, zeker als er wel een hardwarematige RTC aanwezig is op het moederbord. Ik vraag me af wat voor problemen we hier nog meer mee kunnen verwachten op den duur, het zal vast meer zijn dan alleen een afwijking in benchmarks.
Is het niet net de hardwarematige RTC op het moederbord die word ondergeklokt?
De RTC loopt altijd op dezelfde frequentie (meestal 32.768kHz), waarmee bepaalt wordt hoe lang 1 seconde precies duurt. Die klok je dus niet over of onder.
Geniaal dit, terug naar het gouden tijdperk van de turboknopjes dan maar! :)

http://en.wikipedia.org/wiki/Turbo_button
Geld dit dan voor alle soorten benchmarks? dus ook voor bijvoorbeeld 3D Mark? Dat zou het voor Tweakers.NET ook lastig maken om hardware benchmarks te draaien zoals video kaarten, want je hebt dan geen enkel idee of hij wel echt beter performed. Ook tussen hardware van verschillende fabrikanten onderling.
dan pak je toch w7 ipv w8 ?

zou dit een bewuste keuze van MS zijn geweest om w8 beter te laten lijken dan w7?

[Reactie gewijzigd door Mr.Monk op 19 augustus 2013 13:04]

zou dit een bewuste keuze van MS zijn geweest om w8 beter te laten lijken dan w7?
Ja, plus dat de verkoop van alu-hoedjes de laatste tijd tegenvalt.
Zolang je niet overklokt en aan het internet hangt zal je hier al minder last van hebben.
Ik vraag me echter af hoe de tijdsmeting van microsoft dan omgaat met speedstep en cool n quiet technieken...
Zolang je niet overklokt en aan het internet hangt zal je hier al minder last van hebben.
Ik vraag me echter af hoe de tijdsmeting van microsoft dan omgaat met speedstep en cool n quiet technieken...
Geheel niet onderbouwde speculatie: misschien dat deze processoren doorgeven dat ze naar een andere powerstate gaan/onderklokken waardoor de snelheid van de RTC wordt aangepast, iets wat niet gebeurt bij handmatig overgeklokte CPU's?
Volgens mij gaat het zelfs andersom (software driver geeft aan CPU door dat hij het langzamer aan kan doen).
Waarschijnlijk gewoon weer synchroniseren zodra er een verbinding is. Ik zie m'n (Windows) Phone ook weleens verspringen als ik buiten bereik raak in de trein.
Geld dit dan voor alle soorten benchmarks?
Het geldt voor alle soorten van timing. Een seconde duurt gewoon langer dan dat ie daadwerkelijk duurt. Afgezien van een RTC heeft een systeem geen enkel referentiemateriaal voor het verloop van tijd - de meeste clocks (CPU, mem, FSB, PCI, etc.) zijn variabel.

Elke benchmark berekent de snelheid door ofwel een vaste set calculaties te doen en dan te meten hoe lang dat duurde, ofwel in een bepaalde vaste kijken hoeveel calculaties er gedaan kunnen worden. Als bij beide methodes de tijd scheef loopt, dan krijg je dus ook scheve resultaten.

[Reactie gewijzigd door .oisyn op 19 augustus 2013 14:43]

Wordt dit bovenste nu geen probleem voor overclock organisaties die hier prijzen aan verbinden. Je wilt toch zeker weten dat je een prijs juist uitdeelt aan personen die goed hun best hebben gedaan.
Zolang ze (nog) geen prijs hebben uitgedeeld aan iemand die onder W8 de benchmark heeft gedraaid, is er geen probleem. Anders kunnen ze hetzelfde trucje nog eens uithalen onder een ander besturingssysteem om aan te tonen dat het resultaat wel of niet klopt.
Dus een realtime clock die eigenlijk geen realtime meer is. Puik werk weer. Ik geef HWBot 100% gelijk dat ze dit niet accepteren.

Wat ik dan niet snap, waarom kan dit alleen op W8 als het om een hardware chip gaat? Snappen andere OSen wel dat die chip underclocked is en compenseren ze dat dan?
Bij Windows 8 wordt die hardware-rtc niet gebruikt, omdat niet alle platforms waarop Windows 8 moet draaien van een hardwarematige rtc voorzien zijn.
Er wordt dus een RTC binnen het OS gebruikt, ipv dat er standaard naar een hardwarematige RTC gekeken wordt, omdat niet alle platformen waar W8 op draait een hardwarematige RTC hebben. Aan de ene kant begrijpbaar (alle platformen gelijk behandelen), aan de andere kant apart dat een hardware chip niet gebruikt wordt als hij wel beschikbaar is.
Volgens mij is zoiets wel softwarematig op te lossen. Sowieso kan je de tijd syncen met een lokale of online timeserver. Als je dat voor en na een bepaald benchmarkproces doet kan je eenvoudig uitrekenen hoe lang het geduurd heeft.
Alleen als je geen internet/netwerk-verbinding hebt wordt het wel lastig. Dan is niet meer te controleren of de lengte van een seconde intern wel klopt. Maar de meeste cmos-klokken zijn ook niet bepaald zuiver, dus als je voor die seconde het aantal klokcycli uitrekent aan de hand van de specs zit je er denk ik niet heel ver naast.

Ik hou me nooit met benchmarking en overklokken bezig, maar is niet zo dat een monolitisch OS als Windows daar per definitie bij in de weg staat?
Wat ik dan niet snap, waarom kan dit alleen op W8 als het om een hardware chip gaat? Snappen andere OSen wel dat die chip underclocked is en compenseren ze dat dan?
Nee die hardware rtc is onafhankelijk van je processor klok. Dus je hoeft niks te compenseren:

http://nl.wikipedia.org/wiki/Realtimeklok

edit: Linkje toegevoegd.

[Reactie gewijzigd door Delgul op 19 augustus 2013 13:12]

Maar wat is dan het probleem als de afwijking bekend is?
En in genoemd voorbeeld, die 6%, daar kan men bijv. voor de zekerheid toch nog eens
1, 2, 5% of zo afhalen?

En binnen de 'windows 8 clockers groep' blijft het euvel toch voor allen gelden en zijn de onderlinge uitslagen eigenlijk nog steeds 'goed'?

Bij golf houdt men de 'handicap' bij tussen spelers, met computers kan dat niet?
Ik denk dat 5% een te hoge foutmarge is. Daarbij wordt je dan eigenlijk verplicht om de rtc tijd te misbruiken om toch tot realistische resultaten te komen. Beter is het om gewoon een te vertrouwen platform te gebruiken zoals W7.
Die afwijking kan per resultaat verschillen. Het ligt er maar net aan welke instellingen gebruikt zijn. Die instelling die ze hier genoemd hebben is een voorbeeld.

En je wilt eenduidige meetresultaten, zonder correctie achteraf. Want daar krijg je meningsverschillen over.
Logisch zou zijn:

Als er een hardware RTC aanwezig is, gebruik die dan. Zo niet, gebruik de software variant.

De meeste goede programmeurs zouden dat zo oplossen en ik zie niet in waarom hier niet. Zo'n hardware ding is namelijk meestal toch nauwkeuriger.

Wel vrij ongenuanceerd van Microsoft om simpelweg je gespecialiseerde hardware te negeren voor een halfbakken software oplossing. Ben benieuwd naar de reden. Zal wel weer om geld gaan gok ik...

Edit: typo

[Reactie gewijzigd door Delgul op 19 augustus 2013 13:09]

Ik denk dat men dit gedaan heeft omdat men er vanuit gaat dat mensen hun computer toch regelmatig met het internet verbinden. Zelfs op andere systemen die wel gebruikmaken van de hardware chip synct de computer regelmatig met het internet voor zijn klok. Met dat in het achterhoofd zal men gedacht hebben om het dan maar volledig daarop te baseren. Zeker omdat een deel van de systemen die chip niet heeft.

Raar dat dit nu pas boven water komt. Is het een designfout? Geen idee, het kan best by design zijn. Maar als het vroeger boven water was gekomen en er genoeg animo rond was had men het kunnen oplossen in Windows 8.1, nu niet meer.
Belachelijk zeg, en dan bedoel ik niet de ban, maar dat Windows 8 geen gebruik maakt van een hardware RTC als deze wel aanwezig is..

Op dit item kan niet meer gereageerd worden.