Sőt, mondhatnám, hogy ez egy kifejezetten "újprocesszor" betegség. A régiek turbo boost-ja - már amelyiknek volt egyáltalán - annyira lassan reagált, hogy nem lehetett kihasználni ilyen módon. Illetve nem túrbózta túl a processzort, hogy utána vissza kelljen throttlingolnia.
Ugyan nem rágtam még végig a 19 oldalt, de eddig az jött nekem le, hogy a processzor túlfogyasztás és túlmelegedés elleni védelme miatt tud adatfüggő módon ingadozni a frekvencia és így válnak a papíron konstans futási idejű kripto algoritmusok adatfüggően eltérő futási idejűvé.
Ez az egész attól van, hogy a gyártástechnológiai fejlődés már nem járt órajel növekedéssel, ezért a processzorgyártók jobb híján elkezdték gyárilag túlhúzni a processzort, hogy azt a kevéske tartalékot, amit korábban az overclockerek szoktak kisajtolni, az most gyárilag kihozzák belőle. Csak ezzel az egekbe felugrik a fogyasztás és hőtermelés, amire sem alaplapi áramellátást, sem hűtést nem akarják a gyártók méretezni, mert akkor kb vízhűtés kéne minden notebookba is. Ezért az van, hogy nagyon rövid ideig szénné húzza magát a processzor, aztán ha a terhelés nem szűnik meg, akkor elég hamar visszaveszi az órajelet, mert lokálisan túlmelegszik valami, vagy a feszültségstabilizátor nem bírja tartani az áramellátást. Az utóbbi pár generációban azon versenyzett az Intel meg az AMD, hogy ki tud gyorsabban és finomabb felbontással reagáló boost-ot kiépíteni. (Az alaplapgyártók, meg inofficially kiiktatták az időlimitet a boost-ra, aztán jöttek a meglepik, hogy a 95W-os TDP-jű processzor miért eszik 225W-ot...) A lényeg, hogy most már elég időbeli felbontása lett a boost-nak ahhoz, hogy néhány speciális algoritmus esetén (ami mondjuk nagyon sokszor dolgozik ugyanazzal a változóértékkel) már a feldolgozott adatok beállított bitjeinek a száma is kimérhető a frekvenciaváltozásból.
Nyilván erre megoldás az, hogy
1) teljesen letiltani a turbo boost-ot (ez szerver oldalon nem is annyira öntökönlövés - egy cloud szolgáltatóval szemben pl eléggé elvárás, hogy a VM-jei konzisztens teljesítményt adjanak, függetlenül attól, hogy a szomszéd ügyfél VM-je mennyire terhelt. Itt a boost kifejezetten kontraproduktív.)
2) esetleg valami limitált boost-ra visszaállni, ami garantáltan mindig a TDP-n belül marad. Ez átlagteljesítményben megintcsak nem akkora érvágás, mert elsősorban ezeket a nagyon rövid és nagyon durva spike-okat kell lenyesni.