EPIA unter Linux übertakten

Hallo allerseits,

GANZ WICHTIG: Disclaimer weiter unten beachten!

Nachdem mein EPIA durch ein sempron-getriebenes ASRock-Board als VDR abgeloest wurde, habe ich sowohl einen stabilen VDR als auch ein EPIA ME6000 zum Basteln und Spielen uebrig. Es ist wieder in dem Playstation 2 Gehaeuse gelandet, das ich urspruenglich mal fuer den VDR gebaut hatte, ehe mir klar wurde, dass es mit nur einer PCI-Karte nicht wirklich Spass macht

Mit dem Epia habe ich jetzt mal ein paar Versuche gemacht, die vielleicht auch fuer andere spannend sein koennen, die sich darueber aergern, dass die Dinger so ewig brauchen, um Videos zu konvertieren oder einen Kern zu uebersetzen.

Das Schlagwort ist Overclocking.

Macht bei so einer lahmen Kiste natuerlich nur beschraenkt Sinn, andererseits ist ein EPIA auf geringen Energieverbrauch ausgelegt und laeuft somit sicher nicht so schnell in eine thermische Wall. Ein bisschen Google zeigt, dass man ein Epia muehelos per Software (WCPUID) durch Aendern des Multiplkikatos uebertakten kann - das BIOS unterstuetzt es ja nicht im geringsten. WCPUID ist Windows und damit nicht spannend. Ich habe allerdings in der Viaarena (genaugenommen in Googles Cache derselben) einen Beitrag gefunden, dass jemand den Kern so gepachted hat, dass es trotzdem geht. Allerdings hat er nicht gesagt, wie.

Also... das perfekte Projekt fuer einen Sonntagvormittag

Wenn man longhaul unter Linux benutzt, um die Taktfrequenz zu aendern, dann tut das ein C3 ueber den Multiplikator. Ein Blick in

/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

verraet, welche Frequenzen das sind:

399000 532000 465000 598000

(ME 6000, 600 Mhz). Ein bissel rechnen offenbart, dass wir hier die Multiplikatoren 3 bis 4,5 in 0,5er Schritten haben - FSB ist 133.

Als naechstes kommt dann das File

arch/i386/kernel/cpu/cpufreq/longhaul.c

in den Kernelquellen. Es offenbart in seinen Kommentaren Abgruende ueber Vias Hardwaredokumentation, zeigt aber auch, wie die Multiplikatoren ermittelt werden:

switch (longhaul_version) {
        case TYPE_LONGHAUL_V1:
        case TYPE_LONGHAUL_V2:
                /* Ugh, Longhaul v1 didn't have the min/max MSRs.
                   Assume min=3.0x & max = whatever we booted at. */
                minmult = 30;
                mult = maxmult = longhaul_get_cpu_mult();
                break;

Tja... Longhaul 1 und 2 machen es uns also GANZ einfach... (alles, was ich hier schreibe, gilt NUR dafuer, also nur fuer Samuel 1 und 2 sowie Ezra, NICHT hingegen fuer Ezra-T und Nehemia - siehe auch Kommentar am Anfang von longhaul.c).

Modifikation:

switch (longhaul_version) {
        case TYPE_LONGHAUL_V1:
        case TYPE_LONGHAUL_V2:
                /* Ugh, Longhaul v1 didn't have the min/max MSRs.
                   Assume min=3.0x & max = whatever we booted at. */
                minmult = 30;
                mult = longhaul_get_cpu_mult();
                maxmult = mult + 15;
                break;

Die Trennung von mult und maxmult laesst die CPU "normal" booten, solange man den Userspace-Governor drin hat, sonst schaltet sie gleich auf Overclock. "+15" erhoeht den Multi um 1,5, in meinem Fall also von 4,5 auf 6. Das ganze am besten als Modul laden... dann kann man besser testen, und dann schauen, was an Frequenzen geht;:

epia ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
399000 532000 465000 598000 731000 798000 665000

Also dann...

echo "798000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

und

epia ~ # cat /proc/cpuinfo 
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 7
model name      : VIA Samuel 2
stepping        : 3
cpu MHz         : 798.000
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu de tsc msr cx8 mtrr pge mmx 3dnow
bogomips        : 1602.47
clflush size    : 32

Voila... 800 MHz. 866 (6,5) kann diese CPU auch, gammelt aber augenblicklich ab, wenn man irgendwas damit tut.

Kommt also drauf an, was die individuellen CPUs koennen... das muss man VORSICHTIG austesten (mprime ist dabei ein gutes Mittel)... zum Testen empfiehlt sich ein modularer Kern mit Userspace-Governor, damit man ueberhaupt noch was sieht, ehe der Laden abstuerzt.

Noch zwei Hinweise: minmult hat sich bei mir nicht aendern lassen, es fuehrte zu einer Verschiebung des hoeheren Endes. Ich denke, das haengt mit der Art zusammen, wie der restliche Code die Multiplikatoren setzt... aber ich halte untertakten unter 400 MHz nicht fuer sinnvoll, zumal die Stromaufnahme im Idle schon bei 400 und 600 identisch ist. Ferner muss man nach jeder Aenderung des Bereiches NEU BOOTEN; da entladen/laden des Moduls nicht alle Tabellen neu setzt.

WICHTIG: Zum Schluss der Disclaimer:

- Uebertakten kann Hardware schaedigen
- Uebertakten kann Daten schaedigen
- Uebertakten kann zu unvorhergesehenen Ergebnissen fuehren
- Die Maschine kann ueberhitzen... auf keinen Fall ohne aktive Kuehlung oder staendiges Monitoring testen
- Vor dem Einsatz fuer wichtige Zwecke WENIGSTENS 24 h Burn-in mit mprime oder so
- Alles auf eigene Verantwortung... ich uebernehme keinerlei Verantwortung fuer die Folgen
- Obige Modifikation gilt nur fuer C3/C7 mit den Kernen Samuel 1, 2 und Ezra. Sie funktioniert nicht bei Ezra-T, Nehemia und neueren.
- Wie weit man kommt, haengt extrem von der einzelnen CPU ab. Meine laeuft bei 800 MHz noch stabil... bei 866 hingegen nicht mehr.

EDIT: Was die Performance angeht... beispielsweise kommt mein selbstkompiliertes Linpack statt auf 57 MFlops nun auf deren 76... also quasi lineare Skalierung. Speicherintensive Sache bleiben hingegen unveraendert... wir aendern ja nur den Multiplikator, nicht den FSB und auch nicht den Speichertakt.

EDIT 2: Nach 52 Minuten mprime auf 800 MHz:

FATAL ERROR: Rounding was 0.4962310791, expected less than 0.4
Hardware failure detected, consult stress.txt file.
Torture Test ran 52 minutes - 1 errors, 0 warnings.

Also... runter auf 733 und mprime wieder anwerfen.

Viele Gruesse,

Jan

Hallo allerseits,

hab mal den Titel weniger reisserisch gemacht.

Kleine Modifikation: Es ist im Grunde unnoetig, den maximalen Multiplikator auf die oben beschriebene Art aus dem aktuellen zu berechnen, zudem hat das bei mehrfachen Laden/Entladen das Problem, dass er immer hoeher geht (beim Entladen wird auf max geschaltet, dieses dann erhoeht...aber davon abgesehen scheint der Treiber auch generell in so einer Entlade/Lade-Situation einen Bug zu haben). Viel einfacher ist:

maxmult = 60

Wir wissen ja, was wir wollen... damit nageln wir z.B. ein Board mit FSB 133 auf maximal 800 MHz fest.

Meins laeuft seit gestern abends jetzt uebrigens bereits 13 Stunden unter Vollast mit mprime ohne jedes Problem auf 733 MHz... Kerntemperatur ist 68 Grad.

Zum Vergleich: Passiv gekuehlt in einem Gehaeuse mit einer grossen Lueftungsoeffnung direkt ueber der CPU und Luftnachfluss von unten kommt dieses ME6000 bei 600 MHz beim Kernelcompilieren auf ueber 90.

Noch ein Edit: Im Kernel 2.6.22 und folgenden ist die fragliche Stelle deutlich veraendert, es gibt aber nach wie vor die Ermittlung von mult aus dem aktuellen Multiplikator und dann maxmult=mult - das kann man also genauso aendern. Obige Quellauszuege stammen vom 2.6.20.

Viele Gruesse,

Jan

P.S.: Falls es jemand auch austestet, wuerde ich mich ueber Feedback freuen.

Hi,

(ich mach mal als Selbstgespraech weiter... wenn es jemanden nervt, einfach sagen)

Nach 18+ Stunden:

FATAL ERROR: Rounding was 0.4999694824, expected less than 0.4
Hardware failure detected, consult stress.txt file.
Torture Test ran 18 hours, 57 minutes - 1 errors, 0 warnings.

Auch ein Epia braucht also mehr als nur ein bisschen Kuehlung, wenn man es jenseits der Spec betreibt. Ich muss allerdings auch dazusagen, dass mein spezielles Exemplar nicht unbedingt den besten Speicher drin hat... es soll angeblich DDR266 sein, das Board akzeptiert ihn aber nur als DDR200 und laesst DDR266 erst zu, wenn man die RAM-Spannung leicht anhebt. Ist also auch ein bissel Speicher-Uebertaktung... kann also auch daran liegen (zumal es diesmal bei einem speicherintensiven Test gekracht hat). Ich werde das mal auseinandersortieren und weiter testen.

Viele Gruesse,

Jan

Hi,

ein Update fuer die Leser....

An der Temperatur alleine liegt es wohl nicht. Mit besserer Kuehlung (6 cm Luefter auf nahezu unhoerbar statt 4 cm Luefter auf nahezu unhoerbar) sinds 10 Grad weniger (63 C statt 73 bei 800 MHz) und DDR266 gab es sowohl bei 800 als auch bei 733 MHz nach etwa 11 Stunden jeweils Probleme.

Darum also jetzt ganz brav mit langsamen DDR200, denn mir draengt sich der Verdacht auf, dass das Board mit diesen Speichereinstellungen auch bei normalen 600 MHz nicht stabil laufen wuerde und es nur am RAM lag.

Schaun wir also mal...

Trotz meiner Probleme bei mprime - das ganze scheint zu lohnen. mprime erzeugt Last einer Dauer und Intensitaet fuer die CPU (weil es halt kein IO gibt, das die CPU zum Warten verdammt), die beide im Normalbetrieb nie vorkommen. Mal ein Video umrechnen oder noad laufen zu lassen wuerde bei 800 MHz muehelos gehen, ohne dass sich dadurch der Strombedarf wesentlich erhoeht (0-1 Watt im Idle, 1-3 Watt bei Vollast, jeweils netzseitig gemessen).

Wenn es jemanden interessiert, kann ich auch mal ein paar transcodier- oder compilier-Benchmarks machen.

Viele Gruesse,

Jan

Hi,

Quote

tolle arbeit die du hier machst, hut ab nur leider bleibt mir, mit verlaub, der sinn etwas verwehrt..

Der Sinn war fuer mich erstmal die Frage der Machbarkeit... also ob es geht und ob ich es kernelhackingmaessig hinbekomme. Dass es so trivial wird, hatte ich am Anfang nicht erwartet.

Quote

wieso will man grade aus einem der schwächeren epia boards mehr leistung rauskitzeln?
würde sich ja wenn überhaupt bei den boards mit > 1ghz lohnen, oder hab ich grad n brett vorm kopp?

Ob OC "lohnt", ist natuerlich eine andere Frage. Sobald die fragliche Maschine etwas tut, das irgendeinen wirklichen Nutzen hat oder Wert besitzt, wuerde ich davon dringend abraten, denn niemand kann garantieren, ob es gut geht und was sonst noch so alles passiert (z.B. inkorrekte Rechnungen, wie meine Tests mit mprime zeigen). Wenn das ganze aber keinen wirklich ernsten Hintergrund hat, sieht die Sache schon anders aus.

Ich weiss nicht, wie vielen es wie mir geht... das Epia gekauft und mehr erwartet, als es am Ende brachte. Wenn man dann noch am basteln ist und jede Compilation ewig dauert, dann nervt das irgendwann - gerade an der Stelle und gerade bei einem langsamen Board (das ja fuer das Aufnehmen usw. eigentlich reicht) sehe ich durchaus einen Sinn darin. 800 statt 600 MHz machen sowas wie Kompilieren, das auf einem Epia fast nur cpu-bound ist, um 1/3 schneller. Statt 40 min wartet man nur 30 oder so... Sicher... wenn man es vorher weiss, ist ein schnelleres Board immer die bessere Loesung (am besten gar kein EPIA), aber meist ist das Ding ja schon da.

Anderes Szenario... es fehlt bei dem Board, das man hat, gerade noch ein kleines Quaentchen, um ein MPEG4 oder so abzuspielen - auch hier kann ich mir vorstellen, dass selbst 666 statt 600 MHz den Unterschied zwischen "geht" und "geht nicht" ausmachen moegen (und 666 duerfte auf jedem 600er Epia absolut stabil gehen).

Bei schnelleren Epias duerfte es auch klappen... der "neue" (also 2.6.22) Code sieht fuer alle an der Stelle sehr gleich aus und sollte auf manuelles Setzen auch reagieren. Ich weiss allerdings nicht, wie nahe eine C7-CPU an der Grenze dran ist... zumindest die kleinen C3 sind es nicht. Eine halbe oder ganze Multiplikatorstufe (also 66 oder 133 MHz) duerfte aber immer gehen.

Gegenueber den "klassischen" OC-Loesungen hat diese hier uebrigens auch den Vorteil, dass man sie per SW triggern kann, also z.B. zu Beginn des Konvertierscriptes auf 800 MHz hochschalten, danach dann wieder runter. Wenn das nur ein paar Minuten laeuft, muss man sich da vermutlich nichtmal Gedanken drum machen...

Man koennte sogar ein kleines Programm basteln, das automatisch abhaengig von der CPU-Temperatur die obere Grenze setzt.

Sicher... alles nur Gedanken, keine wirkliche Rechtfertigung, aber vielleicht nutzen die ganzen Versuche dem einen oder anderem ja doch irgendwie.

Meine Motivation momentan ist Freude am Ausprobieren und Experimentiertrieb. Wenn es dann noch jemanden nutzt... das waere Klasse.

Ich hab da uebrigens noch eine Ideenbaustelle... erste Versuche dazu waren schon vielversprechend: Mit dem gleichen Treiber koennte man EVENTUELL eine C3/C7 im laufenden Betrieb undervolten (das gibt das BIOS der meisten EPIA ja nicht her). Man koennte vermutlich sogar die vorhandenen Spannungs/Frequenz-Tabellen aehnlich den Powernow- und Speedstep-Treibern mit sinnvollem Inhalt fuellen und damit automatisch untertakten/untervolten - das geht derzeit zumindest beim C3 nicht (also ds undervolten, untertakten geht natuerlich mit dem normalen Treiber). Ich hab zwar keine Ahnung, ob das messbare Einsparungen bringen kann... aber angucken lohnt vermutlich schon. Wenn mein C3 mit 1,25 V auf 800 MHz gut laeuft, dann tut er das vielleicht auch mit 1,1 V bei 400 MHz...

Viele Gruesse,

Jan

Ein Hallo an die tapferen Leser meiner Epia-Quael-Reports,

nun ist es "amtlich"...

FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file.
Torture Test ran 11 hours, 45 minutes - 1 errors, 0 warnings.

Das Epia lief dabei auf 600 MHz, mein gepatchter Treiber war nicht geladen und auch der Speicher war auf "auto" gestellt, also DDR200 mit langsamen Timings. Kuehlung war ein gedrosselter 6 cm Luefter von einem Toledo-Boxed-Kuehler, Kerntemperatur um die 57 Grad.

Das Teil kann also schon unter normalen Bedingungen den mprime-Stresstest nicht durchhalten. Sei es Speicher, sei es die CPU selbst... jetzt weiss ich, dass diese Kiste "getuned" mit DDR266 und 800 MHz ebenso stabil ist wie absolut serienmaessig, nur eben viel schneller.

Nur aus Interesse... hat jemand von euch schonmal einen Stresstest wie mprime oder memtest fuer wirklich lange (24+ Stunden) auf einem Epia erfolgreich laufen lassen?

Ich werde dem Ding jetzt mal mit einem Memorytester zuleibe ruecken... mal sehen, was es dazu sagt, ob es also eher ein Speicher- oder ein CPU-Fehler ist.

Viele Gruesse,

Jan

Hi,

Loop 1:
  Stuck Address       : testing   1FAILURE: possible bad address line at offset 0x013920ee.

Speicher ist nicht 100% iO... den hatte ich, wenn ich mich recht entsinne, hoechstens ganz zu Beginn meiner VDR-Zeit (siehe Anmeldedatum) mal getestet. Also... da muss "badram" drauf, damit kann man unter Linux defekte Speicherbereiche kernelseitig ausblenden und den Rest nutzen.

Gibt also erstmal eine Bastelpause, ehe ich mich dem Undervolting und weiteren Tests zuwenden kann.

Wobei... fragen kann man ja: Gaebe es eigentlich Interessenten fuer Software-Undervolting fuer die "kleinen" C3, also die aelteren Epias?

Viele Gruesse,

Jan

Hi,

Quote

Wenn mein Home-Server zu Nachtzeiten idled, dann legen sich die Platten schlafen. Toll wäre es, wenn auch die CPU ab regelt. Nun weiß ich auch nicht, ob das nicht mit neuerem Kernel von Hause aus möglich ist, da der Server seit einigen Jahren mit 9er SuSE rock-stable läuft (never touch running system) und ich da auch nicht experimentieren mag. Aber Sinn würde eine solche Lösung für mich schon machen. Das wäre dann mal eine Motivation einen Break zu machen.

Naja... ein ME6000 im Serientrimm kannst du mit selbigem Longhaul-Treiber (original) auf 400 MHz untertakten. Dazu musst du nur das ACPI-Zeugs installieren, Longhaul einbinden und den ondemand-Governor waehlen. Schon ist er bei "minmult" von 3x, also 400 MHz. Wenn er Leistung braucht, gehts auf "maxmult", also 4,5x -> 600 MHz automatisch hoch und danach wieder runter. Leider aendern die alten C3 dabei aber nicht die Spannung, ich glaube aber, dass das eher am Treiber als an der CPU liegt. Das werden wir aber bald wissen, wenn ich meine Kiste wieder stabil zu laufen habe (morgen kommt erstmal geborgtes DDR400 aus der Arbeit rein, um zu sehen, obs das RAM ist oder das Board).

Auf jeden Fall kann cpufreq mit dem Epia serienmaessig ein bissel was einsparen - wenn ich die Kiste in Betrieb habe, kann ich auch gerne Zahlen liefern.

Meine Versuche, den minmult unter 30 (also 3x) zu bekommen, sind schiefgegangen, das war aber bevor ich wusste, dass ich auf jeden Fall neustarten muss. Werde ich also auch versuchen, eventuell kommen wir auch deutlich unter 400 MHz.

Mein Fernziel ist, all das zu kombinieren - dann hat man Uebertaktung mit eventuell Ueberspannung, wenn man viel Leistung braucht, und Untertaktung mit Unterspannung sonst. Sozusagen sparsames Rasen.

Viele Gruesse,

Jan

Hi,

Quote

das ging damals mit dem alten 2.4er wohl noch nicht,

Glaube ich auch.

Zum Status: Meine Speicher ist definitiv kaputt. Mit einem geborgten DDR400-Riegel laeuft memtester problemlos durch, allerdings bekomme ich weder memtest86 noch memtest84+ zum Laufen, egal, mit welchem Speicher. Das koennte aber eventuell am Netzwerkboot liegen, es kann sein, dass pxeboot die Dinger nicht sauber laden kann. Das werde ich mit einem bootfaehigen USB-Stick mal noch testen.

Mit "mem=128m" laeuft die Kiste jetzt mit dem halben Speicher zumindest im Kurztest gut (bei 256 MB brach memtester sofort ab) - so duerfte es dann erstmal gehen (Langzeittest folgt noch).

Meinen Treiber werde ich auf den aktuellen 2.6.22 oder vielleicht auch besser gleich 2.6.23 uebertragen, denn da hat sich am longhaul ja was geaendert, so dass es nicht wirklich sinnvoll ist, beim alten zu bleiben.

Ich habe vorhin einen ersten Schnelltest gemacht... kleinere Multiplikatoren als 3 scheint der Treiber nicht zu moegen (also <400 MHz). Da muss ich aber noch ergruenden, woran es liegt, es mag sein, dass das wirklich nur treiberintern ist.

Es bleibt also spannend... jetzt wird erstmal ein Kernel gebacken, was bei dem Epia ja eine Weile dauert (mit 800 MHz ein bissel weniger, aber trotzdem).

Viele Gruesse,

Jan

Hallo,

ein kleines Update fuer die Leser:

Bin gerade dabei, einen badram-Kernel zu backen, nachdem ich memtest86 zum Laufen gebracht habe. Falls irgendwer von euch mal versucht, memtest86 oder memtest86+ per pxelinux ueber das Netz zu booten... benennt das memtest.bin-File so um, dass es nicht mehr .bin heisst. Dann klappt es auch... absolut seltsam, das.

Damit sollte ich dann wieder eine stabile(re) Plattform zum Testen haben.

Den Multiplikator kann man NICHT unter 3 bekommen, das unterstuetzt der C3 nicht und es ist auch keine Bit-Kombination dafuer vorgesehen (Datenblatt... hat nichts mit dem Treiber zu tun).

An der Sache mit den Spannungen bin ich noch dran - *eigentlich* sollte der Samuel 2 das koennen - mal sehen, ob wir ihn dazu zwingen koennen.

Bzw... mit beschraenkten Speicher hatte ich jetzt so 16 h problemloses mprime auf 800 MHz, dann einen Komplettfreeze. Beim Kernelbauen gibt es bei 800 MHz sehr schnell einen internen Compilerfehler, scheinbar ist das fuer den C3 doch ein haerterer Test als mprime (auch wenn ich bei einem anderen Rechner schon das Gegenteil erlebt habe). Bei 733 geht Kernelbauen stabil - wird weiter getestet, wenn badram laeuft.

Viele Gruesse,

Jan

Hi,

es sieht jetzt so aus, als sei zumindest die Hardware jetzt klar. Mit badram verliere ich 384 KB Speicher, ist also laecherlich wenig angesichts von 256 MB. Speichertester unter Linux laufen problemlos durch, egal, ob 600, 733 oder 800 MHz.

Kernelcompilieren geht auf 800 MHz nicht stabil, das System steigt nach wenigen Minuten aus. Auf 733 habe ich mehrfach erfolgreich durchkompiliert und auch mprime laeuft jetzt schon fast 20 Stunden. Das lasse ich noch weiterlaufen... hier inzwischen mal das Ergebnis des Kompilierbenchmarks:

600 MHz: 44:05 min.

733 MHz: 38:09 min

Jeweils Kernel 2.6.23 ueber NFS (100 Mbit), make wurde mit -j2 aufgerufen (das sorgt in der Umgebung fuer 100% CPU, da NFS-Wartezeiten auf diese Weise durch Kompilieren ueberdeckt werden. Ohne -j2 duerfte es etwas laenger dauern, habe ich aber nicht gemessen, weil es darum ja nicht geht.

Skaliert also fast linear mit der Taktfrequenz. Auf einem Gentoo-System kann man beim emergen auf diese Weise also die eine oder andere Stunde einsparen

Edit: Zum Vergleich... exakt der gleiche Kerneltree mit der gleichen Config braucht auf dem NFS-Server (Pentium 3 Tualatin 1200 MHz - mit Ausnahme des Notebooks derzeit mein schnellster 32-Bit-Rechner, alles andere laeuft unter Linux mit 64 Bit) ebenfalls mit make -j2 gerade einmal 12:18 min.

Viele Gruesse,

Jan

Hi,

Quote

hast Du mal während der Laufzeit die Temperatur über sensors überwacht?

Selbstverstaendlich... laeuft staendig mit. Ohne wuerde ich keine Uebertaktung riskieren und auch sonst bin ich da vorsichtig, gerade Dauerkompilieren belastet so eine CPU thermisch sehr.

Aktuell nach etwas ueber 20 Stunden mprime bei 733 MHz:

epia ~ # sensors
vt1211-isa-6000
Adapter: ISA adapter
VCore1:    +1.20 V  (min =  -0.03 V, max =  +2.71 V)   
+5V:       +5.03 V  (min =  -0.08 V, max =  +6.96 V)   
+12V:     +12.96 V  (min =  -0.18 V, max = +15.96 V)   
+3.3V:     +3.22 V  (min =  +0.00 V, max =  +4.18 V)   
System:      0 RPM  (min =    0 RPM, div = 2)          
CPU:      4398 RPM  (min =    0 RPM, div = 2)          
CPU TEMP:  +60.9 C  (high =  +196 C, hyst =   -67 C)   
temp2:     +49.0 C  (high =  +204 C, hyst =    +0 C)   
vid:      +1.250 V  (VRM Version 8.5)

(die min/max-Werte habe ich nicht konfiguriert)

Weiter oben hatte ich schon einige Temperaturwerte, diese hier sind mit einem per Vorwiderstand stark gedrosselten AMD64-Boxed-Fan gemacht. Die reale Luefterdrehzahl ist dabei nur die Haelfte dessen, was hier angegeben wird - zumindest habe ich den Vorwiderstand an dem ASRock-Board so gewaehlt, dass er auf etwas ueber 2000 kommt, ehe ich den Luefter dann wegen zu laut aus dem VDR verbannt und an das Epia gesteckt habe. Auf 800 MHz erreiche ich so 63...64 Grad, auf 600 bleibe ich unter 57. Frueher, mit einem gedrosselten 4 cm Luefter, hatte ich auf 800 ueber 70, woraufhin ich dann die Luefter umgebaut habe (daran lagen die Abstuerze aber dann ja doch nicht). Ohne Luefter kommt dieses Board in diesem recht gut beluefteten (aeh... da fehlt die Rueckwand und direkt ueber dem CPU-Kuehler ist ein grosses Luftloch) Gehauese bei 600 MHz beim Kerneluebersetzen auf ueber 90 Grad... soviel zu "luefterlos".

Fuer ein EPIA also sehr normale Temperaturen. Das Uebertakten macht dabei so arg viel nicht aus, der Sprung von 600 auf 800 MHz fuehrt gerade einmal zu 2 oder 3 Watt mehr aus der Steckdose.

Viele Gruesse,

Jan

Hi,

Quote

60 °C sollten OK sein ( ist doch die Diode im Kern?).

Dem Ansprechverhalten nach ja. Ich lese den VT1211 aus, der hat jene Diode vermutlich als Input.

Quote

Dann wird ihm wohl doch bei 800Mhz etwas Corespannung fehlen. Wenn die CPU wesentlich kälter wäre, hätte man auch den Lüfter so drosseln können, damit die zusätzliche Temperaturerhöhung das Leitverhalten etwas verbessert ohne Corespannungserhöhung. Hier aber bringt das sicher nichts mehr und ist zu sehr am Limit.

Habe ich indirekt auch probiert... mit dem anderen Luefter waren es 70 Grad und eher unstabiler. Vcore duerfte der Weg sein, den man nehmen muss... ich will ja ohnehin sehen, ob man das Voltage Scaling erzwingen kann (die CPU kann es prinzipiell, eventuell aber nicht richtig und eventuell das Board nicht... wird sich zeigen). Damit kann ich natuerlich auch nach oben korrigieren...

Viele Gruesse,

Jan

Hi,

Torture Test ran 68 hours, 48 minutes - 0 errors, 0 warnings.

So, das definiere ich jetzt als STABIL mit 733 Mhz.

Jetzt kommt der Rest dran (aber nicht mehr heute).

Viele Gruesse,

Jan