Erster Blick auf das Kühlsystem der ACA1240/1260

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Uuuuuuu die bustest gerade erst gesehen für ACA1260@100Mhz. Die ChipRam-Werte sind ja identisch mit der BFG9060, also sensationell aus meiner Sicht :) Die FastRam-Werte müsste ich nochmal sichten. Sind echt top aus!

  • Hallo Jens, ich habe letzte Woche eine Warp bekommen und mache gerade einen kleinen Benchmarkmarathon und würde gerne die ersten Daten von der ACA1260 mit aufnehmen. Das Sysspeed Modul habe ich mir schon gesehen - interessant wäre auch ein AIBB Modul. Falls du Zeit hast wäre es klasse wenn, du mit AIBB 6.6 auch ein Modul erstellen und anhängen könntest - die 6.6 ist 060 kompatibel. Ich würde natürlich angeben, dass die Ergebnisse aus dem Prototypenstadium sind. Ideal wären zwei Module - wenn möglich einmal mit 66Mhz und einmal mit MaxSpeed. Die Vergleichskanditaten sind Warp1260 im Test mit 66Mhz und 105Mhz, B1260 mit 66Mhz, V1200 X12 Core 2.17 und eventuell nehme ich noch die Icedrake rein, die ist aber mit X13 ziemlich nahe an der V12. Getestet wird mit Sysspeed, AIBB, Bustest, MachineRecords MacOS, RSCP, Quake und TFX. Anbei die AIBB 6.6

    AIBB66.lha

  • Ich habe mich noch nicht auf die Suche gemacht nach einer Rev.6 CPU die 105MHz schafft. 100MHz geht, aber darüber hängt's sobald setpatch die MMU Tabelle initialisiert. Das ist ziemlich sicher eine Einschränkung dieser CPU, denn wir können "von außen" nichts machen, was die MMU


    Wir arbeiten aktuell am SD-Kartencontroller der ACA1240/1260, und ich habe meine Testkarte so eingestellt, dass sie mit 95MHz startet. Mein AIBB identifiziert sich als V6.5 und zeigt den 68060 als 68040 an. Woher kommt diese 6.6er Version?


    Jens

  • Ich habe mich noch nicht auf die Suche gemacht nach einer Rev.6 CPU die 105MHz schafft. 100MHz geht, aber darüber hängt's sobald setpatch die MMU Tabelle initialisiert. Das ist ziemlich sicher eine Einschränkung dieser CPU, denn wir können "von außen" nichts machen, was die MMU

    Auf Grund der bisherigen Fast und Chipmem Werte würde ich erwarten, dass die ACA1260 bei 95Mhz in einigen Bereichen trotzdem schneller ist als die Warp bei 105Mhz. Die Quake Ergebnisse dürften das auch so zeigen. Geht ein Test mit 66Mhz - oder ist der Wert derzeit fix auf 95Mhz? Das macht dann alle drei 060 Karten besser vergleichbar.


    Woher kommt diese 6.6er Version?

    Die hat jemand aus dem EAB gepatcht - wenn ich mich nicht täusche war es Speedgeek. Ich teste alle Karten mit dieser Version.

  • Habe die V6.6 flott rüber kopiert und ein Modul mit 95MHz gemacht. Seit dem Dezember-Update des Cores hat es am CPU/RAM Subsystem keine Änderungen mehr gegeben - das "Januar 2024" stimmt natürlich trotzdem, weil wir am SPI/SD-Controller ("Franken-SPI", weil er kombiniert 1-bit und 4-bit kann) gearbeitet haben.


    Wir haben zwar grundsätzlich noch die Möglichkeit, einen Wait state aus dem ersten Zugriff eines Burst heraus zu kürzen, aber dafür brauchen wir Zeit - so eine Änderung kann auch als Flash-Update ins Feld ausgerollt werden, wenn wir mit der Karte auf dem Markt sind: First make it work, then make it fast. Wichtig ist, dass nicht die Architektur bremst, sondern ein Teil, der im FPGA-Code geändert werden kann.


    Ich halte schnellen Massenspeicher für mindestens ebenso wichtig wie eine schnelle CPU. Wir booten (fast) alle unsere Systeme noch mit rund 2,3MByte/s, aber es sollte doch mindestens zweistellige MBytes pro Sekunde werden. Das 4-bit Protokoll ist auf unterster Ebene schon reichlich komplex: jedes Kommando und jeder Block-Transfer wird mit einer CRC abgesichert, was ich nicht von der CPU machen lassen möchte, weil das unnötig Zeit kostet. Der SD-Controller erzeugt/prüft die CRC schon automatisch und arbeitet mit einem lokalen DMA-Puffer. Trotzdem ist da noch Arbeit zu machen, bevor wir überhaupt an ein Amiga-Device denken können - wieviel, kann ich erst sagen wenn wir fertig sind. SD-Karten im 4-Bit Mode sind mit dermaßen viel Overhead und widersprüchlicher Dokumentation gesegnet, das geht echt auf keine Kuhhaut...


    Jens

  • Geht ein Test mit 66Mhz - oder ist der Wert derzeit fix auf 95Mhz?

    Es gibt auch einen 66MHz-Core, aber der ist praktisch gar nicht optimiert und er läuft nur mit 66MHz Speichertakt. Entsprechend langsam sind die Werte. Da müsste eigentlich mehr gehen, wenn wir den Speicher bei 133MHz laufen lassen, aber das gehört auch in den Bereich "first make it work, then make it fast". Leseperformance aufs Fastmem ist nur bei knapp über 56MByte/s.


    Der 60MHz Core mit 120MHz Speichertakt macht immerhin 62MByte/Sekunde Leseperformance aufs Fastmem, ist aber natürlich rund 10% langsamer (als 66MHz) bei CPU-intensiven Dingen, die eine hohe Cache-hit Rate haben. AIBB Modul ebenfalls angehängt.


    Jens

  • Ich halte schnellen Massenspeicher für mindestens ebenso wichtig wie eine schnelle CPU. Wir booten (fast) alle unsere Systeme noch mit rund 2,3MByte/s, aber es sollte doch mindestens zweistellige MBytes pro Sekunde werden.

    Absolut - deswegen nehme ich auch Sysspeed, RSCP und einen "realen" Lesetest mit Stoppuhr. Solche Tests müssen mit der ACA dann folgen wenn die Hardware draußen ist - bisher waren die ACA aber da immer sehr gut.


    Danke auch für die "langsameren" Tests - ich schau mal wie das im Vergleich zum Rest aussieht. Ich verlinke in meinem Test dann auch hierher damit die User auch die Kommentare nachvollziehen können, bzw. lege ich hier einen Link zum Test.

  • Ich würde noch etwas "kompilieren" hinzu nehmen, denn da spielen Massenspeicher, CPU und RAM eine Rolle. Sowas wie "einmal <make clean> für AWolf": http://aminet.net/package/game/shoot/AWolf3D_src (beliebige andere Quelltexte gehen auch, aber klassische, große Projekte sind meiner Meinung nach am besten geeignet, um wirklich zu vergleichen).


    Dann noch etwas, was auf keinem anderen System geht, nämlich ein LHA über viele Dateien. Das will man mit keinem anderen Rechner machen, weil sonst die Flags und teilweise die timestamps nicht vernünftig gespeichert werden. Hier werden ebenfalls sowohl Massenspeicher, als auch CPU/RAM gefordert. Basis sollte etwas sein, was "jeder" bei sich zuhause hat, also z.B. der Install-Diskettensatz von OS3.1: Für jede Disk jeweils ein Unterverzeichnis machen, alle Dateien reinkopieren, dann ein großes LHA über all' diese Verzeichnisse erstellen. Hier am besten auch die Version von LHA spezifizieren; ich hatte lange Zeit noch eine 1.52er Version auf meiner "standard-Installation", weil ich die seinerzeit wirklich lizensiert hatte. Die habe ich erst kürzlich durch die viel weiter verbreitete und fehlerfreiere V2.15 ersetzt.


    Du siehst, wohin ich möchte: Dinge, die wirklich den Amiga-Alltag betreffen; keine künstlichen Benchmarks. Ich fürchte zwar, dass dann die günstigeren Versionen der ACA1240/1260 besser abschneiden werden (im Sinne von "bang for the buck"), aber es geht schon lange nicht mehr um Umsatz/Gewinnmaximierung, sondern darum, das Hobby Amiga im preislich sinnvollen Rahmen zu behalten.


    Jens

  • Du siehst, wohin ich möchte: Dinge, die wirklich den Amiga-Alltag betreffen; keine künstlichen Benchmarks. Ich fürchte zwar, dass dann die günstigeren Versionen der ACA1240/1260 besser abschneiden werden (im Sinne von "bang for the buck"), aber es geht schon lange nicht mehr um Umsatz/Gewinnmaximierung, sondern darum, das Hobby Amiga im preislich sinnvollen Rahmen zu behalten.

    Gute Vorschläge - aber leider zu spät, ich habe schon drei Rechner durch und das ist mehr Aufwand als ich dachte. Habe jetzt den ganzen Nachmittag mit Auf,- Abbau und Testen der drei Rechner gebraucht..