Kiváncsi lennék, hogy a driver hatására hogy változik a teljesítmény / fogyasztás arány.

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Üdv! Nekem a teljesitmény nem változott a fogyasztás picit csökkent.

Le a kalappal az AMD előtt.Igen csak vissza tért a Ryzen-al.családi gépben nálunk is kicsit csökkent a fogyasztás.

Linux?

Mindig meglep milyen sokan hiszik el, hogy van ingyen ebéd.

Az mi?

"Az információ korában az evolúciós szelekció azokat tizedeli, akik képtelenek a hamis információt megkülönböztetni a helyestől"

Operáló (=működőképes) rendszer?

Mindig meglep milyen sokan hiszik el, hogy van ingyen ebéd.

itt úgy olvasom, hogy 4.10-es kernelben jött be egy optimalizáció hozzá [link]

Itt van valami teszt, amiben a 4.4 és 4.10.1 közti teljesítményt hasonlították össze (ha jól látom csak 1700x van mindkettővel)

(#8) MongolZ
Van amiben/amihez jobb, gyorsabb, hatékonyabb a linux rendszer.

#9: például android fejlesztőként kimértem, hogy a build time lényegesen gyorsabb linux alól a jobb fájlrendszer kezelés miatt. Win alatt már más feladatok kapcsán is futottunk teljesítményproblémákba az ntfs kezelésének erőforrásigénye miatt.

Android buildnél a 2 mag 4 szálas azonos órajelú és generációs proci hozza linux alatt ugyanazt a fordítási időt, amin win alatt 4 mag 8 szállal kaptam.
Vagy amikor webkit buildelés volt a napi munkám része, akkor az számított sokat, hogy linux alatt vannak kiforrott megoldások a fordítás több gép közötti szétdobására. Win alatt viszont ez nem igazán megy vagy esetleg spéci fizetős és drága, de sokkal butább megoldás lehet. Ott ez 6 perc vs 40 perc volt a linux javára, de persze ott a fordító is más volt, szóval nem teljesen korrekt az összehasonlítás.

Tehát nem youtubeozásnál számít, otthoni felhasználónak bőven mindegy, vagy a játék miatt jobb is lehet a win. Szóval a feladathoz kell az eszközt és nem fordítva.

[ Szerkesztve ]

Miért, a win 7/8/10 nem az ?!

A 7 az, a többit vitatnám

Mindig meglep milyen sokan hiszik el, hogy van ingyen ebéd.

Ha már feldobódott a téma, mikor lesz R5 teszt?

Off-ot érdemlő kérdés, de nagyon sokan várjuk szerintem...

Si tacuisses, philosophus mansisses.

Amilyen processzordrivereket ír a MS, jobb is ha az AMD lecseréli. Vista óta rendszeresen feleslegesen tolja oda a teljes VCORE-t és órajelet a Win. 5% terhelés hatására is akár. Hadd fogyasszon az a gép, még akkor is ha nem szükséges.

De miért 17.10, mikor még csak 4. hó van?

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

😁

Ez a csomag szerintem semmit nem cserél le, egyedül a core parking-ot tiltja, és a min/max órajel százalékokat állítgatja, amit te magad is meg tudsz csinálni kézzel, ha elzarándokolsz a Windows részletesebb energiagazdálkodási beállításaihoz (és vagy a HighPerf preset-et kezded állítgatni magadnak, vagy registry babarálással a Balanced-ban is elérhetővé teszed a parking kapcsolót).

Amúgy, én annak idején, mikor a SpeedStep (ami lényegében az OS driver kezébe adja a CPU szorzó vezérlését a firmware által jelzett min/max közt) volt viszonylag újdonság, akkor egyszer egész sokat töprengtem és keresgéltem a témában, hogy vajon ronthat-e a teljesítményen, de minden racionálisan megalapozottnak tűnő vélemény arra mutatott, hogy nincs kimutatható hátránya (mert hogy a CPU néhány us [micro-, nem millisecundum] alatt vált frekvenciát -> bár ez nyilván csak maga a hardware két órajel közt, nem az az idő, mire egy ütemező felfogja mi történik és reagál, aztán végiggörgeti magát a lépcsőn földszinttől az emeletig) . Egyedül pár "laikus gamer" esküdözött még a VérSzentségre is, hogy márpedig microlagot és random akadozást okoz nekik pár játékban, de én ezt nem igazán vettem észre pár gyorstesztből (illetve még SSD-k szintetikus teszteredményeinél panaszkodtak a C6-ra, esetleg C3-ra, de ott is az volt a konklúzió, hogy a C1E és SpeedStep nem számít, csak a "mélyebb" C3/C6, ami nem csak a CPU magokat, de a buszt és megszakításvezérlőt is lelövi és az is inkább csak a teszteknél jön ki). Ezért sokáig be is be is volt nálam kapcsolva az összes ilyen energiagazdálkodási funkció.

Aztán jött a SpeedShift, illetve annak tesztje például az AnadTech-től is. Ettől nekem volt egy kissebb "nab@zmeg pillanatom", és ki is kapcsoltam az UEFI Setup-ban a SpeedStep-et, C3-at, C6-ot, egyedül a C1E-t hagytam meg (mert ez elvileg úgymond "hardware-es", és csak két állapot közt vált, így elvileg "gyors", viszont az összes közül ez hozza az igazán számottevő eredményt: a többi C-state ehhez képest borravaló, és akkus üzemmódnál, vagy 24/7 üzemelő kis házi szervernél talán értékelhető az a pár Watt is, de a játszós/melós gépeken szerintem többet számít pár százalék teljesítmény, mint pár százalék áramfelvétel, az a pár Watt még akár csak a placebóért is megéri...).

Szóval most pont úgy működik a CPU-m, hogy minimum és maximum közt ugrál: vagy C1E-ben "szundít" (de nem alszik olyan mélyen, mint a hibernált medve), vagy maximális órajelen fortyog, de a kettő közt nem a Windows váltogat.
Itt tenném még hozzá, hogy idő közben ettől függetlenül is megfigyeltem, hogy sok játék szereti fixen 100%-on terhelni az összes CPU szálat, amit használ. Ez valószínűleg kiküszöbölheti a frekvencia-skálázás esetleges negatív hatását (ha körbe-körbe dobálja is az OS ütemező több fizikai magon, mint ahány szoftver szál fut, ha gyors a dobálás, de tegyük fel lassú a skálázás, akkor úgymond "plafonon ragad" a frekvencia, mint ha ki lenne kapcsolva a SpeedStep, ha viszont mégis van idő ilyenkor is fel-le szaladgálni az órajellel, akkor vélhetően elég gyors a skálázás, tehát elvileg nem lehet baj abból, hogy üzemel).

Most ehhez képest nekem még nem tiszta, hogy az AMD pontosan mit csinált a Ryzen-ben: a SpeedStep-re, vagy a SpeedShift-re hasonlít jobban. Azt már százszor hallottam, hogy milyen baromi finoman szemcsézett, és hogy elvileg gyorsan tud váltani, de látni meg pont azt láttam még csak tesztekben, hogy a gyakorlatban nagyon is kimutatható a hátránya teljesítményben, ha nincs óvatosan paraméterezve az OS frekvencia-ütemezője. Viszont a SpeedShift-el még csak Linux-on tudtam játszogatni (a SkyLake-es gépemen az van), ahol nem nagyon lehet paraméterezni a HPW driver-t (vagyis a legfrissebb kernelekben már talán lehet, de az úgymond "natív" módjában eredendően nem, mert az lenne a lényege hogy "hardware vezérlés") így nem tudom az mennyire érzékeny (vagy reagál-e egyáltalán bármit) az OS paraméterezésre.

[ Szerkesztve ]

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Ha semmit sem cserél le, akkor honnan lesz ~10x annyi P-State? Ezt nem tudod állítani a Win Control Paneljén.

Ehhez kéne tudni, hogy terv szerint a hardware vagy szoftver választja a P szintet.

Ha a hardware, akkor mindegy, vagyis a szoftvernek az lenne a dolga, hogy ne erőltessen diszkrét értéket, hanem jelezze a hardware-nek, hogy rábízza (legfeljebb kiválasztja a felhasználó által kíván sémát, ha esetleg van több is, mint pl. a powersave és performance az Intel-nél).

Szoftvernél szerintem alapvetően az ACPI-től kapja az OS a P szinteket, és van valami előre kódolt "vektor" (gondolom az OS fejlesztő rakja össze, de lehet hogy a hardware gyártó ajánlásából?), ami alapján aztán a szoftver zongorázik. -> Na, ezt viszont talán felülírhatja valahogy az AMD (akár a P szint listát is, és azokat a paramétereket, amik azt befolyásolják miként lépkedjen ezek közt a szoftver, gondolom min/max idők és min/max lépéstávok vannak benne).

Hmm... így végiggondolva szoftveres lesz ez, és akkor tényleg ezek lehetnek ebben a csomagban (kibővített "statikusan importált" P lista és esetleg egyebek a használatához). Megzavart, hogy valamiért azt hittem ez is hardware-es, de azzal nem állna össze a kép.

Amúgy nem egészen értem miért jó a csillió P szint, ha szoftveres. <1% fogyasztást akarnak lefaragni vele, vagy csak jól mutat papíron a nagy szám? Szerintem használhatták volna az Intel tapasztalatokat, ahol már az előző generációnál (SkyLake) látszott, hogy megérte a HWP.

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Nem lesz 10x annyi P-state, csak sokkal gyakrabban ellenőrzi hogy mikor melyikbe váltson. Persze ez is csak egy marketing diagram természetesen.

Regeditbe lehet mókolni vele. Ezt csinálja az AMD is csak egy új power plan-al.

De most kapaszkodj meg, mivel az alapértelmezett teljesítménycentrikus windows profilt használták (ezt is erőltetik) ezért az alapjáraton 90% alá nem engedi menni a proci magok frekvenciáját, vagyis a 16 P-state-ből csak a P0 és a P1 fog működni (kerekítés miatt) ami vagy 3500Mhz-en pörgeti a procit (+- boost órajelek) vagy 3300Mhz-en (órajel modeltől függ). És erre még rákapcsolták hogy 10x olyan gyakran ellenőrizze hogy vajon most melyik P-state is kéne hogy működjön (a kettő! közül), vagyis adtak a szarnak egy pofont de rohadt nagyot.

Magyarán a processzor ahelyett hogy azt csinálná amit kéne, fölösleges energiagazdálkodási ciklusokat futtat a háttérbe és azzal szívja el az esetlesesen fontos feladatok elől a processzoridőt. Ennyi erővel már bitcoint is bányászhatna az talán hasznosabb lenne.

[ Szerkesztve ]

Van hardware-es C state, amire akkor is vált, ha a powerplan min=max=100% ?
Mert akkor egyszerű lenne, csak be kell lőni 100%-ra az OS-t, akkor marad egy P és a C(-k) és az OS sem kattog rajta.

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Hardveres van, csak azt ugye implementáni kéne a chipben mint ahogy az Intel csinálja (SpeedShift), és akkor a Windows nem tudna (annyira) beleugatni az ilyen dolgokba. De erre spúrok voltak ergo marad a Windows-os pepecselés.

Igazából úgy kéne normálisan és gyorsan működni egy processzornak alapból hogy 0-5% min (P15) és 100% max (P0) közötti beállításokkal is elfogadható legyen a teljesítménye, és majd azok akiknek ez nem elég égethetik 90%-on a procit (ezzel letiltva a P-statek 90%-át is) közel duplázva a fogyasztást. Ugyanis azért vannak ezek az energiagazdálkodási P-statek hogy használjuk őket, üresjáratba nem zabáljon annyit a processzor.

Arra nem tudok választ adni hogy ezen beállításokkal miért nem nyújt elégséges teljesítményt a chip (szarul vannak belőve a P-state stepek? Lassú a kommunikáció vagy a feldolgozási priorítások rosszak?), ezért is van jelenleg ez a sufni-tuning megoltás hogy tekerjük fel a kakaót és gyorsítsuk a parkolási algoritmusokat.

Itt van egy script amivel elő lehet csalogatni a rejtett processzor energiagazdálkodási beállításokat:

[link]

Ez az összes Windows 7-es algoritmus paramétereit engedi felülírni az energiagazdálkodási profil speciális processzorbeállításai alatt:

Windows 10 viszont rendelkezik pár új algoritmussal is amik ebben nincsenek benne. (mivel jelenleg nincs fent virtuális Windows 10-em.)

De ha manuálisan akarsz kutakodni akkor megteheted ezen a reg címen:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00

Ez az adott OS minden beállítását tartalmazza. WinXP és Win10 között

[ Szerkesztve ]

A viszonylag fiatal SpeedShift az a HWP, most a HWC érdekelne, hogy működik-e Razen-en ezekkel a sémákkal (fura ha nem, de főleg AMD-nél sohasem lehet tudni).
Ahogy mondtam, Intel-nél el tudom játszani a "race to idle" módot, tehát hogy csak egy P és egy C1 közt kapcsolgat (mindig vagy max freking pörög, vagy hardware-esen lekapcsol a CPU magról az órája). Arra vagyok kíváncsi, hogy ezek a Ryzen CPU-k mit csinálnak ilyenkor (átváltanak-e C-be, ha fixen max P-t kér tőlük az OS, de épp nincs semmi dolguk, vagy esetleg pörögnek tovább P-ben).

Szóval annyi a hozzáfűzni valóm, hogy alapvetően tetszik, hogy az AMD is "race to idle" szerű módot kínál, csak azt nem értem, hogy miért kapcsolgat akkor mégis két nagyon közeli P közt, illetve hogy ha szerintük ez a stílus (kvázi ki/be-kapcs) a nyerő, akkor miért nem pont így promózták a CPU-kat ahelyett, hogy csilliómillió P-state így meg úgy...

[ Szerkesztve ]

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Nem tudok választ adni erre. Az az igazság, hogy hardveresen szinte mindent meg lehet csinálni, viszont szoftveresen főleg pár windowsos regedit paraméteren keresztül már nem biztos. Ezek a paraméterek egyedül a CPU saját ütemezési folyamatát befolyásolják ezek 100%-osan szoftveres kernel módban (vagy akár még kernelnél is valamivel nagyobb prioritással) futó időzítő/időzített algoritmusok.

Amiket ez az energia profil változtat a teljesítménycentrikus sémához képest:

1. Processor Performance Increase Threshold: 30% -> 25%
Az a processzor használat ami felett a processzor egy magasabb teljesítményű P-state-be kapcsol.

2. Processor Performance Decrease Threshold: Maradt ugyanaz.

3. Processor Performance Core Parking Increase Time: 7 -> 1
Ennyiszer X ms időnek kell eltelnie mielőtt egy aktív mag parkolóvá válhat.

4. Processor Performance Time Check Interval: Maradt ugyanaz.

5. Minimum Processor State: 100% - 90%

6. Processor performance core parking concurrency headroom threshold: 20 -> 10
A minimális határérték aminek egyszerre teljesülnie kell minden aktív magon hogy egy éppen parkoló mag felébredjen.

[ Szerkesztve ]