Hallo, ist es möglich, in Windows einen thread vom Scheduling auszuschließen? Ich möchte ein zeitkritisches Programm laufen lassen, dass sehr schnell antworten können muss (in Kooperation mit einer Grafikkarte). Wenn es möglich wäre, einen Kern explizit für diesen Thread zu reservieren, wäre das das Beste. Kennt da jemand etwas?
yaro schrieb: > Wenn es > möglich wäre, einen Kern explizit für diesen Thread zu reservieren, wäre > das das Beste. dann mach das doch. Gehe jeden Process durch und setze die Process Affinität so das eine CPU frei wird. Dann setzt du bei deinem Thread die Affinität so das diese CPU genutzt wird. Er wird zwar weiterhin über das Scheduling laufen, aber andes geht es meines wissens nicht. Wenn du dazu noch die Prio auf höchste stufe setze, muss das doch reichen.
yaro schrieb: > ist es möglich, in Windows einen thread vom Scheduling auszuschließen? Das Scheduling ist doch dafür verantwortlich, dass mehrere Programme gleichzeitig laufen. Ich kann mir nicht vorstellen, dass man das einen Prozess bzw. Thread nur auf einen Kern laufen lassen kann. yaro schrieb: > Ich möchte ein zeitkritisches Programm laufen lassen, dass sehr schnell > antworten können muss (in Kooperation mit einer Grafikkarte). Was verstehst Du unter zeitkritisch? Wie viel ist zu berechnen?
yaro schrieb: > ist es möglich, in Windows einen thread vom Scheduling auszuschließen? Windows hat ein recht umfangreiches Prioritätskonzept. Ein Thread mit höchster Echtzeitpriorität muss sich also allenfalls mit einem ebensolchen Kollegen rumärgern. http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx
DasGanze wirc so eh nie laufen. Man sollte dann einen harten Realtimekernel fuer Windows kaufen. Das letzte Mal, als ich mich darueber informierte, kostete der um die 30k. Was guenstig ist im Vergleich zur Zeit, die man noch hinterherwirft. Erst mal die Frage, weshalb es denn ein PC sein muss.
Rufe SuspendThread auf und dein Thread wird nie wieder Rechenzeit vom Scheduler bekommen.
>Windows hat ein recht umfangreiches Prioritätskonzept. Ein Thread mit >höchster Echtzeitpriorität muss sich also allenfalls mit einem >ebensolchen Kollegen rumärgern. Ja, windows hat dieses Konzept, aber als Benutzer (das schließt auch den Admin ein!) kann man einem Prozess keine "Echtzeit"-Prio verpassen, auch wenn die höchste Prio-Stufe, die man vergeben kann, so heißt! Ein Prozess kann keine Prio höher 15 erreichen, bzw kann keine höhere prio manuell vergeben werden, da die höheren Prio-Stufen reserviert sind (system interrupts, etc!). Sollte soweit auch klar sein. Wenn ein vom User gestarteter Prozess eine höhere Prio hat, als system prozesse, wie soll das system dann im zweifells falle reagieren, wenn es selbst ja keine cpu-zeit mehr bekommt, weil da so'n dummer user prozess die cpu blockiert?! Selbst wenn die basis-prio sehr hoch ist, und das priorityboosting/aging zuschlägt, so kann diese gewisse magische grenze der Prio-stufen nicht überschritten werden! (sofern man nicht selber in den windows-kernel eingreift, und das dürfte eher schwer werden) >dass sehr schnell antworten können muss was heißt das? das was für uns menschen "sehr schnell" ist, das sind für eine moderne cpu äonen wo sie sich langweilt. Einen prozess vom scheduling auszunehmen macht keinen sinn, da dem Prozess ja CPU-Zeit zugeteilt werden muss. Und ich bezweifel das du in der Lage bist die Zeit zu berechnen, die dein Prozess braucht. Es ist möglich einen Prozesse auf einen einzelnen CPU-Kern "fest zu nageln", was aber lediglich bedeutet das der Prozess ausschließlich von diesem Kern ausgeführt wird, was aber nicht bedeutet das dieser cpu-kern nichts anderes macht! Das einzige was man hier dann an zeit sparen würde, wäre das die synchro mit threads, die sonst auf anderen kernen ausgeführt werden, entfällt. Ansonsten dürfte dieses vorgehen eher zu einer (im gesamten betrachtet) verlangsamung führen.
yaro schrieb: > Ich möchte ein zeitkritisches Programm laufen lassen, dass sehr schnell > antworten können muss Dann wirst du wohl einen Kernel Mode Interrupt Service schreiben müssen. Von der User-Seite aus ist das was du möchtest mit gutem Grund ausgeschlossen. Gruss Reinhard
@ yaro
bitte mal Zeitkritisch definieren..
sonst ist das nur "herum raten"
(letztens hat sogar mal einer das einlesen von der seriellen
Schnittstelle als "Zeitkritisch" bezeichnet...)
Nachtrag:
>Thread zu reservieren
der thread macht dann was ?
Daten Pollen..
oder auch was "anstrengendes" (video analysieren)
Allenfalls sollte man zeitkritische Dinge auf eigene Hardware auslagern. Worum geht es denn ?
Danke schonmal für die Antworten, auch wenn sie etwas demotivieren. Es geht um Bildverarbeitung auf einer Grafikkarte mit CUDA. Zeitkritisch heißt bei mir, dass ich innerhalb von ca. 5µs reagieren muss, um einen Benefit zu ziehen. Einige Verarbeitungen sind auf einem massiv parallelen Prozessor nicht optimal und sollten auf die große CPU ausgelagert werden. Das Schedulig zieht einem da ohne echtzeit Betriebssystem aber wohl einen Strich durch die Rechnung. Wenn der Thread erst eingewechselt werden muss, können Millisekunden vergehen, was viel zu viel ist. Da nehme ich lieber die unvorteilhafte Berechnung auf der Grafikkarte inkauf, bei der ich mir aber sicher sein kann, dass sie jedes mal in ähnlicher Zeit ausgeführt wird. Ich werde es trotzdem mal mit höherer Prozesspriorität versuchen. Weiß jemand, ob man sie auuch aus dem Programm heraus ändern kann? Gruß, Yaro
nur so interessehalber ca. 5µs da kann, auch eine aktuelle, CPU gerade mal ein paar (wenige) 1000 befehle ausführen..?? das kann dann ja kein "großes" bild sein, was bearbeitet wird?
nachtrag: für den ganzen prozess: HANDLE hThread = GetCurrentThread(void); SetThreadPriority(hThread, THREAD_PRIORITY_TIME_CRITICAL); vielleicht? den "wichten" thread dann noch zusätzlich (aber das sollte ja kein problem sein..)
Danke schön, werde das mal probieren! 5µs sind immerhin ca. 10.000 Takte. Da die heutigen Prozessoren superlinear sind, können in jedem Takt mehrere Befehle in die Pipelines geschoben werden, sodass sich die Zahl vervielfacht. Ich führe eine normierte Korrelation im umkreis von +-10 pixeln um eine Position durch. Bekomme also ein Bild mit 21*21 Pixeln raus, bei dem ich die Stelle mit dem höchsten Wert heraussuchen will. Eigentlich ist das eher was für die CPU und müsste in weniger als 1µs fertig sein.
hab ehrlich absolut keine Ahnung von CUDA usw. würde mir deshalb ein "spezialisierteres" forum suchen..? >Bekomme also ein Bild mit 21*21 Pixeln raus, bei dem ich >die Stelle mit dem höchsten Wert heraussuchen will. ist das nicht IDEAL für CUDA??? das kann man doch bestens Parallel verarbeiten auf 3 oder 7 Zeilen aufteilen jeder dieser teile liefert den höchsten wert und die Position zurück.
Auch wenn die GPU eventuell schneller ist, kann ich mir bei den wenigen daten schon vorstellen das die Transferzeit in und von der GPU zu lange dauert. In welcher Form kommen denn die Daten in den PC und wie erfolgt dann die ausgabe?
Noch kommen die Daten nicht in Echtzeit in den PC, soll aber irgendwann auch so laufen. Momentan sind sie im Arbeitsspeicher. Die Daten befinden sich schon auf der GPU, wenn ich das 21*21 Bild habe. Ich korreliere zwei größere Bilder mit der GPU und dies ist das Ergebnis. Auf der GPU können verschiedene Threads (abhängig davon, von welchem Prozessor sie ausgeführt werden) nur sehr schlecht kommunizieren, sodass man u.U. die Aufgabe mit insgesammt nur 32 von 448 Kernen lösen muss. Es ist wahrscheinlich immer noch sehr schnell, reizt die Geschwindigkeit aber eben nicht aus. Der Transport der Daten von der Grafikkarte auf den Arbeitsspeicher verläuft mit ca 8GBit/s per DMA, sodass sie in weniger als 1µs da sind. Ich werde versuchen, für die GPU noch andere Arbeit zu finden, damit ich die CPU parallel nutze. Das wäre am effektivsten.
> Noch kommen die Daten nicht in Echtzeit in den PC
Definiere doch bitte erstmal "Echtzeit",...
Schonmal überlegt einen anderen Algorithmus zu nehmen, der vllt.
schneller ist?! Vllt. mal in eine andere richtung denken und nicht
zwingend auf dem Weg beharren, von dem Du meinst, das du ihn gehen
musst?!
Und Wer setzt überhaupt die Grenzwerte, von denen du meinst das du sie
einhalten musst?
Yaro schrieb: > Der Transport der Daten von der Grafikkarte auf den > Arbeitsspeicher verläuft mit ca 8GBit/s per DMA, sodass sie in weniger > als 1µs da sind. rechnerisch schon, aber es muss auch der Treiber und die Anwendung davon erfahren. Außerdem gibt es bei den paar Byte noch Overhead auf dem Bus.
>Ich korreliere zwei größere Bilder mit der GPU und dies ist das >Ergebnis. auch wenn ich es (so) nicht 100% verstehe was du genau machst, aber es sollte doch recht einfach möglich sein, während man dieses "korreliere" macht, sich den "hellsten" punkt zu merken...
Yaro schrieb: > Ich werde versuchen, für die GPU noch andere Arbeit zu finden, damit ich > die CPU parallel nutze. Das wäre am effektivsten. Das ist schon eine etwas seltsame Art zu programmieren. Aber ich kann dich beruhigen: GPUs sind es durchaus gewohnt, die meiste Zeit arbeitslos zu sein. Gruss Reinhard
Peter II schrieb: > rechnerisch schon, aber es muss auch der Treiber und die Anwendung davon > erfahren. Außerdem gibt es bei den paar Byte noch Overhead auf dem Bus. Jop, da hast du völlig Recht. Hab mal eben gemessen, der gesammte Kopiervorgang dauert 4µs. Davon sind ca. 2µs das Anstoßen des Kopiervorgangs und 2µs das Kopieren selbst. Der throughput ist dabei nur ca. 800MB/s, weil es so wenig Daten sind (1723KB), sodass die volle Geschwindigkeit nicht ausgereizt werden kann. Kaj schrieb: > Definiere doch bitte erstmal "Echtzeit",... Echtzeit bedeutet, dass jede 5ms ein neues Bild reinkommt. Kaj schrieb: > Schonmal überlegt einen anderen Algorithmus zu nehmen, der vllt. > schneller ist?! Vllt. mal in eine andere richtung denken und nicht > zwingend auf dem Weg beharren, von dem Du meinst, das du ihn gehen > musst?! Versuche ich ständig =) Robert L. schrieb: > auch wenn ich es (so) nicht 100% verstehe was du genau machst, aber es > sollte doch recht einfach möglich sein, während man dieses "korreliere" > macht, sich den "hellsten" punkt zu merken... Das ist echt gut! Es lässt sich zwar nicht zu 100% so einfach machen, aber ich kann das 21*21 Bild recht einfach auf ein 1*14 Bild bringen, mit dem ich dann weiterarbeite. Vielen Dank für die Idee. Reinhard Kern schrieb: > Yaro schrieb: >> Ich werde versuchen, für die GPU noch andere Arbeit zu finden, damit ich >> die CPU parallel nutze. Das wäre am effektivsten. > > Das ist schon eine etwas seltsame Art zu programmieren. Aber ich kann > dich beruhigen: GPUs sind es durchaus gewohnt, die meiste Zeit > arbeitslos zu sein. Es ist so, dass die GPU diese Arbeit trotzdem irgendwann ausführen muss. Wenn ich die Lücke fülle, spare ich mir später Ausführungszeit. Und mal ehrlich, findest du es nicht auch befridigender, wenn die Hardware sinnvoll arbeitet statt brach zu liegen?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.