Merkwürdigkeit mit Sleep()

[Medium]

Zitat von Shark99:

Wie kann ich wirklich exakt 1 Sekunde warten?

Unter den gängigen Windows Varianten: Garnicht. Diese zeitliche Präzision bieten praktisch nur darauf ausgelegte sog. Echtzeit (Betriebs-)Systeme, und das Thema hatten wir schon gefühlte 100 Mal in der DP .
Ganz im Groben erreicht man auf normalen OSs Genauigkeiten so um +/- 0-30ms, je nach Methode. Wofür musst du derart exakt eine Sekunde haben?

[Shark99]

Ich will ein mal Pro Sekunde den CPU Verbrauch anzeigen. Da Windows kein Echtzeit Betriebssystem ist, habe ich mit einer Abweichung gerechnet, allerdings mit 10ms, nicht 160.

[Shark99]

DelayQPC scheint auf dem ersten Blick eine Alternative zu sein, aber ich glaube es würde mehr CPU Zeit kosten als es ein Sleep tut.

Dazu gibt es noch diese Warnung bei MSDN:

QueryPerformanceCounter remarks

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL).

[Medium]

Warum muss das SO exakt sein? Schwankungen von 200ms dürften kaum auffallen, und für gewöhnlich ist CPU-load nicht gerade das, wo man so penibel ist als User. Man schaut max. 3-4 Sekunden hin, bekommt einen gewissen Eindruck, und das langt meist schon. Ob das jetzt perfekt regelmäßig tickt, wäre mir zumindest relativ worscht
Und wie du schon bemerkt hast, legen Methoden die den Mess-Thread nicht schlafen legen, merkbar auf eben den gemessenen Wert drauf. Der Vorteil von Sleep ist, dass man die Verantwortung für's "wecken" an den Scheduler abgibt, und der ist zwar nicht so arg genau, dafür aber sehr ressourcenschonend. Ganz ehrlich: Wenn es bloß für die Anzeige von CPU Load ist, scher dich nicht weiter um die paar ms. So wichtig ist diese Info nicht, als dass man dafür viel Zeit, und schon garnicht merkbar CPU-Time verwenden sollte.

[Shark99]

Ist eigentlich TTimer genauso ungenau, oder sind die Ungenauigkeiten unterschiedlich?

[Medium]

Der Timer basiert auch auf dem Scheduler, und ist in etwa genau so (un-)genau.

[Luckie]

Zitat von Shark99:

Ich will ein mal Pro Sekunde den CPU Verbrauch anzeigen. Da Windows kein Echtzeit Betriebssystem ist, habe ich mit einer Abweichung gerechnet, allerdings mit 10ms, nicht 160.

Weißt du wie lange 160 Millisekunen sind? Ein menschlicher Wimpernschlag dauert ca. 100 Millisekunden (laut Wikipedia). Und jetzt überleg noch mal, ob du die CPU-Auslastung wirklich so genau anzeigen können musst.

Eine Zeitscheibe unter Windows NT hat eine länge von 22 Millisekunden. das heißt ein Thread bekommt für 22 Sekunden Rechenzeit zugeteilt. Dann wird zum nächsten Thread, abhängig von der Priorität gewechselt. Gibts du bei Sleep einen Wert unter 22 Millisekunden an, gibt der Thread den Rest seiner Zeitscheibe sofort ab und kehrt in den zuteilungsfähigen Zustand zurück und kann, wenn er wieder dran ist Rechnzeit zugeteilt bekommen.

[jfheins]

Zitat von Luckie:

Zitat von Shark99:

Ich will ein mal Pro Sekunde den CPU Verbrauch anzeigen. Da Windows kein Echtzeit Betriebssystem ist, habe ich mit einer Abweichung gerechnet, allerdings mit 10ms, nicht 160.

Weißt du wie lange 160 Millisekunen sind? Ein menschlicher Wimpernschlag dauert ca. 100 Millisekunden (laut Wikipedia). Und jetzt überleg noch mal, ob du die CPU-Auslastung wirklich so genau anzeigen können musst.
Eine Zeitscheibe unter Windows NT hat eine länge von 22 Millisekunden.

Wie sinnvoll das ist, ist irrelevant. Wenn das System mit einer Genauigkeit von 20ms arbeitet, dann möchte man diese Genauigkeit auch gerne bekommen. Das ist ja nichts anderes als wenn eine Waage mit "Fehler: +- 20g" beworben wird,du tust ein 1kg Stück drauf und bekommst 1,16kg angezeigt. Da würdest du dich auch wundern
Aber wie gesagt, die Abweichung liegt nicht an Windows sondern am Fehler in der Rechnung - OSI Layer 8 Problem

[Luckie]

Nein, die Zeitscheibe ist nur 22 Millisekunden lang. Wann dein Thread wieder Rechenzeit bekommt, hängt vom Scheduler ab, wie viele andere Threads laufen und mit welcher Priorität. Hast du im System einen Thread mit der höchsten Priorität (Zeitkritisch), kannst du dich mit deinem Programm dumm und dämlich warten.

[himitsu]

was man machen kann, das ist, solange die Operation kürzer ist, als die "Zeitscheibe", bzw. zusammenhängende Rechenzeit, welche einem Windows im Moment gewährt:

Delphi-Quellcode:

Sleep(0);
MachWas;

Wenn MachWas nun also weniger Zeit benötigt, als die oftmals vorliegenden 22 ms, dann wird es mit sehr hoher Wahrscheinlichkeit zusammenhängend ausgeführt.

Sleep 0 gibt die Rechenzeit an Andere Programme ab und fast sofort, wenn das eigene Programm wieder dran, beginnt die Abarbeitung von MachWas, welches somit fast die volle Zeit zur Verfügung hat.

Ohne das Sleep könnte es ja sein, daß das Programm schon fast seine komplette Zeiteinheit aufgebracht hat, MachWas kurz vorm Ende gestartet wird und somit mitten in MachWas Windows die Kontrolle an einen anderen Thread/Programm abgibt.