Brauche absolut exakten Timer
-
Ja wann bestimmst du denn die Zeit?
wenn du es einmal in einem Schleifendurchlauf machst, braucht die Schleife vielleicht 16ms ? Könnte ja sein, dass der Prozess deines Programmes nicht oft genug an der Reihe ist und darum dauerts halt ab und zu mal en bisschen länger
-
nein, meine schleife braucht ca. 99 von 100 mal nur ca. 3 oder 4 1/10000 sekunden.
Die Frage ist nur, wie ich den Thread der das zeitinterval misst dazu gebracht werden kann, nicht unterbrochen zu werden. Mit SetThreadPriority hats nämlich nicht geklappt!
-
chris90 schrieb:
nein, meine schleife braucht ca. 99 von 100 mal nur ca. 3 oder 4 1/10000 sekunden.
Die Frage ist nur, wie ich den Thread der das zeitinterval misst dazu gebracht werden kann, nicht unterbrochen zu werden. Mit SetThreadPriority hats nämlich nicht geklappt!nocht nichmal als Echtzeitthread ?
-
nein, noch nicht einmal als Echtzeitthread bzw falls das Priority Nr. 6 ist...
Es macht bei mir aber auch keinen großen Unterschied ob ich nun -15 oder 6 hatte als Priority...
-
hey, ich glaub ich weiß was ich grade für einen Fehler gemacht hab.
Mein Timer zeigt Millisekunden and und nicht Sekunden! Deswegen habe ich bei Ergebnisse wie "0.012" rot gesehen!
aalso: Mit Echtzeitthread klappt es wunderbar! Auflösung: < 0.5 msWieso wird das nicht immer so gemacht wo es doch eine höhere Auflösung hat?
DANKE!!
chris90
-
chris90 schrieb:
hey, ich glaub ich weiß was ich grade für einen Fehler gemacht hab.
Mein Timer zeigt Millisekunden and und nicht Sekunden! Deswegen habe ich bei Ergebnisse wie "0.012" rot gesehen!
aalso: Mit Echtzeitthread klappt es wunderbar! Auflösung: < 0.5 msWieso wird das nicht immer so gemacht wo es doch eine höhere Auflösung hat?
DANKE!!
chris90Je höher die Threadpriorität, desto öfter kommt der Prozess an die Reihe beim Weiterrechnen.
Echtzeit ist halt verdammt oft, wenn nicht sogar *nur*, bin mir grad nicht sicher.
-
xindon schrieb:
Je höher die Threadpriorität, desto öfter kommt der Prozess an die Reihe beim Weiterrechnen.
????
xindon schrieb:
Echtzeit ist halt verdammt oft, wenn nicht sogar *nur*, bin mir grad nicht sicher.
Echtzeit hat nichts mit oft zu tun, sondern mit Deterministrik. Und die ist in Windows nicht gegeben.
-
Jochen Kalmbach schrieb:
xindon schrieb:
Je höher die Threadpriorität, desto öfter kommt der Prozess an die Reihe beim Weiterrechnen.
????
xindon schrieb:
Echtzeit ist halt verdammt oft, wenn nicht sogar *nur*, bin mir grad nicht sicher.
Echtzeit hat nichts mit oft zu tun, sondern mit Deterministrik. Und die ist in Windows nicht gegeben.
Zwei Threads A und B, beide Mittlere Priorität.
-> A, B, A, B, A, B... usw.Zwei Threads A und B, A hohe Priorität
-> A, A, B, A, A, B, A, A, B .... usw.
-
xindon schrieb:
Zwei Threads A und B, A hohe Priorität
-> A, A, B, A, A, B, A, A, B .... usw.Nein. Wenn A immer "Ready to run" ist, kommt B nie dran!
Lese doch bitte mal "Windows Internal"...
http://www.amazon.de/exec/obidos/ASIN/0735619174/028-1369064-1089362Add: Aus diesem Grunde kann ich auch jedem nur davon abraten ohne fundiertes Wissen an den Prioritäten zu schrauben! Gleich gar nicht irgendwas auf Echtzeit zu setzen...
-
*g* Ich kauf mir bestimmt kein Buch für 50€ wegen einer Sache, mit der ich mich normalerweise gar nicht beschäftige
Ich weiß ja selbst, dass ich keine Ahnung habe; aber ich habe gedacht, dass ich einfach mal das poste, was ich gelesen/gehört hab. Man lernt schließlich nie aus.
Jochen Kalmbach schrieb:
Add: Aus diesem Grunde kann ich auch jedem nur davon abraten ohne fundiertes Wissen an den Prioritäten zu schrauben! Gleich gar nicht irgendwas auf Echtzeit zu setzen...
Mach ich auch nicht
edit:
Der Imperativ von lesen ist lies!
-
xindon schrieb:
Der Imperativ von lesen ist lies!
OT: Ich bin Schwabe, da kann mir das Imperativ gestohlen bleiben
