- Samsung Galaxy S24 - nos, Exynos
- Poco X6 Pro - ötös alá
- Alkalmazásbemutató: Keep
- Futott egy Geekbench kört egy új HTC készülék
- Azonnali mobilos kérdések órája
- Apple AirPods Pro (2. generáció) - csiszolt almaságok
- Huawei Mate 10 Pro - mestersége az intelligencia
- Vodafone-ra áttért Digi Mobilosok
- Xiaomi Mi 11 Ultra - Circus Maximus
- iOS alkalmazások
Hirdetés
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Megjelenési dátumot kapott a Star Wars: Hunters
gp A tervek szerint június elején végre befut a teljes kiadás mobilokra/tabletekre és Nintendo Switch-re.
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
-
Mobilarena
Új hozzászólás Aktív témák
-
Tyrel
őstag
válasz Dyingsoul #7523 üzenetére
A fagyásokra én még mindig azt tudom mondani amit korábban is: feszültség, azon belül is jó eséllyel VDrop probléma.
A min. CPU perf. levétele 15%-ra valószínűleg azért befolyásolja negatívan, mert kb. ezzel engeded meg a processzornak hogy alacsonyabb PState-ekre lépjen, amikor ugye visszaveszi az órajelét és feszültségét. Ha a feszültség szabályzással amúgy is gondok vannak, akkor ha engeded hogy azt még dinamikusan változtatgatni is próbálja, az nyilván ront rajta.Pl. visszaveszi magát a CPU 2200MHz-re meg ilyen 0,75V körüli feszültségre. Hirtelen csinálsz valamit, nem kell nagy dolgot, mondjuk megnyitod a böngésződet. Ezzel felugrik az órajel, és azt közvetlenül kéne követnie a feszültségnek is, itt egyszer számít a VRM "transient response" ideje, vagyis hogy milyen gyorsan tudja felvenni az új állapotokat. Lehet hogy már ez is késik egy kicsit, de önmagában valószínűleg még nem lenne probléma, viszont ha ez mellé még gyenge is és az LLC-vel sincs kicsit kompenzálva, akkor erre a késésre rá jön még egy VDrop is. Most így hirtelen nincs időm erre példákat keresni de Gamers Nexus és Buildzoid YT csatornáin vannak videók amikben magyarázzák ezt - jó eséllyel a CPU fagyival jutalmazza.
A Load Line Calibration egyébként nem varázslat, csak simán egy szoftveres megoldás, kb. ugyan azt csinálja mint a feszültség Offset, csak míg az Offset a processzor VID táblájához vagy a fixen beállított feszültséghez képest egy fix eltérést határoz meg, addig az LLC a terhelés függvényében dolgozik. Pl. üresjáratban nem csinál semmit se, magas terhelésnél meg ráad mondjuk + 0,03V-ot az egyébként óhajtott értékre, hogy a VDrop-ot ellensúlyozza.
Visszatérve a fagyásokra, próbáld erősebbre venni az LLC-t, ha nincs akkor a CPU VID Offset-et tekerd kicsit feljebb, ha az sincs akkor lőjj valami olyan fix feszültséget amin biztosan mennie kell... pl. 40x / 1,35V sztem nem kéne hogy gondot okozzon sehol se.
Ha ilyen probémának akarsz utána járni felejtsd el az itt nagyon menő "úúú 23723 órát futott az IBT Übercharge módban" marhaságokat, ne konstans terheléssel teszteld hanem folyamat cincáld a bajszát, mintha egy autónak adnál gázfröccsöket. Akár egy egyszerű Cinebench is jó, mert az gyorsan lefut. Sokszor futtasd egymás után, elindít, megáll, elindít, megáll, és így tovább. Valószínűleg sokkal biztosabban elő fogod tudni hozni vele a random fagyásaidat, és ha már tudod reprodukálni úgy könnyebb orvosolni is.
--------
A fura megakadások valószínűleg valamelyik háttértár hibájából fakadnak. Ha így beakad a gép és ugyan azt a ~200ms hangmintát ismételgeti, akkor ha véglegesen így marad (értsd. lefagyott) az jó eséllyel valami driver probléma, vagy alapvető stabilitási gondból fakad (CPU/RAM gondok)... viszont ha egy pillanattal később felébred és megy tovább mintha mi sem történt volna, akkor nagy valószínűséggel csak I/O-ra várt. Bármelyik meghajtón is van az operációs rendszer és a Temp / swap cuccok, az lehet a legesélyesebb.
Esetleg az energiagazdálkodásnál tiltsd meg neki hogy leállítsa a meghajtókat, hátha úgy nem jön elő, bár ha magával az egyik meghajtó vezérlőjével van gond, azon ez nem fog segíteni.
[ Szerkesztve ]
Turenkarn