2000GB in 50sec?

[Olliar]

"Einem kleinen Benchmark des Entwicklers zufolge reduziert der Patch die Dateisystemoperationen auf einer 2 TByte großen USB-Festplatte von zuvor rund 380 Sekunden auf nur noch rund 50 Sekunden."

2TB = 2000 Gigabyte in 50 sekunden, 40GB/s? (?)
Ist da was beim Übersetzen falsch gelaufen?


Oder (wenn es "System"-Operationen waren:

Sehr guter 2TB <hust> USB2 stick 25MB/s Read 80.000 Sekunden, und dann 330sec gespart?
Das sind so wenig, das könnte man in ppm ausdrücken.

Passt nicht, also: externe "echte" SATA-SSD mit USB3 500MB/s Read = 4000 sec.
OK, das wäre dann bis zu fast 9% schneller.
Sage bitte keiner, Linuxer verstehen nix vom Marketing! :-)

Heutzutage interessanter wäre:
Wieviel kg CO2 erspart dieser Patch unserer Atmosphäre?
(Durchaus ernstgemeinte Frage)

Anyway:
Ein schönerer Algorithmus ist immer lobenswert.



Original Text:

>With this patch, on slow USB connected 2TB hdd:
>
> [before]
>383.18sec
>
> [after]
>51.03sec

Was hat er in den 51/383sec gemacht?
Was soll das 2TB dadrin?
Wie kann man das reproduzieren?
Hae?

"on slow connected USB", heist dann wohl, das er bei USB3.0 und guten Controlern nicht messbares bringt? (Weil halt der Overhead durch USB2.0 Kommandos erheblich ist,
und er massiv an USB-Kommandos spart hängt die Kiste nicht "ewig" im IO rum?)



6 mal bearbeitet, zuletzt am 14.04.20 17:09 durch Olliar.

[Lasse Bierstrom]

Ins blaue geraten:
Es geht um die Größe der FAT table

[wurstdings]

Olliar schrieb:
--------------------------------------------------------------------------------
> Ist da was beim Übersetzen falsch gelaufen?
Nein beim Verstehen ;)
> Was hat er in den 51/383sec gemacht?
Sagt er nicht, aber ausgehend vom Patch auf jeden Fall Daten gelesen und sehr wahrscheinlich sequenziell.
> Was soll das 2TB dadrin?
So groß war die Partition, ne große FAT ist langsamer als ne Kleine.
> Wie kann man das reproduzieren?
Patch installieren und testen, nennt sich OpenSource.
> "on slow connected USB", heist dann wohl, das er bei USB3.0 und guten
> Controlern nicht messbares bringt?
Er schrieb von langsamen Laufwerk, welches über eine nicht spezifizierte USB-Version verbunden wurde.
> (Weil halt der Overhead durch USB2.0
> Kommandos erheblich ist,
> und er massiv an USB-Kommandos spart hängt die Kiste nicht "ewig" im IO
> rum?)
Nein weil man damit den readahead Wert anpassen kann, was bei sequenziellen Lesevorgängen Vorteile bringt.

[Olliar]

wurstdings schrieb:
--------------------------------------------------------------------------------
> Olliar schrieb:
> ---------------------------------------------------------------------------
> > Was hat er in den 51/383sec gemacht?
> Sagt er nicht,

Das wäre aber schon wichtig zu wissen wenn man diese Zahlen irgendwie einordnen will.

> aber ausgehend vom Patch auf jeden Fall Daten gelesen und
> sehr wahrscheinlich sequenziell.

Em, "wahrscheinlich" so so.
Was soll so eine "Anwort"?


> > Was soll das 2TB dadrin?
> So groß war die Partition, ne große FAT ist langsamer als ne Kleine.

Wo steht das?
Und wie groß waren die Cluster?


> > Wie kann man das reproduzieren?
> Patch installieren und testen, nennt sich OpenSource.

Hm, in meiner Version dieser Welt steht "wie" nicht für "was braucht man".
Und in meiner Version dieser Welt ist klar, das ich das was ich testen brauche.

Und wie teste ich das nun?
Welche commando Zeile? welches Tool?
(In unix time kann man sich die systemzeit anteile anzeigen lassen, hat er das so gemacht)

Welche "langsame Festplatte"? Typ?
Was für Daten sind wie darauf? Fragmentierung?
Wie lautet die kommando Zeile mit der das getestet wurde?

> > "on slow connected USB", heist dann wohl, das er bei USB3.0 und guten
> > Controlern nicht messbares bringt?

> Er schrieb von langsamen Laufwerk, welches über eine nicht spezifizierte
> USB-Version verbunden wurde.

Ja, das stand da, ist aber nicht ausreichend, wenn etwas "test" nennen will.

Er schrieb von einem nicht spezifizierten "langsamen" Laufwerk, welches über eine nicht spezifizierte USB-Version verbunden wurde, wenn es denn überhaupt USB war, mit nicht spezifizierten Daten und einem nicht spezifizierten Datenbewegungvorgang...

So etwas ist doch kein "Test".



> > (Weil halt der Overhead durch USB2.0 Kommandos erheblich ist,
> > und er massiv an USB-Kommandos spart hängt die Kiste nicht "ewig" im IO
> > rum?)
> Nein weil man damit den readahead Wert anpassen kann, was bei sequenziellen
> Lesevorgängen Vorteile bringt.

Wieso "nein"? Das schreibe ich doch.
Weil er die readahed werte anpassen kann, kann er effektiver die Daten holen, und braucht dazu wenige Befehle für das Laufwerk und ist relativ umso schneller je lahmer das Laufwerk resp der Bus ist.

Naja, keine Antwort ist auch ne Antwort.

[Olliar]

Lasse Bierstrom schrieb:
--------------------------------------------------------------------------------
> Ins blaue geraten:
> Es geht um die Größe der FAT table

Ja. Das wird es sein, wenn man davon ausgeght,
das das die Partítion größe ist.
Die Frage darf erlaubt sein:
Ist das realistisch?
Wer legt 2000GB Daten auf einer FAT-Platte ab und warum?

Gibt es Vergleichswerte für Windows?

[wurstdings]

Olliar schrieb:
--------------------------------------------------------------------------------
> Das wäre aber schon wichtig zu wissen wenn man diese Zahlen irgendwie
> einordnen will.
Da stimme ich dir zu. Der Test ist schon recht lax und lässt grundlegende Details vermissen.
> Em, "wahrscheinlich" so so.
> Was soll so eine "Anwort"?
Der Patch ist nunmal nur für ganz bestimmte Operationen nützlich, von daher gibt es nicht viele Möglichkeiten wie der Test ausgesehen hat.
> Wo steht das?
Mit etwas Logik, kann man das herauslesen.
> Und wie groß waren die Cluster?
Das ist für Readahead doch unwichtig?
> Hm, in meiner Version dieser Welt steht "wie" nicht für "was braucht man".
Na Dateien kopieren und Zeit messen oder mit dd direkt von der Patte lesen. Einmal vor dem Patch einmal danach.
> Was für Daten sind wie darauf? Fragmentierung?
Ist doch egal, mach deine eigenen Daten drauf.
> > Nein weil man damit den readahead Wert anpassen kann, was bei
> sequenziellen
> > Lesevorgängen Vorteile bringt.
>
> Wieso "nein"? Das schreibe ich doch.
> Weil er die readahed werte anpassen kann, kann er effektiver die Daten
> holen, und braucht dazu wenige Befehle für das Laufwerk und ist relativ
> umso schneller je lahmer das Laufwerk resp der Bus ist.
Ok, da hatte ich dich falsch verstanden, er schickt ja die gleichen Befehle ans Laufwerk, aber dank Readahead sind halt einige Daten bereits im Cache.