Join the ZenTimings & ZenStates Discord Server!
Check out the ZenTimings & ZenStates community on Discord - hang out with 760 other members and enjoy free voice and text chat.
[Sammelthread] Ryzen DDR5 RAM OC Thread
- Ersteller Reous
- Erstellt am
LuxSkywalker
Urgestein
halte ich für überholt die Regel
VDDIO = VDDQ
VDDQ < VDD
bringt auf meinem System Stabilität
VDDIO = VDDQ
VDDQ < VDD
bringt auf meinem System Stabilität
CrazyCookie
Enthusiast
bei meinem B650M-HDV/M.2 geht VDDIO nur bis 1,35V, denke das ist ein Bug. Ich kann nichtmal VDDIO=VDD=VDDQ machen. Also wenn ich alle 3 Werte zB auf 1,40v stelle hab ich dann 1,35v VDDIO und 1,40v VDD und VDDQ.
Ich denke der Bug limitiert mich auch bei meinem Memory OC, für 8400 hab ich schon teilweise echt miese Timings gebraucht und es wollte nie 100% stabil werden. deshalb bin ich jetzt auf 8000c38 runter, das ist stable as a rock.
Und wenn wir schon bei Bugs sind, Geardownmode und ProcODT Einstellungen im Bios sind bei mir auch ohne Funktion.
Ich denke der Bug limitiert mich auch bei meinem Memory OC, für 8400 hab ich schon teilweise echt miese Timings gebraucht und es wollte nie 100% stabil werden. deshalb bin ich jetzt auf 8000c38 runter, das ist stable as a rock.
Und wenn wir schon bei Bugs sind, Geardownmode und ProcODT Einstellungen im Bios sind bei mir auch ohne Funktion.
Das war bei meinem Taichi anfangs auch so, hat sich mit nem Update irgendwann erledigt.
Alter Asus standard.
VDDIO = < / = VDD_MEM
VDD2_CPU link aka VDDIO aka MC, ist eine eigene Spannung ~ erstellt in der CPU
VDDQ_MEM
& VDD_MEM sind eine eigene Spannung, erstellt auf der anderen Seite des Boards.
PMIC controller. Allerdings LDO's
VDDQ_CPU & VDDIO , können ähnlich sein ~ WENN VDDQ_MEM & VDD_MEM gleich sind.
Allerdings ist VDDQ_CPU automatisch bei AMD, und mitterweile rennen wir
Nur das wie gesagt, VDDQ_CPU auf AMD automatisch antrainiert wird.
Beide Werte
1185 & 1410 mV = nahe zu selbe (A)
Den Spannung bedeutet garnichts.
Es kommt auf die CPU impedance, und für VDDIO die procDQ impedance ~ an
VDDIO = VDD2 = DQ
Die Bedeutung.
VDD2 = DQ (CK, CA, CS) Vref
Es wird VDDIO genannt, da die APU mitversorgt ist.
Es bleibt eine LDO wie fast alle Spannungen. ProcODT als Haupt influencer von dem Rest.
Zuletzt bearbeitet:
Hallo ihr Lieben,
leider war ich beruflich bedingt unterwegs und hatte keine Zeit weiterhin RAM OC zu betrieben.
Ich freue mich zu sehen, dass das Forum noch lebt
Zu meinen Ungunsten habe ich ein Biosupdate (Gigabyte B650E) gemacht (F8 auf F21) welches ich mittlerweile wieder Rückgängig gemacht habe, jedoch sind leider alle meine Einstellung weg.
Von meinen Timings und Spannungen habe ich genügend Screenshots und auch hier im Forum zum Glück einen meiner letzten Posts.
Wenn ich in der Vergangenheit von 0 begonnen hatte, sah mein Weg wie folgt aus:
BIOS Settings: --> = BIOS Save and restart
iGPU off--> MCR off --> Power Down off --> GDM off --> Spannung setzen --> FCLK setzen --> Timings setzen --> fertig ( natürlich noch Tests und Co, aber im Bios wars das)
Aktuell bekomme ich MCR deaktiviert, jedoch nicht GDM und Power Down. Beim Start hänge ich dann im black screen und das Bios setzt sich wieder auf Werkseinstellung. (MCR ebenfalls wieder an)
Fast Boot Off
TSME Auto
TPM switch AMD CPU fTPM
IOMMU Auto
SVM Mode off
SMT Mode Auto
PSS Support on
PPC Adjustment PState 0
Global C-state Controll Auto
SMT Mode Auto
Power Slow Slew Rate Auto
CPU Vcore Loadline Cal. Auto
Async CPU/PCIe Clock off
GFX Glock Frequency Auto
PBO off
CSM Support Off
VDDG Voltage Control (CCD00 = 950 mV, IOD00 950mV)
CPU Clock Control Auto
Habe ich irgendetwas vergessen aktivieren bzw zu deaktivieren?
leider war ich beruflich bedingt unterwegs und hatte keine Zeit weiterhin RAM OC zu betrieben.
Ich freue mich zu sehen, dass das Forum noch lebt
Zu meinen Ungunsten habe ich ein Biosupdate (Gigabyte B650E) gemacht (F8 auf F21) welches ich mittlerweile wieder Rückgängig gemacht habe, jedoch sind leider alle meine Einstellung weg.
Von meinen Timings und Spannungen habe ich genügend Screenshots und auch hier im Forum zum Glück einen meiner letzten Posts.
Wenn ich in der Vergangenheit von 0 begonnen hatte, sah mein Weg wie folgt aus:
BIOS Settings: --> = BIOS Save and restart
iGPU off--> MCR off --> Power Down off --> GDM off --> Spannung setzen --> FCLK setzen --> Timings setzen --> fertig ( natürlich noch Tests und Co, aber im Bios wars das)
Aktuell bekomme ich MCR deaktiviert, jedoch nicht GDM und Power Down. Beim Start hänge ich dann im black screen und das Bios setzt sich wieder auf Werkseinstellung. (MCR ebenfalls wieder an)
Fast Boot Off
TSME Auto
TPM switch AMD CPU fTPM
IOMMU Auto
SVM Mode off
SMT Mode Auto
PSS Support on
PPC Adjustment PState 0
Global C-state Controll Auto
SMT Mode Auto
Power Slow Slew Rate Auto
CPU Vcore Loadline Cal. Auto
Async CPU/PCIe Clock off
GFX Glock Frequency Auto
PBO off
CSM Support Off
VDDG Voltage Control (CCD00 = 950 mV, IOD00 950mV)
CPU Clock Control Auto
Habe ich irgendetwas vergessen aktivieren bzw zu deaktivieren?
Zuletzt bearbeitet:
Hm, alles ja hochinteressant. In Verbindung mit den Spannungsangaben und Widerständen und low UCLK!
Habe meinen RAM getauscht um im hohen MT save zu sein. BIOS Update meines 4 DIMM Boards.
Habe nun 7400 mit IF 2200 UND LowLewel SOC (ehemals 1,265V bei 6400/2166, nun 1,1V bei 7400/2200) mit dem stabilstem RAM Setting am laufen. AIDA zeigt IMMER die "gleichen" Werte. Max Abweichung 10 MB / 0,1 ns. VDD 1,4 / VDDQ 1,42. Die niedrige VSOC Spannung bedeutet eine enorme Entlastung der CPU (ca 3-4 Watt weniger PP und 2-3 Grad kühler) und belastet nun eher das Board.
Es folgt dann 7600/2200 ohne großartigen Einfluss und geringem Performancegewinn, auch stabil mit gleichen Widerständen und ählichen Spannungen (VDDQ/VDDIO +0,01).
Ein Low-Level-Versuch mit 7800/2000 hat schon einmal gebootet und TM5 einen Durchlauf bestanden. Aber nur mit graziösem Einstellen der Spannungen und Widerständen. Eine echte Totur
.Hoffentlich gibt es bald BIOS-Updates, die auf meinem 7-Layerboard mehr möglich machen.
Ergänzung: 7800 mit etwas mehr VMEM läuft nun auch ohne Fehler. Aber nur mit laschen Timings. Denke die Signalwege des Board geben nicht mehr her.
Zuletzt bearbeitet:
Major2312
Enthusiast
Ich frage mich gerade, wenn die CLDO VDDP-Spannung zu niedrig ist, wie äußert sich das?
Direkter Absturz oder bootet garnicht erst?
Ob das TestMem5 mit Fehler "xy" anzeigt?
Direkter Absturz oder bootet garnicht erst?
Ob das TestMem5 mit Fehler "xy" anzeigt?
Fehler #5
Can be incorrect RTL training,
or on AMD too high/low cLDO_VDDP & ClkDrvStr causing tPHYRDL missmatch
TM5 1usmus
Wolf87
Experte
@Veii
@RedF
@LuxSkywalker
Ich hatte ja gesagt ich schreibe Kelutrel an wegen dem core to core Thema in Ropbench.
Anbei die Antwort von ihm.
It is not a bug. That is the core-to-core latency, not the RAM latency or the cache latency. It measures the time for a new byte written by core X to be available for reading by core Y (represented by the X and Y coordinates of that chart).
For example, on a 7950X, if you write a new byte value in a memory location with a CCD1 core, it will take 125-135ns for that new byte value to be "seen" by a CCD2 core. Because that new byte has to go through the three levels of the caches of CCD1 and up to the RAM, and then from the RAM down and through the 3 levels of caches of CCD2, so on average it will be double the ram latency plus some bits for traversing the caches, that is what the tool displays. In that chart, your CCD1 cores are top left, and your CCD2 cores are bottom right.
The values displayed are correct and pretty precise. Afaik there is nothing similar in AIDA64. That latency is also one of the reasons why AMD, on X3D models, limits a videogame on a single CCD even on dual CCD cpus. The latency between CCDs is so high that (depending on how much that game is memory intensive) the performances may suffer even with double the cores. Maybe the color is what made you worry, I should have used a blue tint probably.
If you want to measure the RAM and cache latency instead, in a similar way to AIDA64, you can click on the "RAM & Cache" button
@RedF
@LuxSkywalker
Ich hatte ja gesagt ich schreibe Kelutrel an wegen dem core to core Thema in Ropbench.
Anbei die Antwort von ihm.
It is not a bug. That is the core-to-core latency, not the RAM latency or the cache latency. It measures the time for a new byte written by core X to be available for reading by core Y (represented by the X and Y coordinates of that chart).
For example, on a 7950X, if you write a new byte value in a memory location with a CCD1 core, it will take 125-135ns for that new byte value to be "seen" by a CCD2 core. Because that new byte has to go through the three levels of the caches of CCD1 and up to the RAM, and then from the RAM down and through the 3 levels of caches of CCD2, so on average it will be double the ram latency plus some bits for traversing the caches, that is what the tool displays. In that chart, your CCD1 cores are top left, and your CCD2 cores are bottom right.
The values displayed are correct and pretty precise. Afaik there is nothing similar in AIDA64. That latency is also one of the reasons why AMD, on X3D models, limits a videogame on a single CCD even on dual CCD cpus. The latency between CCDs is so high that (depending on how much that game is memory intensive) the performances may suffer even with double the cores. Maybe the color is what made you worry, I should have used a blue tint probably.
If you want to measure the RAM and cache latency instead, in a similar way to AIDA64, you can click on the "RAM & Cache" button
@Wolf87
Makes sense if he tests L1D to L3 to Cache to L1D back
While i hoped for L1D or if bigger command ~ L2 to L2 betweeen cores.
// Where there are 1 op (zero delay) transfers and normal (long dly) transfers
L3 is shared, soo tracking is difficult
Most commands get broken down into chunks and allocated ~ without ever leaving cache
To my understanding
That should happen on all games, which is what can expose unstable CO or FCLK Package throttle
But i think if the understanding was to target mem oc effectiveness.
~ the cache to mem to cache approach is something that can visualize when MCLK pushing makes sense or not
Hmm difficult.
Optimally would be if both ways are testet and displayed as different visual examples, as this L$ - MEM - L$ , method already should be similar to Cache & RAM test.
Yet nothing of both should actively show FCLK Throttle ~ given that part is load balanced and may not be easily viewed as unstable (low load?)
EDIT:
If we do aim to show dynamic throttle into access time values
Internal testing should not leak to mem.
Above test is an alternate approach for very likely correct target, yet not what i was personally looing for as SiSandra replacement.
// And it will explain why values are different too. We look at two different questions.
Makes sense if he tests L1D to L3 to Cache to L1D back
While i hoped for L1D or if bigger command ~ L2 to L2 betweeen cores.
// Where there are 1 op (zero delay) transfers and normal (long dly) transfers
L3 is shared, soo tracking is difficult
Most commands get broken down into chunks and allocated ~ without ever leaving cache
To my understanding
That should happen on all games, which is what can expose unstable CO or FCLK Package throttle
But i think if the understanding was to target mem oc effectiveness.
~ the cache to mem to cache approach is something that can visualize when MCLK pushing makes sense or not
Hmm difficult.
Optimally would be if both ways are testet and displayed as different visual examples, as this L$ - MEM - L$ , method already should be similar to Cache & RAM test.
Yet nothing of both should actively show FCLK Throttle ~ given that part is load balanced and may not be easily viewed as unstable (low load?)
EDIT:
If we do aim to show dynamic throttle into access time values
Internal testing should not leak to mem.
Above test is an alternate approach for very likely correct target, yet not what i was personally looing for as SiSandra replacement.
// And it will explain why values are different too. We look at two different questions.
Zuletzt bearbeitet:
abbrechen musste ich nichts, ist alles verklebt. Rückbau wäre möglich, dann müsste ich mir Pads besorgen, die sind nicht mehr verwendbar.
Hab mir von Alphacool Heatspreader bestellt. Die sind recht massiv und teste gerade, wie warm die jetzt werden. Ob das überhaupt sinnvoll war, wenn ich die nicht in eine WAKÜ einbinde (werde ich nicht tun) sei mal dahinhgestellt. Der Basteldrang war stärker.
Hab mir noch zwei 40mm Noctua Lüfter bestellt, die kommen nächste Woche. Allein ein CaseFan im Deckel Richtung RAM blasend hat schon mit den Original Heatspreadern ca 7 Grad gebracht. Ich denke mit direktbewindung kann ich dann Richtung 1.6v gehen.
Hab mir von Alphacool Heatspreader bestellt. Die sind recht massiv und teste gerade, wie warm die jetzt werden. Ob das überhaupt sinnvoll war, wenn ich die nicht in eine WAKÜ einbinde (werde ich nicht tun) sei mal dahinhgestellt. Der Basteldrang war stärker.
Hab mir noch zwei 40mm Noctua Lüfter bestellt, die kommen nächste Woche. Allein ein CaseFan im Deckel Richtung RAM blasend hat schon mit den Original Heatspreadern ca 7 Grad gebracht. Ich denke mit direktbewindung kann ich dann Richtung 1.6v gehen.
Nemetron
Experte
- Mitglied seit
- 31.12.2021
- Beiträge
- 1.135
Die schwarzen Stücke oben links sehen so aus als ob sie abgebrochen sind, daher frage ich.
Die AC-Kühlkörper sehen schonmal klasse aus.
Das sowas nichts werksmäßig verbaut wird, immer dieses Plastik.
Die Temperaturen liest du dann auch im Hwinfo aus oder?
Die AC-Kühlkörper sehen schonmal klasse aus.
Das sowas nichts werksmäßig verbaut wird, immer dieses Plastik.Die Temperaturen liest du dann auch im Hwinfo aus oder?
schlecht zu erkennen. Das sind auch so softe Pads, die auf der Rückseite des PCBs auf Höhe des PMICS waren.
ja genau.
Nemetron
Experte
- Mitglied seit
- 31.12.2021
- Beiträge
- 1.135
Also meine Crucial Pro DDR5-5600-CL46 Kits gehen mit 1,11 V auf~34 °C. Welche Temperaturen hast du mit dem Kit vorher gehabt?
Vor allem die Gesamtleistung würde mich mal bei den OC-Kits interessieren. ^^ Die muss ja weit über 1 W sein.
Vor allem die Gesamtleistung würde mich mal bei den OC-Kits interessieren. ^^ Die muss ja weit über 1 W sein.
Zuletzt bearbeitet:
funkflix
Legende
@gimme7
Falls du nicht eh schon nen Lüfter drüber hattest, wird das leider relativ wenig bringen.. Aber Basteldrang verstehe ich!
Ohne großartigen Airflow dauert es halt nur ein paar Minuten weniger bis sie warm werden, und irgendwann hast du die selbe Temperatur wie vorher. Hatte schon lange keine Wakü mehr auf meinen RAMs, erst
mit DDR5 jetzt wieder und das Zeugs geht halt einfach nicht höher als 10°K über Wassertemperatur, das ist schon nett. Wieviel es jetzt tatsächlich taktseitig bringt, ist natürlich wieder die andere Frage.
Ich geh da übrigends deutlich "rabiater" vor, aber eventuell auch nur weil ich schon sehr viele HS abgemacht habe.. Einfach 2-3 Minuten mit der kleinen Heißluftpistole drauf und dann mit "Gewalt" abziehen,
klappt i.d.R. ohne Probleme.
Falls du nicht eh schon nen Lüfter drüber hattest, wird das leider relativ wenig bringen.. Aber Basteldrang verstehe ich!
Ohne großartigen Airflow dauert es halt nur ein paar Minuten weniger bis sie warm werden, und irgendwann hast du die selbe Temperatur wie vorher. Hatte schon lange keine Wakü mehr auf meinen RAMs, erst
mit DDR5 jetzt wieder und das Zeugs geht halt einfach nicht höher als 10°K über Wassertemperatur, das ist schon nett. Wieviel es jetzt tatsächlich taktseitig bringt, ist natürlich wieder die andere Frage.
Ich geh da übrigends deutlich "rabiater" vor, aber eventuell auch nur weil ich schon sehr viele HS abgemacht habe.. Einfach 2-3 Minuten mit der kleinen Heißluftpistole drauf und dann mit "Gewalt" abziehen,
klappt i.d.R. ohne Probleme.
ja, das erwarte ich auch. Nach 60min Karhu ist es noch ca. 7 Grad kühler als mit den alten Heatspreadern. Airflow bleibt trotzdem Pfilcht, wenn es >1.4v geht.
mein Alltagssetting mit 1.4v braucht noch keine aktive Kühlung. Das lief ganz normal. Aber als ich dann die Timings noch angezogen habe wurde es ab ca 48 Grad instabil beim Stresstest. Da hat schon ein bisschen Airflow über den RAM geholfen.
Nemetron
Experte
- Mitglied seit
- 31.12.2021
- Beiträge
- 1.135
Dann wird der SPD Hub bestimmt nicht die richtige Baustein-Temperatur anzeigen. Eigentlich müssen die DRAM-Bausteine auch so 90 °C bis 110 °C schaffen. Interessant, dass es dann ab 48 °C. Klasse danke.
3,5 W sind auch mal eine Ansage. 3,512 / 0,668, das ist mehr als 5x. Unglaublich.
3,5 W sind auch mal eine Ansage. 3,512 / 0,668, das ist mehr als 5x. Unglaublich.
funkflix
Legende
Hab jetzt ma spasseshalber 1.68V Vdd auf die RAMs gejagt, aber bei Wakü passiert da einfach garnix, die ~ 12W Verlustleistung erhöhen nicht mal auf Dauer signifikant die Wassertemperatur..
Watt zu Hitze waren schon immer ein schwieriges Problem.
Der PMIC kann zwar aus dem 5V Input, die ungefähre Verbrauchsleistung aus den SWA,SBW,SWC (+SWD) LDO's rauslesen & mathematisch runden (Watt wird /h ausgerechnet)
Jedoch fehlen UDIMM Sticks die Temperatursensoren (TS) zwischen beiden subchannels (links/rechts pro Seite) ~ um die genauen Thermischen Verluste bzw erhöhtem Stromverbrauch auszurechnen.
In der Realität liegen etwa 12-15° zwischen den IC Bausteinen und dem Spannungswandler (PMIC)
Sowie können die ICs weitaus mehr verbrauchen als die 5V Rail es angibt.
Die Spannungen von dem Mainboard (24pin) bis zu dem PMIC (eine kurze Strecke)
Sowie die Spannungen von dem Memory Controller ausgehend, über dem Mainboard, zu den Dimm-Slots
Wird als Bi-Directional Rail (32+7+21 Traces) mit den schon anliegenden Spannungen von dem PMIC innerhalb des RAMs ~ synchronisiert.
Die Daten Kommunikation geschieht somit in den Differentialschienen (differential rail) ~ zwischen einem Signal High (HI) & Signal Low (LO)
Der Rest der Kommunikation erfolgt über dem i²c Bus von dem SPD-Hub. Bzw im Server Segment wären das 12v & i³c.
Aufgrund dessen kann man zwar den Isolierten Input vorhersagen;
Dennoch wird dies niemals den echten Stromverbrauch des gesamten Sticks darstellen.
Abseits davon dass man Watt/sec nicht messen kann. Sondern nur pro Stunde.
Und "12W" sich nicht exakt als Temperatur übersetzen lassen können, Aufgrund der Transistordichte eines einzelnen ICs.
Jeder dieser (1 Transistor 1 capacitor) Zellen muss seine Daten zeitlich halten und auf Abfrage abgeben.
Eine Bank ~ hat 65536 solcher Transistor-Zellen.
Der PMIC kann zwar aus dem 5V Input, die ungefähre Verbrauchsleistung aus den SWA,SBW,SWC (+SWD) LDO's rauslesen & mathematisch runden (Watt wird /h ausgerechnet)
Jedoch fehlen UDIMM Sticks die Temperatursensoren (TS) zwischen beiden subchannels (links/rechts pro Seite) ~ um die genauen Thermischen Verluste bzw erhöhtem Stromverbrauch auszurechnen.
In der Realität liegen etwa 12-15° zwischen den IC Bausteinen und dem Spannungswandler (PMIC)
Sowie können die ICs weitaus mehr verbrauchen als die 5V Rail es angibt.
Die Spannungen von dem Mainboard (24pin) bis zu dem PMIC (eine kurze Strecke)
Sowie die Spannungen von dem Memory Controller ausgehend, über dem Mainboard, zu den Dimm-Slots
Wird als Bi-Directional Rail (32+7+21 Traces) mit den schon anliegenden Spannungen von dem PMIC innerhalb des RAMs ~ synchronisiert.
Die Daten Kommunikation geschieht somit in den Differentialschienen (differential rail) ~ zwischen einem Signal High (HI) & Signal Low (LO)
Der Rest der Kommunikation erfolgt über dem i²c Bus von dem SPD-Hub. Bzw im Server Segment wären das 12v & i³c.
Aufgrund dessen kann man zwar den Isolierten Input vorhersagen;
Dennoch wird dies niemals den echten Stromverbrauch des gesamten Sticks darstellen.
Abseits davon dass man Watt/sec nicht messen kann. Sondern nur pro Stunde.
Und "12W" sich nicht exakt als Temperatur übersetzen lassen können, Aufgrund der Transistordichte eines einzelnen ICs.
Jeder dieser (1 Transistor 1 capacitor) Zellen muss seine Daten zeitlich halten und auf Abfrage abgeben.
Eine Bank ~ hat 65536 solcher Transistor-Zellen.
Zuletzt bearbeitet:
The file in attachment contains version 1.71 of the RopBench tool.
The SHA-256 of the original archive is: b824fc9745d5056426b6e3ed99b96c6d262ebc816a6500eeb1f46881d99614b3
This is just a minor update. In this version:
The SHA-256 of the original archive is: b824fc9745d5056426b6e3ed99b96c6d262ebc816a6500eeb1f46881d99614b3
This is just a minor update. In this version:
das setting über diesem Beitrag hat in 25 cycles 5 Fehler geworfen. Hab festgestellt, dass Linpack 8GB Stresstest nach 2 Minuten fehlerhaft war. Erhöhung der VSoc hat Abhilfe geschaffen.
VDD aktuell auf 1.57, VDDQ 1.55, VDIO 1.45v
Ne Idee, was ich noch probieren kann?
VDD aktuell auf 1.57, VDDQ 1.55, VDIO 1.45v
Ne Idee, was ich noch probieren kann?
Suspect tWR being too slow (lower value required)
mostly affects the first 5 main timings
- noticed it can be tRCDWR to RD, can be tRP too,
but it also can be the last two tRDWR & tWRRD
which don't play well with your main tRCDWR/RD
#10 at the very start = increase RTT_NOM to something stronger
Versuch mal RTT Nom
ok, die sind beide OFF, also mal mit dem niedrigsten Zahlenwert probieren (habs nicht so mit elektrik)?
Die Fehlerbeschreibungen kommen ja noch aus DDR4 Zeiten. Ist das auf DDR5 anwendbar?
Jetzt läufts gerade mit 0,02v mehr VSoc nochmal und ist im 6ten Cycle. Fingers Crossed.
Die Fehlerbeschreibungen kommen ja noch aus DDR4 Zeiten. Ist das auf DDR5 anwendbar?
Jetzt läufts gerade mit 0,02v mehr VSoc nochmal und ist im 6ten Cycle. Fingers Crossed.
Ähnliche Themen
