Letzteres bezweifle ich doch stark. Der TC Quellcode ist sehr aufgeräumt, OO und von hoher Qualität. Ich sehe da wirklich kein Problem (bedenke, dass DC ein Fork von TC und auch keine Neuentwicklung ist). Warten wir es einfach ab. Leider sind Wartephasen von 1-2j bei TC nicht unüblich (dafür erscheint dann gleich eine stabile Version)...
SSD Disk Encryption (Truecrypt vs Bitlocker vs DiskCryptor)
- Ersteller Ausweiser
- Erstellt am
Dass das Programm eine einfache GUI hat, finde ich vorteilhaft und sehr viel intuitiver als bei TC.
Ich kann mich jetzt nicht mehr genau erinnern, wie ich es damals gemacht habe. Aber auch für damals gilt, es war einfach, es war intuitiv und es machte keine Probleme.
Klar ist eine erzwungene Rescue-CD für Leute mit wenig Ahnung hilfreich. Aber mal ehrlich...es gibt Linux-Live-CDs mit eingebautem DC. Wer also mal ein Problem hat, der zieht sich so eine runter (google nach Hirens Boot CD aber vorher testen, ob sie geht) und decrypted dann bequem. Normalerweise macht sich ein gewissenhafter Nutzer solcher Sicherheitssoftware ohnehin darüber Gedanken, wie man im Fall der Fälle wieder an die Daten kommt, und es geht ja.
Vielleicht verstehe ich Dich jetzt nicht ganz. Die PBA ist für das Systemlaufwerk, im gebooteten System kannst Du dann die Passwörter für den Rest eingeben. Alles automatisch geht vielleicht auch, weiß ich jetzt nicht genau. Aber was bitte ist Magie daran, dass
a) die Software, wenn man die Systempartition verschlüsselt, automatisch den Bootloader bei der Installation entsprechend konfiguriert und
b) die Software, wenn man - vorausgesetzt ich habe Dich richtig verstanden - System- und Datenpartitionen beim Boot gleichzeitig entschlüsselt haben möchte und dafür eine Einstellung setzt, den Bootloader dann entsprechend hierfür konfiguriert.
Ich finde es nicht "zusammen gehackt", sondern einfach nur gut programmiert.
Also an den Punkt des Entschlüsselns bin ich noch nicht gekommen. Aber, wer verschlüsselt oder entschlüsselt ohne zuvor ein Backup gemacht zu haben, ist selber schuld. Selbst wenn also mal was schieflaufen sollte, kann es sich nur um eine Stunde zurückspielen handeln, aber keinen Datenverlust.
Warum sollte DC auch noch das alte Kennwort nach dem Entschlüsseln wollen? Es gibt ja kein Kennwort mehr...ist eigentlich logisch. Und was ist jetzt so schlimm daran, dass man nach dem anschließenden so schwierigen Enter-Drücken unter Windows den Bootloader durch einen einfachen Klick noch deinstallieren muss? Verstehe ich nicht, wenn es doch dann funktioniert.
Bei TC hatte ich eher schon das Problem, dass der Bootloader nicht wegging, obgleich man alles entschlüsselt hatte, also problemfrei ist die all-in-one-automatik von TC nun wirklich auch nicht.
Falls DC jetzt wirklich keinen Passwort-Test vorab unterstützt (ich glaub das geht wirklich nicht), wäre das wirklich etwas, was noch implementiert werden sollte. Aber keine Software ist perfekt. Dafür läuft sie stabil und sehr schnell, das macht den Rest wieder wett, finde ich.
Ich behaupte ja nicht, dass DC nicht funktioniert. Man sieht halt wirklich nur, wie es entstanden ist.. zusammen gehackt
Also das kann ich auch nach Deinen Erklärungen (und meinen Anmerkungen dazu) wirklich nicht nachvollziehen.
Du redest ja förmlich so, als sei die TC GUI völlig überladen, undurchsichtig und kompliziert! Und zwischen einfach/intuitiv zu "billig" (was ich meine), liegt ein Unterschied.
Ich kritisiere ja nicht die Einfachheit. Nur wenn du dir die Entstehung von DC anschaust.. man nehme den TC-Treiber... jetzt braucht man dafür eine GUI... die GUI muss die Möglichkeit bieten bestimmte Werte an den Treiber zu übergeben, also brauchen wir noch einen Dialog... darauf paar Input-Elemente, Buttons... ganz simpel alles. So etwas kann man mal eben, weil man es gerade braucht, zusammen klicken (-> Ziel erreicht; Weiter geht's), oder man ordnet es schön ansehnlich und einheitlich an (-> Ziel erreicht; wirkt nicht so billig - hat evtl. etwas mehr Zeit in Anspruch genommen). Dann kann es immer noch intuitiv sein, wirkt aber nicht "billig".
Dir scheint nicht klar zu sein, was die Rescue-CD von TC ausmacht. Dort befindet sich der Header des Volumens drauf. Der ist bei jedem Volumen individuell - den kann man nicht nachträglich aus dem Internet laden
Wenn es wirklich mal darum geht ein beschädigtes Volumen zu retten, dann entscheidet das Vorhandensein einer Headersicherung ob die Rettung erfolgreich verlaufen wird oder zum scheitern verurteilt ist.
Das passiert eben nicht automatisch! Den muss man manuell installieren.
Und mit Magie meine ich, dass du im Vorfeld einfach nicht weißt, ob das funktioniert. Du kannst mit DC dein System in einen inkonsistenten Zustand versetzen - mit TC und BL ist das nicht möglich. Die Programme prüfen bspw. auf logische Fehler und verhindern sie... DC prüft nicht und auf Grund fehlender Dokumentation weißt du gar nicht, was ein logischer Fehler sein kann. Typisch für etwas was ich "zusammen gehackt" nenne
Nichts - aber da es keine Dokumentation gibt, stehst du als Neuling erst einmal da und weist von nichts. Wirst überrascht. Magic just happens
Tja, der eine überträgt die Verantwortung der Software auf den Nutzer ("Sichere... ich weiß nicht ob ich alles richtig machen werde"), der andere erwartet eben, dass das was etwas tut weiß was es macht und mit Netz arbeitet.
Blah. Im Nachhinein ist alles logisch erklärbar. Im ersten Moment würdest auch du doof dreinschauen. Wenn das dokumentiert wäre oder die Software automatisch erkennt, dass der Bootloader nicht mehr benötigt wird und ihn mit der Entschlüsselung der letzten Partition entfernen würde...
Solche Argumente liebe ich immer. "Aber ich hatte auch schon Probleme"...
Aber darum geht es mir ja gar nicht: Ich kritisiere nur, dass das alles nicht dokumentiert ist. Du weißt nicht was du tun musst und dich erwartet. Gäbe es eine Dokumentation - ich hätte die ganzen Punkte gar nicht erwähnt!Und du musst DC gegenüber mir auch gar nicht verteidigen. Ich habe lediglich zum Ausdruck gebracht, dass auf mich die Software den Eindruck von "zusammen gehackt" (=prototyping) macht. Das habe ich dann auf Nachfrage noch begründet...
Ich behaupte ja nicht, dass DC selbst nicht funktioniert...
Nur als Kurzantwort:
- Die TC Gui ist nicht überladen, aber ich finde sie auch nicht immer intuitiv. DC scheint mir da intuitiver zu sein (für mich!).
- Die tatsächliche Entstehung von TC oder DC wage ich nicht zu beurteilen, da ich keiner der Programmierer bin, aber wenn Du da Einsicht hast...
- die Rescue-CD bietet ein Backup des Headers, stimmt. Kannst Du bei DC aber auch machen lassen, kostet einen Klick. Steht auch in der FAQ, zumindest diese sollte man lesen als halbwegs vernünftiger Anwender, das wiederum erwarte ich.
- Dass eine vorherige Funktionsprüfung wünschenswert wäre, sehen wir ja beide so. Ein "Sicherheitsnetz" kann eine Software dennoch immer nur bedingt leisten. Gerade bei Verschlüsselungssoftware ist ein Backup immer Pflicht, jeder, der etwas anderes behauptet, hat entweder keine wichtigen Daten zu verschlüsseln und die nötige Zeit, alles neu aufzusetzen, oder er ist schlicht naiv.
- Eine funktionierende Software ist nie Magie, das kann ich einfach nicht nachvollziehen.
- Letztlich kommst Du ja selber zum Fazit, dass Du all das nur deswegen kritisierst, weil es angeblich nicht dokumentiert ist. Naja, unabhängig von der tatsächlichen Güte der offiziellen Dokumentation gibt es ein Wiki und ein Forum, in denen weitere Informationen verfügbar sind und auch Fragen gestellt werden können. Klar ist bessere Doku immer netter, aber auch bei TC finde ich nicht alles 100%ig verständlich erklärt oder überhaupt dokumentiert, wenn gleich es übersichtlicher auf deren Homepage zugeht, das stimmt schon. Aber aus all dem den Schluss zu ziehen, die Software sei billig und zusammen gehackt, finde ich dann doch nicht richtig.
Soll jeder einfach das nutzen, was ihm mehr liegt, dann werden alle glücklich!
- Die TC Gui ist nicht überladen, aber ich finde sie auch nicht immer intuitiv. DC scheint mir da intuitiver zu sein (für mich!).
- Die tatsächliche Entstehung von TC oder DC wage ich nicht zu beurteilen, da ich keiner der Programmierer bin, aber wenn Du da Einsicht hast...
- die Rescue-CD bietet ein Backup des Headers, stimmt. Kannst Du bei DC aber auch machen lassen, kostet einen Klick. Steht auch in der FAQ, zumindest diese sollte man lesen als halbwegs vernünftiger Anwender, das wiederum erwarte ich.
- Dass eine vorherige Funktionsprüfung wünschenswert wäre, sehen wir ja beide so. Ein "Sicherheitsnetz" kann eine Software dennoch immer nur bedingt leisten. Gerade bei Verschlüsselungssoftware ist ein Backup immer Pflicht, jeder, der etwas anderes behauptet, hat entweder keine wichtigen Daten zu verschlüsseln und die nötige Zeit, alles neu aufzusetzen, oder er ist schlicht naiv.
- Eine funktionierende Software ist nie Magie, das kann ich einfach nicht nachvollziehen.
- Letztlich kommst Du ja selber zum Fazit, dass Du all das nur deswegen kritisierst, weil es angeblich nicht dokumentiert ist. Naja, unabhängig von der tatsächlichen Güte der offiziellen Dokumentation gibt es ein Wiki und ein Forum, in denen weitere Informationen verfügbar sind und auch Fragen gestellt werden können. Klar ist bessere Doku immer netter, aber auch bei TC finde ich nicht alles 100%ig verständlich erklärt oder überhaupt dokumentiert, wenn gleich es übersichtlicher auf deren Homepage zugeht, das stimmt schon. Aber aus all dem den Schluss zu ziehen, die Software sei billig und zusammen gehackt, finde ich dann doch nicht richtig.
Soll jeder einfach das nutzen, was ihm mehr liegt, dann werden alle glücklich!
Hey Leute. Ich würde gerne aus Performancegründen von TC zu DC wechseln und hab ein paar fragen, hoffe ihr könnt mir helfen.
Momentan habe ich TC auf meiner SSD systemplatte und auf 3 HDDS, die ich mit Truemounter automatisch mounten lasse, wenn ich mich einlogge (per Keyfile, die auf der SSD liegt).
Da man bei TC ja nur die Systemplatte entschlüsseln kann, ich aber keine anderen HDDS habe müsste ich wissen, ob ich beispielweise mit DC die mit TC verschlüsselten HDDS entschlüsseln kann. Ich weiss nur, dass es mit DC selbst wohl geht aber nur bei von DC verschlüsselten Platten. Oder gibt es andere wege die HDDs zu entschlüsseln, bevor ich DC installiere?
Ist es richtig, dass ich mit DC mit der Pre-Boot Authentication direkt alle Laufwerke mounten kann? Kann ich die HDDs dann auch an andere Systeme hängen und dort einzeln mounten?
Momentan habe ich TC auf meiner SSD systemplatte und auf 3 HDDS, die ich mit Truemounter automatisch mounten lasse, wenn ich mich einlogge (per Keyfile, die auf der SSD liegt).
Da man bei TC ja nur die Systemplatte entschlüsseln kann, ich aber keine anderen HDDS habe müsste ich wissen, ob ich beispielweise mit DC die mit TC verschlüsselten HDDS entschlüsseln kann. Ich weiss nur, dass es mit DC selbst wohl geht aber nur bei von DC verschlüsselten Platten. Oder gibt es andere wege die HDDs zu entschlüsseln, bevor ich DC installiere?
Ist es richtig, dass ich mit DC mit der Pre-Boot Authentication direkt alle Laufwerke mounten kann? Kann ich die HDDs dann auch an andere Systeme hängen und dort einzeln mounten?
Dui kannst DC und TC parallel nutzen, d.h. z.B. mit DC die FSE und mit TC die anderen Partitionen und/oder Container ver-/entschlüsseln. Bezüglich des mountens aller Laufwerke nach der PBA einfach mal auf die Wiki-Seite,FAQ und Forum schauen, da ich auch keine Antwort parat.
Hm.. ja, die Idee kam mir irgendwie nicht, ist aber sehr gut 
Genau so hab ichs jetzt umgesetzt, die Keyfile für Truemounter liegt auf der mit DC encrypteten SystemSSD.
Werte sind top, siehe hier (Mit Handy abphotographiert..fragt nicht):
Vorher (links die M4, die Agility 3 hing nur an SATA II, darum der geringere Sequential Speed):
Nachher:
TC in Version 7.0a und DC auch in der aktuellen 1.0.732.111 (beta). Sequential eventuell etwas langsam, das liegt jedoch an der SATA III erweiterungskarte, die nur mit PCIe 1x läuft. (Danke Asus!)
Genau so hab ichs jetzt umgesetzt, die Keyfile für Truemounter liegt auf der mit DC encrypteten SystemSSD.
Werte sind top, siehe hier (Mit Handy abphotographiert..fragt nicht
):Vorher (links die M4, die Agility 3 hing nur an SATA II, darum der geringere Sequential Speed):
Nachher:
TC in Version 7.0a und DC auch in der aktuellen 1.0.732.111 (beta). Sequential eventuell etwas langsam, das liegt jedoch an der SATA III erweiterungskarte, die nur mit PCIe 1x läuft. (Danke Asus!)
Zuletzt bearbeitet:
cRaZy-biScuiT
Enthusiast
Ist deine DRUCK-Taste kaputt?
Ist ja wirklich kaum Performance-Verlust. Sollte ich eine SSD kaufen wird die dann also auch wieder verschlüsselt. Mit TC ist die Performance nicht so gut?
Ist ja wirklich kaum Performance-Verlust. Sollte ich eine SSD kaufen wird die dann also auch wieder verschlüsselt. Mit TC ist die Performance nicht so gut?
"Fragt nicht"! Hab das so gemacht, weil ich ein totales Durcheinander meiner ganzen Platten hatte, da ich grad am basteln war, die SSD nach dem Test ohne Verschlüssellung wieder formatiert habe und die bilder ursprünglich nur für mich zum vergleich wollte.
Truecrypt hab ich sogar auch mal auf der M4 gehabt und auf der Agility 3 sogar 2 Monate.
Zu sagen bleibt, dass bei TC die 4K Random READ Werte bei 10-13 liegen, die WRITE auch nicht wirklich besser sind und die 4k-64Thrd Werte auf so ca ein viertel/fünftel absacken. Alle sagen immer der Sequential Speed wäre bei TC besser. Wenn man das so sagen will, dann liegt der Unterschied aber wirklich nur bei wenigen Prozent.
Da die 64Thrd Werte für den Normalgebrauch wohl nicht aussagekräftig sind, die 4k aber schon und vor allem eher Read als Write bei üblicher benutzung (PrivatPC, Windows, Programme und Games auf SSD), da ja viele kleine Daten gelesen werden, ist Diskcryptor eindeutig die bessere Wahl für die SSD. Da ich TC eigentlich mag hoffe ich, dass da noch eine entsprechend schnelle Version nachkommt.
Im Alltagsgebrauch beim Windows Start oder öffnen von sowas wie Word merkt man nicht wirklich einen unterschied zwischen TC und DC. Er ist zwar da, auch feststellbar aber sooo minimal, dass es eigentlich egal ist. Bei Games ists mir schon eher aufgefallen aber es ist jetzt nicht so als wäre DC doppelt so schnell, nur weil die 4k Werte 2mal höher liegen. Zum einen hängen Ladezeiten nicht zu 100% von der Festplatte ab und zum anderen sind vermutlich 4k-Daten auch schon wieder extrem klein, was in der Praxis nicht so extrem vorkommt (Glaub ich)
Hab das so gemacht, weil ich ein totales Durcheinander meiner ganzen Platten hatte, da ich grad am basteln war, die SSD nach dem Test ohne Verschlüssellung wieder formatiert habe und die bilder ursprünglich nur für mich zum vergleich wollte.Truecrypt hab ich sogar auch mal auf der M4 gehabt und auf der Agility 3 sogar 2 Monate.
Zu sagen bleibt, dass bei TC die 4K Random READ Werte bei 10-13 liegen, die WRITE auch nicht wirklich besser sind und die 4k-64Thrd Werte auf so ca ein viertel/fünftel absacken. Alle sagen immer der Sequential Speed wäre bei TC besser. Wenn man das so sagen will, dann liegt der Unterschied aber wirklich nur bei wenigen Prozent.
Da die 64Thrd Werte für den Normalgebrauch wohl nicht aussagekräftig sind, die 4k aber schon und vor allem eher Read als Write bei üblicher benutzung (PrivatPC, Windows, Programme und Games auf SSD), da ja viele kleine Daten gelesen werden, ist Diskcryptor eindeutig die bessere Wahl für die SSD. Da ich TC eigentlich mag hoffe ich, dass da noch eine entsprechend schnelle Version nachkommt.
Im Alltagsgebrauch beim Windows Start oder öffnen von sowas wie Word merkt man nicht wirklich einen unterschied zwischen TC und DC. Er ist zwar da, auch feststellbar aber sooo minimal, dass es eigentlich egal ist. Bei Games ists mir schon eher aufgefallen aber es ist jetzt nicht so als wäre DC doppelt so schnell, nur weil die 4k Werte 2mal höher liegen. Zum einen hängen Ladezeiten nicht zu 100% von der Festplatte ab und zum anderen sind vermutlich 4k-Daten auch schon wieder extrem klein, was in der Praxis nicht so extrem vorkommt (Glaub ich
)
cRaZy-biScuiT
Enthusiast
Hmmm alles in allem: Wenn ich eine Festplatte mir TC verschlüsselt habe und dann eine SSD damit verschlüssele sollte schon ein deutlicher Performance-Gewinn da sein. Da limitiert dann vermutlich eher mein Q6600 als die SSD & TC
Poddy
Neuling
- Mitglied seit
- 09.04.2011
- Beiträge
- 947
Naja, sagen wir mal ein Bisschen. Sequentiell macht der Q6600@stock so bei 400-450MB dicht und ein Prozi übertaktet auf 5GHz würd bei TC vllt auch noch ein paar IOPs raus holen. Aber grundsätzlich ist dann natürlich schon TC der limitierende Faktor.
Ich habe hier Fileserver wo Q6600 verbaut sind und 4-6 einzelne Festplatten drinnen stecken. Der Prozessor limitiert wirklich nicht.
Rechne pro Festplatte mit 10-20% CPU Last (auch Abhängig von der IO-Last).
Gleiche Systeme durch Prozessoren mit AES-NI ersetzt sorgen nur dafür, dass die Prozessorlast sinkt, d.h. mehr Ressourcen für anderes frei ist/geringerer Stromverbrauch. Es ist aber wirklich nicht so, als limitiere der Prozessor und als würde mit AES-NI mehr gehen.
Rechne pro Festplatte mit 10-20% CPU Last (auch Abhängig von der IO-Last).
Gleiche Systeme durch Prozessoren mit AES-NI ersetzt sorgen nur dafür, dass die Prozessorlast sinkt, d.h. mehr Ressourcen für anderes frei ist/geringerer Stromverbrauch. Es ist aber wirklich nicht so, als limitiere der Prozessor und als würde mit AES-NI mehr gehen.
Zuletzt bearbeitet:
Poddy
Neuling
- Mitglied seit
- 09.04.2011
- Beiträge
- 947
Also bei einzeln HDDs nicht, aber trotzdem schafft man mit TC und dem Prozi (mein Q8400 schafft gleich viel) nicht mehr wie 400MB/s. Ich merks ja bei meinem Raid 5 aus 8 Platten. Mit DC und Serpent limiert er bei ca 600MB. Nicht übertaktet gehen bei mir auch die 4K Werte runter bei TC. Ein Phenom X6 macht auch ungefähr 100MB pro Kern, bei den Prozis auf der Zeit kann man grundsätzlich 100MB pro Kern Rechnen bei ca. 3GHz. Ein Intel Core i5-2520M profitiert dann schon auch von AES-NI, je nach Storage Ausstattung.
Zuletzt bearbeitet:
Das liegt aber nicht am Prozessor, sondern an der Verschlüsselung allgemein.
Wie bekannt schreiben Festplatten immer in Blöcken. Dateisysteme der Betriebssysteme liefern Cluster und der Disktreiber, in welchem die Verschlüsselung stattfindet), schiebt die Blöcke hin und her.
Unverschlüsselt kann die Festplatte jetzt in die Blöcke reinsehen und weiß, welche Bits sich verändert haben. Beim Speichern eines geänderten Blocks muss dieser zwar dennoch gelesen werden (kann allerdings aus dem Cache kommen!) und im Endeffekt wird er auch wieder vollständig geschrieben... der Controller kann aber zwischenspeichern und mit dem echten Schreiben warten bis es ihm passt (bspw. der Track gerade beim Kopf vorbei kommt, anstatt den Kopf der gerade woanders ist zu bewegen, auf den Track zu warten...).
Sobald FDE ins Spiel kommt, kann der Controller nicht mehr in den Block schauen bzw. es haben sich einfach immer alle Bits des Blocks geändert. Somit muss er eigentlich immer direkt schreiben, der Cache läuft so sau schnell voll... und beim Lesen bringt der Cache auch nichts, da das der FDE-Treiber immer volle Blöcke anfordert, weil er diese entschlüsseln muss.
Kurz um: Bei FDE hat die Platte immer zu tun, tolle Cachinglösungen der Hersteller haben keine Chance. Das gilt umso stärker für RAIDs, weil hier der Cache zentral im RAID-Controller ist... der Controller selber an die Platten immer ein Force-Write Command schickt...
Heutige Prozessoren wirst du mit FDE nicht wirklich an die Grenzen bekommen... (insofern sind diese AES-NI Benchmarks von TC völlig irreführend, weil sie wohl kaum jemand richtig versteht)
Wie bekannt schreiben Festplatten immer in Blöcken. Dateisysteme der Betriebssysteme liefern Cluster und der Disktreiber, in welchem die Verschlüsselung stattfindet), schiebt die Blöcke hin und her.
Unverschlüsselt kann die Festplatte jetzt in die Blöcke reinsehen und weiß, welche Bits sich verändert haben. Beim Speichern eines geänderten Blocks muss dieser zwar dennoch gelesen werden (kann allerdings aus dem Cache kommen!) und im Endeffekt wird er auch wieder vollständig geschrieben... der Controller kann aber zwischenspeichern und mit dem echten Schreiben warten bis es ihm passt (bspw. der Track gerade beim Kopf vorbei kommt, anstatt den Kopf der gerade woanders ist zu bewegen, auf den Track zu warten...).
Sobald FDE ins Spiel kommt, kann der Controller nicht mehr in den Block schauen bzw. es haben sich einfach immer alle Bits des Blocks geändert. Somit muss er eigentlich immer direkt schreiben, der Cache läuft so sau schnell voll... und beim Lesen bringt der Cache auch nichts, da das der FDE-Treiber immer volle Blöcke anfordert, weil er diese entschlüsseln muss.
Kurz um: Bei FDE hat die Platte immer zu tun, tolle Cachinglösungen der Hersteller haben keine Chance. Das gilt umso stärker für RAIDs, weil hier der Cache zentral im RAID-Controller ist... der Controller selber an die Platten immer ein Force-Write Command schickt...
Heutige Prozessoren wirst du mit FDE nicht wirklich an die Grenzen bekommen... (insofern sind diese AES-NI Benchmarks von TC völlig irreführend, weil sie wohl kaum jemand richtig versteht)
Poddy
Neuling
- Mitglied seit
- 09.04.2011
- Beiträge
- 947
Versteh schon was du meinst, aber das ändert nichts daran, dass die Aussage dass der Prozi limiert richtig ist.
Das ist doch egal, Fakt ist, dass wenn ich meinen Prozi auf 2,8GHz habe, ich mit TC ziemlich genau 400MB schaffe. Das spiegelt sich dann genauso in Benches und beim Kopieren von Dateien wieder. Habe ich ihn auf 3,4GHz schafft er 50-70MB mehr, also limitiert hier doch der Prozi. Das Gleiche hab ich bei Phenoms gesehen, ein Quad schafft 400 und ein Sixcore 600, also ich das doch auch CPU abhängig?
Man nehme eine Festplatte, lege darauf eine 10GB große Datei.
Wenn man diese Datei jetzt von der Festplatte liest, dann erreicht das System ~130MB/s (sehr gute Werte für aktuelle SATA-Festplatten).
Jetzt verschlüsselst du diese Festplatte und liest die Datei erneut. Diesmal erreicht das gleiche System aber nur ~90MB/s.
Verstehe ich dich richtig das du behauptest, wenn man jetzt lediglich den Prozessor durch einen besseren ersetzen würde (mehr MHz/Cores), du auf >90MB/s kommen würdest?
Wenn ja, wo siehst du denn das Limit?
Wenn man diese Datei jetzt von der Festplatte liest, dann erreicht das System ~130MB/s (sehr gute Werte für aktuelle SATA-Festplatten).
Jetzt verschlüsselst du diese Festplatte und liest die Datei erneut. Diesmal erreicht das gleiche System aber nur ~90MB/s.
Verstehe ich dich richtig das du behauptest, wenn man jetzt lediglich den Prozessor durch einen besseren ersetzen würde (mehr MHz/Cores), du auf >90MB/s kommen würdest?
Wenn ja, wo siehst du denn das Limit?
Poddy
Neuling
- Mitglied seit
- 09.04.2011
- Beiträge
- 947
Nein, da limitiert natürlich die Verschlüsselung
Wobei hier ja DC so gut programmiert ist dass es wohl eher Richtung 130 gehen würde.
Die Limitierung die ich meine geht in Richtung maximal Leistung. Im Moment ärgert es mich dass meine CPU beim Kopieren zwischen den Raid-Arrays limitiert. Mit einem i7-2600 oder 6core hätte ich das Prob nicht mehr
Wobei hier ja DC so gut programmiert ist dass es wohl eher Richtung 130 gehen würde.
Die Limitierung die ich meine geht in Richtung maximal Leistung. Im Moment ärgert es mich dass meine CPU beim Kopieren zwischen den Raid-Arrays limitiert. Mit einem i7-2600 oder 6core hätte ich das Prob nicht mehr
Zuletzt bearbeitet:
Magst du mal etwas kopieren (>10GB große Datei) und davon einen Screenshot erstellen, auf dem folgendes zu sehen ist:
a) Ausgeklappter Kopierdialog von Windows
b) Windows Taskmanager "Leistungstab"
c) Im "Process Explorer" von Sysinternals klickst du mit der rechten Maustaste auf "System" und zeigst das Tab "Threads" sortiert nach CPU-Last absteigend
d) Ressourcenmonitor (über Windows Taskmanager startbar), Tab "Datenträger" (dort die Diagramme rechts)
Sollte sich alles sichtbar für einen Screenshot anordnen lassen...
Würde mich sehr interessieren wie das bei dir aussieht.
a) Ausgeklappter Kopierdialog von Windows
b) Windows Taskmanager "Leistungstab"
c) Im "Process Explorer" von Sysinternals klickst du mit der rechten Maustaste auf "System" und zeigst das Tab "Threads" sortiert nach CPU-Last absteigend
d) Ressourcenmonitor (über Windows Taskmanager startbar), Tab "Datenträger" (dort die Diagramme rechts)
Sollte sich alles sichtbar für einen Screenshot anordnen lassen...
Würde mich sehr interessieren wie das bei dir aussieht.
Poddy
Neuling
- Mitglied seit
- 09.04.2011
- Beiträge
- 947
Ist der Process Explorer wichtig, sonst installier ich den noch.
Wie du sieht 200MB pro Laufwerk > weil ja beide Laufwerke verschlüsselt sind.
http://img842.imageshack.us/img842/1655/neuesbildd.jpg
Wie du sieht 200MB pro Laufwerk > weil ja beide Laufwerke verschlüsselt sind.
http://img842.imageshack.us/img842/1655/neuesbildd.jpg
Anhänge
Zuletzt bearbeitet:
musschrott
Enthusiast
- Mitglied seit
- 31.01.2007
- Beiträge
- 632
Festplatten arbeiten mit Sektoren von 512Bytes bzw. 4k Größe, ich kann mir kaum vorstellen, dass die sich um Veränderungen bei einzelnen Bytes, geschweige denn Bits kümmern. Würde man das versuchen, dürfte das einen ordentlichen Overhead für die Verwaltung der einzelnen Bytes geben. Für die Festplatte dürfte nur relevant sein, ob sich ein Sektor verändert hat und diesen dann komplett Schreiben/Cachen etc. Da die Blockgröße von AES 128 Bits (= 16 Bytes) ist, hätte jede relevante Veränderung so oder so zu einem veränderten Sektor und entsprechender Festplatten-Aktivität geführt.
cRaZy-biScuiT
Enthusiast
Richtig, aber das eben würde ich gerne wollen. Wir leben eigentlich nicht mehr in der PIO-Steinzeit wo ein Festplattenzugriff die CPU auslasten sollte. Auch verschlüsselt muss das nicht sein.
-> Die Screens sind interessant.
Oh, schade. Musste wieder von DC auf TC wechseln. Die Performance von DC war schon gut aber leider hatte ich diverse Probleme. Dirt 3 startete nocht, das Bild blieb einfach schwarz, Starcraft musste ich auf einer anderen Platte, die mit TC verschlüsselt war, installieren und rüberkopieren, diverse andere Programme machten auch Probleme.
Hatte das schonmal wer?
Ohne Verschlüsselung und mit TC funktioniert es problemlos.
Hatte das schonmal wer?
Ohne Verschlüsselung und mit TC funktioniert es problemlos.
1. Mehr Mhz pro Kern bringen definitiv mehr Leistung bei einer Verschlüsselung, genau wie Poddy das schon mehrfach versucht hat klarzustellen. Das hat nichts mit einer grundsätzlichen Limitierung aufgrund der unterschiedlichen Implementierung des Algorithmus von TC oder DC zu tun.
2. Bei mir läuft alles mit DC, noch keine Probleme insoweit gehabt.
2. Bei mir läuft alles mit DC, noch keine Probleme insoweit gehabt.
Ich hab alles ausprobiert. Bei Starcraft ging nur rüberschieben und das Repairtool laufen lassen, danach lief es. Installation auf der SSD ging nicht, da es dann nicht patchbar war.
Bei Dirt 3 ging weder installation noch kopieren auf der/die SSD. Auf einer HDD ging beides. Mit TC gehts nun auch auf der SSD.
Dass das problem nicht jeder haben kann, dachte ich mir auch, aber bei mir gehts nunmal wenn ich nicht DC verwende. Woran das sonst noch liegt, weiss ich nicht, wüsst ich aber gerne. Bimn da ziemlich ratlos leider.
Bei Dirt 3 ging weder installation noch kopieren auf der/die SSD. Auf einer HDD ging beides. Mit TC gehts nun auch auf der SSD.
Dass das problem nicht jeder haben kann, dachte ich mir auch, aber bei mir gehts nunmal wenn ich nicht DC verwende. Woran das sonst noch liegt, weiss ich nicht, wüsst ich aber gerne. Bimn da ziemlich ratlos leider.
Zu 1.
Wenn das Medium z.B. HDD nicht schneller schreibt, spielt das aber keine Rolle.
Also von Dir hätte ich so eine Antwort nicht erwartet, Bob...
Ist uns doch allen klar, dass wenn das Medium limitiert, die CPU so schnell sein kann, wie sie will. Im sequentiellen Bereich wird auch mit einer langsameren CPU kaum eine HDD wegen einer Verschlüsselung mit einem (!) Algorithmus (z.B. AES) limitieren. Bei einer SSD mit über 300 oder 400 MB/s kann das schon mal passieren. Im random Bereich kommt das noch viel eher zu Tage. Bei HDDs ist das egal, die sind eh immer langsam. Bei einer SSD kann man sich aber mit einer langsamen CPU auch gute 4k-Werte abschminken, das wurde auch in User-Tests oftmals belegt.
Ähnlich ist es im realen Betrieb, wenn durch mehrere Zugriffsanforderungen gleichzeitig (verschiedene Programme erteilen Befehle gleichzeitig) etwas gelesen/geschrieben werden soll.
Eine CPU mit hohem Takt pro Kern (da nicht alles perfekt parallelisiert werden kann) ist dementsprechend unumgänglich, um das Medium-Limit überhaupt erreichen zu können.
Ui, jetzt reden wir aneinander vorbei. Ja, TC limitiert bei 4k mehr als DC. Das hat aber nichts mit einer hardwarebasierten Limitierung zu tun. Da gilt dann mein oben gesagtes zu CPU und HDD/SSD. Mit einer Atom-CPU wirst Du z.B. kaum feststellen können, dass TC limitiert, weil eine SSD mangels CPU-Leistung noch nicht mal unverschlüsselt hohe random-Werte schaffen wird.
Sieht man z.B. hier ganz gut:
http://www.hardwareluxx.de/community/11929910-post833.html
Mit 1Ghz deutlich langsamer als bei höherem Takt. War wohl in einem Asus EeePC, CPU weiß ich nicht.
Sieht man z.B. hier ganz gut:
http://www.hardwareluxx.de/community/11929910-post833.html
Mit 1Ghz deutlich langsamer als bei höherem Takt. War wohl in einem Asus EeePC, CPU weiß ich nicht.
Zuletzt bearbeitet:
