Tady právě veškeré zákonitosti typu tohle nastav na čtyřnásobek tohohle končí, bohužel. Ještě u tRRD_L/RRD_S a tWTR_L/WTR_S jde najít nějaký vztah/pravidlo, ale zbytek už je více méně pokus omyl.
Našel jsem na netu tohle https://uploads.disquscdn.com/images/94 ... 50bf30.jpg jede na nižší frekvenci, ale můžeš porovnat časování.
tRFC ještě můžeš zkusit snížit. Klidně bych zkusil něco jako 312.
tREFI označuje, jak často se koná tRFC, je to jediné časování, které pro nejvyšší výkon musí být co nejvyšší. Ale nejsem Ti schopný říct, kde by se mělo pohybovat.
tWTR_L by se mělo pohybovat na cca trojnásobku tWTR_S. Nevím, jak moc půjdou snížit, ale 15 u _L a 5 u _S by mělo být stabilní, dost možná se dostaneš níž, třeba na 13 a 4.
tRRD_S by mělo být na cca ⅔ tRRD_L. Tudíž bych tRRD_S zkusil srazit na 8/7/6. Až najdeš nejnižší tRRD_S, tRRD_L bych potom zkusil srazit na 9, možná 8. Spolu s tRRD_S pak můžeš zase poupravit tFAW.
tRTP bych zkusil 12. To by mohlo být stabilní.
tCWL by mohlo jít na 16/15/14 - to bych vyzkoušel až na konci, jeho úpravou moc nezískáš (můj odhad).
U tCKE si nejsem jistý, jak se chová. Častokrát se doporučuje 8 (které máš nastavené), 6 a 4, ale mně bez problému funguje 1.
Zvýšení o 1000MB/s je poměrně dost, třeba se podaří přidat ještě pár dalších 1000MB/s propustnosti, a pak už budeš o 3000-5000MB/s výše.
Vzhledem k tomu, že vyšší napětí nepomáhá, buď protestuje řadič (podle mě méně pravděpdobné) nebo se při vysokých napětích špatně nastavuje nějaké poddružné napětí - teď nevím, jak se to napětí jmenuje, ale desky ho často nastavují 1:2 vzhledem k napětí RAM. Tudíž pokud má tvoje RAM to napětí ráda třeba okolo 0,750V, dostane ho i spolu s 1,5V hlavním napětím. Ale pak když zvedneš napětí na 1,8V, vedlejší efekt bude zvednutí toho druhého napětí na 0,900V, což už se RAM nelíbí. Vzhledem k tomu, že se to děje jen při vysokých napětích, asi to můžeme ignorovat.
VCCST popravdě nemám ponětí. VCCPLL je jedno z těch druhotných napětí, jde buď do RAM nebo do paměťového řadiče (spíše si myslím, že jde do RAM, ale jsem teď na mobilu a nechce se mi to dohledávat). Pokud si dobře pamatuju, VCCPLL by mělo mít nějaký vliv na přetaktování, ale každý čip má rád jinou úroveň VCCPLL.
To nevím, jestli hry potřebují větší zápis nebo čtení. Asi bych si tipnul čtení, ale nemám to nijak podložené/vyzkoušené.
Dej sem fotku terciálních časováních, pokud tu už někde není a přehlédl jsem ji.
Taktování RAM - DDR4 G.SKILL
Re: Taktování RAM - DDR4 G.SKILL
Aha, ok.
Můžu zkusit podle něj + podle tvého doporučení. (Ale Command Rate 1 mi nenabootuje).
Ono to jde měnit i za jízdy ty časování, přes tu aplikaci? Ale co jsem tak koukal, tak je to aplikace přímo od Asusu a asi to jde jen na některých Asus deskách.
https://rog.asus.com/articles/overclock ... it-scores/
Víc jsem nehledal, ale to mi zas tak nevadí, stejně tohle radši měním přímo v Biosu.
--------------------
Ale včera jsem nechal Linpank běžet delší dobu s tRFC 321, pak 400 a u obojího error po cca 3,5 hod.
Předtím jsem to tak dlouho testovat nenechával. Naposled jsem ale nechával projížděl Small i Large data na 24 hod. a úspěšně, jenže to ještě byla RAM na 1,4V a časování výchozí, asi bych zkusil zvýšil VCCIO a SA z 1,25V na 1,3V, jestli to bude ok, nebo ne. Abych zjistil, co to způsobuje, než budu ladit dál, jestli to není už RAM sama o sobě.
Nvm, jestli by error třeba neodhalil přímo MemTest rychleji, než OCCT Linpack, ale pokud je slabé VCCIO/SA je to mezi komunikací s CPU, ne přímo v RAM, takže nvm.
------------------------
Hm, tak to by mohlo být tím, co způsobovalo ty pády při vyšších V, ale otázka je, jestli mám možnost tohle napětí vůbec někde regulovat, všechny ty napětí VCCxxx by měly ovlivňovat/napájet CPU a jeho podčásti + komunikaci s ostatními částmi, ale přímo a pouze RAM podle mě ne. Ale to řešit nemusíme, děje se to jen při 1,75V+ a to je stejně jen pro testy, jen mě to zajímalo spíš technicky, protože mi přišlo divný, že to při vyšším napětí crashuje rychleji, než při nižším.
Je tam ale taky ještě dalších 5 napětí, ovšem už tam u nich nejsou ukázaný aktuální hodnoty:
------------------------
Zkusil jsem najít VCCST s PLL přímo v datasheetu od Intelu pro 8th generaci i7. A našel jsem:
VCCST - Sustain voltage for processor standby modes - takže by to asi mělo ovlivňovat napětí v CPU v idle, nebo něco v tom symslu. Nejsem si jist, jestli to tak chápu přesně správně, každopádně automatika tam dříve dávala o 0,1V více - před flashem biosu.
Ještě jsem našel čerstvý dotaz - starý 6 dnů:
https://www.reddit.com/r/intel/comments ... y_voltage/
Asi by to nemělo mít moc na nic vliv.
VCCPLL - Je v datasheetu sice taky, ale žádnou přesnou definici jsem se tam nikde nějak nedočetl, co by to vlastně mělo dělat, našel jsem pár odkazů, ale staršího data, netýká se to tedy Coffee Laku, takže některý detaily je třeba brát s rezervou.
Píše se: (2011) VCCPLL: Voltage used by the CPU clock multiplier (PLL, Phase-Locked Loop). This voltage can be changed through an option called “CPU PLL Voltage.”
(zdroj: http://www.hardwaresecrets.com/understa ... erboard/4/)
Takže by to asi mělo krmit násobič v CPU.
---------
2012:
This is the voltage used by the clock multiplier circuit inside the CPU
copied from rgone in another post
CPU Phase Locked Loop (PLL)
The default PLL voltage is 1.8 V, and Intel’s absolute maximum for this is 1.98 V, but you shouldn’t need to get anywhere near that. Intel’s new i7, i5, and i3 CPUs don’t require much of an increase in PLL, so you can probably get by increasing it to at most 1.9 V
Alot of Ivy Bridge actually like around 1.5 - 1.7 on the PLL voltage for improved clocking. Especially memory clocking.
this is from overclockers.co.uk
from masterslayer.com
CPU Phase Locked Loop (PLL)
This option can be used to stabilize the CPU at high BCLKs. Some people need to change this, and some don’t. You may need to start increasing this once you get to a BCLK of around 180 – 200.
The default PLL voltage is 1.8 V, and Intel’s absolute maximum for this is 1.98 V, but you shouldn’t need to get anywhere near that. Intel’s new i7, i5, and i3 CPUs don’t require much of an increase in PLL, so you can probably get by increasing it to at most 1.9 V.
weird some contradicting data google gives me
(Zdroj: http://www.overclockers.com/forums/show ... voltage-do)
---------
Taky 2012, prý vyjádření přímo od Intelu:
CPU PLL Voltage Override (Overvoltage): What the Heck does it do?
So I asked that question to an Intel Overclocking Engineer his explanation was roughly: We went through the BIOS settings trying to find setting that if changed could help overclock our CPUs further. We came across this setting. Think of the CPU PLL voltage as a voltage that is provided to the CPU, but then “clipped” down to an approximate voltage. No matter what that input is whether 1.3v or 1.9v it is clipped (hypothetically let’s say 800mv after clipping (he didn’t say how much)) that way other devices can use the PLL voltage and clip to what they need. The CPU PLL Overvoltage allows for less clipping of that voltage. It can also reduce the lifespan of the CPU, but nothing noticeable.
So those of you who think that increasing your PLL voltage will help with that setting, it really doesn’t.
(Zdroj: http://www.overclock.net/forum/5-intel- ... ltage.html)
--------------------------
Takže obojí asi nemá smysl moc řešit/měnit, ani nevím, jaký by u Coffee Lake měly být max. doporučený provozní hodnoty těchto napětí. U toho VCCIO a VCCSA, vím, že by mělo být do 1,35V.
--------------------------
Jo a ještě terciální jsou zde:
Můžu zkusit podle něj + podle tvého doporučení. (Ale Command Rate 1 mi nenabootuje).
Ono to jde měnit i za jízdy ty časování, přes tu aplikaci? Ale co jsem tak koukal, tak je to aplikace přímo od Asusu a asi to jde jen na některých Asus deskách.
https://rog.asus.com/articles/overclock ... it-scores/
Víc jsem nehledal, ale to mi zas tak nevadí, stejně tohle radši měním přímo v Biosu.
--------------------
Ale včera jsem nechal Linpank běžet delší dobu s tRFC 321, pak 400 a u obojího error po cca 3,5 hod.
Předtím jsem to tak dlouho testovat nenechával. Naposled jsem ale nechával projížděl Small i Large data na 24 hod. a úspěšně, jenže to ještě byla RAM na 1,4V a časování výchozí, asi bych zkusil zvýšil VCCIO a SA z 1,25V na 1,3V, jestli to bude ok, nebo ne. Abych zjistil, co to způsobuje, než budu ladit dál, jestli to není už RAM sama o sobě.
Nvm, jestli by error třeba neodhalil přímo MemTest rychleji, než OCCT Linpack, ale pokud je slabé VCCIO/SA je to mezi komunikací s CPU, ne přímo v RAM, takže nvm.
------------------------
Hm, tak to by mohlo být tím, co způsobovalo ty pády při vyšších V, ale otázka je, jestli mám možnost tohle napětí vůbec někde regulovat, všechny ty napětí VCCxxx by měly ovlivňovat/napájet CPU a jeho podčásti + komunikaci s ostatními částmi, ale přímo a pouze RAM podle mě ne. Ale to řešit nemusíme, děje se to jen při 1,75V+ a to je stejně jen pro testy, jen mě to zajímalo spíš technicky, protože mi přišlo divný, že to při vyšším napětí crashuje rychleji, než při nižším.
Je tam ale taky ještě dalších 5 napětí, ovšem už tam u nich nejsou ukázaný aktuální hodnoty:
------------------------
Zkusil jsem najít VCCST s PLL přímo v datasheetu od Intelu pro 8th generaci i7. A našel jsem:
VCCST - Sustain voltage for processor standby modes - takže by to asi mělo ovlivňovat napětí v CPU v idle, nebo něco v tom symslu. Nejsem si jist, jestli to tak chápu přesně správně, každopádně automatika tam dříve dávala o 0,1V více - před flashem biosu.
Ještě jsem našel čerstvý dotaz - starý 6 dnů:
https://www.reddit.com/r/intel/comments ... y_voltage/
Asi by to nemělo mít moc na nic vliv.
VCCPLL - Je v datasheetu sice taky, ale žádnou přesnou definici jsem se tam nikde nějak nedočetl, co by to vlastně mělo dělat, našel jsem pár odkazů, ale staršího data, netýká se to tedy Coffee Laku, takže některý detaily je třeba brát s rezervou.
Píše se: (2011) VCCPLL: Voltage used by the CPU clock multiplier (PLL, Phase-Locked Loop). This voltage can be changed through an option called “CPU PLL Voltage.”
(zdroj: http://www.hardwaresecrets.com/understa ... erboard/4/)
Takže by to asi mělo krmit násobič v CPU.
---------
2012:
This is the voltage used by the clock multiplier circuit inside the CPU
copied from rgone in another post
CPU Phase Locked Loop (PLL)
The default PLL voltage is 1.8 V, and Intel’s absolute maximum for this is 1.98 V, but you shouldn’t need to get anywhere near that. Intel’s new i7, i5, and i3 CPUs don’t require much of an increase in PLL, so you can probably get by increasing it to at most 1.9 V
Alot of Ivy Bridge actually like around 1.5 - 1.7 on the PLL voltage for improved clocking. Especially memory clocking.
this is from overclockers.co.uk
from masterslayer.com
CPU Phase Locked Loop (PLL)
This option can be used to stabilize the CPU at high BCLKs. Some people need to change this, and some don’t. You may need to start increasing this once you get to a BCLK of around 180 – 200.
The default PLL voltage is 1.8 V, and Intel’s absolute maximum for this is 1.98 V, but you shouldn’t need to get anywhere near that. Intel’s new i7, i5, and i3 CPUs don’t require much of an increase in PLL, so you can probably get by increasing it to at most 1.9 V.
weird some contradicting data google gives me
(Zdroj: http://www.overclockers.com/forums/show ... voltage-do)
---------
Taky 2012, prý vyjádření přímo od Intelu:
CPU PLL Voltage Override (Overvoltage): What the Heck does it do?
So I asked that question to an Intel Overclocking Engineer his explanation was roughly: We went through the BIOS settings trying to find setting that if changed could help overclock our CPUs further. We came across this setting. Think of the CPU PLL voltage as a voltage that is provided to the CPU, but then “clipped” down to an approximate voltage. No matter what that input is whether 1.3v or 1.9v it is clipped (hypothetically let’s say 800mv after clipping (he didn’t say how much)) that way other devices can use the PLL voltage and clip to what they need. The CPU PLL Overvoltage allows for less clipping of that voltage. It can also reduce the lifespan of the CPU, but nothing noticeable.
So those of you who think that increasing your PLL voltage will help with that setting, it really doesn’t.
(Zdroj: http://www.overclock.net/forum/5-intel- ... ltage.html)
--------------------------
Takže obojí asi nemá smysl moc řešit/měnit, ani nevím, jaký by u Coffee Lake měly být max. doporučený provozní hodnoty těchto napětí. U toho VCCIO a VCCSA, vím, že by mělo být do 1,35V.
--------------------------
Jo a ještě terciální jsou zde:
MB: ASROCK Fatal1ty Z370 Gaming K6 CPU: Intel Core i7-8700K @ 5,1GHz/4,9 AVX/4,6 cache; 1,41V Delid FAN: NZXT Kraken X62 RAM: G.SKILL 2x8GB DDR4 3800MHz @ CL16 TridentZ 1,5V GPU: Zotac GTX 1080Ti AMP Extreme Core Edition (11GB) SSD: Samsung 960 EVO 500GB, 850 EVO 500GB, 840 EVO 120GB HDD: WD Blue 2x4TB PSU: Corsair RM850i Case: Fractal Design Define R6 Black TG Monitor: BenQ XL2411Z
Re: Taktování RAM - DDR4 G.SKILL
MemTweakIt uměl upravovat časování ve Windows někdy v dobách Ivy Bridge, na čemkoliv novějším než Skylake už pouze zobrazuje některá časování (na to existují lepší programy, MemTweakIt zobrazuje poměrně málo časování).
Měnit časování ve Windows podle mě stejně není dobrý nápad. Když se to provede v BIOSu, systém se restartuje a CPU provede trénování RAM - paměťový řadič prakticky zkouší různé kombinace časování (takových, které ani v BIOSu nejsou dostupné) pro ideální stabilitu a výkon. V momentě, kdy se změní časování pamětí ve Windows, neproběhne trénování RAM a jedno z těch nepotřebných časování, které nastavuje řadič, může začít dělat problém protože nebylo správně nastaveno vzhledem k té změně.
Když tRFC 400 i 312 dávají cca stejně chyb, nebude chyba v tRFC (tudíž můžeš nechat těch 312, popřípadě ještě zkusit snížit - možná 280?).
Zjistit, které časování způsobuje tu chybu, je skoro nemožné - musel by jsi postupně zvedat a testovat všechny časování které jsi nějak upravil. A vzhledem k tomu že se ta chyba objevuje až cca po 3,5h, chtělo by to spoustu času.
Šel bych na to opačnou cestou, kterou jsi psal - zvýšit stabilitu RAM tak, aby to časování už bylo stabilní a nedělalo problém. Nejideálnější kandidáti jsou právě VCCIO a SA - zkus s nimi trochu pohýbat nahoru i dolů (bohužel u RAM není vždy vyšší napětí lepší).
V neděli/pondělí budu doma, pošlu Ti, jak jsem cca před půl rokem testoval vliv CLDO_VDDP na stabilitu RAM - tohle napětí hýbe se stabilitou nahoru a dolů jak chce, na 0,900V můžeš mít 2 chyby a na 0,905V můžeš mít 15 chyb. Dá ti to nějakou představu, jak se SA a IO chovají - ty sice nejsou tak extrémní že by skákali nahoru a dolů, ale mají svůj sweet spot který není jednoduché najít a když ho přestřelíš tak dělají problém.
K rychlosti objevování chyb - sám jsem to nijak netestoval, ale podle Elmora (inženýr z Asusu) a dalších inženýrů chyby v RAM nejrychleji objevuje StressAppTest. Původně to byl interní program Googlu na testování stability RAM pro všechny jejich servery (to podle mě svědčí o tom, že za něco stojí), a pravděpodobně ho stále používají. Jediný problém je, že běží pouze pod Linuxem. Mně se ho nepodařilo rozchodit ve Windows s nainstalovaným Ubuntu z MS Store (tohle doporučovali inženýři z Asusu na rozchození pod Windows), ale když jsem nabootoval Mint z flashky, fungoval StressAppTest bez problému (právě přes něj jsem testoval vliv CLDO_VDDP).
Často se pak doporučuje Memtest HCI, který používá spousta profi Overclockerů a inženýrů (když třeba G.Skill demonstroval stabilitu jejich 4800MHz RAM kitu, stress testovali právě skrz Memtest HCI) http://hcidesign.com/memtest/download.html funguje normálně ve Windows, otevřeš tolik oken kolik má tvoje CPU vláken (i s HT, tedy 12) a každému oknu nastavíš kolik RAM má projet. Prvním 11 nastavíš třeba 1200MB a poslední necháš na "All unused RAM". Pokrytí 400% je více než dost pro plnou kontrolu stability RAM (když přežije 400% bez erroru, můžeš ji bez problému prohlásit za stabilní), pro nějaké částečné testy stability stačí i pokrytí 100-200% a podobně.
Pak je klasika Memtest86 z bootovacího flash disku, výhoda je v tom, že testuje celou RAM - i tu kterou by normálně zabíraly Windows. Ale kupodivu ho moc overclockerů nepoužívá, Ti jdou spíše po Memtestu od HCI.
OCCT a Prime95 umí RAM taky pěkně zatížit, ale nevím jak jsou na tom s rychlostí vyhledávání chyb.
Máš desku od Asrocku. Asrock je v tomhle legendární. BIOS jejich desek obsahuje každičké možné nastavení, každé napětí a každé časování. I ty naprosto nepotřebné, které nic neovlivňují. Na jednu stranu je to super, ale pak je zase problém, že Asrock u většiny nastavení neuvádí co dělají, na internetu to nenajdeš, takže máš desítky nastavení, u kterých nemáš ponětí co dělají, jestli mají nějaký vliv na stabilitu/výkon a jestli ovlivňují RAM nebo CPU. A takhle to vidí i extreme overclockeři, i pro ně to jsou desítky zbytečných položek v BIOSu.
Evga jde zase opačným směrem. Je zajímá jediná věc - Kingpin držící světové rekordy v 3D Marku s jejich HW. Tudíž když navrhují desku, jejich myšlenkový postup vypadá zhruba takhle: "Ovlivňuje tohle nastavení skóre v 3D Marku? Ne? Takže ho nepotřebujeme."
Třeba jejich X299 Dark je díky tomu fakt dobrá deska. Všechna nastavení jsou v BIOSu dobře popsána co dělají, takže víš co by jsi od nich měl čekat. Jsou tam pouze ta důležitá, takže nemáš pocit kompletního ztracení v čase a prostoru kdykoliv zalistuješ hlouběji do nastavení.
Ale pak přichází ta stinná stránka - Buildzoid dal s Dark RAM na 3900MHz CL12-11-11-10. Bez problému by dal stejná časování s 4000+MHz, kdyby ho deska nechala upravit to napětí, které deska nastavuje jako polovinu napětí RAM. Takhle je zaseklý na 1,8V pro RAM, protože když se tamto napětí přenese přes 0,900V, jeho RAM začne protestovat. Kingpinova RAM tohle nedělá, takže tam regulaci toho napětí Evga nedala.
Měnit časování ve Windows podle mě stejně není dobrý nápad. Když se to provede v BIOSu, systém se restartuje a CPU provede trénování RAM - paměťový řadič prakticky zkouší různé kombinace časování (takových, které ani v BIOSu nejsou dostupné) pro ideální stabilitu a výkon. V momentě, kdy se změní časování pamětí ve Windows, neproběhne trénování RAM a jedno z těch nepotřebných časování, které nastavuje řadič, může začít dělat problém protože nebylo správně nastaveno vzhledem k té změně.
Když tRFC 400 i 312 dávají cca stejně chyb, nebude chyba v tRFC (tudíž můžeš nechat těch 312, popřípadě ještě zkusit snížit - možná 280?).
Zjistit, které časování způsobuje tu chybu, je skoro nemožné - musel by jsi postupně zvedat a testovat všechny časování které jsi nějak upravil. A vzhledem k tomu že se ta chyba objevuje až cca po 3,5h, chtělo by to spoustu času.
Šel bych na to opačnou cestou, kterou jsi psal - zvýšit stabilitu RAM tak, aby to časování už bylo stabilní a nedělalo problém. Nejideálnější kandidáti jsou právě VCCIO a SA - zkus s nimi trochu pohýbat nahoru i dolů (bohužel u RAM není vždy vyšší napětí lepší).
V neděli/pondělí budu doma, pošlu Ti, jak jsem cca před půl rokem testoval vliv CLDO_VDDP na stabilitu RAM - tohle napětí hýbe se stabilitou nahoru a dolů jak chce, na 0,900V můžeš mít 2 chyby a na 0,905V můžeš mít 15 chyb. Dá ti to nějakou představu, jak se SA a IO chovají - ty sice nejsou tak extrémní že by skákali nahoru a dolů, ale mají svůj sweet spot který není jednoduché najít a když ho přestřelíš tak dělají problém.
K rychlosti objevování chyb - sám jsem to nijak netestoval, ale podle Elmora (inženýr z Asusu) a dalších inženýrů chyby v RAM nejrychleji objevuje StressAppTest. Původně to byl interní program Googlu na testování stability RAM pro všechny jejich servery (to podle mě svědčí o tom, že za něco stojí), a pravděpodobně ho stále používají. Jediný problém je, že běží pouze pod Linuxem. Mně se ho nepodařilo rozchodit ve Windows s nainstalovaným Ubuntu z MS Store (tohle doporučovali inženýři z Asusu na rozchození pod Windows), ale když jsem nabootoval Mint z flashky, fungoval StressAppTest bez problému (právě přes něj jsem testoval vliv CLDO_VDDP).
Často se pak doporučuje Memtest HCI, který používá spousta profi Overclockerů a inženýrů (když třeba G.Skill demonstroval stabilitu jejich 4800MHz RAM kitu, stress testovali právě skrz Memtest HCI) http://hcidesign.com/memtest/download.html funguje normálně ve Windows, otevřeš tolik oken kolik má tvoje CPU vláken (i s HT, tedy 12) a každému oknu nastavíš kolik RAM má projet. Prvním 11 nastavíš třeba 1200MB a poslední necháš na "All unused RAM". Pokrytí 400% je více než dost pro plnou kontrolu stability RAM (když přežije 400% bez erroru, můžeš ji bez problému prohlásit za stabilní), pro nějaké částečné testy stability stačí i pokrytí 100-200% a podobně.
Pak je klasika Memtest86 z bootovacího flash disku, výhoda je v tom, že testuje celou RAM - i tu kterou by normálně zabíraly Windows. Ale kupodivu ho moc overclockerů nepoužívá, Ti jdou spíše po Memtestu od HCI.
OCCT a Prime95 umí RAM taky pěkně zatížit, ale nevím jak jsou na tom s rychlostí vyhledávání chyb.
Máš desku od Asrocku. Asrock je v tomhle legendární. BIOS jejich desek obsahuje každičké možné nastavení, každé napětí a každé časování. I ty naprosto nepotřebné, které nic neovlivňují. Na jednu stranu je to super, ale pak je zase problém, že Asrock u většiny nastavení neuvádí co dělají, na internetu to nenajdeš, takže máš desítky nastavení, u kterých nemáš ponětí co dělají, jestli mají nějaký vliv na stabilitu/výkon a jestli ovlivňují RAM nebo CPU. A takhle to vidí i extreme overclockeři, i pro ně to jsou desítky zbytečných položek v BIOSu.
Evga jde zase opačným směrem. Je zajímá jediná věc - Kingpin držící světové rekordy v 3D Marku s jejich HW. Tudíž když navrhují desku, jejich myšlenkový postup vypadá zhruba takhle: "Ovlivňuje tohle nastavení skóre v 3D Marku? Ne? Takže ho nepotřebujeme."
Třeba jejich X299 Dark je díky tomu fakt dobrá deska. Všechna nastavení jsou v BIOSu dobře popsána co dělají, takže víš co by jsi od nich měl čekat. Jsou tam pouze ta důležitá, takže nemáš pocit kompletního ztracení v čase a prostoru kdykoliv zalistuješ hlouběji do nastavení.
Ale pak přichází ta stinná stránka - Buildzoid dal s Dark RAM na 3900MHz CL12-11-11-10. Bez problému by dal stejná časování s 4000+MHz, kdyby ho deska nechala upravit to napětí, které deska nastavuje jako polovinu napětí RAM. Takhle je zaseklý na 1,8V pro RAM, protože když se tamto napětí přenese přes 0,900V, jeho RAM začne protestovat. Kingpinova RAM tohle nedělá, takže tam regulaci toho napětí Evga nedala.
Re: Taktování RAM - DDR4 G.SKILL
Díky za všechny ty podrobnosti.
Zkusil jsem dát VCCIO a SA na 1,3V a Linpack už bez problému projel 24h:
Takže to bylo opravdu tím, že byly moc nízký, předpokládám, že by stačilo i menší zvýšení, než o 0,05V, obzvlášť u toho IO, ale zatím to tak nechám - dokud zrychluji RAM, aby mě to zbytečně nelimitovalo. Nejnižší hodnoty, který budou potřeba ke stabilitě najdu, až dotaktuju kompletně RAM.
Zkusil jsem nyní snížit sekundární, jak jsi mi doporučil a ráno zapnu zas Linpack a nechám běžet přes 8 hod.
Konkrétně jsem změnil:
tRFC: 280
tRRD_S: 7
tWTR_L: 15
tWTR_S: 5
tRTP: 12
Teď jsem si jen zkusil na rychlo Aidu, jak se to projevilo na rychlosti a celkem slušný:
To je zas o 1300MB/s více při čtení, zápis o 500, kopírování o 800.
Tak uvidíme, jestli to projde.
Zkusil jsem dát VCCIO a SA na 1,3V a Linpack už bez problému projel 24h:
Takže to bylo opravdu tím, že byly moc nízký, předpokládám, že by stačilo i menší zvýšení, než o 0,05V, obzvlášť u toho IO, ale zatím to tak nechám - dokud zrychluji RAM, aby mě to zbytečně nelimitovalo. Nejnižší hodnoty, který budou potřeba ke stabilitě najdu, až dotaktuju kompletně RAM.
Zkusil jsem nyní snížit sekundární, jak jsi mi doporučil a ráno zapnu zas Linpack a nechám běžet přes 8 hod.
Konkrétně jsem změnil:
tRFC: 280
tRRD_S: 7
tWTR_L: 15
tWTR_S: 5
tRTP: 12
Teď jsem si jen zkusil na rychlo Aidu, jak se to projevilo na rychlosti a celkem slušný:
To je zas o 1300MB/s více při čtení, zápis o 500, kopírování o 800.
Tak uvidíme, jestli to projde.
MB: ASROCK Fatal1ty Z370 Gaming K6 CPU: Intel Core i7-8700K @ 5,1GHz/4,9 AVX/4,6 cache; 1,41V Delid FAN: NZXT Kraken X62 RAM: G.SKILL 2x8GB DDR4 3800MHz @ CL16 TridentZ 1,5V GPU: Zotac GTX 1080Ti AMP Extreme Core Edition (11GB) SSD: Samsung 960 EVO 500GB, 850 EVO 500GB, 840 EVO 120GB HDD: WD Blue 2x4TB PSU: Corsair RM850i Case: Fractal Design Define R6 Black TG Monitor: BenQ XL2411Z
Re: Taktování RAM - DDR4 G.SKILL
Tak potom co jsem dal tyhle nastavení:
tRFC: 280
tRRD_S: 7
tWTR_L: 15
tWTR_S: 5
tRTP: 12
a následně spustil Linpack tak po 13 minutách error:
Tak jsem zkusil zbytek vrátit zpět a nechat jen tRFC: 280 a to potom projelo bez problému 2 hod.:
Pak jsem si řekl, že snížím zpět ten zbytek, jako předtím na:
tRRD_S: 7
tWTR_L: 15
tWTR_S: 5
tRTP: 12
S tím, že jsem očekával, že nastane chyba po zhruba stejném čase (cca 13 min). Chtěl jsem totiž vyzkoušet, co najde chybu rychleji, jestli OCCT Linpack nebo MemTest HCI, ovšem najednou Linpack jel 1,5hod. bez problému:
Není možný, pokud se změní víc časování najednou, že se potom RAM může takto zachovat = je nestabilní i když by byla při stejném časování stabilní, kdyby bylo nastavené postupně? Protože jinak si to nedovedu vysvětlit, když stejný nastavení nejdřív po chvíli error a potom najednou ok. Flanker tu má článek ohledně taktování Coffee Lake a zmiňuje se tam i o taktování RAM a píše, že když se změní víc časování najednou, že deska nemusí nabootovat, zaseknou se tam některý kódy, ale nvm, jestli se to může projevit i takhle - až potom co nabootuje.
Jinak u OCCT záleží jaký test, Linpack je na testování RAM nejlepší (taky využívá nejvíce RAM), ty ostatní jsou spíš na CPU, chyba by se tam projevila taky, ale po dost delší době.
Každopádně ta StressAppTest... podle toho co jsi o tom napsal, tak by mě to celkem lákalo vyzkoušet, Linux bych si mohl nainstalovat na vedlejší 120GB SSD, to by nebyl takový problém, ale nevím, jakou verzi atd., moc se v Linuxech nevyznám.
tRFC: 280
tRRD_S: 7
tWTR_L: 15
tWTR_S: 5
tRTP: 12
a následně spustil Linpack tak po 13 minutách error:
Tak jsem zkusil zbytek vrátit zpět a nechat jen tRFC: 280 a to potom projelo bez problému 2 hod.:
Pak jsem si řekl, že snížím zpět ten zbytek, jako předtím na:
tRRD_S: 7
tWTR_L: 15
tWTR_S: 5
tRTP: 12
S tím, že jsem očekával, že nastane chyba po zhruba stejném čase (cca 13 min). Chtěl jsem totiž vyzkoušet, co najde chybu rychleji, jestli OCCT Linpack nebo MemTest HCI, ovšem najednou Linpack jel 1,5hod. bez problému:
Není možný, pokud se změní víc časování najednou, že se potom RAM může takto zachovat = je nestabilní i když by byla při stejném časování stabilní, kdyby bylo nastavené postupně? Protože jinak si to nedovedu vysvětlit, když stejný nastavení nejdřív po chvíli error a potom najednou ok. Flanker tu má článek ohledně taktování Coffee Lake a zmiňuje se tam i o taktování RAM a píše, že když se změní víc časování najednou, že deska nemusí nabootovat, zaseknou se tam některý kódy, ale nvm, jestli se to může projevit i takhle - až potom co nabootuje.
Jinak u OCCT záleží jaký test, Linpack je na testování RAM nejlepší (taky využívá nejvíce RAM), ty ostatní jsou spíš na CPU, chyba by se tam projevila taky, ale po dost delší době.
Každopádně ta StressAppTest... podle toho co jsi o tom napsal, tak by mě to celkem lákalo vyzkoušet, Linux bych si mohl nainstalovat na vedlejší 120GB SSD, to by nebyl takový problém, ale nevím, jakou verzi atd., moc se v Linuxech nevyznám.
MB: ASROCK Fatal1ty Z370 Gaming K6 CPU: Intel Core i7-8700K @ 5,1GHz/4,9 AVX/4,6 cache; 1,41V Delid FAN: NZXT Kraken X62 RAM: G.SKILL 2x8GB DDR4 3800MHz @ CL16 TridentZ 1,5V GPU: Zotac GTX 1080Ti AMP Extreme Core Edition (11GB) SSD: Samsung 960 EVO 500GB, 850 EVO 500GB, 840 EVO 120GB HDD: WD Blue 2x4TB PSU: Corsair RM850i Case: Fractal Design Define R6 Black TG Monitor: BenQ XL2411Z
Re: Taktování RAM - DDR4 G.SKILL
Při každém spuštění/restartu systému CPU provádí trénování RAM, během kterého nastavuje ta časování nepřístupná v BIOSu. Paměťový řadič se v trénování postupně zlepšuje - algoritmy se učí, která nastavení fungují a jaká ne a jak jaké časování nastavit. Bohužel, paměťový řadič "zapomíná" to co se ty algoritmy naučily - nevím jak to přesně je, jestli se ty algoritmy restartují při každém vypnutí, nebo musí být pc vypnuté aspoň hodinu. Důležité je, že když večer pc vypneš a další den k němu příjdeš, paměťový řadič si nic z toho co se naučil nebude pamatovat.
Takže se stalo to, že když jsi původně testoval všechny ty změny, řadič byl "tupý" a něco nastavil špatně, OCCT našlo chybu. Pak jsi šel do BIOSu, nastavil pouze tRFC. Paměťový řadič přetrénoval RAM - tentokrát nastavil vše správně, přičemž se spolu s tím se i zlepšil v trénování. OCCT bez chyby. V BIOSu jsi poté nastavil opět všechny změny, tentokrát měl paměťový řadič za sebou už několik procedur trénovaní - vše nastavil dobře. OCCT bez problému.
Tohle je i důvod, proč když profesionální overclockeři nejdříve nabootují RAM na 3600MHz, pak 3800MHz a až pak nastaví svůj profil se vším všudy - jinak by se dost možná ani nedostali do Windows, možná ani ne do BIOSu.
Bohužel to do taktování RAM přidává další neznámou. Chtělo by to více infa o tom, jak to učení probíhá a kdy se to, co se řadič naučí, zapomene - ale získat jakoukoliv takovou informaci je dost těžké.
Ideální by bylo, kdyby se v BIOSu desek dalo nastavit, ať deska při prvním bootu projede trénování RAM na x nastavení a až pak dá finální profil. Sice by pak první boot trval o něco déle, ale systém by byl o poznání stabilnější. Ale nevím o tom, že by tohle jakákoliv deska na jakékoliv platformě uměla.
Díval jsem se po netu na tREFI, a našel jsem dost lidí, kteří při podobných frekvencích jako ty měli hodnoty jemně přes 30000 (ty máš teď cca 11000). Takže bych tREFI viděl jako další oběť, těch 30k by mělo být více méně jistých (snad).
Inženýři z Asusu ke StressAppTest doporučují Mint https://rog.asus.com/forum/showthread.p ... tress-test
Takhle se chová stabilita vzhledem k CLDO_VDDP na AM4 Sloupce jsou hodnoty napětí, v řádcích jsou pak jednotlivé passy (některé výsledky jsem testoval vícekrát, abych se ujistil). Bohužel jsem to tehdy testoval jenom 10 minut StressAppTestu, takže u 0,825V se mi kvůli krátkému času (a tím i vyšší odchylce) udělal opravdu velký rozptyl - dokonce se podezírám, že jsem u 3. a 4. průchodu omylem použil jiné nastavení, ale to teď už nezjistím. Počet chyb různě roste a klesá, s trochou představivosti by se tam dal najít nějaký vlnový vzor - kdyby jsem testoval delší dobu než 10 minut a pokryl bych celé spektrum od 0,750V až po 0,950V, dost možná by tam byl dost zřetelný nějaký vzor. Tehdy jsem s tím skončil kvůli aktualizaci BIOSu (která dosavadní data udělala nerelevantní), rozptylu výsledků měření u 0,825V a protože jsem nebyl spokojený s odchylkou - příště bych testoval minimálně 20 minut, spíše 30 minut. Někdy se chystám to přeměřit.
VCCIO a SA se bude chovat trochu podobně, ale bude méně extrémní. Očekával bych, že budou vypadat jako střecha - křivka bude mít jeden bod, při kterém bude stabilita nejvyšší, a zvýšení i snížení napětí by lineárně snižovalo stabilitu. Možná to nebude úplně lineární křivka, bude někde prudší/plytší nebo bude mít nějakou formu vln, ale ve výsledku tam bude jeden bod, při kterém bude stabilita nejvyšší.
Takže se stalo to, že když jsi původně testoval všechny ty změny, řadič byl "tupý" a něco nastavil špatně, OCCT našlo chybu. Pak jsi šel do BIOSu, nastavil pouze tRFC. Paměťový řadič přetrénoval RAM - tentokrát nastavil vše správně, přičemž se spolu s tím se i zlepšil v trénování. OCCT bez chyby. V BIOSu jsi poté nastavil opět všechny změny, tentokrát měl paměťový řadič za sebou už několik procedur trénovaní - vše nastavil dobře. OCCT bez problému.
Tohle je i důvod, proč když profesionální overclockeři nejdříve nabootují RAM na 3600MHz, pak 3800MHz a až pak nastaví svůj profil se vším všudy - jinak by se dost možná ani nedostali do Windows, možná ani ne do BIOSu.
Bohužel to do taktování RAM přidává další neznámou. Chtělo by to více infa o tom, jak to učení probíhá a kdy se to, co se řadič naučí, zapomene - ale získat jakoukoliv takovou informaci je dost těžké.
Ideální by bylo, kdyby se v BIOSu desek dalo nastavit, ať deska při prvním bootu projede trénování RAM na x nastavení a až pak dá finální profil. Sice by pak první boot trval o něco déle, ale systém by byl o poznání stabilnější. Ale nevím o tom, že by tohle jakákoliv deska na jakékoliv platformě uměla.
Díval jsem se po netu na tREFI, a našel jsem dost lidí, kteří při podobných frekvencích jako ty měli hodnoty jemně přes 30000 (ty máš teď cca 11000). Takže bych tREFI viděl jako další oběť, těch 30k by mělo být více méně jistých (snad).
Inženýři z Asusu ke StressAppTest doporučují Mint https://rog.asus.com/forum/showthread.p ... tress-test
Takhle se chová stabilita vzhledem k CLDO_VDDP na AM4 Sloupce jsou hodnoty napětí, v řádcích jsou pak jednotlivé passy (některé výsledky jsem testoval vícekrát, abych se ujistil). Bohužel jsem to tehdy testoval jenom 10 minut StressAppTestu, takže u 0,825V se mi kvůli krátkému času (a tím i vyšší odchylce) udělal opravdu velký rozptyl - dokonce se podezírám, že jsem u 3. a 4. průchodu omylem použil jiné nastavení, ale to teď už nezjistím. Počet chyb různě roste a klesá, s trochou představivosti by se tam dal najít nějaký vlnový vzor - kdyby jsem testoval delší dobu než 10 minut a pokryl bych celé spektrum od 0,750V až po 0,950V, dost možná by tam byl dost zřetelný nějaký vzor. Tehdy jsem s tím skončil kvůli aktualizaci BIOSu (která dosavadní data udělala nerelevantní), rozptylu výsledků měření u 0,825V a protože jsem nebyl spokojený s odchylkou - příště bych testoval minimálně 20 minut, spíše 30 minut. Někdy se chystám to přeměřit.
VCCIO a SA se bude chovat trochu podobně, ale bude méně extrémní. Očekával bych, že budou vypadat jako střecha - křivka bude mít jeden bod, při kterém bude stabilita nejvyšší, a zvýšení i snížení napětí by lineárně snižovalo stabilitu. Možná to nebude úplně lineární křivka, bude někde prudší/plytší nebo bude mít nějakou formu vln, ale ve výsledku tam bude jeden bod, při kterém bude stabilita nejvyšší.
Re: Taktování RAM - DDR4 G.SKILL
Aha, takže v podstatě když je problém s nastavením, které zvolím, tak to může vyřešit i pouhý restart (protože řadič může nastavit ty subhodnoty jinak)? Ale jakmile to jednou najde správnou kombinaci k nastavení, které jsem zvolil, tak už by to pak mělo být vždy ok ne? Pokud na to už nebudu sahat.
To by určitě bylo lepší, jednou delší boot by k těmhle účelům vůbec nevadil.
Ok, tREFI potom můžu zkusit zpracovat, ale je tu ještě jeden problém. Nevím jestli jsi četl téma, kde jsem řešil přehřívání VRM ve small datech v OCCT, ale každopádně upgradoval jsem airlflow a k žádnému přehřívání už nedochází, ale je tu teď problém, že mám v tom testu errory a před taktováním RAM jsem to měl odladěné tak, že tu zde žádné nebyly (24 hod bez problému), nyní jsou většinou do 1 hod.
Zkoušel jsem různě ladit VCCIO a SA a nejlepšího výsledku jsem zatím dosáhl s IO 1,29V a SA 1,32V - to vydrželo 2 hod. 32m., když zvýším/snížím jedno z nich jen o 0,01V error nastává už o dost rychleji 1,5 hod. když hýbu více, tak mezi 8min - 46min.
Jinak většinou pokud OCCT nenajde problém do 5 hod., tak to pak už projede i 24h. Jednou mi to kleklo po 10ti hod., ale jinak vždy do 5ti.
Celkově jsem všechny možný variace samozřejmě nezkoušel, protože když vezmu v potaz, že bych měl zkusit všechny možnosti od 1,25-1,35V, s rozestupem 0,01V (tj. tedy 11 kroků). Tak to je celkem 11*11 a - 11 protože 11x máme stejnou hodnotu pro obě napětí = to je tedy 110 možností, jestli se nepletu. (A to by zabralo komplet otestovat, když vezmu v potaz, že odhalení chyby trvá v průměru 20 min (20 * 110 / 60 = ~ 36 hod.)) Ale samozřejmě, že některý variace je zbytečný testovat, protože už vím, že nemají šanci na stabilitu a crash pak může být třeba i v několika sekundách.
Ovšem je tu ještě jedna věc, jak jsem zkoušel ty různý kombinace napětí, tak někdy mi OCCT hodí jen jako error detected a někdy přímo error on core #0-6. Tedy error přímo na jádře, neznamená to, že bych měl tím pádem navýšit i vcore napětí? Jestli tím, když jsem zrychlil RAM, tak toho mohou pak jádra zpracovat více najednou a napětí na jádrech už nemusí dostačovat?
Vyzkoušel jsem zatím 12 možností mezi napětími IO a SA a když se teď dívám na ty výsledky, tak to vypadá následovně:
Z toho mi jasně vyplývá následující, že u IO se zdá být při této rychlosti RAM sweet spot 1,29V a zároveň vždy když je 1,29V, tak nastává error na jádře. Nejlepší kombinace vypadá jako 1,29/1,32V (vydržela nejdéle), jestli bych tedy neměl zkusit zvýšit vcore při 1,29/1,32V. Co si o tom myslíš?
Btw: Jo charakteristiku jako střecha to bude mít určitě, ale úplně lineární asi ne.
dom324 píše:Ideální by bylo, kdyby se v BIOSu desek dalo nastavit, ať deska při prvním bootu projede trénování RAM na x nastavení a až pak dá finální profil. Sice by pak první boot trval o něco déle, ale systém by byl o poznání stabilnější. Ale nevím o tom, že by tohle jakákoliv deska na jakékoliv platformě uměla.
To by určitě bylo lepší, jednou delší boot by k těmhle účelům vůbec nevadil.
Ok, tREFI potom můžu zkusit zpracovat, ale je tu ještě jeden problém. Nevím jestli jsi četl téma, kde jsem řešil přehřívání VRM ve small datech v OCCT, ale každopádně upgradoval jsem airlflow a k žádnému přehřívání už nedochází, ale je tu teď problém, že mám v tom testu errory a před taktováním RAM jsem to měl odladěné tak, že tu zde žádné nebyly (24 hod bez problému), nyní jsou většinou do 1 hod.
Zkoušel jsem různě ladit VCCIO a SA a nejlepšího výsledku jsem zatím dosáhl s IO 1,29V a SA 1,32V - to vydrželo 2 hod. 32m., když zvýším/snížím jedno z nich jen o 0,01V error nastává už o dost rychleji 1,5 hod. když hýbu více, tak mezi 8min - 46min.
Jinak většinou pokud OCCT nenajde problém do 5 hod., tak to pak už projede i 24h. Jednou mi to kleklo po 10ti hod., ale jinak vždy do 5ti.
Celkově jsem všechny možný variace samozřejmě nezkoušel, protože když vezmu v potaz, že bych měl zkusit všechny možnosti od 1,25-1,35V, s rozestupem 0,01V (tj. tedy 11 kroků). Tak to je celkem 11*11 a - 11 protože 11x máme stejnou hodnotu pro obě napětí = to je tedy 110 možností, jestli se nepletu. (A to by zabralo komplet otestovat, když vezmu v potaz, že odhalení chyby trvá v průměru 20 min (20 * 110 / 60 = ~ 36 hod.)) Ale samozřejmě, že některý variace je zbytečný testovat, protože už vím, že nemají šanci na stabilitu a crash pak může být třeba i v několika sekundách.
Ovšem je tu ještě jedna věc, jak jsem zkoušel ty různý kombinace napětí, tak někdy mi OCCT hodí jen jako error detected a někdy přímo error on core #0-6. Tedy error přímo na jádře, neznamená to, že bych měl tím pádem navýšit i vcore napětí? Jestli tím, když jsem zrychlil RAM, tak toho mohou pak jádra zpracovat více najednou a napětí na jádrech už nemusí dostačovat?
Vyzkoušel jsem zatím 12 možností mezi napětími IO a SA a když se teď dívám na ty výsledky, tak to vypadá následovně:
Z toho mi jasně vyplývá následující, že u IO se zdá být při této rychlosti RAM sweet spot 1,29V a zároveň vždy když je 1,29V, tak nastává error na jádře. Nejlepší kombinace vypadá jako 1,29/1,32V (vydržela nejdéle), jestli bych tedy neměl zkusit zvýšit vcore při 1,29/1,32V. Co si o tom myslíš?
Btw: Jo charakteristiku jako střecha to bude mít určitě, ale úplně lineární asi ne.
MB: ASROCK Fatal1ty Z370 Gaming K6 CPU: Intel Core i7-8700K @ 5,1GHz/4,9 AVX/4,6 cache; 1,41V Delid FAN: NZXT Kraken X62 RAM: G.SKILL 2x8GB DDR4 3800MHz @ CL16 TridentZ 1,5V GPU: Zotac GTX 1080Ti AMP Extreme Core Edition (11GB) SSD: Samsung 960 EVO 500GB, 850 EVO 500GB, 840 EVO 120GB HDD: WD Blue 2x4TB PSU: Corsair RM850i Case: Fractal Design Define R6 Black TG Monitor: BenQ XL2411Z
Re: Taktování RAM - DDR4 G.SKILL
Taktuješ paměti na krev a tím se ti zhoršila stabilita CPU. Celkem normální jev.
Méně je někdy více.
Méně je někdy více.
Fractal Design Define R6 TG (6x Noctua A14 ULN) - Intel Core i9-9900K @ 4,9GHz (Noctua D15S) - ASUS Z370 MAXIMUS X APEX - 16GB G.Skill Trident Z DDR4 4000Mhz - MSI GTX 1080 Ti Lightning Z 11GB (ACEX IV + 3x Noctua A9 PWM) - Samsung 960 PRO 512GB + ADATA SX8200 PRO 2TB + Samsung SpinPoint M9T 2TB - Corsair RM650X - 27" LG 27GL850 @ 144Hz + 24" DELL P2419H
Re: Taktování RAM - DDR4 G.SKILL
No to jo, ale zase ve prospěch výkonu a to to nám jde, tedy možná o 0,01V víc na vcore by mohlo pomoc ke stabilitě, když je error po 2,5hod., tak už jsem poměrně blízko.
MB: ASROCK Fatal1ty Z370 Gaming K6 CPU: Intel Core i7-8700K @ 5,1GHz/4,9 AVX/4,6 cache; 1,41V Delid FAN: NZXT Kraken X62 RAM: G.SKILL 2x8GB DDR4 3800MHz @ CL16 TridentZ 1,5V GPU: Zotac GTX 1080Ti AMP Extreme Core Edition (11GB) SSD: Samsung 960 EVO 500GB, 850 EVO 500GB, 840 EVO 120GB HDD: WD Blue 2x4TB PSU: Corsair RM850i Case: Fractal Design Define R6 Black TG Monitor: BenQ XL2411Z
Re: Taktování RAM - DDR4 G.SKILL
Jenom restart by to neměl spravit - musíš změnit i nějaké nastavení, nejlépe frekvenci (protože to je skoro stejné, jako by jsi změnil úplně všechny časování - řadič bude mít spoustu dat).
Tak to jsme se nepochopili. Řadič jednou najde správnou kombinaci (už bude dostatečně naučený) k nastavení které jsi zvolil, ale tu kombinaci i všechno co se naučil zase zapomene (zase, nevím jak dlouho přesně trvá, než to zapomene, ale když přijdeš další den k pc už bude všechno trénování ztraceno). Tudíž když další den přijdeš k pc, musíš trénovat znovu, i když jsi na nastavení vůbec nešahal.
To, že OCCT hlásí přímo jádro na kterém chyba nastala, není nic zvláštního a nemusí to být chyba na straně CPU - když RAM pošle jádru špatné data, i když je jádro plně stabilní a neudělá samo o sobě žádnou chybu, tak jelikož mu RAM poslala špatné data, výsledek bude špatný a nastane chyba. Memtest86 (od verze 7.0 která přinesla Multithreading) vždy hlásí na kterém jádru chyba nastala a hlásí přímo i instrukci (ještě jsem ale neviděl nic jiného než ADDR).
Neznám sice OCCT moc do hloubky, ale Error Detected možná znamená, že byla nalezena chyba v RAM, která by za normálních podmínek byla opravena (algoritmem podobným ECC) - tudíž by CPU dostalo správné data a nakonec by chyba nenastala. Error přímo na jádře by pak znamenal, že chyba nebyla odhalena, dostala se až do CPU a způsobila chybné operace. Ale je to jen moje domněnka, i když mě nenapadá co jiného by Error Detected mohl být.
Můžeš zkusit zvýšit VCore, ale podle mě by to ty errory přímo na jádře nemělo odstranit.
Má OCCT tak moc stabilní výsledky, že nalezne error vždy po cca stejně dlouhé době? Protože mně se více osvědčil opačný postup - nastavit neúplně stabilní nastavení RAM (abych nedostával výsledky na úrovni chyby měření), nechat stress test běžet vždy po stejnou dobu a zaznamenávat počet chyb. Přišlo mi, že tak vzniká menší statistická odchylka.
K počtu variací - nevím jak moc jsou na sobě SA a IO závislé (jestli se bude IO chovat jinak při 1,25V a 1,3V SA) - je možné, že by Ti stačilo otestovat IO na 11 nastavení (těch 1,25V až 1,35V) s jakýmkoliv SA, a pak s nejstabilnějším IO udělat 11 testů SA.
Faster1 píše:Ale jakmile to jednou najde správnou kombinaci k nastavení, které jsem zvolil, tak už by to pak mělo být vždy ok ne? Pokud na to už nebudu sahat.
Tak to jsme se nepochopili. Řadič jednou najde správnou kombinaci (už bude dostatečně naučený) k nastavení které jsi zvolil, ale tu kombinaci i všechno co se naučil zase zapomene (zase, nevím jak dlouho přesně trvá, než to zapomene, ale když přijdeš další den k pc už bude všechno trénování ztraceno). Tudíž když další den přijdeš k pc, musíš trénovat znovu, i když jsi na nastavení vůbec nešahal.
To, že OCCT hlásí přímo jádro na kterém chyba nastala, není nic zvláštního a nemusí to být chyba na straně CPU - když RAM pošle jádru špatné data, i když je jádro plně stabilní a neudělá samo o sobě žádnou chybu, tak jelikož mu RAM poslala špatné data, výsledek bude špatný a nastane chyba. Memtest86 (od verze 7.0 která přinesla Multithreading) vždy hlásí na kterém jádru chyba nastala a hlásí přímo i instrukci (ještě jsem ale neviděl nic jiného než ADDR).
Neznám sice OCCT moc do hloubky, ale Error Detected možná znamená, že byla nalezena chyba v RAM, která by za normálních podmínek byla opravena (algoritmem podobným ECC) - tudíž by CPU dostalo správné data a nakonec by chyba nenastala. Error přímo na jádře by pak znamenal, že chyba nebyla odhalena, dostala se až do CPU a způsobila chybné operace. Ale je to jen moje domněnka, i když mě nenapadá co jiného by Error Detected mohl být.
Můžeš zkusit zvýšit VCore, ale podle mě by to ty errory přímo na jádře nemělo odstranit.
Má OCCT tak moc stabilní výsledky, že nalezne error vždy po cca stejně dlouhé době? Protože mně se více osvědčil opačný postup - nastavit neúplně stabilní nastavení RAM (abych nedostával výsledky na úrovni chyby měření), nechat stress test běžet vždy po stejnou dobu a zaznamenávat počet chyb. Přišlo mi, že tak vzniká menší statistická odchylka.
K počtu variací - nevím jak moc jsou na sobě SA a IO závislé (jestli se bude IO chovat jinak při 1,25V a 1,3V SA) - je možné, že by Ti stačilo otestovat IO na 11 nastavení (těch 1,25V až 1,35V) s jakýmkoliv SA, a pak s nejstabilnějším IO udělat 11 testů SA.
Re: Taktování RAM - DDR4 G.SKILL
Aha, no ale mně připadá, že i ten restart stačí, protože jsem o víkendu zkoušel u RAM měnit různě frekvenci i časování, co to dá (nabootoval jsem i na 4300MHz při CL19, vcore: 1,41V, IO: 1,29V; SA: 1,32V; DRAM: 1,5V), ale ve small data OCCT po chvilce error, ani ne 5 minut. Potom jsem dal zpět na 4200MHz, CL16 + všechny ty další časování, tak jak jsem měl předtím a změnil jsem ještě tREFI na 30000, to vydrželo trochu delší dobu, ale pak taky error. Tak jsem to vrátil zpět na auto - tj. asi těch cca 11000 a spustil OCCT small data znovu a opět po pár minutách error. Což je divný, když tahle konfigurace mi předtím způsobovala error až po cca 2 hodinách. Jen jsem restartoval PC a spustil ten samý test znovu a chovalo se to jako dřív error až po 1,5 hod (předtím byl mezi 2-2,5 hod.). Takže se mi zdá, že i jen restart pomůže, nebo jinak si to moc neumím vysvětlit.
To jinými slovy znamená, že když to už budu mít komplet odladěné, bez erroru a další den zapnu PC (třeba po 15 hod. co byl vypnutý), tak to může být najednou zas nestabilní, protože tam dá řadič jinou konfiguraci? Potom ale nechápu, jak je teda možný najít plně stabilní konfiguraci, když tam jeden den řadič hodí to a druhý ten zas něco jiného.
Ok, to chápu. Jj error detected bude, že chyba nastala někde mimo jádro. Podle mě to nemusí být jen přímo v RAM, ale třeba na cestě do jádra CPU, tedy, to asi může způsobit také nízké/vysoké VCCIO a/nebo VCCSA a/nebo moc rychlá CPU cache.
Zvýšení vcore asi nepomůže, teď už mám aktivní chlazení na VRM, tak to klidně mohu vyzkoušet ve small datech i při napětí jako 1,45V.
Ono když se zrychluje RAM, tak se nezrychluje celkový výkon CPU, jako takového, ne? V případě, když je vytížený na 100% tak jádra toho pořád zpracují stejně, ne? Mělo by to ovlivňovat to, jak rychle se dostanou do jader instrukce, který potřebuje zpracovat, ne? Tudíž navyšování vcore asi není potřeba, ale nejsem si jistej, jestli se v tomhle nepletu.
----------------------------
Ohledně výsledkům v OCCT, řekl bych že ano, ale samozřejmě v případě, že nezměním žádný nastavení a vyberu v OCCT stejný typ testu. Když jsem dával stejný typ testu, bez změny nastavení, řekl bych, že chyba nastává tak po +/- 30% stejné době. Ale nesledoval/nezapisoval jsem si to až tak moc podrobně, tedy tvrdit si to s jistotou netroufám, to bych si musel ještě ověřit na několika pokusech.
To máš asi pravdu, že to by byla lepší varianta, nechat to běžet dál i potom co nastavene 1. chyba, ale to v OCCT není možný udělat. Protože když OCCT najde error, tak test automaticky zastaví. A uživatelsky se tohle nedá nijak změnit, to jedině nějakým zásahem přímo do toho programu. Ale např. Prime jede dál i potom, co nějaká chyba už nastala. Ovšem OCCT je efektivnější na hledání chyb, než Prime. V Primu by to zabralo o dost delší dobu.
----------------------------
Ohledně toho nastavení IO a SA, jo to bude asi nejefektivnější způsob, jak co nejrychleji najít potřebný volty. Jedno nechat konstantní a druhý měnit v rozsahu 1,25-1,35V. Pak hodnotu, při které error nastával po nejdelší době, tak tu nastavit jako konstantní a k ní ladit zas to druhé napětí v rozsahu 1,25-1,35V. Zdá se ale, že já jsem to vhodný už našel. Ten error v OCCT mi asi způsobuje moc nízký některý z těch časování. Možná bych taky mohl zkusit to nechat projet jen se sníženým primárním a sekundární a terciální nechat na auto, abych zjistil, jestli alespoň tohle proběhne bez erroru. Ale právě ta stresstestapp předpokládám, že by na tohle mohla být efektivnější/rychlejší k nalezení chyby.
----------------------------
Pár dotazů k Linuxu:
Zprovoznil jsem si Linux a měl bych dotaz ohledně té StressTestApp. Kdysi jsem na Linuxu sice dělal na škole, ale to jen tak na úrovni spuštění nainstalovaných aplikací
. No každopádně už jsem se trochu zorientoval a tu appku nainstaloval. Nemá to žádný uživatelský rozhraní, jeslti chápu správně? Tedy jde to ovládat jen přímo pomocí těch příkazů. Jaké nastavení používáš pro testování?
A ještě je nějaká dobrá aplikace, která běží pod Linuxem jako např. HWMonitor? Abych viděl teploty a rychlosti ventilátorů?
Jinak pod Linuxem asi nějaký antivir ani potřeba není, ne?
dom324 píše:Tak to jsme se nepochopili. Řadič jednou najde správnou kombinaci (už bude dostatečně naučený) k nastavení které jsi zvolil, ale tu kombinaci i všechno co se naučil zase zapomene (zase, nevím jak dlouho přesně trvá, než to zapomene, ale když přijdeš další den k pc už bude všechno trénování ztraceno). Tudíž když další den přijdeš k pc, musíš trénovat znovu, i když jsi na nastavení vůbec nešahal.
To jinými slovy znamená, že když to už budu mít komplet odladěné, bez erroru a další den zapnu PC (třeba po 15 hod. co byl vypnutý), tak to může být najednou zas nestabilní, protože tam dá řadič jinou konfiguraci? Potom ale nechápu, jak je teda možný najít plně stabilní konfiguraci, když tam jeden den řadič hodí to a druhý ten zas něco jiného.
dom324 píše:To, že OCCT hlásí přímo jádro na kterém chyba nastala, není nic zvláštního a nemusí to být chyba na straně CPU - když RAM pošle jádru špatné data, i když je jádro plně stabilní a neudělá samo o sobě žádnou chybu, tak jelikož mu RAM poslala špatné data, výsledek bude špatný a nastane chyba. Memtest86 (od verze 7.0 která přinesla Multithreading) vždy hlásí na kterém jádru chyba nastala a hlásí přímo i instrukci (ještě jsem ale neviděl nic jiného než ADDR).
Neznám sice OCCT moc do hloubky, ale Error Detected možná znamená, že byla nalezena chyba v RAM, která by za normálních podmínek byla opravena (algoritmem podobným ECC) - tudíž by CPU dostalo správné data a nakonec by chyba nenastala. Error přímo na jádře by pak znamenal, že chyba nebyla odhalena, dostala se až do CPU a způsobila chybné operace. Ale je to jen moje domněnka, i když mě nenapadá co jiného by Error Detected mohl být.
Můžeš zkusit zvýšit VCore, ale podle mě by to ty errory přímo na jádře nemělo odstranit.
Ok, to chápu. Jj error detected bude, že chyba nastala někde mimo jádro. Podle mě to nemusí být jen přímo v RAM, ale třeba na cestě do jádra CPU, tedy, to asi může způsobit také nízké/vysoké VCCIO a/nebo VCCSA a/nebo moc rychlá CPU cache.
Zvýšení vcore asi nepomůže, teď už mám aktivní chlazení na VRM, tak to klidně mohu vyzkoušet ve small datech i při napětí jako 1,45V.
Ono když se zrychluje RAM, tak se nezrychluje celkový výkon CPU, jako takového, ne? V případě, když je vytížený na 100% tak jádra toho pořád zpracují stejně, ne? Mělo by to ovlivňovat to, jak rychle se dostanou do jader instrukce, který potřebuje zpracovat, ne? Tudíž navyšování vcore asi není potřeba, ale nejsem si jistej, jestli se v tomhle nepletu.
----------------------------
Ohledně výsledkům v OCCT, řekl bych že ano, ale samozřejmě v případě, že nezměním žádný nastavení a vyberu v OCCT stejný typ testu. Když jsem dával stejný typ testu, bez změny nastavení, řekl bych, že chyba nastává tak po +/- 30% stejné době. Ale nesledoval/nezapisoval jsem si to až tak moc podrobně, tedy tvrdit si to s jistotou netroufám, to bych si musel ještě ověřit na několika pokusech.
To máš asi pravdu, že to by byla lepší varianta, nechat to běžet dál i potom co nastavene 1. chyba, ale to v OCCT není možný udělat. Protože když OCCT najde error, tak test automaticky zastaví. A uživatelsky se tohle nedá nijak změnit, to jedině nějakým zásahem přímo do toho programu. Ale např. Prime jede dál i potom, co nějaká chyba už nastala. Ovšem OCCT je efektivnější na hledání chyb, než Prime. V Primu by to zabralo o dost delší dobu.
----------------------------
Ohledně toho nastavení IO a SA, jo to bude asi nejefektivnější způsob, jak co nejrychleji najít potřebný volty. Jedno nechat konstantní a druhý měnit v rozsahu 1,25-1,35V. Pak hodnotu, při které error nastával po nejdelší době, tak tu nastavit jako konstantní a k ní ladit zas to druhé napětí v rozsahu 1,25-1,35V. Zdá se ale, že já jsem to vhodný už našel. Ten error v OCCT mi asi způsobuje moc nízký některý z těch časování. Možná bych taky mohl zkusit to nechat projet jen se sníženým primárním a sekundární a terciální nechat na auto, abych zjistil, jestli alespoň tohle proběhne bez erroru. Ale právě ta stresstestapp předpokládám, že by na tohle mohla být efektivnější/rychlejší k nalezení chyby.
----------------------------
Pár dotazů k Linuxu:
Zprovoznil jsem si Linux a měl bych dotaz ohledně té StressTestApp. Kdysi jsem na Linuxu sice dělal na škole, ale to jen tak na úrovni spuštění nainstalovaných aplikací
. No každopádně už jsem se trochu zorientoval a tu appku nainstaloval. Nemá to žádný uživatelský rozhraní, jeslti chápu správně? Tedy jde to ovládat jen přímo pomocí těch příkazů. Jaké nastavení používáš pro testování?A ještě je nějaká dobrá aplikace, která běží pod Linuxem jako např. HWMonitor? Abych viděl teploty a rychlosti ventilátorů?
Jinak pod Linuxem asi nějaký antivir ani potřeba není, ne?
MB: ASROCK Fatal1ty Z370 Gaming K6 CPU: Intel Core i7-8700K @ 5,1GHz/4,9 AVX/4,6 cache; 1,41V Delid FAN: NZXT Kraken X62 RAM: G.SKILL 2x8GB DDR4 3800MHz @ CL16 TridentZ 1,5V GPU: Zotac GTX 1080Ti AMP Extreme Core Edition (11GB) SSD: Samsung 960 EVO 500GB, 850 EVO 500GB, 840 EVO 120GB HDD: WD Blue 2x4TB PSU: Corsair RM850i Case: Fractal Design Define R6 Black TG Monitor: BenQ XL2411Z
Re: Taktování RAM - DDR4 G.SKILL
Můžeš zkusit tohle: https://askubuntu.com/questions/15832/h ... emperature
3/4 roku jsem bez antiviru na Mint 18.1 a zatím jsem přežil. Třeba jsem přenašeč infekce, ale nevím o tom:). S instalací Wine se nebezpečí trochu zvyšuje, ale taky to mám a zatím mi disk nic nezašifrovalo.
S Wine spustím klidně benchmark pro windows https://www.techpowerup.com/download/super-pi/
Pěkný příkaz je inxi -Fxz
Nějaké další dva příkazy na co jsem narazil: xev, top
S výměnou zvukovky jsem přišel na příkaz alsamixer, kde se dá vyřešit problém se zvukem, když nepomohlo nastavení zvuku co se otvírá běžně z lišty.
Nějak se mi tam dostal i starý program co funguje jako parodie na aidu HardInfo 0.5.1.
3/4 roku jsem bez antiviru na Mint 18.1 a zatím jsem přežil. Třeba jsem přenašeč infekce, ale nevím o tom:). S instalací Wine se nebezpečí trochu zvyšuje, ale taky to mám a zatím mi disk nic nezašifrovalo.
S Wine spustím klidně benchmark pro windows https://www.techpowerup.com/download/super-pi/
Pěkný příkaz je inxi -Fxz
Nějaké další dva příkazy na co jsem narazil: xev, top
S výměnou zvukovky jsem přišel na příkaz alsamixer, kde se dá vyřešit problém se zvukem, když nepomohlo nastavení zvuku co se otvírá běžně z lišty.
Nějak se mi tam dostal i starý program co funguje jako parodie na aidu HardInfo 0.5.1.
-
- Mohlo by vás zajímat
- Odpovědi
- Zobrazení
- Poslední příspěvek
-
- 1
- 1431
-
od Gerete
Zobrazit poslední příspěvek
31 črc 2023 23:44
-
- 0
- 1534
-
od nakatomi
Zobrazit poslední příspěvek
26 pro 2023 19:30
-
- 3
- 2586
-
od Airen
Zobrazit poslední příspěvek
09 úno 2024 11:02
-
-
GIGABYTE B760 GAMING X DDR4 problém v BIOSE Příloha(y)
od filipo88 » 30 dub 2023 13:45 » v Problémy s hardwarem - 5
- 1345
-
od pcmaker
Zobrazit poslední příspěvek
03 kvě 2023 11:01
-
-
-
Pracovní stanice i9 9900, 48GB DDR4,RTX 4000 8GB,SSD+8TB HDD
od DeNNI85 » 25 črc 2023 10:10 » v P: Hardware - 3
- 2509
-
od DeNNI85
Zobrazit poslední příspěvek
20 srp 2023 18:41
-
Zpět na “Taktování a další úpravy PC”
Kdo je online
Uživatelé prohlížející si toto fórum: Žádní registrovaní uživatelé a 4 hosti