Zusi3 Demo auf SSD

[bottomisenormous]

Nach dem die Zusi3 Demo endlich auch auf SSD gelandet ist kann ich kurz berichten:

An den Ladezeiten hat sich etwas geändert, der Dg 54714 brauchte beim ersten Aufruf vom Klick auf "Starten" bis zum Bild ca. 55s, beim zweiten Aufruf nach Schließen und Neustart des Programmes nur noch 20s. Dieses Verhalten ist mir auch schon bei anderer Software aufgefallen. Links unten die grünen Punkte für die Streckenmodule (?) kommen deutlich schneller als zuvor. Auch hat sich das Fahrgefühl subjektiv verändert - Die Lok läuft nun seidenweich und geschmeidig über die Gleise, der Unterschied ist sehr schwer zu beschreiben: Vorher lief es auch ruckelfrei und glatt aber jetzt läuft es so geschmeidig wie Seife in Öl. Ansonsten gibt es eigentlich keine Auffälligkeiten aber ich denke bei einer vollständigen Installation dürften die Vorteile einer SSD noch deutlicher zu Tage treten.

[Oliver Lamm]

Seife in Öl

??? Sicher ? Ich glaube der Vergleich hinkt :-)

SCNR, Oli

[Max Senft]

Hi,

wunderbarer Einstieg für eine stets unbeachtete Technik in Zusi: Wieso nicht die zu einem Modul, bzw. einem Objekt zugehörigen vielfachen Dateien in ein Archiv stecken und im Hauptspeicher "auseinanderklabüstern"? Ich würde ja mal behaupten - ohne es irgendwie getestet zu haben - dass dies auch nochmal einen Geschwindigkeitsvorteil bringt? Der mehrfache Zugriff auf viele kleine Dateien auf einer Festplatte wird aber wohl doch langsamer sein, als der Zugriff auf eine größere Datei? Das anschließende Durcharbeiten durch die einzelnen Dateien wird auch nicht gerade "lange" dauern?

Grüße
Max

[bottomisenormous]

Das klingt für mich durchaus plausibel denn an RAM sollte es heutzutage den Wenigsten mangeln.
Ich würde allerdings in meiner umfassenden Unwissenheit nichts in noch zu entpackende Archive stecken sondern versuchen beim System so viel Speicher wie möglich für die Anwendung zu reservieren und dann diesen sozusagen "Level 4 Cache" weitestgehend gefüllt zu halten. Wenn ich allerdings lese daß die aktuellen SATA-6G SSDs um die 550 MB/s über die Leitung schieben können dann dürfte sich solch ein Programmieraufwand schon erübrigt haben.

[Roland Ziegler]

Eine projektspezifische Speicherverwaltung ist immer aufwändiger, aber oft effizienter als eine allgemein anwendbare. Die einfachste universelle ist die "unsichtbare" per Auslagerung, die jedes Betriebssystem mit virtueller Adressierung besitzt.

Der Preisverfall für Hauptspeicher eröffnet neue Möglichkeiten für speicherintensive Anwendungen. Ich würde mal erwarten, dass der Trend zu 64bit-Prozessen sich verstärken wird. Mehr physikalischen Speicher nutzen zu können, wird die Notwendigkeit eigener, spezifischer Verwaltung verringern. So weit, so einfach.

Aber mit der Verbreitung der SSD und deren hohem Durchsatz verwischt sich ein wenig die klare Abgrenzung zwischen langsamer Platte und schnellem Hauptspeicher (wobei niemand bisher wirklich sagen kann, wie lange die "Flash-Platten" in der Praxis tatsächlich halten werden). Auf abstrakter Ebene wird die SSD vielleicht zum n-th Level Cache, so dass man sich an noch speicherintensivere Anwendungen heran zu trauen wagt.

Auf jeden Fall eine spannende Entwicklung für das Software-Design, die einige Grundsätze, die noch vor wenigen Jahren als unumstößlich galten, ein wenig in Frage stellt.

[F(R)S-Bauer]

Nabend,

Man sollte aber auch nicht vergessen, das SSD für bestimmte Sachen nicht optimal sind, z.B beim Verschlüssel der Daten.
Auch weis man noch nicht über die langzeithaltbarkeit und die möglichen Rettungsmaßnahmen bei Aufall wichtiger Daten.

mfg

Ralf

[bottomisenormous]

Es gibt Jemanden der den MSTS seit 3 Jahren auf SSD betreibt - Muß wohl an der Quelle sitzen. Wenn man weiß wieviel tausende von Dateien Train Store hin und her schiebt denke ich daß da wohl schon ein paar Schreibzugriffe gelaufen sind aber die Haltbarkeit hängt ja auch entscheidend davon ab wie voll man das Teil packt.
Ein regelmäßiges Backup ist ohnehin für jeden Datenträger anzuraten, auch für gebrannte CDs und DVDs.

[Andreas Karg]

Naja, hinsichtlich der Lesezyklen ist eine SSD ja annähernd verschleißfrei. Wenn dieser Jemand nicht ständig den gesamten MSTS im Kreis schaufelt, dürfte er keine Probleme bekommen.

Ich sehe das Problem vielmehr darin, dass gerade der Bereich wo die SSDs am meisten bringen (Betriebssystempartition) am meisten Kleinscheiß passiert. Logdateien, temporäre Dateien, dies, jenes und oben drauf noch sonstiges. An sich bin ich aber mit meiner SSD (40 GB) sehr zufrieden. Für Neuanschaffungen würde ich mindestens das Doppelte vorsehen, weil die 40 GB praktisch über Nacht voll sind. Ist schon mit einem gewissen Aufwand verbunden, das Ding einigermaßen sauber zu halten. :-(

[MichaelT]

Auch weis man noch nicht über die langzeithaltbarkeit und die möglichen Rettungsmaßnahmen bei Aufall wichtiger Daten.

Ich glaube die Diskussion hatten wir hier schon einmal. Beschreiben kann man die SSDs je nach Bauart der SSD zwischen 3000 und 5000 mal (je Zelle). Danach ist sind die Zellen nicht mehr beschreibbar, jedoch bleiben sie lesbar.
Zumindest wenn man sich keinen Schrott einbaut.

[Roland Ziegler]

An sich bin ich aber mit meiner SSD (40 GB) sehr zufrieden. Für Neuanschaffungen würde ich mindestens das Doppelte vorsehen, weil die 40 GB praktisch über Nacht voll sind.

Zu SSD als Systemplatte: Das Program Files-Verzeichnis umzulegen, wird bei Win 7 nicht mehr unterstützt. Allerdings kann man Program Data und Users verschieben. Vielleicht hilft das etwas, mit dem knappen Platz besser hauszuhalten.

[Andreas Karg]

Das hab ich teilweise sogar schon gemacht, aber danke für den Hinweis. Zumindest die Riesenbrocken Dokumente und Downloads (immer etwas unaufgeräumt...) sind schon mit Junctions versehen. Mal schauen - wenn ich die Kiste das nächste Mal neu aufsetze, bau ich vielleicht gleich ne halbwegs saubere Lösung.

[Frank Wenzel]

...Zu SSD als Systemplatte: Das Program Files-Verzeichnis umzulegen, wird bei Win 7 nicht mehr unterstützt...

Ich nehme an, du meinst dass man es als Standardeinstellung nicht mehr umlegen kann. Manuell geht es ja, will sagen, einen Ordner program files auf einer anderen Festplatte anlegen und bei der Installation peinlichst genau darauf achten, dass die Programme dann auf XYZ installiert werden.

[Roland Ziegler]

Ich nehme an, du meinst dass man es als Standardeinstellung nicht mehr umlegen kann. Manuell geht es ja, will sagen, einen Ordner program files auf einer anderen Festplatte anlegen und bei der Installation peinlichst genau darauf achten, dass die Programme dann auf XYZ installiert werden.

Natürlich. Nur greift dann der eingebaute Schutzmechanismus in 7 nicht mehr. Und MS sagt explizit "Not supported". In XP war das egal. Der Programmordner auf C: hatte keine Sonderfunktion und ließ sich durch den Registry-Eintrag beliebig verschieben.

Das hab ich teilweise sogar schon gemacht, aber danke für den Hinweis. Zumindest die Riesenbrocken Dokumente und Downloads (immer etwas unaufgeräumt...) sind schon mit Junctions versehen. Mal schauen - wenn ich die Kiste das nächste Mal neu aufsetze, bau ich vielleicht gleich ne halbwegs saubere Lösung.

"Program Data" und "Users" verschiebt man am einfachsten bei der Installation, im Audit-Mode, mit xml-Skript. Das ist von MS sogar dokumentiert.

Die "Junctions" heißen jetzt übrigens "Symbolic links" und verhalten sich auch praktisch wie in Unix. Ich nehme mal an, die tollen Libraries werden so verwaltet. Aber Windows-Kunden kann man ja olle Kamellen als neu verkaufen. Es gibt durchaus Berichte von Anwendern, die den Programmordner über Symbolic Links ausgelagert haben. Aber will man das? Für irgendwas soll die SSD ja gut sein.

[Jan]

Ich nehme an, du meinst dass man es als Standardeinstellung nicht mehr umlegen kann. Manuell geht es ja, will sagen, einen Ordner program files auf einer anderen Festplatte anlegen und bei der Installation peinlichst genau darauf achten, dass die Programme dann auf XYZ installiert werden.

Natürlich. Nur greift dann der eingebaute Schutzmechanismus in 7 nicht mehr. Und MS sagt explizit "Not supported". In XP war das egal. Der Programmordner auf C: hatte keine Sonderfunktion und ließ sich durch den Registry-Eintrag beliebig verschieben.

Vor kurzem bin ich auf eine Erklärung für dieses neue Verhalten gestoßen.

[bottomisenormous]

Die C't -Redaktion hat mal versucht einen USB-Stick mutwillig kaputt zu schreiben aber auch nach weit über 100.000 schreib/lese-Zyklen gab es noch keine Ausfälle.

[F(R)S-Bauer]

Hi,

...Vor kurzem bin ich auf eine Erklärung für dieses neue Verhalten gestoßen.

Das Problem ist blos das gleiche wie bei der Registry, es gibt immer noch Deppenprogramierer die zwar die geilsten Grafiken im Logo dreifach Aniemirrt und Funfach rumgewirbelt einbauen, aber deren Programe 13 Jahre nach dem Start von NTFS immer noch nicht mit Links, Verknüpungen und Dateirechten umgehen können. Selbsredent ist das genau das Programm was Chefe und Vertrieb UMBEDINGT haben wollen und sauteuer ist. Da Bekommst du dan so aussagen, wie "Sie müssen unser Programm auf FAT 32 Installieren"...

mzg

Ralf