Performance Events mit 20Khz
-
Hallo Leute,
ich habe eine Gerät, welches mit Daten/Event im 20Khz takt schickt. Hierzu habe ich eine C++ SDK über diese
verbinde ich mich mit dem Gerät , registriere eine Callback Funktion, und starte das die event.Ich bekomme so alle 50microsecs eine eventt mit daten... so schön und gut.
nun würde ich aber diese API in .NEt core verwendet, und muss auf PInvoke bzw. CLI zurückgreifen... aber ich FRAGE mich wird das funktionieren von der Performance her. so dass ich quasi in .net auch all3 50microsec eine event bekommen!?
Die Maschine auf der das läuft: CPU i7-8700T (6 Core), 32GB ram Win10 IoT!
Grund weshalb ich das in .Net core machen möchte liegt ,darin da ich da schon viele komponenten haben die ich verwenden möchte.
Also was meint ihr soll ich doch lieber in C++ bleiben, oder ist das möglich mit Cli bzw. PInvoke!?
Danke schonmal
-
@SoIntMan Wie wichtig ist denn das exakte Timing? Weil in .Net kann dir der garbage collector ebenwelches immer mal zerschießen. Ansonsten dauert das hin und her zwischen managed und unmanaged natürlich etwas Zeit. Ob zuviel musst du selber wissen.
-
@SoIntMan sagte in Performance Events mit 20Khz:
Ich bekomme so alle 50microsecs eine eventt mit daten... so schön und gut.
Oh je, das ist keine kleine Aufgabe. Ich würde da eher .NET sein lassen und mich mit der Treiberentwicklung beschäfigten.
Überlege doch mal, dein Prozess wird 20.000 mal in der Sekunde aufgerufen. Das ist eine Menge Holz. Ein printf Aufruf innerhalb der Callback Funktion könnte da schon zu einer 100% Prozessorauslastunge führen.
Warum benötigst du einen solchen hohen Takt? Was passiert wenn du einen Takt verpasst?
-
@Tyrdal sagte in Performance Events mit 20Khz:
@SoIntMan Wie wichtig ist denn das exakte Timing? Weil in .Net kann dir der garbage collector ebenwelches immer mal zerschießen. Ansonsten dauert das hin und her zwischen managed und unmanaged natürlich etwas Zeit. Ob zuviel musst du selber wissen.
Servus @Tyrdal danke für die Antwort. Ja das mit dem GC habe ich auch schon gedacht. Die Frage ist ob die "Zeit" > 50 microsecunden sein wird.
Ich könnte auf der c++ seite auch die events chunken und dann so das callback interval rüber in c# verkleinden.. hmm.. zeitstempel sind bei den frames mit dabei.. es geht erstmal um datenaufzeichnung zur späteren auswertungn "harte" echtzeit ist nicht gefordert.
-
@Quiche-Lorraine sagte in Performance Events mit 20Khz:
Oh je, das ist keine kleine Aufgabe. Ich würde da eher .NET sein lassen und mich mit der Treiberentwicklung beschäfigten.
Überlege doch mal, dein Prozess wird 20.000 mal in der Sekunde aufgerufen. Das ist eine Menge Holz. Ein printf Aufruf innerhalb der Callback Funktion könnte da schon zu einer 100% Prozessorauslastunge führen.
Warum benötigst du einen solchen hohen Takt? Was passiert wenn du einen Takt verpasst?Das sind sehr gute Fragen;) soweit ich mit der Evaluierung bin, sehe ich dass frames in der strategiy fire-and-forget gasenden werden.. is die Callback funktion blockiert. gehen die anderen verloren.. das Gerät puffert NICHT..
Der Takt gibt mir das Gerät vor, allerdings lässt sich das evtl runterdrehen... im produktionsmodus allerding müssen die daten in quasi realtime gestreamt werden.. um Auswertungen zu machen, und feedback zu geben
-
Definiere quasi-realtime. Wie viel Latenz ist vertretbar?
Und über welche Schnittstelle bekommst du die Daten? Serielle Schnittstelle? ...?Was die 50us angeht: das ist viel viel zu kurz für .NET und auch viel zu kurz für off-the-shelf PC hardware im Allgemeinen. 1-2ms mit 99.99% Trefferquote kann man auf normalen PCs vermutlich noch halbwegs gut hinbekommen. Aber nicht 50us. Und schon doppelt und dreifach nicht im Usermode.
Die Art und Weise wie man das normalerweise löst ist dass man eine Schnittstelle verwendet die puffert. z.B. ne serielle Schnittstelle mit ner entsprechend grossen hardware FIFO. Der Kernelmode Treiber liest die Daten dann von der Hardware und schiebt sie in einen grösseren RAM Puffer. Und von dort kann man sie dann gemütlich in grösseren Stücken vom Usermode Programm aus lesen.
Wenn die damit erreichbare Latenz zu hoch ist, dann sollte man vermutlich von PC auf was anderes wechseln. Eine Möglichkeit wäre ein SoC ARM System. Mit dem passenden SoC und Kernel kann man da viel geringere worst-case Latenzen rausholen als aus nem PC. Also z.B. irgendeinen Raspberry Pi/Zero/Pico mit passendem RTOS Kernel.
-
@hustbaer sagte in Performance Events mit 20Khz:
Definiere quasi-realtime. Wie viel Latenz ist vertretbar?
Und über welche Schnittstelle bekommst du die Daten? Serielle Schnittstelle? ...?
Was die 50us angeht: das ist viel viel zu kurz für .NET und auch viel zu kurz für off-the-shelf PC hardware im Allgemeinen. 1-2ms mit 99.99% Trefferquote kann man auf normalen PCs vermutlich noch halbwegs gut hinbekommen. Aber nicht 50us. Und schon doppelt und dreifach nicht im Usermode.
Die Art und Weise wie man das normalerweise löst ist dass man eine Schnittstelle verwendet die puffert. z.B. ne serielle Schnittstelle mit ner entsprechend grossen hardware FIFO. Der Kernelmode Treiber liest die Daten dann von der Hardware und schiebt sie in einen grösseren RAM Puffer. Und von dort kann man sie dann gemütlich in grösseren Stücken vom Usermode Programm aus lesen.
Wenn die damit erreichbare Latenz zu hoch ist, dann sollte man vermutlich von PC auf was anderes wechseln. Eine Möglichkeit wäre ein SoC ARM System. Mit dem passenden SoC und Kernel kann man da viel geringere worst-case Latenzen rausholen als aus nem PC. Also z.B. irgendeinen Raspberry Pi/Zero/Pico mit passendem RTOS Kernel.Hallo Hustbaer,
ja der begriff "real-time" kann relativiert werden, wenn ich die daten puffere und dann alles 1-2ms weiter gebe ist auch kein problem. Im Endeffekt bauch ich über den Daumen gepeilt, alle 25ms ein Datenpaket .
Die Daten kommen über USB3, die API liefert mir eben eine vebindung zu dem gerät und ich hänge mein callback dran.. nicht mit kernelmode und Harder FIFO..
d.h. ich muss ein fifo oder ringpuffer schreien und die daten dann holen oder über eine enkoppelten 2 ms timer weiter geben.. noch keine ahnung..
aber OK, d.h. die events direkt cli/ in die .NET welt relayen is wohl dann keine Gute idee.. aber würde ich die frames in blpcke sammel und jede ms weitergeben , wäre erfolgsversprechener!?
-
@SoIntMan sagte in Performance Events mit 20Khz:
ja der begriff "real-time" kann relativiert werden, wenn ich die daten puffere und dann alles 1-2ms weiter gebe ist auch kein problem. Im Endeffekt bauch ich über den Daumen gepeilt, alle 25ms ein Datenpaket .
Nochmal die Frage: Dürfen Pakete verloren gehen? Was passiert wenn z.B. 50ms lang Pakete verloren gehen?
-
@Quiche-Lorraine sagte in Performance Events mit 20Khz:
Nochmal die Frage: Dürfen Pakete verloren gehen? Was passiert wenn z.B. 50ms lang Pakete verloren gehen?
wenn ich in dem callback ein blockierend call mache, und wieder weiter laufen lasse, queued er nichts .. d.h. es geht was verloren., ob das schlimm ist kann ich jetzt noch nich sagen;) alles dünnes eis noch,)
-
@SoIntMan sagte in Performance Events mit 20Khz:
wenn ich in dem callback ein blockierend call mache, und wieder weiter laufen lasse, queued er nichts .. d.h. es geht was verloren., ob das schlimm ist kann ich jetzt noch nich sagen;) alles dünnes eis noch,)
Kommt mir jetzt komisch vor. Mit USB sollte es eigentlich kein Problem sein die Daten irgendwo im Kernel gepuffert zu lassen und dann ein paar ms später abzuholen.
-
@hustbaer sagte in Performance Events mit 20Khz:
Kommt mir jetzt komisch vor. Mit USB sollte es eigentlich kein Problem sein die Daten irgendwo im Kernel gepuffert zu lassen und dann ein paar ms später abzuholen.
Hey hustbaer, das ist gefährliches halbwissen von mir (momentan). Das Geräte und des entsprechende USB treiber werden installiert, über eine mit gelieferte SDK kann ich dann sowas machen wie (pseudo):
void MyCallback(const Data* x) { // her daten ~1,5KB alle 50microsec } int main() { Device x; x.AddCallback(MyCallback); x.start(); ... }Ich muss mich da noch bissel einlesen, vll. puffern die hersteller die daten ja auch .. ich hab aber keinen telegramzähler,
daten x enthalten einen relativen timestamp (0 ab start) in microsec "long long".
-
Vielleicht einfach mal beim Hersteller nachfragen. Wenn das Ding so schnell Daten schickt, werdet ihr sicher nicht die einzigen Kunden sein die da Sorgen haben dass Pakete gedroppt werden wenn das Programm mal für ein paar ms steht.
