Overclock-Tester

[EvilDragon]

Hallööö,

ich bräuchte ein kleines Programm, bin aber kein Coder ,)

Hintergrund:
Ich möchte für einen kleinen Aufpreis Overclocking-getestete gp2x verkaufen.

Dafür bräuchte ich aber ein praktisches Programm. Ich hab nicht die Zeit, solange zuzuschauen, bis der gp2x stehen bleibt - ich bräuchte da ein kleines Programm.

Und zwar hab ich an einm Programm gedacht, welches bei 240 Mhz anfängt, immer 3 Minuten lang einen Testlauf macht (irgendwas machen, den Bildschirm mit bunten Farben füllen oder so, so dass man halt sieht, dass der gp2x noch läuft), dann in eine Textdatei schreibt "240MHz... 1 Minute Success! .... 240 MHz... 2 Minutes Success!", etc.
Also jede Minute (syncen nicht vergessen).

Die Clockspeed sollte dann alle drei Minuten um 5 MHz steigen und den Test weiterführen (vorher natürlich in die TXT-Datei schreiben, dass eine neue Geschwindigkeit angefangen hat).

Ich will also quasi einfach den gp2x ein paar Stunden rumliegen lassen und dann im Textfile nachschauen können, wo er denn abgestürzt ist.

Kann das jemand für mich machen?

Danke schonmal!

 

[funkyferdy]

Ich würd das Teil primzahlen berechnen lassen bis er kotzt

 

[B4N5H33]

gute idee ED, allerdings hinkt die theorie:

mein gp2x läuft z.b. bei gngeo stundenlang (genauer gesagt 3 std.) auf 275 MHz...ohne absturz. bei uae4all allerdings kommt es schon teilweise nach wenigen minuten zum absutrz bei 275 MHz (egal ob von hand per cpu_speed oder mittels menü übertaktet). ähnliche erfahrungen habe ich auch bei anderen emus gemacht. die schwankungen liegen immer im bereich von wenigen MHz - d.h. mit 276 MHz stürtzt der GP2X u.U. schon nach 23 min ab. auf 277Mhz nach 12, mit 278 nach 7 usw...

somit sind 3 minuten ein viel zu kleiner zeitraum um auf die OC-fähigkeiten der einzelnen GP2X zu schließen & es ist programmabhängig, wie lange der GP2X stabil auf einer bestimmten taktung läuft

wäre ja zu blöd, wenn du einen "290 MHz-certified GP2X" für teuer geld verkaufst und der kackt nach exakt 4 min bei 290 Mhz ab bzw. bringt es bei manchen emus nur auf 280 Mhz...

gruß

B4N5H33

 

[EvilDragon]

Naja, soweit hinkt das nicht:
Wenn ich die ca. Frequenz weiss, zieh ich nochmal 10 MHz ab, und die dürften sicher laufen.

 

[B4N5H33]

es war ja auch nicht so gemeint, dass ich das für ne schnapsidee halte. um den bereich einzugrenzen ist dieses tool sicher okay, aber um dem 2X einen sicheren OC-wert zuzuordnen mit dem er mehrere stunden lang mit allen verschiedenen programmen läuft ist zeitaufwendig (spreche da aus erfahrung).

ich denke mal das mit dem rechenaufwand ist auch ein einflußfaktor. bei komplexen berechnungen (wie z.b. primzahlen) wird er sicher schneller abkacken als bei nem counter der 3 minuten runterzählt.

wie gesagt, prinzipiell ist die idee sehr gut aber man müsste die CPU schon auslasten, um zuverlässige werte zu erhalten, die sich dann auch mit der lauffähigkeit bei emus vergleichen lassen

gruß

B4N5H33

 

[boeseronkel2k]

naja nur die cpu burnen zu lassen finde ich auch nicht ausreichend, denn der arm ist nicht der einzige chipteil, welcher unter der höheren taktung mehr beansprucht wird, sd kartenzugriffe, usb,...

 

[Octoate]

Naja, um die CPU etwas zu testen koenntest du dir ja z.B. den Client von distributed.net (http://www.distributed.net) downloaden. Das Ding braucht keine Workunits vom Dnetc Server, laeuft also auch ohne INet Verbindung und kann fuer eine in einer Konfigurationsdatei eingestellten Zeit laufen (z.B. 30min). Im Prinzip wuerde dann ein kleines Shell-Skript mit folgendem Ablauf reichen:

- CPU Speed setzen
- per 'echo' eine Ausgabe auf Konsole (kann ja in eine Log-Datei geschrieben werden)
- Client starten

Wenn der Durchlauf durch ist, kann man die CPU auf die naechste Geschwindigkeit setzen und wieder rechnen lassen.
Einen Absturz kann man dann auch daran erkennen, ob der GP2x die Konsolenausgabe von Dnetc noch ausgibt.

 

[hackgrid]

Warum eigentlich immer abstürzen?
Ich verwende dieses cpu_speed Dingens und wenn ich über 320Mhz geh taktet der einfach nicht hoch und bleibt beim Standardtakt. Abgekackt ist mir mein GP2x wegen Übertakten noch nie.

 

[EvilDragon]

Ja, weil über 320Mhz nicht im CPU_SPEED integriert ist
Aber viele gp2x kacken schon vorher ab

 

[Emu&Co]

Das Tool muss aber ins Filearchiv.

Ach btw. Das einige Programme früher andere später abkacken, hat mit der Auslastung zu tun. So ein Tool wie damals für den GP32, das die CPU auf 100% dreht, das brauchen wir.

 

[boeseronkel2k]

ich bin grad auf der suche nach dem sourcecode von dem lcd tweaker, doch finde nichts :twisted: dannach würd ich dann weiterschauen, ob ich das nicht nebenbeimachen kann
schreib nämlich momentan eine phyik engine

 

[god_at_hell]

Source ist beim Programm dabei ...

ED: Soll das alles grafisch sein oder reicht ne fixe Textapplikation. Dann würde ich das mit Primzahlen machen.

 

[infiltr8]

jo B4N5H33 ... hab das grad mal durchprobiert ... haste recht sind sogar recht große abweichungen .... zumindest zwischen uae4all und gngeo ... aber ich hab noch was bemerkt .. mit Akkus bei uae4all schneller Absturz als mit Netzteil .. wo gibts denn sowas? mit Akkus gehts 10Min@266MHz mit Netzteil haste 10Minuten bei 271MHz ... App: Pinball Fantasies Skid Row Cracktro

mfg
tom

 

[Digitalrat]

mit höherem takt brauchst du halt mehr strom, wenn die akkus den nicht liefern können sollte der effekt verständlich sein...

 

[infiltr8]

volle akkus .. natürlich .. der gp2x stürzt ab .. akkus sind aber frisch geladen ..

mfg
tom

 

[Digitalrat]

nicht jeder akku kann die volle leistung erbringen, auch nicht wenn sie voll aufgeladen sind

 

[infiltr8]

jo .. wie mans dreht und wendet .. Ben hat wohl Recht ...

mfg
tom

 

[god_at_hell]

ok ... hab da mal was geschrieben. Ist eigentlich ehr Flickwerk, aber ok.

Das Prog berechnet alle Primzahlen bis maximal 300000. Nach jedem Zyklus wird die CPU-Geschwindigkeit um 5mhz erhöht, der Output in eine Datei geschrieben und ein sync durchgeführt (per execl). Das ganze geht so lange bis der GP abstürzt. Die getestete Geschwindigkeit und die derzeitige Primzahl werden auf dem Bildschrim ausgegeben ... letzteres nur damit man weiß, dass der GP noch lebt. Am Anfang kann es zu GFX-Fehlern kommen, da ein Flip durchgeführt wird obwohl es im 2. Buffer noch keinen Hintergrund gibt. Dachte mir: "das sieht lustig aus" . Das Gleiche ist beim flackernden "XXXMhz checked" ... bin jetzt auch zu faul das zu ändern *G* ... es erfüllt ja seinen Zweck.

Der Primzahlenrechner ist recht optimiert und nutzt vorherig berechnete Primzahlen als Teiler anstatt alle Zahlen durchzugehen ... außerdem wird nur bis zur Quadratwurzel der zu untersuchenden Zahl verglichen und sofort zur nächsten gewechselt falls die Wurzel ganzzahlig ist.

Wichtig ist noch, dass die Dateiausgabe im "append"-Modus erfolgt. D.h. einer bestehenden "speed.txt"-Datei werden die neuen Einträge einfach angehängt. Man sollte die alte Datei löschen um nicht durcheinander zu kommen (z.B. Script vor der Ausführung).

Hm .. das scheint recht fressend zu sein... mein GP ist grade bei 275Mhz abgeschmiert obwohl er QuakeII mit 285 Mhz packt. Die Datei hat als letzten Eintrag den Wechsel zu 270Mhz und die erfolgreiche Primzahlermittlung bei dieser Geschwindigkeit .. der Wechsel zu 275Mhz wurde nicht hineingeschrieben, da der Dateiabschluss und Sync erst nach der "Check"-anzeige kommt.

Das Programm gibt es hier: http://www-users.rwth-aachen.de/markus.vehring/speedtest.zip

 

[Emu&Co]

Das Programm muss kaputt sein. Mein GP2X macht 310 mit und dein Prog kackt bei 270 ab. So wie bei dir...

 

[Moortier]

Das wird wohl daran liegen, dass ihn das Programm dann auch voll fordert und Quake vielleicht nicht...

Ist ja immer ein Unterschied, viele können ihren PC auf teilweise 5 Ghz bringen aber sobald sie dann was machen stürzt er ab. Also wäre das für Eds Zweck vielleicht garnicht so schlecht.