Hirdetés
- Lassan állítjuk a fát, és a hardverek is be vannak csomagolva
- Klasszikus kínai festmények ihlették a Colorful legfrissebb memóriáinak külsejét
- Ultrakompakt Key E SSD-vel jelentkezett a Silicon Power
- Mesterséges intelligenciára kihegyezett mini PC jött az ASUS műhelyéből
- ASUS blog: ExpertBook P5 notebook, a munkagép
Új hozzászólás Aktív témák
-
Resike
tag
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 ]
-
janos666
nagyúr
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."
-
Resike
tag
Itt van egy script amivel elő lehet csalogatni a rejtett processzor energiagazdálkodási beállításokat:
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 ]
-
Resike
tag
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.
-
janos666
nagyúr
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."
-
Resike
tag
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 ]
-
janos666
nagyúr
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.
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
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."
-
#13
MittuDomain_
őstag
MittuDomain_
őstag
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.
-
#12
tibcsi0407
félisten
E.Kaufmann
#11
tibcsi0407
félisten
válasz
E.Kaufmann
#11
üzenetére
Nem verziószámokról szól ez a történet.
Az csak a hab a tortán.utdetailing.hu
-
#11
E.Kaufmann
veterán
tibcsi0407
#9
E.Kaufmann
veterán
válasz
tibcsi0407
#9
üzenetére
Még a 9x-es termékcsaládra el is süthették ezt a poént, mert igazuk volt. De az NT kernel térnyerése óta már nem olyan jó vicc.
Egyszerűen volt az NT5 (2000/XP/2003) különböző szerepkörökkel majd jött az NT6 (Vista/7/8/2008(R2)/2012) különböző szerepkörökkel és témákkal, és hiába mondták, hogy ez már az NT10 (Win10/2016) valójában még az NT6-nál tartunk. De a Linux kernelnél is viccesen cserélgették a verziószámot a 2.6 után.[ Szerkesztve ]
Le az elipszilonos jével, éljen a "j" !!!
-
azbest
félisten
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 ]
Az csak a hab a tortán.
?
Új hozzászólás Aktív témák
Hirdetés
ph A 17.10-es meghajtót, minden Ryzen processzorral rendelkező felhasználónak érdemes telepítenie.
- iPhone topik
- Asszociációs játék. :)
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Kínai és egyéb olcsó órák topikja
- Digitális Állampolgárság Program DÁP
- PlayStation 5
- Vivaldi (böngésző)
- Feháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasgatni
- Milyen GPS-t vegyek?
- SSD kibeszélő
- További aktív témák...
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Axon Labs Kft.
Város: Budapest