Inlägg

Av någon underlig anledning har många fått för sig att sämre boostande kärnor kan ges större negativ offset i curve optimizer och jag kan inte begripa varför, de kärnor i den CCD med bäst kvalité kan av naturliga skäl undervoltas/frekvens ökas mer än den med sämre kvalité.

Det är extremt vanligt att CCD0 kan klockas sådär 2-300MHz högre än CCD1 vid samma spänning, för curve optimizer är det samma sak, du kan ge den bästa ccd'n större offset än den sämsta, kombinerar du med ökad fmax så kommer du öka frekvens under last med så mycket som 400MHz vilket inte nödvändigtvis kommer vara stabilt. 5950x som redan har höga frekvenser i stock har betydligt mindre utrymme till frekvens ökning medan lägre modeller har mer/större utrymme.

Sen lär man tänka på att Curve optimizer inte kan stabilitetstestas som normal OC då det är en icke linjär kurva man pillar på och då lär man tekniskt testa alla lägen längs kurvan, det verkar dessutom som att det är absoluta botten och toppen som orsakar instabilitet, alltså extremt lätt last eller ingen alls. Att bara testa full load säger ingenting om stabilitet med curve optimizer

Finns en del 32GB moduler med dual rank, en del kör micron b-die eller andra 2GB chip.

Vill man vara riktigt noga kan man köra exempelvis OCCT med en kärnas last manuellt konfad & sen sätta affinity en kärna i taget & kika på "effektiv frekvens" för varje kärna, då får man lite mer varians mellan kärnor ofta & kanske lite bättre bild än boost tester kan ge, det är också en jävla massa mer manuellt arbete än just boost tester

Om jag inte misstar mig helt så är detta en metod att se om resize bar är aktivt, kika under egenskaper för gpu'n i fråga och resources, där ska man kunna se "Large Memory Range" om SAM/RE-size är aktivt.

https://i.imgur.com/3OAee9y.jpg

Är som sagt inte helt 1000% säker då jag inte kan validera det själv men enligt utsago från andra så verkar detta vara en bra metod att se det på.

Var inte menat på så vis nej, jag konstaterade bara det uppenbara ifall någon trott att man tweakar curve optimizer först för att sedan kolla i boost tester vilka man kan tweaka.

Helt OK, bara som notis så är bilden jag lade upp med stock settings i boost tester då det är meningslöst att kolla boost nivåer för att justera curve optimizer med redan tweakad curve optimizer, poängen är att med stock inställningar så kan man se vilka kärnor som potentiellt klarar högre boost och då är det en klar fördel att köra just stock i det läget. Sen kan man såklart kolla om det gör någon skillnad i boost tester efter justering men för att använda det som ett hjälpverktyg till curve optimizer så är det som sagt bäst med stock.

Boot problemet kommer sig av CSM, enligt vad jag läst mig till så kan CSM ställa till resizable bar eller vice versa, CSM brukar finnas någonstans under boot eller advance boot options, det är kort för compatibility support module tror jag & kan ge stöd för att boota med äldre hårdvara som inte är uefi kompatibelt exempelvis men kan också göra så att andra typer av kontrollers (usb ethernet osv) kan funka normalt. I vissa fall kan dock CSM leda till mer strul än det löser så per default bör CSM vara avslaget & när man slår på Resize bar & above 4g decoding (bägge ska vara på), så slås även CSM av. Jag kunde dock aktivera CSM manuellt även med resize och above 4g decode igång så det verkar bara vara att slå på eller av CSM som man vill/behöver. Har man installerat win10 med CSM påslaget så kan det vara svårt att avaktivera CSM & kunna boota. För min del verkar CSM på eller av inte påverka om jag kan boota eller ej trots att jag hade CSM igång så vad som gäller här verkar mer eller mindre bero på tur/otur.

Här syns var man kan hitta resize & above 4g på msi bord, bägge behöver vara aktiverade för att SAM ska funka.

https://i.imgur.com/pHmCdyb.jpg

Här kan man justera CSM

https://i.imgur.com/M1LyHXE.jpg

Med CSM avslaget så kan uefi kommunicera med GPU på annat sätt enligt följande integrerad drivare

https://i.imgur.com/Xlmcpsm.jpg

Om det är så att man måste köra med UEFI läge och inte CSM och man har installerat windows med just CSM aktiverat så kan det möjligtvis ställa till saker enligt vad jag läst men har inte kunnat testa det ännu själv då jag inte har någon AMD gpu som stödjer sam tillgänglig.

Nej inget särskilt, det är en vettig funktion och den ska som sagt komma till nvidias rtx 3000 serie också med nya drivare och detta i kombo med 1.1.9.0 agesan för Zen3 på ett 500 serien moderkort, resterande moderkort skulle få åtkomst till det senare enligt rykten. Även en del intel moderkort har nu tillgång till denna funktion också men än så länge bara med AMD gpu. Här har du en liten video om sam

Som synes kan det ge än mer prestanda i enskilda fall och faktiskt negativ prestanda skalning i andra men i merparten av spel ligger skillnaden som sagt 0-10% och hur mycket det skiljer blir helt & hållet beroende på spelet man kör för stunden. Det är lite som hardware gpu scheduler på det viset.

Än så länge är det väl bara AMD som lirar med detta då nVidia inte fått ut drivarna som sägs stödja det för 3k serien, men för AMD så landar prestanda boost på allt mellan 0-10% mer prestanda vilket ändå är en hel del sett till att det inte kostar något att slå på funktionen.

Kopierar det jag skrev i en annan tråd om detta, kör denna offset du ser till höger i tabellen, mitten i tabellen är bara det jag gissade mig till kanske skulle funka. Här har jag dock testat med lite elak last en kärna i taget och noterat effektiv frekvens, alltså inte boost tester.

Kör samma med större offset på bra kärnor och lägre på sämre, testade tvärs om bara för att validera det hela och det skapade instabilitet direkt vilket är fullt logiskt. Högre kiselkvalite medger större undervolt/högre boost helt klart. Med boost tester så slapp jag som sagt sätta manuell affinity en kärna i taget vilket var en jäkligt bra liten applikation.

Tipset från @34832 om BoostTester var inte så tokigt, smidigt litet program i kombo med HWiNFO för att se hur högt processorn kan boosta individuella kärnor.

https://github.com/jedi95/BoostTester

Så här ser det ut för mig när jag testar, som synes är CCD0 den bättre av de två och det matchar tidigare tester jag gjort väldigt väl, då har jag kört enkärne laster manuellt & satt affinity manuellt vilket är ganska tidskrävande, detta snabbar upp processen avsevärt och ger en snabb indikation på vilka kärnor man kan sätta kraftigare negativ offset på i curve optimizer

https://i.imgur.com/z16tFSM.png

Bet i det sura äpplet & testade precis nya 1.1.9.0 agesan på mitt MSI x570 Unify, det ser ut att fungera som tidigare faktiskt och det skiljer för mig inte speciellt mycket i prestanda, fick lite sämre multicore resultat men vi pratar 0,1% och single core låg på 679 i CPU-Z jämfört 680 med 1.1.0.0 agesan, detta kan dock bero på skillnad i rumstemp mer än något annat.

Nu kör jag med allt vad gäller minne helt manuellt konfigurerat och likaså spänningar samt manuellt justerad per core curve optimizer, kör man allt på full auto så kanske det blir större skillnader mellan dessa versioner.

Vad gäller WHEA fel så hade jag inga innan uppdatering så enda skillnaden vore om det plötsligt spottade ur sig fel och det ser det inte ut att göra heller.

Skillnaden för mig mellan de två är mer eller mindre bara det utökade stödet för resize bar som ska enligt utsago inkludera nVidia när de behagar fixa drivarna för det.

Provade lite snabbt med justerad PLL här på två olika moderkort, ett MSI och ett ASRock (bägge kör samma agesa), bägge blåvägrar boota så fort jag pillar på PLL alls, enbart auto som ger boot, milage may vary med andra ord vad gäller PLL tweak.

Det hela hänger mestadels på hur ofta du är gpu limiterad eller inte, är du till 99% gpu limiterad jämt så kommer man se mycket liten skillnad (eller ingen alls) mellan olika minnen & inställningar. Är man däremot sällan eller aldrig gpu limiterad så kan minnesprestanda vara klart märkbar.

Haha, ja där ser man, fullt logisk namngivning då Tänk att det ska vara så svårt & hålla konsekventa namn på saker oavsett tillverkare

Bra tips om att sätta högre PLL innan ökad FCLK ifall det inte vill boota med extrem FCLK

Lite gissning här men CPUVDD18 är troligen PLL och PM_1V8 är troligt en av chipset spänningarna (mobo chipset). De övriga benämnda PM ser nämligen ut som normala chipset spänningar.

PLL har tidigare varit något som bara gett effekt för LN2 klockare och specifikt med BCLK klockning, om det nu stämmer att PLL faktiskt kan stabilisera hög FCLK på Zen3 är det kalas Ska testa lite & lägga till detta i diverse guider i så fall, tack för tipset!