[Sammelthread] Offizieller AMD [[ RX6700 // RX 6700XT // 6750XT // X6800 // 6800XT // 6900XT // 6950XT]] Overclocking und Modding Thread [[ Wakü - Lukü - LN2]]

Das ist inzwischen mit dem MPT verschmolzen, seit VDDCI und MVDD dabei sind. Nur das Häkchen für den thermalen Controller fehlt..
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@Holzmann: Entspann dich, hast ja recht. Wenn du ein Video machen willst, dann natürlich freiwillig. :)

AMD kann nur künftige Treiber ändern, nicht existierende. Selbst wenn die's vermasselt haben, muss UL das Problem irgendwie lösen. Die können ja auch schlecht alle Treiber von z. B. 21.9.1 bis 21.11.1 vom Ranking ausschließen.

Bis dahin ist hier wohl Benchpause. Ich hab jedenfalls kein' Bock auf den Aufwand, wenn ein tolles nächstes Ergebnis nicht mehr beklatscht, sondern schief angesehen wird. 😕
 
Zuletzt bearbeitet:
can we somehow by edit PPT in regedit , can change this value ?
SMU_11_0_7_ODFEATURE_GFXCLK_LIMITS = 1 << SMU_11_0_7_ODCAP_GFXCLK_LIMITS , // GFXCLK Limit
value 1 is this same for 6700 / 6800/6900 ?
Sorry, i went too fast. This is the bit for the Overdrive Features on the first tab. It is a 32bit value, and the bits are shifted by the SMU_11_0_7_ODFEATURE_... values. The 1 is just notation, if you know the bit is shifted by n bits, you know where to write a 1 or a 0 to activate/deactivate the named feature. That is what the check buttons on tab 1 do.
..and again, too fast. The overdrive features are bytes, not bits. That would be the PPT features. But it is basically the same, the position where to write a 1 or 0.
 
Meins und das einiger anderer hier. Ich verstehe, was du sagen willst. Aber ohne ein gewisses Vertrauen in die Akkuratesse der Messungen und die Rechtmäßigkeit der Ergebnisse würden hier nicht eine ganze Reihe von Leuten jede Menge Kohle und Lebenszeit ins 3DMark-Benchen versenken.
Sorry, dass ich das jetzt nochmal hoch hole, war ne Runde spazieren: Ich kann natürlich nur für mich sprechen, aber für mich ist jeder Score legit, bevor jemand berechtigte(!) Zweifel anmeldet und das auch belegen kann. @snakeeyes hat sich selber bei UL gemeldet, wo ist also das Problem? Ganz im Gegenteil: Ich sehe das als sehr positiv.
Was weleh hingegen bei OCN schreibt: "Offenbar wurden auch bei weiteren Luxx Scores der Bug ausgenutzt" Achja? Bei welchen denn? Belege? Hinweise? --> Keine, also vermutlich doch nur ne leere Behauptung respektive Bullshit. Den Post hatte er auch geschrieben, bevor @Devcom seinen, später wieder gelöschten, Score hochgeladen hat.
Wir als Team-LUXX und in diesem Fall vor allem auch ihr als HOF-6900xt-Bencher sollten über so einem Blödsinn stehen. Darüber hinaus ist unsere Diskussion hier öffentlich für jeden einsehbar, jeder kann teilnehmen und der Großteil der Leute postet doch sogar seine kompletten Settings, wo manch anderer ein großes Geheimnis draus machen würde. Mehr Transparenz geht doch fast nicht.

So, fertig gemeckert.
 
Vermeer geht zwar bis 1.5v, allerdings nicht bei allcore load. Das sollte man immer nicht vergessen.
Eigentlich sollte man das vergessen, außer du redest vom SOC 🤔
Es existieren +30 aktive sensoren, aufgeteilt in 4-5 stages des throttlings

Vermeer's core range geht über 1.55v durch FIT tolleriert und über 1.68v im OC_Mode (auch durch FIT, welcher sich nicht komplett deaktiviert) tolleriert
Der maximale wert liegt weitaus höher im confidential Berreich
FIT-PRE throttle voltage (meistens dual CCD units triggern das), liegt je nach sample zwischen 1.45 und 1.5v
FIT-VID Boost cap liegt allerdings bei 1.4v und tiefer
Jeder kern welcher über 1.4v VID requested innerhalb momentanen "zuu strikten" limits und "zuu strikten FIT Scalar" ~ wird hard-frequency throttled
Dies hängt zwar zusammen mit dem CAC-Sensor, welches eine direkte verbindung zum EDC hat, aber halt auch "nicht nur"

Zuu lange geschichte
Zuu falscher thread
Zuu wenig Zeit gerade. 2 Tage damit verbracht einen defekten 5900X wiederzubeleben. Geht morgen nach DE zurück zZZ
======================================
Letzteres gehe auch an diesem OCN dude. Keine Angenehme ehmalige erfahrung gemacht, aber ich hab echt gerade zu wenig Zeit um mit ihm zu streiten

Es ist traurig dass er den ganzen research ignoriert (oder einfach wirklich ingorant ist ~ heh) und nicht rauslesen kann wieso der Unterschied so hoch ist
Naja über den Tesselation bug kann keiner was - aber ehrlich gesagt sollte man anfragen was nun "korrekt" sei ~ da die neuen driver ebenfalls andere Tesselation werte haben als die Ehmaligen
Kann ja echt nicht sein dass 3D-Mark keine fixen settings enforced, wenn AMD ebenfalls bei der Surface Optimization "cheated" ~ aber dann mit sowas kommt
Mein Beileid an alle LUXX nutzer mit invalid scores :(
 
Zuletzt bearbeitet:
@Techlogi: Ich stimme dir in jedem Punkt zu. Hattest du einen anderen Eindruck?
 
Eigentlich sollte man das vergessen, außer du redest vom SOC 🤔
Ich meine den Wert, den man zB mit HWinfo ausliest.
Schreib doch auf englisch, wenn es dir leichter fällt. :)
 

Anhänge

  • 1636413854394.png
    1636413854394.png
    2,8 KB · Aufrufe: 73
Nein, der Post war zuerst da. Ist doch aber egal jetzt. Beachtung bringt Verstärkung.
 
Du hältst das für falsch?
 
Naja, was heißt falsch? Ich würde eher sagen "nicht nötig", da es ja eher eine "teaminterne"* Liste ist und trotzdem jeder weiter bei UL hochladen kann.

*Mir ist natürlich klar, dass nicht jeder als [LUXX] bencht.
 
Der 21.11.1 hat auch den "Tesselation" bug ?
Ich mein wir können das direkt im driver.inf ändern, wenn 3D Mark irgendwelche speziellen anforderungen habe.
* die Paar werte welche ich damals gezeigt hatte, passen die signature & hash checks ~ brechen somit nicht WHQL und sind immer noch "signed" drivers

Nur ich kann nichts davon rauslesen
Wenn , dann ja ~ sollten sie alle scores mit den Treiben löschen. Gleiches Recht für alle :cautious:

Kann ja nun echt keiner was davon dass 3D Mark's "legit" Ansichten nun komplett anders sind, als das was AMD mit den Treibern ausliefert
 
Ok @Devcom hat gerade derbe rasiert. Das wars für mein Kärtchen.

2953 🤣. Naja somit ist er erste Favorit von mir dann vorne.
 

So jetzt ist nix verändert Tess, auf Anwendung Treiber 10.2 Windows 11

und auch gefilmt mit Wattman Einstellungen beim Start.
Hatte auch noch nie so einen Cpu score.
 
Was ich lustig finde. Ich wurde am 1.8 schon auf nen Discord angeschrieben, Bezüglich den Tess Bug . da wurde ich nur belächelt. Am 16 August habe ich UL mein Ergebniss mit 25.452 Overall gemeldet bezüglich meiner Vali des Laufes.

Der übrings immer noch keine Vali bekommen hat.

Und erst jetzt wo Snake sich dazu meldet , und das Public aus dem OCN Forum machen, soll gehandelt werden.
 
@Techlogi: Durch den großen Erfolg der Listenteilnehmer hier unterscheiden sich die besten Ränge zwischen 3DMark und unseren Listen kaum. Und nur weil [LUXX] drauf steht, muss nicht überall Ehrenhaftigkeit drin stecken. Es ist eine psychologische Tatsache, dass einfache Regelverstöße im gleichen Maß zunehmen wie das Risiko dabei ertappt zu werden abnimmt. Und das Ausnutzen des Tess Bugs ist nicht nachweisbar.

Bis jetzt waren wir (fast) alle im Glauben, dass sich durch Tess Off keine zusätzlichen Punkte erzielen lassen. Jetzt liegt der Preis aber auf dem Tisch und die Versuchung ist da. Selbst wenn jeder hier sich selbst für charakterfest genug hält, ihr zu widerstehen, kann er das von seinem Nächsten nur vermuten.

Die Ruhendstellung der Ranglisten soll uns schützen, und zwar vor gegenseitigen Verdächtigungen. Die müssen nicht mal laut ausgesprochen werden: Die Unsicherheit allein genügt schon, um Gedanken zu vergiften und aus Glückwünschen insgeheime Verwünschungen zu machen. Wer das für übertrieben hält, kennt die Menschen nicht, behaupte ich. ;)

BTW: Was glaubst du, wieviele PNs heute im Lauf des Tages schon zum Thema hatten, ob der Score dieses oder jenes Dritten wohl legit sei? Hast du wirklich keine bekommen? Glückwunsch. :)

Ich höre gern deine und weitere Meinungen dazu.
 
Zuletzt bearbeitet:

So jetzt ist nix verändert Tess, auf Anwendung Treiber 10.2 Windows 11

und auch gefilmt mit Wattman Einstellungen beim Start.
Hatte auch noch nie so einen Cpu score.
Mach mal folgendes, Lass den Treiber mal absichtlich abstürzen mit zu viel Takt . Dann Startest Du , und versuchst mit dem gleichen Takt einen Run( Wo Du sicher bist das er durch geht ). Ich könnte drauf schwören, das das Ergebniss schlechter aus schaut
 
@Devcom hast du mal folgende werte für mich? Gerne auch einfach nur mal mit gt2 laufen lassen, das reicht mir.

Spannung, Wassertemperatur, gpu Hotspot. Mit dem neuen rekord setting.
 
Jetzt muss der Videobeweis ran. :ROFLMAO:

Und die 27k sind wieder da. :-)
 
Es gibt einen Unterschied zwischen Bugrun oder nicht ,den man aber nur
1: mit dem EVC messen kann , oder mit einem externen Strommessgerät.
Sobald Tess on ist , steigt die Leistungsaufnahme gewaltig, grade in Verbindung mit einer Spannungserhöhung.
 
@ShirKhan Den Tess Bug gibt es ja nicht erst seit heute und ich denke, nur weil es nun ein Ergebnis in der HOF gab (welches vom User selbst erst an UL gemeldet und dann gelöscht wurde), müssen wir nicht in Panik verfallen. Stattdessen hier im Thread weiter research betreiben und das ganze (weiter) an UL und AMD melden.

Jetzt darf aber gerne auch nochmal jemand anders dazu was sagen. :)
 
Aber würdest du grundsätzlich auch sagen, dass mögliches Degrading bei niedrigen Temperaturen später, also erst bei höheren Spannungen einsetzen wird?
Temperaturen und Spannungen gehen hand in hand
- Dauer des spikes, ob 10-20ms oder <1ms
- Die "höhe" des Amperage's im Zusammenhang mit der Spannung (viel spannung, wenig current = fein, fast egal auf welcher temp)
- Die Dichte der Node, nm-nodesize , somit die chance an Kettenreaktionen zwischen "Gates"
- Die Zeit welche es ab/in 65c, 90c, 105c verbringt ~ den wie AMD schon meinte, 105c Hotspot "sind fein" , zumindest in den öffentlich genannten und programmierten limits

Am Schluss kommt noch die Silicon Lottery ins spiel ob Leaky Silicon oder nicht (je nach Fab und color change benimmt es sich anders, liebt spannung/hasst spannung)

Also generell auch bei RAM , bedeuted Voltage garnichts - fast nichts
Arriving Amperage, ist das wichtige ~ so ebenso bei Zen.
Voltage heißt auch nicht gleich Hitze , aber high input current kann manchmal helfen ~ wie wir es hier wohl machen dank dem VMIN mode

Normalerweise haben alle Zen units (GPUs too) mindestens 2 Emergency sensoren ~ komplett getrennt von OverCurrent Sensing units
Selbst wenn du FIT verbuggst und die oben genannten (Vermeer kern) limits fährst ~ also wo FIT nicht mehr zurückthrottlen kann und das wirklich ankommt
(nicht nur visuel gesendet oder requested wurde)
Dann besteht immer noch die Möglichkeit dass sich das Gerät im fail safe mode schaltet, und bei 550mhz zb, sind auch 1.8v potentiell je nach dauer, und sehr niedrigem Amperage (last) wert ~ komplett harmlos
Mit sehr vielen * dazugeschrieben

Das selbe sollte bei der GPU sein
Ich denke, man kann sie spike technisch auf weitaus höherer Spannung rennen
Solange die Karte nicht hardwaremäßig modifiziert wird ~ werden "tödliche !" spikes zum Kern rechtzeitig aufgehalten
Im besten Falle zwar garnicht erst gesendet, aber wenn ~ dann sicherlich aufgehalten. *

* Damit will ich nicht garantieren dass die Leute nicht derren Karte killen können mit MPT,
Aber logisch und designmäßig betrachtet, hätte sogar das Bios nicht genug zugriff eine tödliche Spannung zu senden (bitte nicht übertreiben) ** :(
** letztenendlich kommt es aber weiterhin drauf an "wie kalt war die karte, wie hoch war der Wiederstand und wie lange der spike anliegt (XOC wäre potentiel gefährlicher, da resistency fällt)

Degrading, ist ein "Zeit" Thema,
Es ist schwer etwas mit solch vielen Sensoren zu degraden. Besonders wenn es sich dann fast realtime mäßig anpasst und die spannungen selber niedriger stellt, bzw effective clock dropt
(aus XYZ "zu hohem" Grund)
Wirkliche "degradation" merkst du nur, wenn du die selben Ergebnisse im selben Raum, mit der selben Raumtemperatur, und potentiell der selben Jahreszeit (+1 Jahr) vergleichst.
Und selbst das garantiert dir nicht perfekte vergleiche, dass "degradation" daran schuld war und nicht einfach "external sources" wie zb anderers sauberer strom zu dieser Jahreszeit ~ deinen Boost verhindern.

Degradation ist ein langes langsames Thema, und wirklich rausfinden wirst du es nicht in der kurzen Zeit
Dafür kannst du alle variablen nicht issolieren welche gegen dich arbeiten und sich spannungs und frequenz technisch korrigieren :)
 
Zuletzt bearbeitet:
Fast der gleiche Takt , nur 21.7.2 Treiber


ebenfalls gleicher Takt nur 21.10.2


Bisher war der 21.7.2 der schnellste Treiber für Timespy.



Und bevor die Disku wieder aufkommt. Ich habe keinen als Cheater betitelt.

Selbst Rauf hat mit LN2 und einem 12900k@ Ln2 keinen so einen hohen GPU Score gehollt.
 
Zuletzt bearbeitet:
Win 11 schiebt die Cpu jetzt auch gut an

Verbrauch gesamt 1008W
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh