Keresés

Hirdetés

Új hozzászólás Aktív témák

  • janos666

    nagyúr

    LOGOUT blog

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

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz #65675776 #14 üzenetére

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz #65675776 #20 üzenetére

    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. :N

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Resike #23 üzenetére

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Resike #25 üzenetére

    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."

Új hozzászólás Aktív témák