Hallo Leute, ich habe von einem Bekannten erfahren (beruflich arbeitet er in der Thematik), dass diese auf einem Windows System einen Kern isolieren und darauf eine Simulation laufen zu lassen. Die Isolation und Auslagerung der Applikation ist nötig, um ein Zwischenbrüllen von Windows bei Zeitkritischen Berechnungen zu verhindern -> soweit noch klar. Dass man unter Windows Kern(e) isolieren kann kenne ich auch (run -> msconfig -> Start -> erweitere Optionen), wenn gleich mir bis dato unklar war, wieso eigentlich. Die berechneten Ergebnisse werden dann von Windows abgeholt und dargestellt. Gehandelt wird dieses Zusammenspiel von der Software "Beckhoff Twincat" - gefüttert wird alles über eine ProfiBus-Schnittstelle. Auch wenn mir immer noch kein sinnvoller Einsatzzweck eingefallen ist, interessiert mich der Prozess sehr. Gerne würde ich hier experimentieren wollen - einfach nur der Neugierde wegen. Kennt jemand die Thematik und kann mir etwas mehr dazu sagen? Leider findet sich Online kaum für mich verwertbare Literatur. Ist es (mit vertretbarem Aufwand) möglich z. B. ein C-Programm auf die CPU zu laden und hier Berechnungen durchzuführen, während Windows auf den restlichen Kernen quasi parallel weiter arbeitet? Wie würde das ganz praktisch aussehen? Bitte teilt eure Gedanken mit mir...
:
Verschoben durch Moderator
Um ein Programm auszuführen brauchst du weit mehr als einen CPU Kern. Alles wird vom Betriebssystem verwaltet, deswegen sehe ich keinen Sinn darin, hier irgendwie am Betriebssystem vorbei arbeiten zu wollen. Wenn dein Programm möglichst wenig unterbrochen werden soll, dann setze die Priorität des Threads auf den höchstmöglichen Wert REALTIME_PRIORITY_CLASS. Aber wundere dich dann nicht, wenn Dateizugriffe in einer Endlos-Schleife hängen. https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadpriority
Wenn es wirklich so zeitkritisch ist: Warum Windows und kein Echtzeitbetriebssystem (QNX o.ä.)?
Sim schrieb: > ich habe von einem Bekannten erfahren (beruflich arbeitet er in der > Thematik), dass diese auf einem Windows System einen Kern isolieren und > darauf eine Simulation laufen zu lassen. Wozu das auch immer gut sein soll... > Dass man unter Windows Kern(e) isolieren kann kenne ich auch (run -> > msconfig -> Start -> erweitere Optionen), wenn gleich mir bis dato > unklar war, wieso eigentlich. Nunja, der einzige Vorteil gegenüber der kooperativeren Verfahrensweise über Prozess- und Threadprioritäten ist der (einigermaßen) garantierbare Durchsatz für die Berechnung. Ist aber auch dann noch weit jenseits von Echtzeit. Jedenfalls ohne weitere Maßnahmen. Insbesondere natürlich die ähnlich exclusive Bereitstellung des benötigten RAMs und zwar sowohl für den Code als auch für die Daten. Nur wenn beides in die jeweiligen Caches des Core paßt, kann man darauf verzichten.
Es gibt Hypervisor wie Acontis, da kann man CPUs teilen, hat dann aber zwei OS parallel laufen. In einem Windows kann man AFAIK eine CPU in einem Prozess bevorzugen, aber anderen nicht verbieten diese auch zu benutzen, hat also keinen exklusiven Zugriff. Und Realtime Prio hat seine Tücken wie Stefan schon schrieb.
Lass dich von den relativ unqualifizierten Zwischenruf nicht irritieren. Sim schrieb: > Gehandelt wird dieses Zusammenspiel von der Software "Beckhoff Twincat" > - gefüttert wird alles über eine ProfiBus-Schnittstelle. Ja, das ist eine Standardlösung für Software sps/cnc. Das ganze ist relativ einfach. TwinCat kannst du die einfach runterladen. Bei Beckhoff gibt es auch die Doku wie das programmiert wird. Ist eigentlich relativ einfach damit echtzeit zu programmieren. Nachteil: Der Task wird in fixem Abstand (z. B. 1ms) aufgerufen. Dauerhaft laufend ist damit nicht so einfach.
Twincat bringt seinen eigenen Hypervisor mit und lässt ein Realtime System parallel laufen. In dem System kommuniziert das über Beckhoffs ADS oder Ethernet mit dem Rest der Welt. Es gibt ein eigenes SDK und API, da kann nicht das Windows API benutzt werden.
Sim schrieb: > Kennt jemand die Thematik und kann mir etwas mehr dazu sagen? > Leider findet sich Online kaum für mich verwertbare Literatur. https://infosys.beckhoff.com/index.php?content=../content/1031/tc3_c/110699019.html
Stefan ⛄ F. schrieb: > Um ein Programm auszuführen brauchst du weit mehr als einen CPU Kern. > Alles wird vom Betriebssystem verwaltet, deswegen sehe ich keinen Sinn > darin, hier irgendwie am Betriebssystem vorbei arbeiten zu wollen. Naja, der Prozessor wird halt vom Systemkern nicht für "normale" Prozesse benutzt. Das kennt man unter Linux mit dem Kernelparameter "isolcpus"; nach dem Booten kann man mit taskset(1) bestimmte Prozesse an diese "freien" Kerne binden, so daß sie völlig ungestört arbeiten können (natürlich sind sie noch auf andere Ressourcen angewiesen, aber auch dafür gibt es ja andere Möglichkeiten). In bestimmten Setups kann zum Beispiel Redis für so etwas sehr dankbar sein. Und ich wüßte nicht, warum es nicht auch noch andere Anwendungsfälle geben sollte, in denen solche Techniken eine Daseinsberechtigung haben sollten.
Stefan ⛄ F. schrieb: > Wenn dein Programm möglichst wenig unterbrochen werden soll, dann setze > die Priorität des Threads auf den höchstmöglichen Wert > REALTIME_PRIORITY_CLASS. Mann kann nicht nur die Priorität zuordnen, sondern auch sagen welsche CPU verwendet werden dürfen (quasi die wo vorher gesagt wurde das Windows diese nicht von selbst nutzen soll): https://docs.microsoft.com/de-de/windows/win32/api/winbase/nf-winbase-setthreadaffinitymask https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setprocessaffinitymask
Irgend W. schrieb: > Mann kann nicht nur die Priorität zuordnen, sondern auch sagen welsche > CPU verwendet werden dürfen (quasi die wo vorher gesagt wurde das > Windows diese nicht von selbst nutzen soll): Sicher? _Weißt_ du das, oder ist das Spekulation? Weil soweit ich weiß ist genau das nicht möglich. Wenn CPU Kerne unter Windows deaktiviert werden, kennt Windows die gar nicht mehr. So als ob die gar nicht existieren. Daher können die mit Windows Mitteln nicht mehr verwendet werden. Kerne für den Sheduler zu sperren aber Weiter zu verwenden ist unter Windows (im Gegensatz zu Linux, da ist es trivial) nicht Möglich. Sollte es doch möglich sein, freue ich mich über Hinweise darauf.
Sim schrieb: > Die berechneten Ergebnisse werden dann von Windows abgeholt und > dargestellt. Dafür sind so drastische echtzeit Maßnahmen normalerweise unnötig. > Gehandelt wird dieses Zusammenspiel von der Software "Beckhoff Twincat" > - gefüttert wird alles über eine ProfiBus-Schnittstelle. Genau - Bei der zeitkritischen Kommunikation nach außen wird das Interessant. > Auch wenn mir immer noch kein sinnvoller Einsatzzweck eingefallen ist, > interessiert mich der Prozess sehr. > > Gerne würde ich hier experimentieren wollen - einfach nur der Neugierde > wegen. > > Kennt jemand die Thematik und kann mir etwas mehr dazu sagen? > Leider findet sich Online kaum für mich verwertbare Literatur. Echtzeitprogrammierung ist ein interessantes Thema. Aber ohne Anwendungsfall finde ich den Einstieg schwierig. Such also Möglichst erst mal nach dem Einsatzzweck. > Ist es (mit vertretbarem Aufwand) möglich z. B. ein C-Programm auf die > CPU zu laden und hier Berechnungen durchzuführen, während Windows auf > den restlichen Kernen quasi parallel weiter arbeitet? Wie würde das ganz > praktisch aussehen? Ja ist Möglich. Je nach Fähigkeiten und der Definition von "vertretbaren Aufwand". Ich könnte es. Aufwandsschätzung: 1-6Monate Vollzeit. Bei den Fragen die du stellst: Hänge noch eine Null hinten dran. Also eher Nein (mit vertretbarem Aufwand). Es sei denn es gibt irgendwo bereits fertigen Code dafür. Ich kenne da aber nichts. Vorgehen in etwa: - CPU Kern in Windows deaktivieren. - Treiber programieren den den C Code lädt oder enthält. - Einsprungadresse und Speichermapping herausfinden. - Den CPU Kern initialisieren(Speichermapping) - Den Code Ausführen (Einsprung wahrscheinlich per Interrupt) Jetzt fängt der Spaß so richtig an: Auf diesem Kern läuft kein Betriebssystem. Den muss man Bare Metal programmieren. Alles von Hand machen. Zum teil in Assembler. Also: - Den CPU Kern initialisieren. Kann man sich von Linux/BSD/Minix etc. abgucken. Und schon läuft das C Programm... Das nächste große Thema: Dieses Programm kann mit nichts interagieren. Keine Eingabe, keine Ausgabe, keine WIN API, nur Shared Memory. Also muss man sich eine Kommunikation per Shared Memory programmieren um mit einem Windows Treiber zu kommunizieren. Daher: Vergiss diese Variante. Ansonsten: Weg 1: Mit RT PRIORITY kann man schon sehr viel Machen. Ist relativ normale Programmierung. Weg 2: Beckhoff TwinCat. Insbesondere wenn man eh etwas in Richtung Soft SPS/Soft NC macht. - Ist kostenlos - Damit bekommt man relativ einfach seinen C/C++ Code auf einen eigenen Kern - Die Kommunikation mit der nicht-echtzeit Welt ist relativ einfach. Nachteil: - Der Task wird in einem fixen Zeitraster(z.B. alle 1ms) aufgerufen und muss auch entsprechend schnell fertig werden.
Timo W. schrieb: > Vorgehen in etwa: und genau das macht das von mir schon genannte Acontis Tool: es reserviert einen CPU Kern für ein weiteres OS für Realtime Aufgaben. Das ist aber auch da nicht dazu gedacht etwas schnell zu berechnen (das könnte eine GPU / FPGA Karte eventuell schneller), sondern um SPS Funktionalität zu bauen.
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.