4. Brauche absolut exakten Timer

Brauche absolut exakten Timer

  • C

    Es geht um eine Simulation. Damit die möglichst schnell abläuft, möchte ich ein kleinstmögliches Intervall haben. Eine einfache For-Schleife in einem neuen Thread genügt deswegen nicht, da die Simulation in Echtzeit graphisch angezeigt werden soll. Glaubt ihr es macht da etwas wenn ich eben alle paar zehntelsekunden mal ein 20ms-Intervall drinhabe neben einem 1 ms Intervall?
    Und wie soll ich dann mit den zu großen Intervallen umgehen? Ignorieren ? Dynamisch berechnen - dann hab ich aber wieder das Problem dass ich dann kein Standart - Intervall habe und das könnte dumme folgen haben auf den Ablauf der Simulation.

    danke
    chris90

    0
  • J

    Warum misst Du nicht einfach die Zeit zwischen zwei Aufrufen Deines Timers???
    Damit weisst Du wie schnell du die "Bewegung" jetzt ausführen musst. Somit spielt die Genauigkeit des Aufrufes keine Rolle mehr...

    0
  • C

    Das Problem ist eben dass ich gewissermaßen "integriere". Sprich je größer das Intervall, desto ungenauer die Berechnung. Das bedeutet, dass ich ein konstantes kleines Intervall benötige.
    ich glaube ich werde es so machen, dass ich größere Intervalle als kleinere behandele.

    danke
    chris90

    0
  • X

    Der Performance Counter ist in der Hardware implementiert und läuft mit 3.19 Mhz. Das gibt uns eine Auflösung von ca. 1 Mikrosekunde (1/1.000.000stel einer Sekunde).
    *
    Low-Level Timing

    Ich hab den kürzlich erst bei meinem MS3D Loader benutzt. Ist gut, wenn man jeden Frame die FPS hochrechnen will um Bewegungen gleichmäßig zu machen.

    0
  • J

    xindon schrieb:

    *Der Performance Counter ist in der Hardware implementiert und läuft mit 3.19 Mhz. Das gibt uns eine Auflösung von ca. 1 Mikrosekunde (1/1.000.000stel einer Sekunde).
    *

    Von welchem Performance Counter redest Du da? Und wo steht sowas?

    0
  • X

    Jochen Kalmbach schrieb:

    xindon schrieb:

    *Der Performance Counter ist in der Hardware implementiert und läuft mit 3.19 Mhz. Das gibt uns eine Auflösung von ca. 1 Mikrosekunde (1/1.000.000stel einer Sekunde).
    *

    Von welchem Performance Counter redest Du da? Und wo steht sowas?

    klick doch mal auf den Link darunter 🙂

    0
  • J

    Die einzige Referenz die bei der WinAPI verwendet werden sollte ist die MSDN (die auch nicht perfekt ist 😉 )...

    Falls Du also von QueryPerformanceCounter reden solltest, dann ist die Frequenz abhängig von der HAL und nicht fest vorgegen! (sonst würde es ja auch keine QueryPerformanceFrequency geben, oder)?

    0
  • X

    Jochen Kalmbach schrieb:

    Die einzige Referenz die bei der WinAPI verwendet werden sollte ist die MSDN...

    Falls Du also von QueryPerformanceCounter reden solltest, dann ist die Frequenz abhängig von der HAL und nicht fest vorgegen! (sonst würde es ja auch keine QueryPerformanceFrequency geben, oder)?

    Auf den meisten heutigen CPU's liegt die Frequenz aber bei 3.19Ghz und die Funktion gibt es, da sie auch anders sein kann, wie du sagst.

    Das hab ich irgendwo gelesen.
    Ich kann nur aus Erfahrung sprechen, dass ich gute Erfahrungen mit dem Counter gemacht habe beim Rendern, wenn ein Schleifendurchgang nur 5ms oder weniger dauert. Zum hochrechnen wie schon gesagt.

    0
  • C

    naja das Problem ist ja wohl eher nicht dass ich keine Möglichkeit hätte z.b. über QueryPerformanceCounter einen höchstgenauen Zeitabstand zu messen. Das Problem ist, dass ich in der Überprüfung plötzlich immer wieder 16ms abstand habe. Die genauste Timer-Funktion nützt mir nichts, wenn ich sie nur alle 16ms überprüfen kann 😞

    0
  • X

    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

    0
  • C

    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!

    0
  • X

    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 ?

    0
  • C

    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...

    0
  • C

    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 ms

    Wieso wird das nicht immer so gemacht wo es doch eine höhere Auflösung hat?

    DANKE!!
    chris90

    0
  • X

    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 ms

    Wieso wird das nicht immer so gemacht wo es doch eine höhere Auflösung hat?

    DANKE!!
    chris90

    Je 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.

    0
  • J

    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.

    0
  • X

    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.

    0
  • J

    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-1089362

    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...

    0
  • X

    *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! 😛

    0
  • J

    xindon schrieb:

    Der Imperativ von lesen ist lies! 😛

    OT: Ich bin Schwabe, da kann mir das Imperativ gestohlen bleiben 😃

    0
Anmelden zum Antworten