Hey,
unter Unix gibt es ein Kommando oder auch ein Bash-Builtin "time" mit
dem man die beanspruchte Prozessorzeit und Realzeit messen kann.
Auf Wikipedia liest sich das so:
Die "Prozessorzeit" (englisch "CPU Time") bezeichnet die gemessene Zeit
in Stunden, Minuten und Sekunden, in der ein laufendes Programm seit dem
letzten Programmstart tatsächlich Kommandos an den Prozessor gesendet
hat. Diese Summe ist praktisch immer niedriger als die gesamte Laufzeit
des Programms, da dieses selbst bei intensiver Nutzung kaum pausenlos
Befehle an den Prozessor sendet.
Nun meine Frage, wie soll man dies nun ermitteln? Finde das ein bisschen
Missverständlich wie das beschrieben wird, da hier suggeriert wird ein
Programm würde Befehle "senden" und eigentlich arbeitet ja der Prozessor
die Befehle eines Programms ja ab. Und naja, die werden ja eig alle
nacheinander abgearbeitet und wenn man jetzt mal außer acht lässt das
die CPU das Programm unterbricht und andere Prozesse ausführt, dann weis
ich nicht in welchem Zeitpunkt kein Befehl an die CPU sendet. Selbst
wenn ich auf Ressourcen warte wie z.B. Netzwerkpakete dann wird das
Programm ja auch unterbrochen und zu einem anderen Kernel-Space Prozess
gesprungen und selbst da muss doch in irgend einer Art und weise Polling
betrieben werden.
mfg Seb
Moin Seb,
das klingt in der Tat merkwürdig:
Seb schrieb:> Die "Prozessorzeit" (englisch "CPU Time") bezeichnet die gemessene Zeit> in Stunden, Minuten und Sekunden, in der ein laufendes Programm seit dem> letzten Programmstart tatsächlich Kommandos an den Prozessor gesendet> hat.
Ein Programm ist nix aktives. Selbt ein "laufendes Programm" (Prozess)
wird vom Prozessor (od. entsprechenden Einheiten) ausgeführt. Der
Prozessor (od. die Ausführungseinheit) ist also der aktive Teil.
Der time Befehl akkumuliert imho die Zeit, die ein Prozess (i.e. seine
Threads) als "running" scheduled sind.
Grüße, Steffen
Seb schrieb:> Diese Summe ist praktisch immer niedriger als die gesamte Laufzeit> des Programms, da dieses selbst bei intensiver Nutzung kaum pausenlos> Befehle an den Prozessor sendet.
das dürfte aber nicht stimmen. Man kann auch ein 5min 12min CPU zeit
verbrauchen. Dann wenn man mehr als eine CPU nutzt. (Threads).
Peter II schrieb:> Seb schrieb:>> Diese Summe ist praktisch immer niedriger als die gesamte Laufzeit>> des Programms, da dieses selbst bei intensiver Nutzung kaum pausenlos>> Befehle an den Prozessor sendet.>> das dürfte aber nicht stimmen. Man kann auch ein 5min 12min CPU zeit> verbrauchen. Dann wenn man mehr als eine CPU nutzt. (Threads).
Naja, ein Beispiel ist z.B. wenn ich jetzt hier mal ein einfaches
apt-get update mache.
also:
1
time sudo apt-get update
Der Output ist dann:
1
real 0m26.212s
2
user 0m3.004s
3
sys 0m0.372s
Also 26s ist das Programm gelaufen, davon 3s im Userspace + 0.3 s im
Kernel Space.
Aber in welchem Moment der 26 s ist das Programm nicht aktiv gewesen?
Sprich eig nur wenn die CPU gerade andere Prozesse ausgeführt hat. Aber
ich geh mal davon aus das die große Zahl von 26 s hauptsächlich das
warten auf Netzwerkpakete betrifft, aber selbst wenn das Programm auf
Netzwerkpakete wartet, wird das Programm doch weiterhin ausgeführt, oder
nicht? Polling etc....?
Weil mir 3 s ein bisschen wenig erscheint und mit 3s + 0.3s kommt man
nie auf diese 26 s . Was ist also in den restlichen 22.6s passiert?
Seb schrieb:> Netzwerkpakete wartet, wird das Programm doch weiterhin ausgeführt, oder> nicht?
nein wird es nicht. Es macht wird erste wieder "geweckt" wenn daten für
das Programm da sind.
Polling macht man eigentlich nicht mehr.
Auch bei einem Sleep(100). Wird einfach im Betiebsystem ein wecker
gestellt und dieser weckt dann Pünktlich die Applikation. Dabei
verbraucht die App keine CPU zeit.
Seb schrieb:> Sprich eig nur wenn die CPU gerade andere Prozesse ausgeführt hat.
Nein, auch I/O oder sleep kann ein Programm unterbrechen.
Seb schrieb:> wenn das Programm auf Netzwerkpakete wartet
Wenn es wartet wird es "beiseite geschoben", bei aktivem polling würde
man natürlich auch alle Zeit verbraten, wenn man aber aktiv von sich aus
Zeit abgibt (z.B. indem man blockierend liest) sieht das schon anders
aus.
Peter II schrieb:> Seb schrieb:>> Netzwerkpakete wartet, wird das Programm doch weiterhin ausgeführt, oder>> nicht?>> nein wird es nicht. Es macht wird erste wieder "geweckt" wenn daten für> das Programm da sind.>> Polling macht man eigentlich nicht mehr.>> Auch bei einem Sleep(100). Wird einfach im Betiebsystem ein wecker> gestellt und dieser weckt dann Pünktlich die Applikation. Dabei> verbraucht die App keine CPU zeit.
Naja, aber wenn das Programm jetzt z.B. aus einem Socket versucht zu
lesen und noch keine Daten da sind, ist das doch eine blockierende
Aktion, sprich ich bin doch noch immer im Programm, bzw. in der
System-Routine. Das System könnte sonst dem Scheduler einfach sagen,
Programm inaktiv wartet auf Ressourcen und sobald das System feststellt
das Sie verfügbar sind, kann das System wieder zum Programm springen,
das würde mir einfallen?!
Ich hab mal Angefangen ein kleines Mini-Betriebssystem zu schreiben,
wenn man nun dort z.B. auf einen leeren Tastatur-Puffer wartet im
Keyboardcontroller wird einfach gepoolt, weils keine andere Möglichkeit
gibt. Dort führt die CPU dann imemer wieder Befehle aus, und wenns nur
überprüfen und zurückspringen ist. Wenn ich nicht mehr will das die CPU
was ausführt, müsste man einen halt - Befehl senden (hlt in Assembler),
aber dann krieg ich sie auch nicht mehr wach. Allso die Ausführung
konkret unterbrechen, da kenn ich keine möglichkeit, außer irgendwas
anderes zu machen.
In meinem kleinen Betriebssystem hab ich ein einfaches Round-Rubin ohne
Prioritäten.
Aber wenn ich dort von der Eingabezeile lese überprüft die Systemroutine
einfach immer und immer wieder ob Zeichen im Puffer stehen und kehrt
erst dann wieder aus der schleife zurück.
Ich meine selbst Event-Bibliotheken arbeiten so. oder die Win32 - Api.
Da gibts die Nachrichten schleife die immer und immer wieder auf
eingetroffene Events wartet. Im Grunde nichts andere als das was ich mit
dem Puffer mache.
Seb schrieb:> Naja, aber wenn das Programm jetzt z.B. aus einem Socket versucht zu> lesen und noch keine Daten da sind, ist das doch eine blockierende> Aktion, sprich ich bin doch noch immer im Programm, bzw. in der> System-Routine.
du bist immer im Programm, sonst währe ja das Programm beendet.
Wenn du in der Systemfunktion Read blockierst, dann brauchst du keine
CPU-Zeit mehr. Denn der Kernel gibt dir erst wieder CPU-Zeit wenn daten
ankommen. Dein Programm ist also in der Zeit nicht aktiv sondern liegt
nur im RAM rum.
Der Prozessor wartet nicht, bis er aus einer Schnittstelle ein Byte
rauspopeln kann. Die Schnittstelle teilt die Verfügbarkeit von Daten per
Interrupt mit und der Prozessor reagiert darauf. Wenn der Prozessor grad
garnichts zu tun hat, dann legt er sich schlafen und spart Strom.
Peter II schrieb:> Seb schrieb:>> Naja, aber wenn das Programm jetzt z.B. aus einem Socket versucht zu>> lesen und noch keine Daten da sind, ist das doch eine blockierende>> Aktion, sprich ich bin doch noch immer im Programm, bzw. in der>> System-Routine.>> du bist immer im Programm, sonst währe ja das Programm beendet.>> Wenn du in der Systemfunktion Read blockierst, dann brauchst du keine> CPU-Zeit mehr. Denn der Kernel gibt dir erst wieder CPU-Zeit wenn daten> ankommen. Dein Programm ist also in der Zeit nicht aktiv sondern liegt> nur im RAM rum.
Aber was verstehst du unter blockieren? Ich versteh unter einer
blockierenden Operation, das sie den Programmablauf stoppt durch eine
Schleife oder aus Systemsicht eine Routine die das Programm erst mal bei
Seite schiebt.
Ich meine ich versteh den Begriff CPU-Zeit irgendwie immer noch nicht so
richtig. Also ist das jetzt einfach die Zeit, wo das Programm vom
Prozessor auch aktiv gerade ausgeführt wird, sprich laufend scheduled
ist? Und die reale Zeit die, bis das Programm fertig durchgelaufen ist?
Peter II schrieb:> Seb schrieb:>> Diese Summe ist praktisch immer niedriger als die gesamte Laufzeit>> des Programms, da dieses selbst bei intensiver Nutzung kaum pausenlos>> Befehle an den Prozessor sendet.>> das dürfte aber nicht stimmen. Man kann auch ein 5min 12min CPU zeit> verbrauchen. Dann wenn man mehr als eine CPU nutzt. (Threads).
Das ist aber was anderes, weil während dieser Zeit "echt-parallel"
gearbeitet wird und von daher praktisch Nebeneinander ausgeführt wird.
Ich glaube es geht da weniger um die CPU-Auslastung, weil du da recht
mit hast, aber das währe dann CPU-Zeit im Rahmen von Multitasking.
Seb schrieb:> Peter II schrieb:>> Seb schrieb:>>> Diese Summe ist praktisch immer niedriger als die gesamte Laufzeit>>> des Programms, da dieses selbst bei intensiver Nutzung kaum pausenlos>>> Befehle an den Prozessor sendet.>>>> das dürfte aber nicht stimmen. Man kann auch ein 5min 12min CPU zeit>> verbrauchen. Dann wenn man mehr als eine CPU nutzt. (Threads).>> Das ist aber was anderes, weil während dieser Zeit "echt-parallel"> gearbeitet wird und von daher praktisch Nebeneinander ausgeführt wird.> Ich glaube es geht da weniger um die CPU-Auslastung, weil du da recht> mit hast, aber das währe dann CPU-Zeit im Rahmen von Multitasking.
EDIT: sorry, ich meine im Rahmen von Multithreading!!!
Konrad S. schrieb:> Der Prozessor wartet nicht, bis er aus einer Schnittstelle ein> Byte> rauspopeln kann. Die Schnittstelle teilt die Verfügbarkeit von Daten per> Interrupt mit und der Prozessor reagiert darauf. Wenn der Prozessor grad> garnichts zu tun hat, dann legt er sich schlafen und spart Strom.
Ja aber der Prozessor wird wohl kaum bei jedem einzelnen Byte das
laufende Programm unterbrechen, sondern eher Paketweise etc. je nachdem
wie die Schnittstelle das regelt...
Und das empfangen ist eine Sache aber nur weil das System weis das die
Daten da sind weis das das Programm noch lange nicht, bis das System die
Daten weiter gibt.
Seb schrieb:> aber nur weil das System weis das die> Daten da sind weis das das Programm noch lange nicht, bis das System die> Daten weiter gibt.
Wenn du eine Taste von der Tastatur einlesen willst, ist entweder schon
eine verfügbar oder der Scheduler merkt sich das und schaltet sofort auf
einen anderen Thread um.
Zu deinem Programm schaltet er erst wieder zurück, wenn eine Tastendruck
verfügbar ist. Deine Frage stellt sich also garnicht - dein Programm ist
sozusagen bewusstlos, solange keine Taste gedrückt wurde, wenn es ins
Leben zurückkehrt ist auch die Taste da. Den Programmzustand warten auf
eine Taste gibt es garnicht. Den kannst du zwar in dein Programm
reinschreiben, aber das Betriebssystem sorgt dafür, dass die
Warteschleife nie ausgeführt wird.
Gruss Reinhard
Seb schrieb:> Klar gibt es den
Verstehst du es nicht oder willst du es nicht verstehen? Ein Process im
Zustand wait läuft eben NICHT - keiner von deinen Befehlen wird
ausgeführt.
Aber ich klinke mich hier aus, sinnlos jemandem was zu erklären, der
überzeugt ist, dass er das besser weiss.
Gruss Reinhard
Reinhard Kern schrieb:> Seb schrieb:>> Klar gibt es den>> Verstehst du es nicht oder willst du es nicht verstehen? Ein Process im> Zustand wait läuft eben NICHT - keiner von deinen Befehlen wird> ausgeführt.>> Aber ich klinke mich hier aus, sinnlos jemandem was zu erklären, der> überzeugt ist, dass er das besser weiss.>> Gruss Reinhard
Habe ich je das Gegenteil behauptet? NEIN... meine fresse...
> Habe ich je das Gegenteil behauptet? NEIN... meine fresse...
Nur so wie du es formuliert hast, wirkte das so als würdest du behaupten
wollen, das das Betriebssystem den Prozess eben gerade nicht beiseite
schiebt, wenn es Ressourcen anfordert, die aber noch nicht vorhanden
sind!
