Wenn Du doch den ASS Benchmark programmiert hast, dann hast Du doch ein gewisses Grundverständnis wie das Betriebssystem funktioniert:
Transparent verhalten kann sich eigentlich nur etwas aus Usersicht. Wenn Du aus Programmiersicht eine Layered Architecture bedienst, dann kannst ohne Hacks nicht auf die unteren Schichten zugreifen. Du weißt auf Ebene vom TCP/IP Protokoll nichts von PPPoE oder PPP. Manchmal werden Ebenen übersprungen aus Performancegründen. Das ist richtig. Da würde aber Microsoft Windows abhängig von APIs von Truecrypt machen. Das ist definitv NICHT der Fall.
Dann gibt es nur noch eine Möglichkeit für die Transparenz, die Du ansprichst: Angenommen Microsoft Bitlocker wäre vollständig modular über Interfaces nach oben/unten eingebunden, so könnte Truecrypt tatsächlich sich so einbinden - über die von Bitlocker verwendeten APIs -, dass Microsoft darüber/darunter immer noch die wildesten Spielchen treiben kann. Wenn dies so wäre, wäre das wie von mir geschildert eine vehemente Sicherheitsverletzung, die dem Reviewteam von Truecrypt schon lange aufgefallen wäre. Dem Reviewteam von Microsoft für Bitlocker ebenfalls.
Zeig' mir die Stelle im Truecrypt Code, die erlaubt, dass Microsoft weiterhin TRIM fahren kann im Falle einer OS Truecrypt Partition. Ich bin mir nahezu 100% sicher, dass es die aus Sicherheitsgründen nicht geben kann.
--
Ich hätte ohnehin noch ein paar Fragen zu ASS Programm. Der Quelltext ist ja leider nicht öffentlich. Vielleicht geht das per PN:
. Du umgehst bei den Zugriffen den Betriebssystem-Cache. Wie umgehst Du z.B. den Rückschreibcache des IASTOR.SYS? Das ist der intel matrix storage Manager RAID Treiber. Gibt's dazu auf Device Ebene ein NOCACHE Flag? Das gleiche Problem ergäbe sich bei RAID Controllern mit eigenem Ram. Die haben ja teilweise 512MB, 1GB Ram. Deine Dateigröße ist 1GB u. wird von Caches dieser Größenordnung manipuliert.
. Du schreibst "64 Threads verteilt sind (typischer Start eines Programms)". Wie kommst Du darauf, dass viele Threads gleichzeitig .dlls etc. laden? Wie kommst Du darauf, dass mehrere Threads lesen? Kennst Du das Sync/Async Pattern wie es für I/O Zugriffe von Betriebssystemen angewendet wird? Blocking I/O aus vielen Threads wird dort auf Non-Blocking Eventqueues mit 1-4 Threads gemappt. Oder meinst Du mit den 64 Threads einfach z.B. Abarbeiten der Autostart Gruppe?
. "Der 4k-64Thrd-Test wird in den Ergebnissen am stärksten gewichtet, da dies laut Fachleuten die Hauptbetriebsart einer SSD darstellt." Dass die Stärke eine SSD I/Os sind, darüber brauchen wir nicht reden. Welche Fachleute zitierst Du? Und was meinst Du mit "Hauptbetriebsart"?
. Woher sind die ISO/Programm/Spiel Zugriffsmuster? Sind das echte Traces/Captures? von welchen Programmen bzw. Spielen? Office DriveMark 2006 verwendet Traces aus Office XP, Winzip 9.0, und Symantec Antivirus 2003. Welche verwendest Du?
Die Aussagekraft eines Benchmarks kann man nur beurteilen, wenn man nachvollziehen kann WAS es misst. Deshalb würde ich dies gerne genauer verstehen wollen.
---------- Beitrag hinzugefügt um 19:38 ---------- Vorheriger Beitrag war um 19:28 ----------
Das ist doch schlicht falsch.
Garbage Collecting ist der Prozess Erase Blocks, die nur zum geringen Teil mit Nutzdaten gefüllt sind, durch Mergen mit anderen solcher gering gefüllter Erase Blocks freizugeben u. so den Pool an freien Blocks zu erhöhen. Da für das Schreiben in eines solchen gering gefüllten Erase Block ohnhin der gesamte erstmal gelöscht werden möchte, zieht GC eigentlich nur das Löschen zeitlich vor.
Die Gesamtzahl der überschriebenen Eraseblocks erhöht sich nicht großartig. GC wurde erfunden, um die Write Amplification zu reduzieren. Das geht nur indem man das Löschen zeitlich vorzieht.
Schaut man genauer hin gibt's natürlich Fälle wo das GC zusätzliche Writes auslöst: GC merged mit einem anderen Block (= 2x Erase) u. dieser zweite Block wird im folgenden modifiziert. Das macht mit GC 3x Erase (u. +1 ein freier Block). Ohne GC nur 1x Erase. Das macht aber sicher eher die Minderheit aus. Nichts weswegen man das GC verteufeln sollte.
Zuletzt bearbeitet:
