TTimer zu ungenau - wie funktioniert der EpikTimer?

[mschnell]

aber bei Windows gibt es dem QueryPerformanceCounter() damit kann man exakt die ms vom Betriebssystem auslesen.

Versteht ihr das denn wirklich nicht ? Der Timer selbst ist nicht das Problem. Das Problem ist, dass man nicht weiß, wann das Programm den Timer ausliest, weil es an jeder Stelle im Code vom Betriebssystem unterbrochen und beliebig lange aufgehalten werden kann. So kann man keine Zeiten mit irgendwie definierbarer Genauigkeit messen.

-Michael

[MmVisual]

Mit einem Timer kann man nichts genau messen. Wenn mal die eigene App "Hängt" wegen z.B. Netzwerkzugriff, dann kommt eben der Timer später.

Aber eine QueryPerformanceCounter() kann die exakte ms des aktuellen CPU Taktes gelesen werden. Damit könnte man sogar eine Zeitmessung realisieren um z.B. fest zu stellen wie lange eine Query Datenbankabfrage dauert.
Mehr dazu auch in der MSDN M$ Hilfe.
http://support.microsoft.com/kb/172338/de" onclick="window.open(this.href);return false;

Wenn man eine echte Echtzeitmessung benötigt, dann gibt es dazu genau zwei möglichkeiten:
- Externe CPU verwenden
- Real-Time Kernel für Windows schreiben, der als zweiten Kernel neben dem Betriebssystem installiert wird. Dann hat man allerdings KEINE Windows API Funktionen mehr sondern muss die Kernel DLL's verwenden.

Beispiel: Beckhoff hat für die Soft-SPS die man auf einem PC installieren kann solch einen zweiten Kernel geschrieben. Man kann so mittels CodeSys Programmierung ein Programm schreiben, das läuft dann exakt alle 10ms, unabhängig davon was Windows sonst noch treibt (Außer Blue-Screen).

Mit Lazarus wird wohl beides nicht möglich sein.

[creed steiger]

QNX wäre eine Möglichkeit aber da siehts mit FPC düster aus.
Wobei mich Window CE in dieser Liste
http://en.wikipedia.org/wiki/Real-time_operating_system" onclick="window.open(this.href);return false;
etwas erstaunt.

Letztendlich glaube ich das selbst eine embedded Lösung ein bissl über deinen Möglichkeiten liegt.
Aber tröste dich,alle andern da draußen kochen auch bloß mit Wasser

[Euklid]

Unter Windows ist Zeitmessung im Millisekundenbereich über gettickcount möglich. Allerdings bleibt die Frage, ob es nicht bei der Bearbeitung von Ereignissen wie Tastaturanschlägen durch das Betriebssystem zu grssen Ungenauigkeiten kommt.




Um Epiktimer nachzuvollziehen lohnt ein Blick in die Demo, die dem Code des Projektes beiliegt.

[af0815]

@eva: Was ist eigentlich dein Begriff von Genauigkeit ? Was ist für dein Projekt signifikant ?

Bei den ganzen Beiträgen wird nicht wirklich von Fakten gesprochen. Klar wirst du bei jedem System einen Meßfehler erhalten. Als Faustregel muß das Meßsystem um den Faktor 10 genauer sein.

[Heinrich Wolf]

@eva: Was ist eigentlich dein Begriff von Genauigkeit ? Was ist für dein Projekt signifikant ?

@af0815: Eva hat ihre Anforderungen am Anfang des Threads ganz genau formuliert, hier gekürzt, bitte selber nachlesen: Bitmaps mit Vielfachen von 100 ms Dauer Genauigkeit anzeigen, Tastatureingaben mit 20 ms Genauigkeit lesen.

[mschnell]

Test:

- Programm schreiben, das die Zeitdifferenz zwischen je zwei Tastenderücken misst und in eine Stringlist schreibt. Bei Programm-Ende schreibt es die Stringlist in eine Date.

- Programm starten

- ein Gewicht auf eine Taste legen

- Netzwerkkabel ziehen

- versuchen zu Browsen und eine Datei vom Netzwerk zu lesen

- Programm stoppen.

- Datei angucken.



- Michael

[ruewa]

Entschuldigt, wenn ich diesen alten Thread noch einmal aufwärme. Der Grund ist ganz einfach der, daß jeder, der nach Informationen über den EpikTimer googelt, zwangsläufig auf dieser Seite landet und das hier Besprochene als autoritative Beurteilung des Sachverhalts mitnehmen muß und so schlicht auf die falsche Fährte gesetzt wird.

Ich will im Folgenden zum einen beschreiben, was die verschiedenen Komponenten TTimer, TFPTimer und EpikTimer eigentlich darstellen und worin ihre Aufgaben und Unterschiede bestehen. Dann werde ich das Meßproblem diskutieren, auch hier lief die Diskussion in in eine völlig abstruse Richtung. Zunächst aber lassen sich ein paar Anmerkungen zum hier gepflegten Stil nicht vermeiden.

1) Stilfragen

Das kannst Du nicht beurteilen.
...
Völliger Unsinn !!!!

Wer sich mit Programmiersprachen herumschlägt, steht, egal ob Anfänger, Fortgeschrittener oder Profi, stets vor demselben Problem: Daß die Komplexität des Gegenstands die eigenen Fähigkeiten im Grunde übersteigt. Jedenfalls solange man sich mit mehr als Albernheiten beschäftigt. Ausnahmslos jeder hat Verständnisprobleme, auf unterschiedlichstem Niveau, gewiß, aber egal auf welchem Niveau: Jeder verfügt nur über ein begrenztes Wissen. Wenn das aber so ist, dann braucht sich hier doch keiner als Platzhirsch des Halbwissens aufzuspielen! Die Diskussion in diesem Thread ist von außen betrachtet wirklich frappierend: Keiner hier hat sich den EpikTimer genauer angesehen, keiner hat das Thema "Meßgenauigkeit" technisch angemessen diskutiert, aber jeder wußte - irgendwie - "Bescheid". Am Ende hat Bora4D alle seine Postings (die offenbar nicht dem Mainstream der Platzhirsche entsprach) gelöscht und sich zurückgezogen, und auch Eva ward nie wieder gesehen - was man ihr nicht verdenken kann. Merkt Ihr sowas eigentlich noch?
Nun zum eigentlichen Thema.

2) TTimer - TFPTimer - EpikTimer

Timer ist nicht gleich Timer. Ein Timer kann nämlich zwei ganz unterschiedliche Aufgaben wahnehmen: Er kann eine Art Wecker bzw. Eieruhr darstellen, der sich nach einer festgelegten Zeit meldet und irgendwelche Aktionen ermöglicht. Eine Variante dessen ist das Metronom: Der Timer kann sich in regelmäßigen Abständen immer wieder melden. Eine vollkommen andere Aufgabe stellt hingegen die Stoppuhr dar: Sie mißt auf Abruf die Zeit zu einem bestimmten Zeitpunkt, legt den Wert als Variable ab, nimmt dann, wiederum auf Anforderung, eine zweite Zeitmessung vor und ermittelt die verstrichene Zeit zwischen diesen beiden Zeitpunkten. Mit einem Wecker kann man ohne weiteres keine Zeitabschnitte messen, eine Stoppuhr sagt einem nicht ohne weiteres, wann man los muß, um den Bus nicht zu verpassen.

So: Der TTimer und der TFPTimer sind Eieruhren und Metronome, sie verwalten Intervalle, aber sie messen keine beliebigen Intervalle. Sie sind zur Zeitmessung nicht geeignet, bzw. nur auf Umwegen. Der EpikTimer hingegen ist eine Stoppuhr, mit ihm lassen sich keine Weckfunktionen wahrnehmen (bzw. ebenfalls nur auf Umwegen z.B. über eine selbst programmierte wiederkehrenden Abfrage). Der Unterschied zwischen dem TTimer und dem TFPTimer besteht zum einen darin, daß der TTimer eine LCL-Komponente ist, der TFPTimer nicht, und zum anderen der TTimer den jeweiligen Widgetset-Timer implementiert, während der TFPTimer ein eigenständiges Widgetset-unabhängiges Freepascal-Modul ist. Beide lassen ihre Taktgebung in eigenen Threads laufen, keiner von beiden unterstützt die Zeitabnahme zu einem beliebigen Zeitpunkt und die Berechnung von Zeitdifferenzen.

Der EpikTimer hingegen ist eine reine Stoppuhr ohne jedwede Event-Triggerfunktion. Das Grundprinzip ist denkbar einfach: Nehme die Zeit, speichere sie als Variable, nehme ein zweites Mal die Zeit und berchne die Differenz. Okay, er kann schon noch mehr, wie eine richtige Stoppuhr eben auch: Die Zeit weiterlaufen lassen, die Messung pausieren und wiederaufnehmen etc. Richtig ausgefuchst ist der EpikTimer dort, wo er selbständig ermittelt, welches die präziseste Methode der Zeitabnahme unter den gegebenen Umständen von Betriebssystem und Hardware darstellt. Zudem bietet er Schnittstellen, um weitere Zeitquellen flexibel einzubinden. Und er nimmt eine Kalibrierung der Systemzeit vor, um große Zeiträume sauber zu messen (das habe ich noch nicht wirklich verstanden). Im Gebrauch aber ist er denkbar einfach und komfortabel.

Eva hätte also für ihre Bildschirmdarstellung einen TTimer gebraucht (warum der "zu ungenau" sein sollte, hat sich mir nicht erschlossen, da ist sie wohl einem Denkfehler aufgesessen), und für die Messung des Tastendrucks einen EpikTimer. Was auch kein Problem gewesen wäre, die Komponenten beißen sich nicht.

3) Meßgenauigkeit

Das Betriebssystem kann aus internen Gründen jedes Programm jeder Zeit beliebig lange aufhalten.

Das ist nur insofern eine Halbwahrheit, als jedes Betriebssystem per definitionem die Macht dazu hat. Aber die Realität ist schlichtweg eine andere, denn es zählt zu den vornehmsten Aufgaben eines jeden multitaskingfähigen Betriebssystems, eben genau das nicht zu tun! Um das angemessen zu diskutieren, hätte irgendjemand wenigstens einmal das Stichwort "Latenzzeiten" aufs Tapet werfen müssen. Latenzzeiten sind aber statistische Größen, also hätte man über Wahrscheinlichkeiten diskutieren müssen.

Vom Prinzip her haben einige das Grundproblem schon ganz richtig dargestellt: Eva startet ihr Programm, der Timer triggert, ihr Programm reagiert darauf mit einer Anzeige, der Timer triggert erneut, ihr Programm löscht die Bildschirmdarstellung, startet die Stoppuhr, die Tastatur meldet sich, ihr Programm stoppt die Stoppuhr und speichert das Ergebnis. Das Problem daran ist nun in der Tat nicht, daß die Zeiten nicht zuverlässig und hinreichend genau ausgelesen werden könnten oder gar die Systemuhr gestolpert wäre. Das Problem ist vielmehr, daß das Triggern der Timer-Events, das Durchdringen der Benachrichtigung, das Drücken der Stoppuhr immer erst dann geschehen kann, wenn ihrem Programm gerade mal wieder vom Betriebssystem Prozessorzeit zugewiesen wurde. Es vergeht also zwangsläufig bei jedem dieser Ereignisse eine gewisse Zeit, bis andere, gerade laufende Hintergrundprozesse unterbrochen und aufgeräumt werden und die Rechenkapazität wieder ihrem Programm zugeordnet wird (u.U. fügt es sich dann auch so, daß ihr Programm ohnehin gerade dem Prozessor zugeteilt ist, dann sind die Zeitverluste veschwindend gering).

Aber wie groß sind diese Verluste? Sind sie in einer solchen Größenordnung, daß Evas Experiment dadurch beeinträchtigt oder gar verunmöglicht worden wäre? Der Einzelfall ist in der Tat nicht vorhersagbar, die statistische Verteilung der vielen Einzelfälle aber schon. Wie gesagt, man spricht hier von der "Latenzzeit". Die modernen Betriebssysteme haben ausgefeilte Stategien entwickelt, diese Latenzeiten niedrig zu halten - starre Zeitscheiben, die bürokratisch unbeeindruckt Stück für Stück durchgereicht werden, gibt es schon lange nicht mehr. So erhalten Programme, die offenkundig auf eine Benutzereingabe warten, eine höhere Priorität als Rechenknechtprozesse im Hintergrund. Und wenn ein Thread seine Zeitzuteilung nicht wirklich benötigt, wird sie ihm auch schnell wieder entzogen. Da sind äußerst ausgefuchste Algorithmen am Werk. Wer mehr darüber erfahren möchte, wird im Internet unter dem Stichwort "Scheduler" reichlich fündig.

Ich wollte das jetzt einfach mal genau wissen, und deshalb ich habe ein kleines Testprogramm geschrieben. Es startet einen TTimer mit einer zufälligen Intervallzeit zwischen 0,25 und 1,25 Sekunden (um auf jeden Fall sicherzugehen, daß zwischen Start und Stop ein Threadwechsel stattfindet). Zugleich startet eine EpikTimer-Stoppuhr. Wenn der Timer triggert, wird ein kleines TShape auf enabled:= false gesetzt, was wiederum ein OnPaint-Event anstößt. Dort dann wird der EpikTimer gestoppt, die Intervallzeit des TTimers vom Ergebnis des EpikTimers abgezogen und so die Latenzzeit (beim Durchlauf zweier Ereignisse, was auch Evas Design entspricht) gemessen. Danach geht alles wieder von vorne los. Dies habe ich einmal unter CPU-Vollast durchgeführt (mit einer ffmpeg-Umcodierung und einem Download im Hintergrund), und dann unter normalen Bedingungen. Eine bestmögliche Idle-Situation wollte ich auch noch, aber das erwies sich dann als unnötig. Die Ergebnisse sind wie folgt:

Das Ergebnis ist in beiden Fällen eindeutig: In über 98 % der Fälle beträgt die Latenzzeit unter normalen Bedingungen weniger als 3 Millisekunden. Selbst unter Schwerlastbedingungen verschiebt sich das Ergebnis nicht wirklich gravierend. Erstaunlicherweise gibt es sogar einen leichen Bias zulasten der Hintergrundprozesse, der dem Testprogramm noch einen höheren Anteil sehr kurzer Reaktionszeiten verschafft hat. (Diese Werte entsprechen in etwa auch dem, was man darüber nachlesen kann).

Okay: Angemerkt werden muß unbedingt, daß das nur für Linux mit einem aktuellen Kernel gilt (auf einem Dual-Core AMD64). Wie sich das unter Windows darstellt, kann ich weder testen noch beurteilen - Linux steht allerdings im Ruf, in Hinblick auf Latenzzeiten deutlich besser zu zu sein als Windows. Man hätte Eva sicherlich mal fragen können, ob sie Zugriff auf einen Linux-Rechner hat, und ihr empfehlen können, das Experiment besser dort laufen zu lassen.

Jedenfalls bleibt von den hier vor zwei Jahren im Übermaß gepflegten Kassandrarufen nicht viel übrig!

4) Fazit

a) Eva hätte ihre Aufgabe völlig problemlos mit den von ihr gewählten Werkzeugen bewältigen können. Ich hoffe, sie hat es getan, anstatt sich von den Experten ins Bockshorn jagen zu lassen.

b) Die Latenzzeiten eines modernen Linux-Systems bewegen sich gut berechenbar in der Größenordnung von 1-3 ms, selbst unter Vollastbedingungen bleibt das System hervorragend reaktionsfähig.

c) Aller Glaubensstreit um die allerallergenaueste Zeitmessung (GetTickCount, GettickCount64, Now, GetTimeOfDate etc.) ist ein Streit um des Kaisers Bart. Auf einem Linux-System beträgt die Meßgenauigkeit einige wenige Millisekunden, nicht weniger, aber auch nicht mehr. Und das liegt nicht an irgendwelchen Systemuhren oder supermodernen vs. veralteten Taktgebern, sondern ganz einfach an der Arbeitsweise des Systems.

d) Der Epiktimer ist das Werkzeug der Wahl, wenn man sich das Selbstprogrammieren einer Stoppuhr sparen will. TTimer und TFPTimer hingegen sind die Mittel der Wahl, wenn man eine Eieruhr bzw. ein Metronom braucht.

Gruß Rüdiger

[mse]

Mit dem MSEgui ttimer welcher setitimer() und SIGALRM verwendet kommt man auf Linux typisch weit unter 1ms Genauigkeit. Das MSEgui timer System korrigiert allfällige Fehler im nächsten Tick und versucht die Frequenz möglichst genau einzuhalten.
Ein Testlauf mit 80ms Periodenzeit und wenig Last:

Code: Alles auswählen

 
n   tp (s)  average (s)
1 0.080231 0.080231
2 0.080931 0.080581
3 0.079143 0.080102
4 0.080124 0.080107
5 0.079891 0.080064
[...]
903 0.079974 0.080000
904 0.079997 0.080000
905 0.080227 0.080001
906 0.079861 0.080000
907 0.079942 0.080000
908 0.079999 0.080000
909 0.079996 0.080000
910 0.080033 0.080000
911 0.080019 0.080000
 

Auf Windows wird für hohe Präzision der mmtimer mit auf 1ms verkleinerte Granularität verwendet (normal ist 15ms):

Code: Alles auswählen

 
n   tp (s)  average (s)
1 0.081000 0.081000
2 0.079000 0.080000
3 0.080000 0.080000
4 0.080000 0.080000
5 0.080000 0.080000
6 0.080000 0.080000
7 0.080000 0.080000
8 0.080000 0.080000
9 0.080000 0.080000
10 0.081000 0.080100
11 0.079000 0.080000
12 0.080000 0.080000
13 0.080000 0.080000
 

Was aber nichts daran ändert, dass diese Methode der Zeitengenerierung für Messzwecke ungeeigent ist, da Ausreisser beliebiger Grösse vorkommen können welche dann dem Experiment zugeordnet werden.

[ruewa]

Mit dem MSEgui ttimer welcher setitimer() und SIGALRM verwendet kommt man auf Linux typisch weit unter 1ms Genauigkeit.

Das kommt schon hin. Vergiß nicht, ich habe - in Anlehnung an Evas Design - 2 Eventbearbeitungen in der Reihe, bevor ich nachmesse. Die Genauigkeit wird nicht durch die Timer-Werkzeuge determiniert, sondern durch das Betriebssystem. Das aber verhält sich bei solchen Aufgabenstellungen zwangsläufig fehlerbehaftet, andererseits aber auch hinreichend genau und vorhersagbar, das ist der Punkt. Dieser Fetisch der "supergenauesten Zeitmessung" dank diesem oder jenem Werkzeug bzw. Funktionsaufruf ist eine Fata Morgana!

Was aber nichts daran ändert, dass diese Methode der Zeitengenerierung für Messzwecke ungeeigent ist, da Ausreisser beliebiger Grösse vorkommen können welche dann dem Experiment zugeordnet werden.

Warum sollte das ein Problem sein? Zu jedem Experiment gehört eine Fehlerabschätzung. Ein Promille Ausreißer? Das ist das Leben! Es gibt kein "fehlerfreies" Experiment! Damit umzugehen gehört zum kleinen 1x1 der Statistik, von der Eva als Psychologiestudentin erheblich mehr verstehen müßte als die meisten Computerfreaks...

[mse]

Die Genauigkeit wird nicht durch die Timer-Werkzeuge determiniert, sondern durch das Betriebssystem.

Wobei die Betriebssysteme verschiedene Timer Dienste anbieten und je nach dem wie die Timer-Werkzeuge diese Dienste nutzen eine bessere oder schlechtere Genauigkeit erreicht wird.

Ein Promille Ausreißer? Das ist das Leben!

Da möchte ich dir als Hardware-Ingenieur entschieden widersprechen. Denke nur an deinen nächsten Flug in die Ferien oder deine nächste Autofahrt.

[ruewa]

Denke nur an deinen nächsten Flug in die Ferien oder deine nächste Autofahrt.

Ist das nicht Äpfel mit Leuchtreklame verglichen? Evas Ansatz war, eine Reaktionsgröße in Abhängigkeit variierter Bedingungen statistisch hinreichend trennscharf zu erfassen. Und ihre Sorge war, daß der Rauschabstand des Meßsignals zu gering sein könnte. Und da kann man klar sagen, das hätte schon funktioniert.

Jetzt laßt doch mal die Kirche im Dorf, herrgottnochmal! Diese technikverliebte Nanosekundenfeilscherei auf der einen Seite paßt doch überhaupt nicht zu den aufgeregten "Es brennt, es brennt!"-Rufen des "jederzeit beliebig lange aufhalten könnens"! Eine vernünftige Abschätzung sagt: Mit dem Computer lassen sich Zeiten auf 1 - 3 Millisekunden genau messen bei 99 % Zuverlässigkeit. Für die eine Aufgabe ist das hinreichend, für die andere nicht. So what?

[mschnell]

Der EpikTimer hingegen ist eine Stoppuhr

Schön wärs.

Ich habe vor Kurzem versucht EpikTimer (in Linux) zu verbessern, ist mir aber nicht zu meiner Zufriedenheit gelungen. Je nach FPC-RTL greift er auf unterschiedliche Betriebssystem-APIs zu. unter anderem eben auch "Eieruhr".

Der Einzelfall ist in der Tat nicht vorhersagbar, die statistische Verteilung der vielen Einzelfälle aber schon.

Stimmt. Und genau das bedeutet, dass man auf diese Weise keine Messung programmieren kann, sonern nur eine Schätzung. Wenn ich mich recht erinnere, sprach der OP von Zeitmessung.

Die Latenzzeiten eines modernen Linux-Systems bewegen sich gut berechenbar in der Größenordnung von 1-3 ms

Kein "normales" Linux System gibt eine Ofür die Latenz um User-Space an. Es ist also definitiv nicht "berechenbar", also nicht deterministisch bzw "Hard-Realtime" fähig. Für solche Anwendungen gibt es andere OSes und für Linux gibt es Realtime-Erweiterungen, die u.U. helfen können.

... Linix ... Der Epiktimer ist das Werkzeug der Wahl

Als ich das vor kurzem versucht habe, ließ sich EpikTimer für Linux gar nicht übersetzen.

-Michael

[mschnell]

Warum sollte das ein Problem sein? Zu jedem Experiment gehört eine Fehlerabschätzung. Ein Promille Ausreißer? Das ist das Leben!

"Ein Promille Ausreißer" ist keine Fehler-Abschätzung (was "Abschätzung der Größe des Fehlers" bedeutet), sondern eine Angabe zur Wahrscheinlichkeit eines Fehler.

Das ist statistisch etwas völlig anderes.

Und ein Wert, der - zwar selten aber manchmal - beliebig falsch sein kann ist eben keine Messung, sondern Selbstbetrug.

-Michael

[mschnell]

technikverliebte Nanosekundenfeilscherei

Du widerspricht Dir selber. Es geht nicht um Nanosekunden, sondern um Zeit-Angaben die ab und zu beliebig falsch sind (also mindestens Größenordnungen von zig Millisekunden ab und zu auch Sekunden).

Wenn ich keine Messung machen will, sondern ein Ergebnis mit entsprechend eingeschränkter Relevanz, kann man darüber gerne Diskutieren, wenn sich alle Beteiligten darüber klar sind.

Terminus Technikus dafür ist "Soft Realtime", was bei Multimedia-Anwendungen absolut geeignet ist. Wenn jemand aber Messung und "Experiment" sagt, sollte man davon ausgehen, dass er weiß, wovon er spricht.

-Michael