[Erledigt] Rechenleistung beim Kopieren von Bedeutung?

Warum Debian? Was muss ich vorher wissen? Wo geht's nach der Installation weiter?
wanne
Moderator
Beiträge: 5839
Registriert: 24.05.2010 12:39:42

Re: [Erledigt] Rechenleistung beim Kopieren von Bedeutung?

Beitrag von wanne » 14.06.2019 03:31:57

MSfree hat geschrieben: ↑ zum Beitrag ↑
13.06.2019 22:55:52
wanne hat geschrieben: ↑ zum Beitrag ↑
13.06.2019 21:34:37
Üblicher Schreib/Lesespeed von ner SSD sind 3GBit/s.
Nicht ganz, SATA macht nur 2.4GBit/s.
[/quote]Nein SATA kann bis zu 1.97 GB. Siehe auch: https://en.wikipedia.org/wiki/Serial_AT ... ther_buses
zugegebener weise machen die meisten SSDs entweder SATA mit 600MByte/s oder M.2 oder NVMe mit U.2.
rot: Moderator wanne spricht, default: User wanne spricht.

MSfree
Beiträge: 4241
Registriert: 25.09.2007 19:59:30

Re: [Erledigt] Rechenleistung beim Kopieren von Bedeutung?

Beitrag von MSfree » 14.06.2019 08:27:19

wanne hat geschrieben: ↑ zum Beitrag ↑
14.06.2019 03:21:02
Nur dd ist so dämlich nacheinander zu lesen und zu schreiben.
cp aus coreutils/src/copy.c macht es auch so, also schön nacheinander read/write, da ist nichts parallelisiert und gepipelined.

Bei cat hast du zumindest die Parallelisierung durch die zwei Prozesse "cat" und die laufende Shell, so daß das Lesen vom cat-Prozeß kommt und die Ausgabeumleitung mit ">" die Shell übernimmt.
Alle anderen tools machen das parallel.
Bestimt nicht "alle". Ich gehe sogar so weit, zu sagen, daß praktisch gar kein Tool intern irgendetwas parallelisiert hat.
Wenn duin deinem 100 Mal schnelleren RAM kopierst ist dd schneller wie cp auf der Platte welch wunder.
Nunja, ganz dumm bin ich nun auch wieder nicht. Ich habe dd und cp zweimal ausgeführt, so daß die Ausgangsdatei auf jeden Fall spätestens beim zweiten Lauf im Cache war. Die jeweils schnelleren Zeiten hatte ich aufgeführt: Vorteil dd.

Und zumidest in dem Scenario, das ottonormal durchgeführt hat, also Nutzung von USB3-SATA-Wandlern bist du auf 2.4GBit/s auf der SATA-Seite beschränkt.

atarixle
Beiträge: 247
Registriert: 20.02.2006 19:30:37

Re: [Erledigt] Rechenleistung beim Kopieren von Bedeutung?

Beitrag von atarixle » 14.06.2019 08:42:57

dd ist nur für eines gut: man bestimmt hier die Größe des auf einmal zu lesenden Blocks. Dies kann die Lese-/Schreibgeschwindigkeit beeinflussen. Ansonsten halte ich es auch für extrem lahm, wenn ich das mit drag'n'drop unter irgend einer Oberfläche vergleiche.

Wenn du die Platte spiegeln willst, kannst du auch cat oder cp nutzen, ich selber nehme auch nur aus Gewohnheit dd.

Wann immer es mir möglich ist, lass ich aber den Verzeichnisbaum auf Datei-Ebene duplizieren.

TomL
Beiträge: 4101
Registriert: 24.07.2014 10:56:59

Re: [Erledigt] Rechenleistung beim Kopieren von Bedeutung?

Beitrag von TomL » 14.06.2019 11:38:10

wanne hat geschrieben: ↑ zum Beitrag ↑
14.06.2019 03:21:02
TomL hats ja schon erwähnt.
Ja, ich habe allerdings vorher (!) für gleiche Bedingungen gesorgt, in dem ich vorher das grml.iso einmal nach x.iso kopiert habe. Mit der Vermutung, dass -wenn Cache- der für die beiden dann folgenden Vergleiche gleichermaßen greift. Und vor dem Hintergrund ist cp deutlich schneller.
vg, Thomas

wanne
Moderator
Beiträge: 5839
Registriert: 24.05.2010 12:39:42

Re: [Erledigt] Rechenleistung beim Kopieren von Bedeutung?

Beitrag von wanne » 14.06.2019 17:19:23

MSfree hat geschrieben: ↑ zum Beitrag ↑
14.06.2019 08:27:19
cp aus coreutils/src/copy.c macht es auch so, also schön nacheinander read/write, da ist nichts parallelisiert und gepipelined.
Nein. Guck dir das Verhalten an. Die Magic steckt im read() der glibc. Das lässt den Kernel schonmal die nachfolgende Bytes vorsorglich lesen, wenn man ro geöffnet hat. – Solange man das nicht per fcntl kaputt macht. – Das lesen passiert dann parallel zum write() im cp. Wenn cp dann das nächste mal read() macht ist das weitestgehend instand fertig, weil die glibc das schonmal in vorauseilendem gehorsam gemacht hat.
Bestimt nicht "alle". Ich gehe sogar so weit, zu sagen, daß praktisch gar kein Tool intern irgendetwas parallelisiert hat.
Mann muss sich schon sehr anstrengen das oben genannte verhalten kaputt zu bekommen. Deswegen habe ich gemeint, dass das defakto jedes Programm nutzt. Die haben das nicht alle selbst implementiert. Es ist einfach da.
Bei cat hast du zumindest die Parallelisierung durch die zwei Prozesse "cat" und die laufende Shell, so daß das Lesen vom cat-Prozeß kommt und die Ausgabeumleitung mit ">" die Shell übernimmt.
Nein.> Übernimmt nicht die schell sondern übergibt nur den fd an cat. Du kannst dasda machen: cat a > b & exit dann hast du keine schell mehr aber das cat läuft weiter durch.
Nunja, ganz dumm bin ich nun auch wieder nicht. Ich habe dd und cp zweimal ausgeführt, so daß die Ausgangsdatei auf jeden Fall spätestens beim zweiten Lauf im Cache war. Die jeweils schnelleren Zeiten hatte ich aufgeführt: Vorteil dd.
Die aussage ist schlicht gelogen.
400MiB im RAM kopiere mit cp selbst auf meinem T420 nie mehr als 0.3s. Mit dd bin ich imme bei ~2s. Wie gesagt: Kann jeder mal selber nachbauen. Wenn man das oft genug macht läuft man etwa auf den Faktor 10 raus. – Außer natürlich der User heißt MSfree.
Und zumidest in dem Scenario, das ottonormal durchgeführt hat, also Nutzung von USB3-SATA-Wandlern bist du auf 2.4GBit/s auf der SATA-Seite beschränkt.
Ja eher deutlich stärker. Die 2.4GBit/s bekommst du eher nicht durch USB3. Deswegen ja meine empfehlung richtung nativen SATA. Und dafür war meine Überschlagsrechnung schon nicht schlecht. – Auch wenn sie mit 1Byte==10Bit gerechnet hat.
Edit: Die 2.4GBit/s sind natürlich totaler Unfug. 4,80GBit/s sind die Nettodatenrate von allen gebräuchlichen SATA-Anschlüssen. SATA II hat seit Jahren keiner mehr verbaut. Ich bin ohne weiter nachzudenken davon ausgegangen, dass du meine Umrechnung von 600MByte/s auf 6GBit/s kritisiert hast.
rot: Moderator wanne spricht, default: User wanne spricht.

Antworten