Új hozzászólás Aktív témák
-
Nálam szerencsémre még nem volt gond a 8600K-val 7C, majd 80-as ucode-on se (bár előbbi csak pár napig futott az UEFI frissítés után, azóta egy driver tölti be a 80-ast, hogy az is megjelent) Windows-al, ahogy a G4400-el C2 ucode-on Linux-al se (utóbbi 24/7 megy, a Linux kernel töltötte be a microcode-ot, EUFI frissítés nincs).
[ 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."
-
#43
janos666
nagyúr
Massmurderer
#41
válasz
Massmurderer
#41
üzenetére
Azért számolj utána, hogy leromlik-e AMD szintre ettől az Intel, vagy nem.
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."
-
válasz
#16939776
#95
üzenetére
Ezt most komolyan gondolod, vagy viccelődsz?
Bár az tény, hogy a 2500K-t élete nagyobb részében "race to idle" módban használtam (tehát csak a C1E volt aktív, a magasabb C szintek és a SpeedStep tiltva voltak), mert enélkül idle-ben is viszonylag erősen fűtötte a vizet/radiátort, ha kihajtottam belőle a maximális órajelben, amit lehetett és elbírt a hűtés terhelés alatt (magyarul szét volt feszelve a tuning miatt, és így viszonylag sokat fogyasztott idle is, ha nem volt engedélyezve a C1E).
A 8600K-n pedig már a C1E-t is letiltottam (és persze ugyan így minden más C szintet és SpeedStep, illetve SpeedShift is OFF), mert ez a maximálisan kisajtolható órajelhez tartozó feszültséggel sem fűt már olyan durván, mint a sok évvel korábbi elődje (csak annyit fogyaszt feleslegesen sokat idle-ben, ami már nem tud zavarni, nem olyan nagy szám, mint a 2500K-nál volt, "nem izzaszt").
Az talán tényleg kicsit gáz, hogy ahány CPU kisgeneráció, annyiféle újabb és újabb C és P állapot és kezelési séma, persze mind alapértelmezésben engedélyezve az UEFI Setup-ban még az enthusiast és "gamer" orientált alaplapoknál is, mert jujjnehurrdurrpurrfurr, ha valami tesztben egyik lapban pár wattal többet eszik a gép, ettől fog leolvadni az északi sarok a Föld csúcsáról és billen ki a tengelyéből, ha az eltűnik....
Sőt, mai napig kb. csak a SpeedShift-et látom alapértelmezésben tiltva, a SpeedStep viszont mindig aktív, pedig előbbi sokkal jobb, ha már használjuk valamelyiket.
A nagyobb gond viszont szerintem "játéksimaság" tekintetben még mindig agrafikus API-ban (főleg DirectX 11) és grafikus motorokban van, amik egyre nagyobb lagot engedtek meg maguknak (queue lenght), és ettől érezzük mostanában "dadogósnak" a játékokat, mikor magas átlag fps mellett hirtelen rátunk az egéren. Vagy az történik, hogy már rántjuk az egeret, de még mindig csak a bufferelt dolgokat látjuk történni, vagy pedig eldobja a buffert, de akkor meg pontszerűen ott leesik a teljesítmény (ha mindig alacsony queue lenght-el menne, akkor alacsony lenne az átlag fps, és ilyenkor ezt tapasztaljuk meg abban a pillanatban, a pontszerűen alacsony teljesítményt). De ez csak az én laikus teóriám.
[ 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."
-
válasz
#16939776
#118
üzenetére
Linkelhetnéd egy régebbi hsz-ed másik topic-ból, ha már belementél valahol, valamikor.
Valami nagyon hasonlót én is megfigyeltem az évek során, de végül csak visszalukadtam oda, hogy ha feltelepítek egy öreg Half-Life 2-t, abban nem érzem azokat a problémákat 60Hz-en 60fps-el sem, amit a "modern" játékokban (Frostbite3 és más DX11 kortársai) akár 120Hz-en >60fps-el, inkább tűnik úgy, hogy a szoftver oldal vette el a konzisztensen alacsony késést és azt a "közvetlenség" érzést, ami ~10 éve még megvolt (plusz olyasmik, hogy a CS 1-et még analóg CRT-n játszottuk, amihez csak a Gsync kerül közel, de olyanom pl. nekem sincs, mert most TV-n játszom, ami kapásból ~21ms lag ---- igaz, áttértem FPS-ről RPG-re, csak az a baj, hogy még abban is zavar néha a "közvetlenség+simaság" hiánya, mikor pl. DAI-ban barangoltam, az agyamra akart néha menni, pedig FPS-t is csinálnak ezzel a motorral). És akkor olyanokat még nem is említettem, mint a Unity Engine, ami szerintem sétálószimulátorokhoz sem elég jó csúcsgépeken se.
[ 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."
-
A microcode-ot az OS is tudja frissíteni, illetve teszi is. Linux-on meg is kapod az összes CPU-ra az összes hivatalos verziót, csak a Windows bán ezzel konzervatívan és szelektíven, szóval egyszerűen csak a Windows-t kéne fejleszteni annyival, hogy a Windows Update letölti a teljes microcode katalógust az Intel-től és AMD-től, ahogy a Linux is, és alapértelmezésben frissít minden kompatibilis CPU-t, amihez van a katalógusban frissítés (jelenleg csak néhány CPU-t frissít magától a Window, ott is egy bizonyos verzióra, ami már javít egy-egy specifikus hibát, nem próbál minél több CPU-hoz és minél frissebb ucode verziókkal operálni).
Ha ez nem is történik meg, akkor sem lepne meg, ha majd némi késéssel most egyszer belelapátolná az összes elérhető microcode-ot a Windows-ba a Microsoft, amik a biztonsági frissítéshez kellenek, akkor is ha később nem frissítik őket tovább (és kihagyják a CPU-kat, amikre van frissítés, de nem pont erre a problémára való).
Az alaplap verziója csak akkor érdekes, ha már az OS betöltését is érintheti a bug, amit a microcode javít (a Linux kernel tud olyat, hogy korai frissítés, tehát ez az egyik legelső dolog, amit boot közben csinál, de az alaplap nyilván még ettől is korábban be tudja tölteni...).
[ 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."
-
válasz
Kékes525
#173
üzenetére
Linux-ra szerintem elég felületes és potenciálisan mindkét irányba félrevezető lehet az az ellenőrző script, mert ahogy nézem, lényegében csak a debugfs-t olvassa ki, hogy az mit mond/gondol a Spectre védelmekről.
Nálam pl. jelenleg a 4.14.14-gentoo kernel fut (GCC 7.2.0-r1 p1.1 fordítóval született), a build config-ban engedélyezve van a két új védelmi opció (PTI és ratpoline is) és a boot legelején betöltődik a C2-es microcode a SkyLake alapú Pentium G4400-ba, de ...
1: egyrészt onnan indul a dolog, hogy alapjáraton le volt nálam tiltva a debugfs, így nem is lepődtem meg (miután vetettem egy nagyon gyors és felületes pillantást a script tartalmára), hogy positive (=sérülékeny) az ellenőrzés eredménye Spectre V1 és V2-re, csak Meltdown-ra mondja, hogy OK (pusztán mert engedélyezve van a PTI).
2: kizárólag emiatt engedélyeztem a debugfs-t (újraforgattam és reboot), de ugyan ezt mondja, de szerintem csak az a baj, hogy a gentoo patchset nem teszi ki oda a debugfs-be ezeket a file-okat, ahogy a Debian patchset (és más disztrók, amik a Debian-ra alapulnak, vagy onnan kölcsönözték 1:1 a patch-eket), itt csak az upstream kernel kód játszik.
De lehet, hogy tévedek és már én is összekeverem a dolgokat, hogy a három probléma közül melyikhez pontosan mi kell (software és/vagy compiler és/vagy microcode --- különböző együttállásokban), lehet hogy nekem kell majd még a GCC 7.3 is a kétféle Spectre-hez és a microcode illetve kernel kód csak a Meltdown ellen jók.
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
ph A vállalat szerint szinte minden hardver érintett, de már érkezik a javítás.
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen