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
Reinhard Kern schrieb: > 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 Klar gibt es den, hier: http://de.wikipedia.org/wiki/Prozess_(Informatik)#Prozessmodell
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.