Echtzeit und C# ? Genauer Timer ?
Hallo
ich habe eine Anwendung in der ich einen 1ms Timer benötige.
Der System.Windows.Forms.Timer lässt sich zwar auf 1 ms einstellen, aber wann der wirklich kommt steht ja woanders.
Ich habe es mal gemessen. Er braucht manchmal über 100ms statt einer.
Gibt es eine Möglichkeit einen genaueren Timer zu benutzen oder sonstige Tricks wie man in Richtung Echtzeit kommt?
Gruß
Andreas
Hallo willivonbienemaya,
es gibt ja nun drei verschiedene Timer (siehe :rtfm: Doku). Aber in Richtung 1ms wirst du m.E. mit keinem kommen. Die Genauigkeit steht m.E. auch in der Doku.
herbivore
Hallo herbivore,
ich habe in der Doku nur die Timer Klasse gefunden. Und ich habe auch keine Genauigkeiten gesehen.
http://msdn.microsoft.com/library/deu/default.asp?url=/library/DEU/cpref/html/frlrfSystemThreadingTimerClassTopic.asp
Kannst du mir den Link posten? Ich glaub ich seh den Wald vor lauter Bäumen nicht.
Wenn ich schon keinen schnellen Timer bekomme, wäre wenigstens einer hilfreich der in immer gleichen Abständen kommt.
Windows und Echtzeit geht nicht. Es gibt keinerlei zugesichertes Zeitverhalten durch das BS. In Theorie und Praxis kann es also vorkommen, dass das System mal eben komplett 2 Sekunden steht. Kennt jeder, der zum ersten mal den Explorer aufmacht. Dann steht das ganze System für kurze Zeit. Auch deine Timer werden dann nicht kommen, weil die Prozesse gar nicht erst rankommen.
Aber vielleicht reicht dir ja ein 99%-Verhalten.
Es gibt aber Echtzeiterweiterungen für Windows von Drittherstellern. Einfach nach "Windows Realtime Extension" googeln.
To understand recursion you must first understand recursion
Hallo willivonbienemaya,
wenn man Timer in den Index der :rtfm: Doku eingibt, werden einem sofort alle drei Arten von Timer angezeigt (siehe auch aufruf alle 10 sekunden). Keine Ahnung, warum du die nicht gefunden hast. Wenn du die :rtfm: Doku gar nicht offline hast, solltest du sie dir bitte installieren. Wir setzen voraus, dass die notwendigen Hilfsmittel vorhanden sind.
herbivore
Original von tscherno
Es gibt aber Echtzeiterweiterungen für Windows von Drittherstellern. Einfach nach "Windows Realtime Extension" googeln.
Gibt es. Der Echtzeit-Code muss dann allerdings in C/C++ geschrieben sein. .NET geht schon deswegen nicht, weil der GC nicht echtzeittauglich ist.
Sorry, konnte irgentwie heute Mittag nix ins Forum schrieben. Kam immer ein Fehler.
Das hatte ich schreiben wollen:
"
@ svenson
Mit einem 99% Verhalten würde ich mich ja zufrieden geben. Aber wenn ich 1ms einstelle und 100ms bekomme, is das ein mieses Verhalten 😉
@ tscherno
Ich weiss. Habe ich sogar hier. Die Real-Time-Suite von Kithara.
Nur hat die den Haken, dass die nicht unter C# funktioniert.
Die unterstützt nur C++ und Delphi leider.
@herbivore
gut möglich dass ich zu dumm bin, aber ich finds echt nicht.
Ich hab die MSDN Doku installiert.
"
Hallo willivonbienemaya,
durch meinen Link, weißt du genau, wie die Klassen heißen (nämlich alle Timer) und und in welchen Namespaces sie liegen. Außerdem brauchst du wie gesagt nur Timer in den Index einzugeben.
herbivore
Original von svenson
Windows und Echtzeit geht nicht. Es gibt keinerlei zugesichertes Zeitverhalten durch das BS.
Das stimmt so nicht ganz. Mit einer entsprechenden Echtzeit-Einsteckkarte und dem passenden Treiber dazu lassen sich zuverlässige Echtzeitanwendungen auf PC und Windows Basis erzeugen. Das funktioniert aber nur bei Intel und nicht bei AMD Prozessoren. Die Einsteckkarte missbraucht nämlich einen Interrupt, der beim IBM XT verwendet wurde, um den Speicher zu refreshen. Moderne Systeme benötigen diesen Interrupt nicht mehr, aber er ist auch in den neuen CPUs noch vorhanden. AMD CPUs verwenden ihn aber scheinbar anderweitig.
Ich spreche aus eigener Erfahrung, da die Firma, für die ich arbeite, bis vor einigen Jahren PC gesteuerte Maschinen entwickelt und vertreiben hat. Ich sebst habe für zwei Typen die Benutzeroberfläche geschrieben. Diese Maschinen arbeiteten definitiv Echtzeitfähig.
Diese Einsteckkarte wurde ursprünglich von der LP Elektronik GmbH entwickelt. Diese wurde von Kuka (die machen Industrieroboter) übernommen. Kuka verwendet glaube ich auch ähnliche Karten zur Steuerung ihrer Roboter.
Hier Links zum Thema:
http://www.realtime-info.be/magazine/97q2/1997q2_p043.pdf
http://www.globalewirtschaft.de/pm/index.php?w=det&ID=17846
Es gibt immer noch Unterscheidungen bei dem Wort "Echtzeit". Dass ein normales Windows-OS zu harter Echtzeit faehig ist, glaube ich nichtmal im Ansatz. Dass PC Hardware aus dem Regal dazu faehig ist ebensowenig. Fuer "weiche" Echtzeit mag es Workarounds/Tools etc. geben, aber deswegen wuerde ich trotzdem keine Raketen mit Windows und nem Standard-PC als Navigationssystem ausruesten..
Pound for pound, plutonium is about as toxic as caffeine when eaten.
Hmm.. Kuka sagt auf der Homepage, dass sie VxWorks oder Windows CE parallel zu Windows XP auf einem einzigen Prozessor hart echtzeitfaehig kriegen..
Hmm - das sieht zwar serioes aus, widerspricht aber all meinen Kenntnissen ueber Windows (und u.a. auch PC Hardware, eine Architektur die dafuer mal bescheiden geeignet ist). Interessant jedenfalls.
Pound for pound, plutonium is about as toxic as caffeine when eaten.
@ herbivore
Ich habe schon die drei Timerarten durch deinen Link gefunden. Habe sie jetzt auch in der Doku gefunden. Nur habe ich keine Infos über die Genauigkeit finden können.
Ich werde wohl für diese Applikation nach Delphi wechseln müssen, da es wohl keine Möglichkeit gibt mit C# schnell genug zu werden.
Hallo willivonbienemaya,
wie liest du denn die Doku? Unter System.Windows.Forms.Timer steht, z.B.:
Die Zeitgeberkomponente in Windows Forms ist Singlethreaded und auf eine Genauigkeit von 55 Millisekunden beschränkt. Wenn Sie einen Multithread-Zeitgeber mit größerer Genauigkeit benötigen, verwenden Sie die Timer-Klasse im System.Timers-Namespace.
Bei System.Timers.Timer steht:
Serverzeitgeber können zwischen Threads wechseln, um das ausgelöste Elapsed-Ereignis zu behandeln, wodurch eine höhere Genauigkeit erreicht wird als bei Windows-Zeitgebern, da das Ereignis zum richtigen Zeitpunkt ausgelöst wird. Weitere Informationen zu serverbasierten Zeitgebern finden Sie unter Einführung in serverbasierte Zeitgeber.
Und wenn man dem Link folgt, steht dort:
Der serverbasierte Zeitgeber wurde für die Verwendung mit Arbeitsthreads in Multithreaded-Umgebungen entworfen. Da sie eine andere Architektur verwenden, haben serverbasierte Zeitgeber ein wesentlich höheres Genauigkeits_potenzial_ als Windows-Zeitgeber.
Das ist zwar keine so präzise Genauigkeitsangabe, wie bei System.Windows.Forms.Timer, lässt aber doch zwei Rückschlüsse zu: "wesentlich genauer" wird also wohl mindestens ein Faktor > 2 sein. Und dann steht da steht da Genauigkeits_potenzial_. Das bedeutet, was in dem Thread hier schon angeklungen ist: Echtzeit ist unter Windows Essig. Es kann auch mal Sekunden dauern, bis der Timer-Event ausgelöst wird, wenn z.B. ein Kerneltreiber spinnt. Und noch ein Schluss ist möglich, nämlich dass die konkrete Genauigkeit von der Geschwindigkeit des Rechner abhängt.
herbivore
@ herbivore
Danke, das sind schon mal nützliche Informationen.
Leider alles zu langsam.
Ich will eine PCI Hardware testen. Da ich mit C# ja nicht an den Hardwareinterrupt komme, muss ich die Hardware mindestens alle 1ms pollen. Und das scheint mir in C# nicht möglich zu sein.
Klar wird das mit einem Windows nie gehen, aber es ist ein unterschied ob ein ms Timer ganz selten mal ein aussetzer hat oder nie pünktlich kommt.
Ich habe übrigens mal die Timer verglichen.
Auf demselben Rechner habe ich einen Forms.Timer und einen Timers.Timer mit 1ms laufen lassen.
Beide Timer liefen etwa gleich schnell mit 15ms.
Hallo, vielleicht interessiert euch das:
Hab jetzt die Posts dieses Themas gelesen und konnte mir nicht vorstellen, dass man wirklich nur so "ungenau" programmieren kann mit C#.
Habe daraufhin eine eigene Klasse mit einem Thread programmiert, deren Ziel es ist, immer wenn eine Millisekunde vergangen ist den Zeitpunkt in eine Liste zu speichern.
Mein Ergebnis: obwohl ich den Thread auf höchster Priorität laufen lies und sonst keine weiteren rechenintensiven Anwendungen laufen hatte war das Program höchst ungenau. Mindestens +- 8 Millisekunden. Selbst wenn das Programm nur alle 100 Millisekunden den Zeitpunkt speichern sollte, gab es diese Abweichungen.
Also mit Echtzeit und Genauigkeit unter C# und Windows sieht es wirklich schlecht aus.
Das hatte ich auch festgestellt.
Ich habe die ganze Zeit gehofft, dass ich noch etwas falsch mache.
Scheinbar geht es aber nicht besser.
Das Problem ist schon mal die Zeitmessung. .NET wrappt im Prinzip nur die WINAPI Funktionen und Funktionen wie TimeGetTime / GetTickCount und co sind alle höchst ungenau (im Bereich von 55 ms (evtl. auch ein bisschen weniger)). Das einzige, womit man unter Window halbwegs genaue Zeitintervalle bekommt ist QueryPerformanceCounter (ist aber auch Hardwareabhängig und ältere Intel CPU's haben angeblich ne Macke) - bei Dual Core braucht man einen Patch von MS, damit es korrekt läuft!
Jedenfalls liefert QPC eine Genauigkeit von ein paar µs! Demnach könntest Du eine Schleife schreiben die nix macht bis Deine gewollte Zeit vergeht und dann die Hardware pollen. Ist aber höchst unsauber da die CPU Last auf dem Kern auf 100% geht. Und Sleep(0) ist wieder kritisch da Du vermutlich nicht innerhalb von 1 ms wieder aufwachst...