Hirdetés

2019. október 16., szerda

Gyorskeresés

Hozzászólások

(#1) Bici


Bici
(nagyúr)

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

Keresek AMD A10-7890K APU-t.

(#2) apa111 válasza Bici (#1) üzenetére


apa111
(aktív tag)

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

(#3) kromatika


kromatika
(veterán)

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.

Korg DS DAC 100M,és AKG 712 Pro eladó

(#4) t72killer


t72killer
(félisten)
LOGOUT blog

Linux?

"A win98 biztonságos, ui már vírust sem írnak rá 10 éve."

(#5) 5150 válasza t72killer (#4) üzenetére


5150
(aktív tag)

Az mi?

https://youtu.be/4MYJ9nrBeoY

(#6) t72killer válasza 5150 (#5) üzenetére


t72killer
(félisten)
LOGOUT blog

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

"A win98 biztonságos, ui már vírust sem írnak rá 10 éve."

(#7) azbest válasza t72killer (#4) üzenetére


azbest
(nagyúr)

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 ]

(#8) MongolZ válasza t72killer (#6) üzenetére


MongolZ
(addikt)

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

(#9) tibcsi0407 válasza MongolZ (#8) üzenetére


tibcsi0407
(félisten)

Egy Linuxos szemében sosem lesz az.
Egyébként, ha tehetném én is inkább Linux alatt dolgoznék, de a programjaim Windows only-k...

[ Szerkesztve ]

Asrock X370 Taichi - Ryzen 7 1800X -Corsair DDR4-3200C16 Vengeance LPX 16 GB (2 x 8 GB) - Coolermaster Masterliquid 240 - 250GB Samsung 960 Evo Nvme - GIGABYTE GV-N1080G1 GAMING-8GD - Netgear R7800 - Huawei P30 Pro 8/256 Aurora blue

(#10) t72killer válasza MongolZ (#8) üzenetére


t72killer
(félisten)
LOGOUT blog

A 7 az, a többit vitatnám:R

"A win98 biztonságos, ui már vírust sem írnak rá 10 éve."

(#11) E.Kaufmann válasza tibcsi0407 (#9) üzenetére


E.Kaufmann
(őstag)

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 ]

(#12) tibcsi0407 válasza E.Kaufmann (#11) üzenetére


tibcsi0407
(félisten)

Nem verziószámokról szól ez a történet. :) Az csak a hab a tortán.

Asrock X370 Taichi - Ryzen 7 1800X -Corsair DDR4-3200C16 Vengeance LPX 16 GB (2 x 8 GB) - Coolermaster Masterliquid 240 - 250GB Samsung 960 Evo Nvme - GIGABYTE GV-N1080G1 GAMING-8GD - Netgear R7800 - Huawei P30 Pro 8/256 Aurora blue

(#13) MittuDomain_


MittuDomain_
(senior tag)

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.

(#14) daa-raa


daa-raa
(titán)

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.

Vannak olyan fallal körülvett városok, melyeket nem szabad megostromolnod. - Szun-ce XL

(#15) MZperX75


MZperX75
(addikt)

Ryzen5 teszt jöhetne,szívesen olvasgatnám a hétvégén.
Meg persze a jó sok komentet.... :DDD
Valaki ?

Jó munkához idő kell.....

(#16) janos666


janos666
(nagyúr)

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

(#17) htc07 válasza janos666 (#16) üzenetére


htc07
(addikt)

novemberig nem jön új. :DDD

(#18) Fionn válasza htc07 (#17) üzenetére


Fionn
(tag)

😁

(#19) janos666 válasza daa-raa (#14) üzenetére


janos666
(nagyúr)

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 ]

(#20) daa-raa válasza janos666 (#19) üzenetére


daa-raa
(titán)

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

Vannak olyan fallal körülvett városok, melyeket nem szabad megostromolnod. - Szun-ce XL

(#21) janos666 válasza daa-raa (#20) üzenetére


janos666
(nagyúr)

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.

(#22) Resike válasza daa-raa (#20) üzenetére


Resike
(tag)

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.

(#23) Resike válasza Resike (#22) üzenetére


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 ]

(#24) janos666 válasza Resike (#23) üzenetére


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.

(#25) Resike válasza janos666 (#24) üzenetére


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.

(#26) Resike válasza Resike (#25) üzenetére


Resike
(tag)

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 ]

(#27) janos666 válasza Resike (#25) üzenetére


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 ]

(#28) Resike válasza janos666 (#27) üzenetére


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 ]

Copyright © 2000-2019 PROHARDVER Informatikai Kft.