Om energie te besparen, past de CPU in je PC z’n klokfrequentie steeds aan.  Dat is op veel manieren te merken, waarvan het aanspringen van de ventilator in je systeem bij zwaar rekenwerk de meest bekende is.  Het is ook op andere manieren merkbaar en wel door verlies van data in bijzondere gevallen.

Stilte tijdens Schalen

Een moderne CPU kan heel veel werk doen per seconde. Echter tijdens het maken van een sprongetje in kloksnelheid lijkt het werk even stil te liggen tot de nieuwe frequentie stabiel doortikt en alles weer op elkaar is afgestemd.

Ik heb nog niet goed kunnen achterhalen of ook het rekenwerk stil komt te liggen, maar in elk geval de I/O naar andere hardware zeker wel.  Hier ligt dan ook het dataverlies op de loer.

Zolang je packet-based bezig bent en de zender of ontvanger even kan wachten tot jij er weer klaar voor bent, is er niets aan de hand. Dus je download van ‘t internet zal echt niet fout gaan. (althans niet hierdoor) Echter andere vorm van communicatie, die het moet hebben van buffers voor een succesvolle afronding van het proces, kan wel degelijk last hebben van dit schakelen.

Een vergelijking die mij te binnen schiet is het branden vroeger van CD’s voordat er branders waren met Buffer Underrun Protection.  Dat is eigenlijk geen issue meer sinds 2000, maar heeft voordien ondergetekende menig (dure) “onderzetter” gekost.

Buffergrootte vs Overbruggingstijd

Waar het niet tijdig legen of vullen van de buffer in het CD-brand-tijdperk vooral werd veroorzaakt door een harde schijf die te druk ergens mee bezig was, ging het toen om buffers van enkele MegaBytes die enkele seconden moesten overbruggen. Bij het schakelen van de CPU frequentie gaat het om enkele tientallen microseconden. (μsec)

Toch kunnen ook die fracties van milliseconden genoeg zijn om net te laat te zijn om een buffer te legen of te vullen.

Neem bijvoorbeeld een TV-kaart met de oude bekende BT878 chip. Dat is nog steeds een goedkoop en bruikbaar kaartje om bijvoorbeeld tapes van een oude camera of VHS-banden mee te digitaliseren.

Deze kaart werkt met meerdere buffers van 512 bytes en als je niet op tijd bent met het leeglezen van die buffers, is de data gewoon weg. De video bron stopt namelijk niet om even te wachten.

Bij PAL video hebben we het over ruim 11 Mpixel/sec (768×576 x 25fps). In werkelijkheid is het nog iets erger, aangezien 1 regel in 64 μsec gelezen wordt. Met 4 bytes/pixel is de buffer in 8 μsec leeg en met 3 bytes/pixel in 11 μsec en dan is de data echt verloren. De data in de leesbuffer wordt dan niet overschreven en er ontstaan strepen in beeld.

Hoe lang duurt het stappen?

Hierbij bedoel ik uiteraard niet tot hoe laat de kroegen open zijn, maar hoe lang de processor bezig is met z’n frequentie aan te passen. 🙂

Kennelijk hebben meer mensen zich dit afgevraagd en ik kwam uiteindelijk uit op dit paper: Evaluation of CPU Frequency Transition Latency, waarin een aantal onderzoekers heeft uitgezocht hoe lang dit schakelen duurt. Ze kwamen hierbij op verrassende resultaten uit.

• Het omlaag schalen kost vrijwel constante tijd, ongeacht de stapgrootte.
• Het omhoog schalen lijkt bij de iets gedateerde Intel Sandy Bridge processoren (gebruik ik ook) vrijwel lineair te gaan met de stapgrootte.
• Omhoog schalen kost meer tijd dan omlaag.

De kleur van de lijnen geeft de start-frequentie weer en elk knooppunt de eindfrequentie van elke sprong.  De diagonale lijnen beschrijven dus de latency bij een stap omhoog en de vrijwel horizontale lijn onderin de latency bij een stap omlaag in frequentie.

Zoals te zien, is de kleinste stap, een stap omlaag, al te veel voor het arme oude TV-kaartje en is er grote kans op dataverlies bij elke keer schakelen van de CPU-frequentie.

Wanneer schakelt de CPU?

Om te herkennen waar de strepen precies zitten, heb ik in mijn test-opstelling de buffers na het lezen van een videoframe eerst overschreven met herkenbare data en daarna de TV-kaart weer opnieuw laten schrijven. Telkens wanneer de buffer te vol was, kwamen er strepen in beeld die ik er dan zo uit kon pikken.

Tijd voor wat statistiek…

Onderstaande metingen representeren een periode van 10 minuten op een voor de rest vrijwel idle systeem.

• 15013 frames (a 25 fps = 600 sec = 10 minuut)
• 14771 frames met minimaal 1 streep (98.4%)
• 85003 strepen in het beeld.
• Gemiddeld bleek er 142x per sec een stuk data te ontbreken. Kortom, de processor was 142x per seconde aan het schakelen.

De duur van een onderbreking was ook opvallend:

Histogram duur buffer overrun (in pixels)

Het vaakst kwam een onderbreking van 1 .. 16 pixels voor (4 .. 64 Byte) en dan niets tot 128 pixels (512 Byte).

Dit zullen dus waarschijnlijk de “down clock” stappen zijn. Let wel; Het PAL videosignaal heeft een ‘horizontal blanking‘ van 12.05 μsec, waarin er geen data bij komt. Dat opgeteld bij de 8 μsec “buffergrootte”, kom je uit op 20 μsec, wat weer goed overeen komt met het eerder genoemde onderzoek.

Het maximum ligt op zo’n 768 pixels (3072 Byte), oftewel 1 regel van 64 μsec. Samen met de 8 μsec om de buffer vol te krijgen, zit je op zo’n 72 μsec, wat ook weer akelig goed overeen komt met het genoemde onderzoek.

Dan nu de verdeling in tijd wanneer een streep begint.

De eerste grafiek geeft aan de start in een regel (X-positie) van een stuk missende data en de 2e grafiek het regelnummer van een frame waar het ontbrekende stuk begint.

De X-as is redelijk constant verdeeld, met een piekje rond de 256e pixel (2x 512 bytes, 2 bufferlengtes) en relatief weinig op de eerste positie van een regel. Waarschijnlijk omdat er vlak daarvoor net een horizontal blanking is geweest.

Interessanter is de verdeling op de Y-coördinaat. Daarbij lijkt elke 64 regels een (ander) aliasing patroon te ontstaan. Vermoedelijk schakelt de CPU dus wel degelijk op vaste momenten.

Ik heb op deze PC de Windows Timer Resolution op 1 msec gezet (default is 64x per sec, dus 15.625 msec) tijdens deze metingen. Dus ik vermoed dat de momenten van schakelen wel degelijk samen kunnen vallen met deze Windows Timer.

Het is een interlaced beeld, dus elke 32 beeldlijnen (a 64 μsec) verschijnt er een ander patroon. Dat is elke 2048 μsec, wat aardig dicht bij een veelvoud van die 1 msec ligt.

Conclusie

Het schakelen van de CPU frequentie legt eigenlijk het hele systeem tijdelijk plat en daar moet je dus ook met de hardware(buffers) rekening mee houden. Zelfs al gaat de transfer van data zelf buiten de processor om, via DMA.

Het onderzoek FTALAT , wat oorspronkelijk bedoeld was om de effecten te onderzoeken van CPU frequency scaling op parallellisatie technieken als OpenMP, blijkt veel breder toepasbaar te zijn.  Het heeft namelijk ook direct invloed op de overige I/O van de computer.

Dit effect is met zo’n simpele TV-kaart heel makkelijk aan te tonen, maar zal op veel meer zaken toepasbaar zijn. Denk bijvoorbeeld aan de wisselende latency bij muziek apparatuur. (MIDI apparaten bijvoorbeeld)

Bronnen

• Windows Timer Resolution – MegaWatts wasted. Interessante blogpost over hoe Windows (niet Windows 8) met de interne timer omgaat.
•  ArsTechnica – Hoe Windows 8 omgaat met de Windows Timer. Zeer interessant leesvoer over wat er allemaal in Windows 8 is veranderd.
• Evaluation of CPU Frequency TrAnsition LATency (FTALAT), onderzoek door medewerkers van de University of Versailles Saint-Quentin-en-Yvelines, France , naar de effecten van verandering van CPU frequentie op parallellisatietechnieken als OpenMP.