Timing Problem

[Probe-Nutzer]

@zeek2003:

ok, auch bei mir ist CLOCKS_PER_SEC auf 1000 festgelegt, aber es hätte ja sein können, daß das bei dir nicht der Fall ist, zumindest ist mir das zuerst eingefallen, als ich deine Eingangsfrage gelesen habe. Da ich schon lange nichts mehr unter DOS programmiert habe, war mir die Größe der Konstante CLOCKS_PER_SEC auf einem DOS-System nicht gerade bekannt. Wie man sieht, ist CLOCKS_PER_SEC = 1000 für dein System völlig ungeeignet, da wäre eine Anpassung in den Headern nötig, wenn man ungefähre Sekunden-Werte erhalten will. Den Unterschied bei den delays kann ich mir schon vorstellen, ein 32Bit-DOS mit Extender aktualisiert wohl die Stelle, aus der delay seine Warte-Zyklen abliest, anders als ein 16Bit-DOS, von daher weißt du also nur, daß delay sich je nach System anders verhalten kann. Mit delay wirst du also nur eine system-abhängige Lösung erzielen können, aber du brauchst dann wohl eine Lösung die auf allen DOSen möglichst genau ist, so wie es klingt. Oder war das nur ein Test, und du kannst dich doch auf die Lösungssuche für ein System beschränken...?

@AJ:

ich erinnere mich auch an den Wert 18,.. bei einem DOS-System, aber das paßt wie gesagt nicht zusammen, da CLOCKS_PER_SEC dann in den Headern gleich 18 sein müßte. D.h., die Umrechnung sollte man auf jeden Fall machen, wenn man mit clock() arbeitet (mit korrekten Headern kommen dann auch die für das jeweilige System passenden Werte heraus), in diesem Falle ist natürlich die "Auflösung" eines Ticks zu grob, um damit arbeiten zu können

[AJ]

@probe
Naja die Konstante heißt ja auch CLOCKS_PER_SECOND und nicht TICKS_PER_SECOND ;). Anscheinend haben die Entwickler für clock() einfach Millisekunden als Einheit verwendet. Deswegen ist der Rückgabewert von clock() trotz alledem von den Ticks abhängig, wie man sieht. Teile mal 1000 durch 55, dann kommst du in etwa auf die 18,2.

@zeek
Hmmm ich würde in google nach Google: C Bibliothek Timer erstmal suchen (bzw. mit der englischen Übersetzung von Bibliothek).

[Probe-Nutzer]

@AJ:

es ist, glaube ich, nicht ganz angekommen, worauf ich hinauswollte. Stellen wir uns eine Hardware(-Implementation) vor, in der der clock-Wert nur (ungefähr) 18 mal in der Sekunde um eins erhöht wird. CLOCKS_PER_SECOND muß dann 18 sein, und jetzt zitiere ich noch mal zeek2003 aus dem ersten Beitrag:

[...] Es scheint so als ob DOS die Uhr alle 55 Millisekunden um den Wert 55 erhöht[...]

nun, mit der "Uhr" meint er hier den clock-Wert (der clock-Wert erhöht sich nur alle 55ms um den Wert eins (eins = 1 clock-Intervall = 55ms auf seinem System)

Und noch mal die Doku:

In other words, clock returns the number of processor timer ticks that have elapsed.

A timer tick is approximately equal to 1/CLOCKS_PER_SEC second.

beachte die Unterscheidung zwischen dem Wert, den clock zurückgibt (clock gibt immer eine Anzahl von "timer ticks" zurück, die nicht die "Auflösung" eins besitzen muß, soll heißen, die Differenz, die man zwischen zwei auseinanderliegenden clock-Aufrufen bekommt, ist immer ein Vielfaches einer hardware-abhängigen Konstante), und dem Begriff "timer tick".

Genau deswegen ist ja CLOCKS_PER_SEC als (implementationsabhängige) Konstante festgelegt, und bei zeek2003 müßte die Konstante 18 sein

Also zusammengefaßt : CLOCKS_PER_SEC sagt aus, wie oft ein "clock-Ereignis" eintritt, bei dem der clock-Wert um eins erhöht wird, und es gibt Systeme bei denen eine Einheit von clocks nicht Millisekunde, sondern ein Vielfaches einer Anzahl von Millisekunden ist...(deswegen habe ich auch immer von "Auflösung" des "clock-Timers" gesprochen)

Solltest du das gleiche gemeint haben, dann vergiß meine Erklärung, aber mir schien wichtig, noch einmal darauf hinzuweisen.

MfG

[AJ]

Anscheinend stimmt das was in der Doku steht nicht mit dem überein, was programmiert wurde. Leider...

Ich habe mir die Ticks immer über eine bestimmte Adresse geholt bei 16Bit-Anwendungen. Da wars wenigstens sicher, dass es die Ticks waren

Ich frage mich, ob es in DOS (16Bit) überhaupt die Möglichkeit gibt, kleinere Werte als die 55 Millisekunden zu erhalten. Das hätte ich früher schon mal gut gebrauchen können.

[Probe-Nutzer]

AJ schrieb:

Anscheinend stimmt das was in der Doku steht nicht mit dem überein, was programmiert wurde. Leider...

wie meinst du das jetzt? Bist du wirklich der Meinung, daß die Doku nicht stimmt (so, wie ich es oben erklärt habe, gibt es doch keine Diskrepanz zwischen Doku und Realität?)

AJ schrieb:

Ich habe mir die Ticks immer über eine bestimmte Adresse geholt bei 16Bit-Anwendungen. Da wars wenigstens sicher, dass es die Ticks waren

Ich frage mich, ob es in DOS (16Bit) überhaupt die Möglichkeit gibt, kleinere Werte als die 55 Millisekunden zu erhalten. Das hätte ich früher schon mal gut gebrauchen können.

ich habe an einer Portierung DOS zu Linux mitgearbeitet, bei dem es auch um Kommunikation mit der seriellen Schnittstelle ging (also zeitkritisch), da wurde auch aus der Adresse gelesen, der clock-Wert ist also ungeeignet.

Und bei kleinen Warte-Zyklen wurde Assembler mit prozessorspezifischen Konstanten eingesetzt, um mit den Takt-Zyklen gewisser Anweisungen Wartezeiten zu erreichen, die unter 55 ms liegen, so daß ich ziemlich sicher bin, daß ohne Assembler nichts anderes geht, um unter die 55 ms zu kommen...

MfG

[zeek2003]

Nochmal zur Klärung:

Probe-Nutzer: Der Clock-Wert erhöht sich NICHT alle 55ms um den Wert 1, sondern alle 55ms um den Wert 55, gibt also sehr wohl die Millisekunden zurück, aktualisiert sie aber nur alle 55ms. Dies stimmt also nicht mit der Doku überein. Um das nochmal zu verdeutlichen, hier eine kleine Tabelle:

Tatsächliche Zeit - Zurückgegebene Zeit
0ms - 0ms
1ms - 0ms
2ms - 0ms
3ms - 0ms
4ms - 0ms
[...]
52ms - 0ms
53ms - 0ms
54ms - 0ms
55ms - 55ms
56ms - 55ms
57ms - 55ms
[...]

Abgesehen davon steht "delay" wie folgt in der Doku:

Synopsis:
#include <i86.h>
void delay( unsigned milliseconds );

Description:
The delay function suspends execution by the specified number of milliseconds.

Und das ist ja auch schlichtweg falsch. Der Delay ist immer um das 55-fache länger.

Ich begebe mich jetzt mal auf die Suche nach einer Bibliothek. Wenn irgendwem noch was einfällt, bitte posten!

Gruß,
Zeek

[Probe-Nutzer]

zeek2003 schrieb:

Der Clock-Wert erhöht sich NICHT alle 55ms um den Wert 1, sondern alle 55ms um den Wert 55, gibt also sehr wohl die Millisekunden zurück, aktualisiert sie aber nur alle 55ms. Dies stimmt also nicht mit der Doku überein

du hast mich falsch verstanden, ich habe es schon so gemeint, mit diesem Satz:

nun, mit der "Uhr" meint er hier den clock-Wert (der clock-Wert erhöht sich nur alle 55ms um den Wert eins (eins = 1 clock-Intervall = 55ms auf seinem System)
*

mit "eins = 1 clock-Intervall = 55ms auf seinem System" meinte ich ja gerade, daß eine clock-Erhöhung zur Erhöhung um 55 Millisekunden führt (oder anders ausgedrückt: clock erhöht sich immer um 55-Millisekunden-Einheiten, mit der Erhöhung um eins meinte ich eine Erhöhung um eine solche 55-Millisekunden-Einheit).

Und wenn du meine Interpretation der Doku genau gelesen hast, dann stimmt das auch mit der Doku überein...(Interpretations-Sache, aber meiner Meinung nach richtig)

zum Verhalten von delay kann ich nichts weiteres sagen, man kann nur sehen, daß die Doku zu delay mit Sicherheit nicht stimmt, zumindest nicht für jedes System

MfG

[AJ]

@probe-nutzer
Also ich habe den Dokuauszug von dir so verstanden, dass clock() eigentlich nach 55 Millisekunden 1 zurückgeben müsste und nicht 55 und so gehts wohl auch zeek2003.

Wobei die Dokumentation dahingehend wieder stimmt, dass der Rückgabewert von clock() abhängig ist von CLOCKS_PER_SECOND. Allerdings steht dem wieder gegenüber, dass in CLOCKS_PER_SECOND nicht 1000 stehen dürfte sondern nur 18.2, da ja in der Doku eindeutig von TICKS die Rede ist.

Darum denke ich, dass die Doku und die Programmierung nicht ganz übereinstimmen (was durchaus mal vorkommen kann ;)).

[Probe-Nutzer]

AJ schrieb:

Also ich habe den Dokuauszug von dir so verstanden, dass clock() eigentlich nach 55 Millisekunden 1 zurückgeben müsste und nicht 55 und so gehts wohl auch zeek2003.

so habe ich es auch gemeint, da habe ich wohl zeek2003's letzten Beitrag zu schnell gelesen (ich dachte, er hat noch umgerechnet, aber er schreibt ja, daß der Wert von clock sich wirklich um 55er-Einheiten ändert, mich hat irritiert, daß er von 55 Millisekunden-Sprüngen als Rückgabe von clock spricht, denn clock gibt eine einheitenlose Zahl zurück, so daß ich eine Umrechnung in Millisekunden annahm). Wenn clock dann nur Werte in Schritten von 55 zurückgibt, und alle 55 Millisekunden erhöht wird, würde das ja bedeuten, daß die Konstante CLOCKS_PER_SECOND mit dem Wert 1000 doch korrekt ist, nur daß Zwischenwerte eben systembedingt nicht ermittelt werden können (auf anderen Systemen wird clock dann öfter aktualisiert).

D.h. aber, daß man sagen kann, daß die Doku nur in der Hinsicht nicht stimmt, daß der Wert genau ist, wie man beim Lesen dieses Teils

In other words, clock returns the number of processor timer ticks that have elapsed.
*

annehmen müßte (die Konstante CLOCKS_PER_SECOND (=1000) suggeriert zusätzlich, daß wirklich alle Millisekunden um eins erhöht wird).

Einigen wir uns darauf, daß clock also je nach Implementierung nur einen mehr oder weniger geeigneten Wert zurück gibt, und man mit einer Ungenauigkeit rechnen muß, wenn man diesen Wert für Timing-Aktionen verwenden will

MfG

[AJ]