Merkwürdiges (Zeit-)Verhalten

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.

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. ☺

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.

1

man top

2

...

3

4

   2b. TASK and CPU States

5

       This portion consists of a minimum of two lines.  In an SMP  envi‐

6

       ronment,  additional  lines  can reflect individual CPU state per‐

7

       centages.

8

9

       Line 1 shows total tasks or threads, depending on the state of the

10

       Threads-mode toggle.  That total is further classified as:

11

           running; sleeping; stopped; zombie

12

13

       Line 2 shows CPU state percentages based on the interval since the

14

       last refresh.  Where two labels are shown below,  those  for  more

15

       recent kernel versions are shown first.

16

           us, user    : time running un-niced user processes

17

           sy, system  : time running kernel processes

18

           ni, nice    : time running niced user processes

19

           wa, IO-wait : time waiting for I/O completion

20

           hi : time spent servicing hardware interrupts

21

           si : time spent servicing software interrupts

22

           st : time stolen from this vm by the hypervisor

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.

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?

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.

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.

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.

Cartman E. schrieb:

Ein time als besseres Binary hat das 2018er GRML leider nicht.

Wenn nicht ein zwingender Grund für die antike Version spricht, gibt es auf grml.org eine aktuelle Version mit zeitgemäßen Programmversionen. Besagtes eigenständiges ›time‹ ist da zwar nicht per default vorhanden, lässt sich dann aber recht einfach nachinstallieren.