SSD Stresstest Programm



  • hi,
    ich hoffe mal ich befinde mich hier im richtigen Abschnitt des Forums, ansonsten fühlt euch frei diesen Beitrag entsprechend zu verschieben.
    Zur Situation:
    Ich habe ein kleines Programm geschrieben, mit dem ich die möglichen Schreibzyklen einer Solid State Disk (SSD) messen will. Laut Herstellerangaben sind das so um die 2.000.000 Zyklen. Mein Programm kopiert daher abwechselnd, eine 10MB große .txt Datei (einmal voll 1-en und einmal voll 0-en) auf eine fast volle Partiton der zu testetenden SSD. (freier Speicherplatz 11,3 MB)
    Mein Problem liegt darin, dass dieses "Stresstest" Programm nach ca. 12.000 Durchläufen, also ~24.000 schreibzyklen den pc einfriert. Ich bin mir jetzt nicht ganz sicher, ob es daran liegt, dass die zu testende Partition nurnoch 1,3 MB freien Speicherplatz hat, oder ich irgendeinen Fehler in meinem Quellcode habe.
    (vielleicht hab ich auch schon bestimmte Sektoren der SSD kaputt bekommen, halte ich aber für eher unwahscheinlich, erstens hab ich bis jetzt nur ~50.000 Schreibzyklen und zweitens zeigen chkdik bzw. hddscan, keine fehler an)

    System: Windows 2000 SP4; 2,39 GHz P4; 1GB Ram;
    Partiton c: OS 1,5GB 512MB Auslagerungsdatei 389MB frei
    Partation d: (zu testende) 5,89 GB beim test noch 1,32 MB frei
    Die SSD ist eine Stec M2

    #include "stdafx.h"
    #include <fstream>
    #include <iostream>
    #include <windows.h> //copyfile
    #include <string>
    #include <time.h>
    using namespace std;
    
    int main(int argc, char* argv[])
    {
    	int durchlaeufe;
    	int t = 0;
    	fstream f5;
    	int i;
    	string eins_v =	"d:\\Eins.txt";  
    	string null_v =	"d:\\Null.txt";
    	string test_v =	"d:\\test.txt"; 
    	string log_v  =	"c:\\log.txt";
    	cout << "Bitte Anzahl der Kopiervorgaenge festlegen "<< "\n";
        cin  >> durchlaeufe;
    
    	for(i = 1; i<durchlaeufe+1;i++)
    	{
    		cout<< "Durchlauf: "<< i<<"\n";
    		CopyFile (null_v.c_str(),test_v.c_str(),0);
    		CopyFile (eins_v.c_str(),test_v.c_str(),0);
    
    		if (t<(i - (i % 10)))
    		{
    			time_t z;
    			tm *nun;
    			z = time(0);
    			t = i-(i%10);
    			f5.open(log_v.c_str(), ios::out|ios::app);
    			nun = localtime(&z);
    			f5 << t << " Durchläufe - "<< (2*t) <<" Kopiervorgaenge  "<< nun->tm_mday << '.' << nun->tm_mon+1 << '.'
    		       << nun->tm_year+1900 << " - " << nun->tm_hour
    		       << ':' << nun->tm_min <<"\n";
    			f5.close();		
    		}
    	}
    	return 0;
    }
    

    mfg
    MisterSmith



  • Also auf den ersten Blick kann ich an dem Quellcode nichts falsches erkennen. Mit was für Anzahlen von Durchläufen hast du es getestet?

    Das einzige was mir auf den ersten Blick problembehaftet aussieht ist dein Variablentyp für die Durchläufe. Integer hast du normal Werte von ca. −32.700 bis ca. 32.700 (soweit ich im Kopf hab) also falls es bei diesen Werten abkackt, dann probiers mal mit nem anderen Variablentyp wie Long oder so.



  • hi, danke erst mal für die schnelle antwort;
    also bis jetzt hab ich es immer mit 100.000 Durchläufen versucht, von denen er ca. 12.000 bis zum einfrieren geschaft hat.
    Ich werde ihn jetzt einfach mal mit 32.000 Durchläufen test, um diese Fehlerquelle ausschließen zu können.
    weiß in ein paar Stunden ob es daran gelegen hat.
    mfg MisterSmith

    p.s. ist nicht INT_MAX+1 = INT_MIN, also 32767+1 = -32767 (oder verwechsel ich da was)
    und ich hätte im prinzip eine endlosschleife gemacht?



  • Hallo,

    MisterSmith schrieb:

    p.s. ist nicht INT_MAX+1 = INT_MIN, also 32767+1 = -32767 (oder verwechsel ich da was)

    Nein, das ist abhängig davon, was in limits.h steht. Ich wette aber, bei dir steht dort auch 2147483647 für INT_MAX.

    MfG,

    Probe-Nutzer



  • hi,
    INT_MAX beträgt wirklich 2147483647
    heißt: daran kann es auch nicht liegen;
    sonst noch irgendjemand eine idee;
    passt dann vielleicht nicht mehr richtig in dieses Forum, aber ich denke langsam, dass das Laufwerk mit dem geringen freien Speicherplatz nicht richtig umgehen kann. Bei kommerziellen Stresstest-Programmen müssen meines Wissens, auch immer 5-10% des Laufwerks frei gehalten werden. Der technische Grund, ist mir aber nicht ganz klar.
    Auf meinem zu testendem Laufwerk befinden sich ja ansich keine anderen Daten, auf die zugegriffen wird. Außerdem würde mehr freier Speicherplatz den Test nicht mehr aussagefähig machen.
    mfg
    MisterSmith



  • Hast du das Prog denn schonmal auf einem "leeren" Laufwerk ausprobiert? Dann kannst ja leicht überprüfen ob es an deinem Programm liegt oder ob deine Platte damit nicht zurecht kommt.



  • MisterSmith schrieb:

    Partiton c: OS 1,5GB 512MB Auslagerungsdatei 389MB frei
    Partation d: (zu testende) 5,89 GB beim test noch 1,32 MB frei

    Das sieht nach einer einzigen 8GByte-SSD aus, also beide Partitionen auf einem Laufwerk!
    Oder hast Du zwei getrennte, physikalische Laufwerke im Einsatz?

    Welches Dateisystem hat die Partition 😨 ?
    Bei NTFS schreibt Windows zusätzlich Journaling-Informationen auf die Partition(en) -> Windows (und nicht etwa Dein Programm) "friert" möglicherweise bei Speichermangel ein?
    Vielleicht ist das augenblickliche "Einfrieren" des Systems nur eine lange Wartezeit bis die (zumindestens bei alten SSDs) Daten komplett geschrieben sind (evtl. aus dem Schreibcache?)? Wie lange wartest Du, bevor Du den Reset- Knopf drückst?

    MisterSmith schrieb:

    cin  >> durchlaeufe;
    

    Bekommt die Variable durchlaeufe wirklich den Wert den Du per cin eingibst? Lass mal ihren Wert noch vor der for-Schleife zur Kontrolle ausgeben.

    Anderer Ansatz:
    Hast Du bei den File-Aktionen evtl. auch das "Defekt-Management" der Festplatten Controller beachtet?
    Es könnte auch sein, daß der Controller einfach einen "Lese- bzw. Schreibfehler" meldet, während er einen defekten Sektor erkannt hat, und intern diesen Sektor gegen einen funktionierenden Ersatz-Sektor ersetzt?
    (Übrigens, dieses Defekt-Management ist IMHO in fast allen Festplatten und SSD-FlashDisks eingebaut!)

    Nur mal so als Tipp, woran es auch liegen könnte.
    Martin


Anmelden zum Antworten