Windows Kernelmodetreiber echtzeitfähig?

Gast++ schrieb:

anonymus schrieb:

3GHz == 3 Milliarden
=> Die CPU müsste doch im Nanosekundenbereich ihre Befehle abarbeiten?

Aeehh, ja, kleiner Rechenfehler von mir...
Vergiss also am besten mein Geschwätz von gestern.

Grüsse

*this

P.S.: Wer lacht da? Einstein hat sich afaik mal um über 60 Grössenordnungen verschätzt - bei mir waren's nur drei!

Sind denn 3GHz nicht 3 Milliarden Takte pro sekunde?
kilo = tausend.
mega = millionen
giga = milliarden

1 Nanosekunde = 1000 Picosekunden = 10^-9 Sekunden
also 3 Takte pro Nanosekunde. Oder verrechne ich mich auch?

oder etwa nicht?

Ja es sind genau 333,3... pikosekunden pro takt:
3Ghz = 3.000.000.000 Hz
1 Takt = 3,333... * 10^-10 sekunden | *1000
1 Takt = 3,333... * 10^-7 ms | *1000
1 Takt = 3,333... * 10^-4 µs | *1000
1 Takt = 0,333... ns | *1000
1 Takt = 333,3... ps

anonymus

hustbaer schrieb:

Windows (egal welche Version) ist ohne eigene "Extensions" nicht Echtzeitfähig. Mit einem Treiber kann man zwar die durchschnittlichen Latenzzeiten deutlich verkürzen, ändert aber Grundsätzlich nix.
Mikrosekundenbereich kannst du IMHO vergessen. Auf ~~1ms ja, vielleicht, mit Bauchweh, aber auch nur wenn nix wichtiges davon abhängt.
Mit selektierter Hardware und selektierten Treibern sollte deutlich weniger als ~~1ms möglich sein, ob man in den Microsekundenbereich kommt ... weiss nicht ... mich würde es wundern. Kritisch darf die Anwendung aber auch mit selektierter Hardware nicht sein.
Nicht selektierte PC Hardware ist - egal welches OS - nicht Echtzeitfähig, da es immer noch das BIOS gibt, und dieses oft den SMI (den du softwaremässig nicht maskieren kannst, zumindest gibt es keinen Standard dafür) verwendet um diverse Hardware Fehler auszubügeln.

Dann läßt sich also sagen, dass es mit einem Kerneltreiber funktioniert,
unter der Voraussetzung, dass die Schnittstelle mitspielt?

Nein (siehe oben).
EDIT:

dann müsste sich sowas doch in einer Interrupt Routine (=höchste Priorität) machen lassen.

Du brauchst keinen ISR, du brauchst wenn dann KeRaiseIrql(). Wenn du damit auf CLOCK_LEVEL oder sowas brutales hochgehst ist das so ziemlich das Beste was du mit Windows hinbekommen wirst.
Aber selbst dann kannst du noch von diversen Dingen für (relativ) kurze Zeit unterbrochen werden.
Wenn dann ein Interrupt getriggert wird, während dein Thread mit z.B. CLOCK_LEVEL läuft, dann wird der zuständige ISR zwar nicht ausgeführt, aber es kann sein dass der Interrupt Handler von Windows selbst noch angesprungen wird, und erst dort dann die Interrupts gesperrt, damit dein Thread weitermachen kann. Das erfordert ein paar Port Zugriffe, und die sind oft ordentlich langsam.

Das macht natürlich wenig Hoffnung.
Wenn da nicht weniger als eine Millisekunde drin ist.
5-6 ms Reaktionszeit kriegt man ja schon im Usermode hin
(gut, nicht garantiert, aber gemessen hab ich nie mehr...)

Von einem Treiber hätt ich mir doch einiges mehr erwartet.

Sorry, was ist "selektierte Hardware"? Google bringt mich ned wirklich weiter.

Najo, jetzt geht's erstmal a paar Tage nach Italien.
Und dann mal schaun, wie's weitergeht.
Aber schaut dann wohl ned so gut aus...

mfg
Martin

hustbaer

selektiert: ausgewählt.

schirrmie

gerade neue News bei tecchanel, da musste ich gleich hieran denken
http://www.tecchannel.de/news/themen/entwicklung/470000/index.html

schirrmie

anonymus

schirrmie schrieb:

gerade neue News bei tecchanel, da musste ich gleich hieran denken
http://www.tecchannel.de/news/themen/entwicklung/470000/index.html

Hab mich da mal a bissl eingelesen und das schaut ganz vernünftig aus.

Allerdings macht das von Hustbaer vorgeschlagene "KeRaiseIrql()"
auch eine ganz gute Figur.

Da werd ich jetzt einfach mal viel lesen müssen.
Anhaltspunkte hab ich jetzt zumindest schon mal.

Thx @all.

hallo

WIndows XP ist grundsätzlich nicht Echtzeitfähig, allerdings kann mit einigen Tricks schon sehr zeitkritische Anwendungen realisieren. Dein Problem sollte sich mit einem Kernelmodetreiber eigentlich locker realisieren lassen, sofern die Hardware mitspielt. Als beispiel kann man im Kernelmode Timer Initialisieren (XP), welche in 100 ns Intervall angegeben werden.
Millisekunden sollten da ebenso möglich sein.
Allerding ist die einarbeitung in dieses Thema schon recht aufwendig und die Dokomentatinen recht rar, ausser das Windows DDK.

hustbaer

IIRC kann man zwar in 100ns Schritten das Timeout angeben, der Timer wird aber dadurch nicht genauer. D.h. die Genauigkeit mit der der dann feuert ist genauso durch die Frequenz mit der der Scheduler aufgerufen wird begrenzt. Also üblicherweise ~15ms bzw. minimal 1ms wenn man die Frequenz "runterdreht".

anonymus

Hab mir das Protokoll nochmal genauer angeschaut und muss sagen, dass es eigentlich keine Echtzeitimplementierung in dem Sinne ist, dass innerhalb einer bestimmten Zeit auf ein Ereignis reagiert werden muss.

Vielmehr ist es so, dass es (fast) egal ist (ca. 10 ms dürfen vergehen, und die sollte man sogar im Usermode hingekommen, zumindest warens über RS232 mal ~6ms) wann eine Funktion abgearbeitet wird,
es muss nur sichergestellt sein, dass sie, wenn sie mal arbeitet, nicht mehr
unterbrochen wird.
Und das müsste mit dem "KeRaiseIrql()" doch möglich sein, mit allen Einschränkungen die sich draus ergeben (hab ein Dokument gefunden, wo drin steht,
dass man z. B. drauf achten muss, dass man keinen Speicher verwendet, der
ausgelagert werden kann, falls das Level höher als XX gewählt wird).

Was ich dann allerdings brauch ist eine Counter, den man abfragen kann, wieviel Zeit vergangen ist, so dass man in einer Schleife eine bestimmte Zeit warten kann.

Der Time Stamp Counter wäre zwar so ein Kandidat, aber was ich so gelesen hab, ist der nicht allzu verlässlich (grade in Systemen mit mehr als einem Kern weil dann zwei Counter laufen, die nicht zwingend gleiche Werte haben, auch Hyperthreading soll da schon Probleme machen... oder falls die Taktfrequenz von der Last abhängt)
Auf der anderen Seite, wenn der Code nicht unterbrochen wird, dann müsste doch sichergestellt sein, dass er nur auf einem Kern läuft und somit müsste der TSC trotzdem OK sein.

APIC timer wäre evtl. eine Alternative, aber da hab ich noch nix gefunden, wie man da rankommt...

pale dog

anonymus schrieb:

APIC timer wäre evtl. eine Alternative, aber da hab ich noch nix gefunden, wie man da rankommt...

http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx
http://rtg.informatik.tu-chemnitz.de/docs/vortraege/def-sa-wiet.pdf
http://plan9.bell-labs.com/sources/plan9/sys/src/9/pc/apic.c

hustbaer

Für "muss in 10ms erledigt sein" wird's KeRaiseIrql wohl tun, aber ganz "ununterbrochen" läuft man auch dann nicht - wenn ein Interrupt auftritt kann das schnell mal ein Unterbrechung von ein paar hundert oder tausend nanos sein, selbst wenn der Interrupt einen niedrigeren IRQL hat als der mit dem man gerade läuft. Nur zur Info. (Wie lange solche Unterbrechungen genau sein werden, und wie oft man damit rechnen muss kann niemand so genau sagen, das hängt u.A. auch von der verwendeten Hardware ab, und was das System gerade noch tut).

Vonwegen Timer ... warten kannst du mit KeStallExecutionProcessor (busy wait). Längere Zeiten kann man mit KeDelayExecutionThread warten, allerdings nur auf PASSIVE_LEVEL, und nur mit sehr grober Auflösung.

Ansonsten gibt es noch KeQueryInterruptTime (was wahrscheinlich zu ungenau sein wird) und KeQueryPerformanceCounter. Ob KeQueryPerformanceCounter für dich funktionieren wird kann ich nicht sagen, ich hab' mit dem performance counter auf jeden Fall schlechte Erfahrungen gemacht, allerdings war das im Usermode.

kann mir jemand sagen was es mit den isa/pci-steckkarten auf sich hat die eigene timer haben? kann man die für sowas gebrauchen oder sind die nur zum zeitmessen da um den wert dann auszulesen?

anonymus

Zur Info:
Hab's jetzt nachgemessen:

Die Signalzeiten werden auf ca. 2µsec genau eingehalten.
=> gut so.

Falls die Reaktionszeit interessiert:
Wenn sich an einem Pin der parallelen Schnittstelle ein Wert ändert,
läßt sich innerhalb von 3µsec ein anderer Pin ändern.
=> auch gut.

Übrigens waren 3µsec auch die minimalen Signalzeiten, weniger war nicht möglich.

Dazu Interrupts mittels _asm{cli} deaktiviert, im Anschluss mit _asm{sti} wieder aktiviert.
Ab IRQL 28 auch brauchbare Ergebnisse in ähnlicher Größenordnung,
alles unter 28 ist grauenhaft

mfg
Martin

Jochen Kalmbach

Windows (NT/W2k/XP) ist *nicht* Echtezeitfähig... somit kann es auch keine Treiber geben die Echtzeitfähig sind!!!

Die ganze Diskussion hier ist Sinnlos...

Echtzeit heisst *nicht* so schnell wie möglich, sondern es heisst "deterministisch"!!!!

Und das ist nun mal unter Windows (NT und höher) nicht gegeben!!!!

Wenn irgendjemand einen Treiber schreibt der (aus versehen) mal 10 Sekunden braucht (innerhalb CLI), dann haben die anderen Treiber halt Pech gehabt!

Undertaker

Jochen Kalmbach schrieb:

Windows (NT/W2k/XP) ist *nicht* Echtezeitfähig... somit kann es auch keine Treiber geben die Echtzeitfähig sind!!!

kann es wohl. windows ist nicht allmächtig.

Jochen Kalmbach schrieb:

!!!!
!!!!

http://storage9.myopera.com/AlchemicalSecrets/albums/290842/omg1.png

hustbaer

Undertaker schrieb:

Jochen Kalmbach schrieb:

Windows (NT/W2k/XP) ist *nicht* Echtezeitfähig... somit kann es auch keine Treiber geben die Echtzeitfähig sind!!!

kann es wohl.

Ja, träum weiter, Kind. Dass hier ein WINDOWS Treiber gemeint war sollte wohl klar sein.

Undertaker

hustbaer schrieb:

Dass hier ein WINDOWS Treiber gemeint war sollte wohl klar sein.

du weisst nicht, das man mit code, der im ring0 ausgeführt wird, nahezu alles anstellen kann?

Jochen Kalmbach

Undertaker schrieb:

du weisst nicht, das man mit code, der im ring0 ausgeführt wird, nahezu alles anstellen kann?

Und genau das ist das Problem!!! Ich glaube Du hast mein Post nicht richtig gelesen...

Wenn *Du* alles machen kannst, dann können *andere* auch alles machen und dann ist Dein determinismus wieder dahin!

hustbaer

Undertaker schrieb:

hustbaer schrieb:

Dass hier ein WINDOWS Treiber gemeint war sollte wohl klar sein.

du weisst nicht, das man mit code, der im ring0 ausgeführt wird, nahezu alles anstellen kann?

Du kannst selbst in Ring 0 den SMI nicht loswerden, und das war's dann schonmal mit echtzeitfähig.
Was Windows angeht: klar kannst du alle Interrupt abdrehen und lala und lalubb, bloss andere können das auch.
Dass ein OS echtzeitfähig ist heisst NICHT dass man es "anhalten" kann, damit man dann diverse blöde polling Schleifen laufen lassen kann während alles andere steht um eben "echtzeit" zu bekommen.
Dass ein OS echtzeitfähig ist heisse dass man eben NICHT das OS anhalten oder sonstwie stören muss und TROTZDEM garantiert bekommt dass z.B. Interrupts mit einer max. Latenz aufgerufen werden. Und genau das geht unter Windows NICHT.

Windows
ist
> NICHT <
echtzeitfähig
!

Undertaker

hustbaer schrieb:

Du kannst selbst in Ring 0 den SMI nicht loswerden, und das war's dann schonmal mit echtzeitfähig.

wieso nicht?

hustbaer schrieb:

Was Windows angeht: klar kannst du alle Interrupt abdrehen und lala und lalubb, bloss andere können das auch.

was hat das mit 'anderen' zu tun?

hustbaer schrieb:

Dass ein OS echtzeitfähig ist heisst NICHT dass man es "anhalten" kann, damit man dann diverse blöde polling Schleifen laufen lassen kann während alles andere steht um eben "echtzeit" zu bekommen.

richtig.

hustbaer schrieb:

Dass ein OS echtzeitfähig ist heisse dass man eben NICHT das OS anhalten oder sonstwie stören muss und TROTZDEM garantiert bekommt dass z.B. Interrupts mit einer max. Latenz aufgerufen werden.

wenn das OS nicht mitspielen will/kann (wie windoofs), dann muss es darauf hinauslaufen, dass ihm die kontrolle entzogen wird.

hustbaer schrieb:

Und genau das geht unter Windows NICHT.

geht alles. es gibt ein paar realtime extensions für win. guckst du internet suchmaschinen: 'windows RTX' oder sowas...