Merkwürdiges (Zeit-)Verhalten

[Cartman E. (cartmaneric)]

Ich habe gerade von einer knapp 2 GB grossen Datei den MD5-Hash
ausrechnen lassen, um zu sehen ob sie heil ist.
time md5sum rödelt etwa 1 Minute, und dann das überraschende Ergebnis:
ca. 12 s User und ca. 3 s System.
Gesamte Ausführungszeit etwas mehr als eine Minute.
Keine weiteren CPU-Fresser mit top erkennbar.

Was hat die Kiste die restlichen 45 Sekunden getrieben?

Rechner ist ein i5Gen6 mit 32 GB. Das Linux ist ein grml von 2018.

[Sheeva P. (sheevaplug)]

Cartman E. schrieb:
> ca. 12 s User und ca. 3 s System.

Vermutlich die Zeit zum Lesen der Datei (rotierender Rost?), das 
Bash-Builitin time zeigt ja nur die CPU.

Tipp: anstelle des Builtin das Programm /usr/bin/time(1) mit dem 
Schalter "-v" benutzen. Das zeigt viel mehr Informationen, darunter auch 
den Fs-I/O.

[Cartman E. (cartmaneric)]

Sheeva P. schrieb:
> Cartman E. schrieb:
>> ca. 12 s User und ca. 3 s System.
>
> Vermutlich die Zeit zum Lesen der Datei (rotierender Rost?), das
> Bash-Builitin time zeigt ja nur die CPU.

Ja, richtig. Ist man mittlerweile nicht mehr so gewohnt, und wundert
sich entsprechend.

> Tipp: anstelle des Builtin das Programm /usr/bin/time(1) mit dem
> Schalter "-v" benutzen. Das zeigt viel mehr Informationen, darunter auch
> den Fs-I/O.

Im Moment ist er noch mit einem fsck beschäftigt. ☺

[Axel S. (a-za-z0-9)]

Cartman E. schrieb:

> time md5sum rödelt etwa 1 Minute, und dann das überraschende Ergebnis:
> ca. 12 s User und ca. 3 s System.

Ja, und?

> Was hat die Kiste die restlichen 45 Sekunden getrieben?

Darauf gewartet, daß die Platte mit den Daten rüberkommt.
In anderen Worten: iowait

> Keine weiteren CPU-Fresser mit top erkennbar.

Hättest halt auch mal in der 2. Kopfzeile von top nachschauen sollen, 
was die CPU so treibt.

man top
...

   2b. TASK and CPU States
       This portion consists of a minimum of two lines.  In an SMP  envi‐
       ronment,  additional  lines  can reflect individual CPU state per‐
       centages.

       Line 1 shows total tasks or threads, depending on the state of the
       Threads-mode toggle.  That total is further classified as:
           running; sleeping; stopped; zombie

       Line 2 shows CPU state percentages based on the interval since the
       last refresh.  Where two labels are shown below,  those  for  more
       recent kernel versions are shown first.
           us, user    : time running un-niced user processes
           sy, system  : time running kernel processes
           ni, nice    : time running niced user processes
           wa, IO-wait : time waiting for I/O completion
           hi : time spent servicing hardware interrupts
           si : time spent servicing software interrupts
           st : time stolen from this vm by the hypervisor

[Norbert (der_norbert)]

45 Sekunden Lesezeit für 2GB? Das muss dann aber ein echt altes 
Schätzchen sein. 2½" im Notebook?

Wobei … eigentlich 60 Sekunden. Die Berechnung läuft ja parallel zum 
Lesevorgang.

[Jack V. (jackv)]

Cartman E. schrieb:
> Gesamte Ausführungszeit etwas mehr als eine Minute.

Die Zeit passt recht genau zu einem via USB2 angeschlossenen Datenträger 
– ist das hier der Fall gewesen?

[Rbx (rcx)]

Cartman E. schrieb:
> Was hat die Kiste die restlichen 45 Sekunden getrieben?

Wo bleiben deine genaueren Informationen? Grml kannst du auch ins Ram 
laden mit einem RamFS. Probier das ganze doch dann da nochmal.

[Cartman E. (cartmaneric)]

Jack V. schrieb:
> Cartman E. schrieb:
>> Gesamte Ausführungszeit etwas mehr als eine Minute.
>
> Die Zeit passt recht genau zu einem via USB2 angeschlossenen Datenträger
> – ist das hier der Fall gewesen?

Es war eine Toshiba 2 1/2" 2 TB per USB3 direkt am Root-Hub.
Die ganzen 2 TB werden in ca. 5 Stunden gelesen => ca. 110 MB/s.
Wenn ich mich nicht verrechnet habe. ☻ So fix ist USB2 dann doch nicht.

Ein time als besseres Binary hat das 2018er GRML leider nicht.
Den Wert für IO-Wait, hätten sie ja auch ins Builtin-time integrieren
können.

GRML aus dem RAM laufen zu lassen, bringt in dem Fall nüx.

Aber ich könnte das md5sum 2 x starten. Beim zweiten mal, würde
er dann ja die Daten aus dem Cache lesen.

Ich habe auch keine Pläne, die Disk(s) durch SSDs zu ersetzen.
Es sind derer nämlich zwei.

Danke für die Hinweise und die rege Beteiligung/Anteilnahme. ☺

Wenn ich die 2 md5sum-Läufe vollbracht habe, gibe es die neuen Zahlen.

[Norbert (der_norbert)]

Passt ungefähr. Bei ⌀ 110MB/s erreicht man grob 140 am Anfang der Platte 
und 70 am Ende. Je nachdem wo die 2GB Datei ihre letzte Ruhe gefunden 
hat.