Timer verhalten bei hoher CPU Last / Funktionsweise

[changlee]

Hallo,

Ich habe mal ein paar Fragen zu TTimer:

1. Wenn das Intervall recht groß ist (z.B. 1 Tag) und die CPU läuft während der Wartezeit mehrere Stunden unter Volllast, ist dann davon auszugehen, dass das der Zeitpunkt des OnTimer Ereignis an Genauigkeit verliert, auch wenn zum Auslösezeitpunkt die CPU Last gering ist?

2. Wie funktioniert denn TTimer? Fragt er selbst in gewissen Abständen die Systemzeit ab? Oder zält er in irgendeiner Weise die Zeit mit, ohne af die Systemzeit zu schauen?

3. Wenn ich den Timer um 0:00 Uhr starte und will, dass er genau um 23:59 Uhr (nagut, +- 1 Sekunde) eine Funktion startet,
kann ich dann ruhigen Gewissens das Intervall auf die enstprechende Differenz dt in Millisekunden stellen, oder sollte ich das Intervall lieber z.B. 0.6*dt stellen und dann die Zeitdifferenz nochmal prüfen / Intervall neu setzen?

4. Ich habe hier im Forum gelesen, dass der Timer nicht immer zuverlässig ist, sondern bei hoher CPU Last Aussetzer haben kann.
Wenn die CPU Last konstant auf 100% ist und der Timer jetzt eigentlich auslösen sollte, verpasst er dann einfach nur den korrekten Zeitpunkt und startet onTimer sobald die CP Last es wieder zulässt? Oder wird das onTimer Ereignis "verchluckt" und der Timer wartet dann wieder ein volles Interval?

Weiß das jemand? Testen ist in diesem Fall ja sehr Zeit- und CPU aufwändig

[Luckie]

Der VCL Timer kapselt den Timer von Windows. Dieser verwendet die Nachricht WM_TIMER, um ein Fenster über ein Timer-Ereignis zu benachrichtigen. Diese Nachrichten haben im System eine sehr niedrige Priorität, das heißt, dass, wenn was anderes zu tun ist, diese erstmal nicht verschickt werden. Deswegen ist ein Timer auch recht ungenau. Eine Prüfung sollte des wegen immer mit "größer" erfolgen.

Wurde eine Timer Nachricht versendet, hängt es vom empfangenen Fenster ab ob und wann sie verarbeitet wird.

[Medium]

1. Der Timer verschiebt sich in diesem Fall nicht, nein. Die Ungenauigkeit ist immer gleich, egal wie hoch das Intervall ist. (Es kummuliert sich nur auf, wenn man ein kleines Intervall hat und darüber selbst einen Zähler führt der Echtzeitnah sein soll, weil diese Ungenauigkeit dann ja bei jedem Callback neu dazu kommt.)

2. Timer sind ein Service von Windows. Wie sie exakt intern funktionieren weiss ich nicht, aber ich vermute dass es kaum über plumpes "polling" der Systemzeit geht.

3. Du kannst ruhigen Gewissens das Intervall exakt einstellen, du musst nur zusehen dass dein Programm die Messageloop auch entsprechend abarbeitet; siehe 4

4. Das Ereignis wird gefeuert. Wen ich mich nicht irre haben Timer relativ hohe Priorität. Das Problem ist dann die Anwendung selbst, die die Message empfängt. Ist diese beschäftigt und arbeitet ihre Messageloop nicht ab, wird das Event verzögert. Es tritt aber ein.
Das sollte so lange wahr sein, wie nicht ein anderes Programm mit einer Priorität von TimeCritical nebenher die CPU vollknattert - das gehört sich allerdings auch nicht, und dürfte in freier Wildbahn kaum anzutreffen sein. Bzw. die Message könnte evtl. sogar raus gehen, nur wird dein Programm, wie sehr es auch versucht, nicht dazu kommen seine Msgloop zu verarbeiten.


Edit: Luckie, ich lese da auch gerade "low-priority message". Ist das nun nur im Rahmen der Messages zu verstehen, sprich andere Mesages haben Vorrang, aber Messages generell sind über Anwendungsprogrammen angesiedelt, oder ist das direkt in die Reiher der Prioritätsklassen wie für Threads im Allgemeinen zu verstehen? Ich war bislang immer der Auffassung, dass Messages immer hohe Prio haben, und lediglich der Empfänger der langsamere Teil ist der u.U. zu beschäftigt ist.

[Luckie]

Zitat von Medium:

4. Das Ereignis wird gefeuert. Wen ich mich nicht irre haben Timer relativ hohe Priorität.

Genau das Gegenteil ist der Fall.

Zitat:

Das Problem ist dann die Anwendung selbst, die die Message empfängt. Ist diese beschäftigt und arbeitet ihre Messageloop nicht ab, wird das Event verzögert. Es tritt aber ein. Das sollte so lange wahr sein, wie nicht ein anderes Programm mit einer Priorität von TimeCritical nebenher die CPU vollknattert - das gehört sich allerdings auch nicht, und dürfte in freier Wildbahn kaum anzutreffen sein. Bzw. die Message könnte evtl. sogar raus gehen, nur wird dein Programm, wie sehr es auch versucht, nicht dazu kommen seine Msgloop zu verarbeiten.

Das meinte ich mit "vom Empfänger abhängig".

[changlee]

Vielen Dank für eure Hilfe!

das heißt also zusammengefasst:

##################
1. Windows Seite:
Die onTimer-Nachricht wird von Windows immer verschickt - auch bei 100% CPU Last. Möglicherweise wird sie aber erst verschickt, wenn die CPU Last wieder geringer ist (--> Zeitverzögerung).


2. Anwendungs-Seite:
Egal wie hoch die CPU-Last ist, die onTimer Message wird verarbeitet. Die Frage ist nur wann.
Anwending Idle: onTimer tritt unverzüglich ein.
Anwendung beschäftigt: onTimer verzögert sich - tritt aber ein, wenn Anwendung wieder im "Leerlauf" oder ProcessMessages aufgerufen wird.

Unwahrscheinlicher Ausnahmefall: ein anderer Prozess läuft mit Priorität TimeCritical bei voller CPU Ausnutzung. (--> Vernachlässigbar)

##################

Zitat von Luckie:

Eine Prüfung sollte des wegen immer mit "größer" erfolgen.

Was meinst du damit?

Zitat von Luckie:

Wurde eine Timer Nachricht versendet, hängt es vom empfangenen Fenster ab ob und wann sie verarbeitet wird.

Also wäre es hier besser, größere Programmaufgaben in einem Thread laufen zu lassen, damit das Hauptprogramm Zeit zum Empfangen der Timer-Nachricht hat.

Ist die länge der Liste mit den abzuarbeitenden Messages der Anwendung eigentlich begrenzt? So dass sich nach einer gewissen Zeit ohne ProcessMessages (in einer Schleife) Messages verloren gehen können?

[hoika]

Hallo,

die Frage stellt sich hier doch erst mal so.
Was willst du mit einem Timer, der einmal am Tag feuert ?

Ich würde das in "geplante Vorgänge" packen,
dort wird dein Programm mit einem Parameter /auto ?) aufgerufen,
den fragst du ab ubd machst das, was du machen willst.
Danach beendest du dein Programm wieder.


Heiko

[Luckie]

Du sollst nicht auf Gleichheit bei der Uhrzeit prüfen, sondern, ob sie schon vorbei ist. Danach natürlich den Timer deaktivieren.

Zitat:

Also wäre es hier besser, größere Programmaufgaben in einem Thread laufen zu lassen, damit das Hauptprogramm Zeit zum Empfangen der Timer-Nachricht hat.

[paul panzer mode on]Richtig![paul panzer mode off]

Zitat:

Ist die länge der Liste mit den abzuarbeitenden Messages der Anwendung eigentlich begrenzt?

Bestimmt. Aber wenn es für dich interessant wird, machst du eh was falsch.

[changlee]

Zitat von Luckie:

Du sollst nicht auf Gleichheit bei der Uhrzeit prüfen, sondern, ob sie schon vorbei ist. Danach natürlich den Timer deaktivieren.

Achso. Ja, Gleichheit prüfe ich sowieso nicht. Das wär mir zu riskant.

Ich werde mich also darum kümmern, dass alle großen Afgaben in Threads laufen.

Zitat von hoika:

Was willst du mit einem Timer, der einmal am Tag feuert ?

Ich erstelle gerade eine CronJob Klasse. Die sollte alle beliebigen Zeitintervalle abarbeiten können.
z.B. Emails checken alle 5 Minuten, aber Backup nur einmal die Woche. Andere Backups zweimal täglich. Da will ich ja nicht für jede erdenkliche Zeitafgabe ein extra Programm haben.


Viele Grüße,

Stefan.

[hathor]

Vielleicht wäre das ein Fall für den TaskScheduler.
Wenn etwas nur 1x/Tag eintritt, muss nicht die ganze Zeit der PC laufen, wenn es sonst nichts zu tun gibt.
Aus Standby/Hibernation kann der TaskScheduler auch aktiv werden.

http://delphi.icm.edu.pl/ftp/d50free/TaskSched.zip

[hathor]

Zitat von changlee:

...z.B. Emails checken alle 5 Minuten...Viele Grüße,

Stefan.

Bei Freemailern geht das nur alle 15 Min.