Was macht ein guter Memory-Test?

    • Offizieller Beitrag

    Moin,


    ich bezieh mich hier auf den Tester für 2114 RAMs Thread und stell mal die Frae, was muss/soll ein vernuenftiger Memory Test alles testen?


    Ich meine nicht, wie es bei den meisten Computer gemacht wird, alles 0x00 schreiben, testen und danach 0xFF schreiben und testen. Das ist fuer mich kein anstaendiger Test, sondern max. eine Erkennung wieviel Speicher ist vorhanden.


    Hat jemand Erfahrung mit richtigen Memory Tests? Oder sinnvolle Ideen dazu?


    Und ich meine gar nicht Zugriffszeiten oder sowas ! Sowas sollte der Hardwareentwickler des Computers festgelegt haben.


    Bin mal gespannt.

    • Offizieller Beitrag

    Sieht gut aus, aber da muss man mal ein paar Minuten investieren.

    Bis spaeter...

  • Das hängt wohl von der Definition von "richtig" ab - Will man's "richtig" machen, schreibe man alle Werte, die der Speicher aufnehmen kann in allen Permutationen an Nachbaradressen, rein, und schaue, ob man sie wieder auslesen kann. Das dauert natürlich "unendlich" lang, will man auch kurzgeschlossene Address- und Datenleitungen und kaputte Bustreiber erkennen können, dann hat man ganz schön zu tun - Der Benutzer will bestimmt nicht so lange warten, bis so ein Memory-Test abgeschlossen ist.


    Also muss man sich was schlaueres einfallen lassen, das aber trotzdem noch schlauer ist als simple Bitpattern lesen und schreiben.


    Nachdem ein Memory-Test bei jedem Einschalten wieder aufs Neue durchläuft, braucht man eigentlich nicht "immer alles" zu testen. Ein schlauer Speichertest kann z.B. ab einer von der Uhr- (oder einer Wartezeit bis zu einem Tastendruck des Benutzers) "verzufallten" Anfangsadresse (damit man bei jedem neuen Einschalten andere, zufällige Pattern generiert) ROM ins RAM schreiben und dann vergleichen - Damit bin ich eigentlich bisher immer ganz gut gefahren. Früher oder später findet so eine Routine jeden Fehler, auch solche, wo das Schreiben einer Adresse eine ganz andere verändert.


    Tobias

    • Offizieller Beitrag

    Mit "richtig" oder "sinnvoll" meine ich Tests, die im wahrsten Sinne des Wortes den Speicher "sinnvoll" testen.

    D.h. mit hoher Sicherheit (>90% ?) sollte der Speicher funktionieren.

    Und dies kann auch etwas dauern, von mir aus auch Stunden, wenn damit die Sicherheit, die ich mir wuensche, erreicht wird.

    Ein solcher Test wird explizit gestartet oder extern durchgefuehrt.


    Ich meine nicht einen Speichergroessentest nach einem Power-Up wie oben beschrieben.

    Der darf den Anwender natuerlich nicht zeitlich stressen.

  • Vielleicht solltest Du noch dazusagen, ob Du da an einzelne Chips denkst, oder an SIMMs, oder installierte Systeme.

    Bei 1kB großen Chips würde "sinnvoll" möglicherweise anders aussehen, als bei 2 TeraByte in einer aktuellen Z-Maschine.


    Ich würde mir evtl. auch mal die Sachen angucken, die zum defnierten Löschen von Datenträgern benutzt werden (CleanEraser etc.). Da gibt es solche eigenartigen Bitfolgen, die ganz gut sicherstellen sollen, daß man danach nichts mehr auslesen kann, und ich vermute, daß es dafür auch ein paar Texte gibt, wo begründet wird, warum gerade diese Bitfolgen. Und da man damit ja irgendwie "alles" erwischen will, müßte das, in Abwandlung" auch für Tests brauchbar sein. Ist aber nur so eine Idee ...


    Ansonsten - auf Chipebene für Kleincomputer - scheint mir auch wichtig, daß der Chip mal schön benutzt worden ist. D.h. man macht erstmal nur für eine bestimmte Zeit irgenwelche Schreib/Lesezugriffe, damit der Chip "warm" wird (z.B. 2 Minuten o.ä. (dafür kann man dann eine Kurve machen, wenn man das Tool "stehen" hat und den optimalen Zeitraum bestimmen). Erst dann kommt eine Lese Test mit irgendwelchen Pattern.



    Und: am Besten ist wahrscheinlich, sowas immer mitlaufen zu haben, also ECC RAM ..., und sowas ginge auch als IRQ Routine o.ä. auf Kleinstcomputern (man kann die Prüfsummen ja in den Bildschirmspeicher schreiben ;) ).

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    • Offizieller Beitrag

    ob Du da an einzelne Chips denkst, oder an SIMMs, oder installierte Systeme.

    Chips und Systeme.

    SIMMs sehe ich als Chips, da i.a. nur die Datenbusbreite erhoeht wird. ECC u.ae. lasse ich mal aussen vor, da hier keine unabhaengige Information gespeichert ist.


    Bei 1kB großen Chips würde "sinnvoll" möglicherweise anders aussehen, als bei 2 TeraByte in einer aktuellen Z-Maschine.

    Sehe ich nicht so.

    Wenn ich wissen will, ob ich Speicherfehler habe, was hat die Groesse fuer einen Einfluss? Ausser Zeitbedarf, klar. Aber den ignoriere ich zur Zeit.



    Erstmal soll es um das "WIE" gehen.

    Je nach Anwendungsfall kann man Abstriche machen oder Dinge hinzufuegen.

  • Eines der wichtigsten Dinge bei einem "richtigen" Memorytest ist, den Speicher auch mit der maximalen Geschwindigkeit zu testen!


    Der Memorytest, den Inmos z.B: für Transputersysteme zur Verfügung gestellt hat, taugt diesbezüglich nichts - mit dem wurden schon Speicherbausteine für gut befunden, deren Ground-Pin nicht mal angeschlossen war! :)


    Also Geschwindigkeit ist (fast) alles bei so einem Test - für die meisten Systeme heißt das, Datenblöcke mittels DMA zwischen

    internem und externem, sowie innerhalb des externen Speichers hin - und her zu kopieren.

    Einmal editiert, zuletzt von dlchnr ()

  • Für den Speichertest von Maschinen, auf denen Linux läuft, gibt es memtest86 oder memtest86+. Der wird anstelle eines OS geladen und kann somit das gesamte vorhandene RAM testen. Es laufen viele Varianten des lesens und schreibens durch, ein einziger Durchlauf dauert ca. 30 Minuten auf einem Core 2 Duo mit 1,86 GHz.

    Aber auch solche Tests schützen nicht vor Fehlern. Es kann ja sein, daß eine Speicherzelle nach dem Test den Geist auf gibt. Murphy eben. Der ist mein ständiger Begleiter bei Service und Reparatur und schlägt manchmal zu.

    Abolute Funktionssicherheit gibt es nirgendwo, bei keiner Maschine und bei keinem Menschen.

  • Ich könnte mir vorstellen, daß ggf. auch die Versorgungsspannung (oder besser der Bereich) im Rahmen der Datenblattvorgaben zum Test hinzugezogen werden sollten. Ist aber kein Wissen meinerseits, sondern eher aus dem Bauch heraus.

    Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    An die Person, die meine Schuhe versteckt hat, während ich auf der Hüpfburg war: Werd' erwachsen! :motz:


    ::matrix::

  • Naja... hier geht es ja wohl eher darum, was einen guten Memory Tester auszeichnet. Klar kann ich das jeweilige RAM dann auch in einen Rechner setzen, aber ich denke, daß es bei diesem Thread nicht die Intention von funkenzupfer war/ist.

    Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    An die Person, die meine Schuhe versteckt hat, während ich auf der Hüpfburg war: Werd' erwachsen! :motz:


    ::matrix::

    Einmal editiert, zuletzt von tokabln ()

  • Wenn es nur um ein 2114 geht, würde ich das mal in einen C64 packen (Farbram), da sieht man dann schnell, ob es noch Ok ist.

    Vielleicht ist das ja sogar schon "die Idee" für einen guten Tester. Nur daß halt das Ganze mit einem RPi beschrieben/gelesen wird und als Grafik angezeigt wird.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Wenn es nur um ein 2114 geht, würde ich das mal in einen C64 packen (Farbram), da sieht man dann schnell, ob es noch Ok ist.

    Vielleicht ist das ja sogar schon "die Idee" für einen guten Tester. Nur daß halt das Ganze mit einem RPi beschrieben/gelesen wird und als Grafik angezeigt wird.

    Oder um das zeitkritische hinzubekommen vielleicht mit nem FPGA?


    Wenn der RAM zwar mit ner Taktung von 500 Hz funktioniert, kann es immer noch sein, dass er bei 1MHz nicht mehr geht.

    • Offizieller Beitrag

    Mal zur Klarstellung:
    Mir geht es nicht um einen Tester! Von Hardware sind wir noch ganz weit weg! Von Software auch.


    Ich will wissen, was man fuer Tests/Pruefungen machen muss/soll, um die reine Funktion eines Memorys zu verifizieren.


    Ob ich solche Pruefungen spaeter in Software und/oder Hardware realisiere, steht noch auf einem ganz anderen Blatt.



    for(;;) , den Artikel muss ich mir noch durchlesen.

    fritzeflink , den RAMBUG hab ich inzwischen am MFA am laufen. Dazu werd ich noch was schreiben.

    Currock , den memtest86 hatte ich mir schon mal an geschaut wegen den Tests. Da kann man was rausholen.


    dlchnr , tokabln , csdragon

    Mit Geschwindigkeit und einstellbaren Versorgungsspannungen kann ich ein Memory-IC stressen, wenn ich aber die angegebenen Spezifikationen einhalte, sagt mir das gar nichts zur Funktion eines ICs.

  • Mal ein paar Anregungen:


    Diverse Bitmuster schreiben und wieder lesen, mindestens 0000000, 11111111, 10101010, 01010101, 00001111, 11110000, 00110011, 11001100, 00111100, 11000011. Refresh-Test (wieviele Refreshcyclen düerfen ausfallen, bis der Speicherinhalt weg ist. In schneller Reihenfolge immer wieder die gleiche Speicherzelle behämmern und wieder auslesen (und vergleichen), Speicherzelle immer wieder beschreiben, und schauen ob sich der Inhalt von Nachbar-Speicherzellen dadurch ändert (Rawhammer-Methode). Fortlaufende Tests benachbarter Speicherzellen. Zufällige Speicherzellen, ...


    Kannst ja mal in den Quellcode von memtestx86 oder yaart (yet another atari ram test) reinschauen.

    1ST1

  • > @dlchnr ...

    > Mit Geschwindigkeit ......... kann ich ein Memory-IC stressen, wenn ich aber die angegebenen Spezifikationen einhalte,

    > sagt mir das gar nichts zur Funktion eines ICs.


    Es geht hier nicht darum, irgendwelche Timingzeiten auszureizen,

    sondern Situationen zu simulieren, wie sie in einem laufenden Systen

    ständig auftreten - das einem READ unmittelbar ein READ auf einer ganz

    anderen Adresse folgt oder auf einen READ unmittelbar danach (beginnend

    mit dem nächsten Clocksyklus) ein WRITE erfolgt.


    Wie schon geschrieben, entging dem Memorytest von Inmos für Transputersysteme,

    dass bei einem Transputerboard der Ground-Pin der DRAMs nicht angeschlossen

    war!


    Oder ein anderes Beispiel - ich wurde von einem Konzern beauftragt,

    deren Neuentwicklung "zuverlässig" zum Laufen zu bringen. Da dort geklotzt

    wurde gab es nicht ein Prototypenboard, sonder "zig" davon:


    - ein Handvoll der Boards fiel beim Memorytest durch, der Fehler konnte aber

    nicht gefunden werden.

    - das Gros der Board bestand den Memorytest, "schmierte" aber beim Programmlauf

    binnen weniger Minuten ab.

    - drei der Boards liefen stundenlang, manchmal sogar ein/zwei Tage, bis dann

    auch bei denen ein Programmabsturtz auftrat.


    Mit dem Memorytest, den ich dann für das Board geschrieben habe, waren dann

    auch bei den zuletzt gennanten drei Boards nahezu alle Speicherzugriffe

    (ca. 70% bis 90%) fehlerhaft!

    • Offizieller Beitrag

    Hast du dir mal den Post durchgelesen? Ausser dem Teil den du zitierst.


    Mir geht es nicht um einen Tester! Von Hardware sind wir noch ganz weit weg!


    Du hast Recht mit dem was du schreibst. Keine Frage.

    Ein funktionierender Speicher (IC) in einem schlechten Board funktioniert nicht.

    D.h. aber nicht das der Speicher defekt ist.

    Und da will ich erstmal hin.

    • Offizieller Beitrag

    Ich hab den RAMBUG mal eingetippt und disassembliert. Die SW ist nicht ganz ohne.


    Ich hab dann die Ein- und Ausgabefunktionen unter CP/M drangebaut.

    Cursorpostionierung etc sind VT-100 kompatibel.


    Die CPMv1.0 macht die Ein-/Ausgabe uebers BDOS. Damit der RAMBUG nicht ueberall hin verschoben wird, habe ich die ZeroPage und das BDOS/BIOS aus der Memory-Suchroutine rausgelassen.

    Die CPMv1.1 benutzt das BIOS zur Ein-/Ausgabe, dadurch wird mehr Speicher "testbar". da einige BIOSe das IOBYTE benutzen sind Quereffekte bei der Ein-/Ausgabe moeglich. Also nicht meckern, wenn der RAMBUG haengen bleibt.


    Beide Versionen laufen auf meinem MFA mit Z180 gut.


    Viel Spass

  • Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    An die Person, die meine Schuhe versteckt hat, während ich auf der Hüpfburg war: Werd' erwachsen! :motz:


    ::matrix::

  • Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    An die Person, die meine Schuhe versteckt hat, während ich auf der Hüpfburg war: Werd' erwachsen! :motz:


    ::matrix::

  • Nun in diesem Post gibt es Informationen zu einem RAM / ROM Tester sowie zu einem Simtester.


    Der Post darunter ist tatsächlich nicht wirklich relevant... aber hier kann man schön sehen wie z.B. ATARI seine Produkte getestet hat...

    Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    An die Person, die meine Schuhe versteckt hat, während ich auf der Hüpfburg war: Werd' erwachsen! :motz:


    ::matrix::

  • Ich hab dann die Ein- und Ausgabefunktionen unter CP/M drangebaut.

    Cursorpostionierung etc sind VT-100 kompatibel.

    Das wäre für meinen Intertec Superbrain interessant, von dem ich immer noch nicht weiß, ob das RAM nun eigentlich okay ist oder nicht. Aber der verwendet keine VT100-Sequenzen, sondern irgend eine andere Terminal-Emulation, die ich erst mal wieder ermitteln müsste. Wäre das viel Aufwand, das anzupassen? Möchtest Du vielleicht die Sourcen irgendwo veröffentlichen, kann könnte ich das auch selbst machen?

    • Offizieller Beitrag

    Ich schlage vor, wir tauschen. Du kriegst den guten RAMBUG, ich den kaputten Superbrain.

    :)


    Änderungen haben natürlich Aufwand.

    Du kannst aber auch gerne den Source haben.


    Was wär dir am liebsten? Willst du mit CP/M arbeiten oder lieber "raw"?


    Ich pack das Original zusammen. Dann kann sich jeder dies selber erweitern.

  • Warte... lass mich kurz nachdenken... also ich glaube, ich mach' das besser selbst!


    Das Ding bootet ordentlich hoch in sein CP/M, also wird das schon gehen.


    Bare metal wäre nicht so cool weil dort ein TMS 2716 verbaut ist, das im Gegensatz zu den üblichen 2716 noch +12 Volt und so'n Quatsch haben will, das kann ich leider nicht brennen.

    • Offizieller Beitrag

    Möchtest Du vielleicht die Sourcen irgendwo veröffentlichen, kann könnte ich das auch selbst machen?

    So, hier ist die Binaerdatei und der Code aus dem Disassembler.


    Wenn du auch die Sourcen der CPM-Version haben moechtest, sag Bescheid.