Support Request #7789
closedStreamTime acting in a Playback Config
Description
Support Anfrage:
Ich habe eine Config mit einem HD-Player und einem Filter, in dem ein cKernelTimer mit 10 ms timeout läuft.
In der Timer-Methode wird geprüft, wie viel Zeit zwischen dem aktuellen und dem letzten Aufruf vergangen ist.
Da kommt öfters mal 0 als Differenz raus, was für den darin laufenden Algo ein Problem darstellt.
Das DAT-File beinhaltet mehrere Streams, die schnellste Update-Rate eines Streams beträgt im Mittel 10 ms.
Der HD-Player aktualisiert die StreamTime nur, wenn er ein MediaSample verschickt. (Richtig?)
Die Datenrate der Streams schwankt aber leicht.
Wenn zwischen zwei Updates nur 9 ms vergangen sind, reicht das natürlich nicht um den cKernelTimer erneut zu triggern.
Danach kommt dann z.B. ein neues Update 11 ms später, die StreamTime wird direkt um 20 ms erhöht und der cKernelTimer direkt zweimal hintereinander getriggert. Zweimal mit der gleichen StreamTime.
Gibt es eine vernünftige Lösung, dass der cKernelTimer trotzdem zwischendrin getriggert wird?
Ich hatte mal aus einem anderen DAT-File einen Stream mit höherer UpdateRate reingemerged. Das löst das Problem, ich betrachte das allerdings nicht als 'vernünftige Lösung' ;)
Lösung:
Die Stream Time wird diskret vor jedem verschickten Sample erhöht. Der Kernel wird synchron über diesen Zeitsprung informiert und überprüft dann welche Timer in der Zeitspanne hätten laufen sollen. Leider hat er dafür nur den letzen und den neuen Zeitstempel zur Verfügung. Er kann also leider nur die Anzahl der notwendigen Timer-Aufrufe feststellen. Selbst wenn er dabei die Zeit interpolieren würde, kann er die Stream Time nicht mehr in die Vergangenheit zurücksetzen, damit ein pClock->GetStreamTime() im Anwender Code den passenden Zeitstempel liefert.
Also ja, die Genauigkeit, der Timer hängt von der maximalen Datenrate im DAT-File ab. (Das ist ein Punkt der in ADTF 3 besser gelöst wird, da hier auch die Trigger von Verarbeitungsketten mit aufgezeichnet werden).
Leider bleiben nur die zwei Möglichkeiten:
- zum einen den Algorithmus so anzupassen, dass eine Zeitdauer zwischen den Aufrufen von 0 kein Problem darstellt (das könnte theoretisch auch im Live-Betrieb auftreten wenn der OS-Kernel durch die Last nicht nachkommt)
- so wie beschrieben höherfrequente Datenströme mit aufzeichnen/einfügen. Da oft ein CAN oder Flexray Bus mit aufgezeichnet wird, kommt das Problem in anderen Use-Cases nicht so sehr zum tragen.
Zusätzlich wurde das Produktticket ACORE-10107 Playback: Improve Timer Handling erstellt.
Siehe Kommentar 14
Updated by hidden almost 5 years ago
- Project changed from Public Support to 5
- Status changed from New to Customer Feedback Required
- Topic set to ADTF::DAT
- Customer set to BOSCH
Hallo Stephan,
kannst Du uns bitte noch die verwendete ADTF Version nennen?
Updated by hidden almost 5 years ago
Win 64 2.13.3
Korrektur: die streamtime wird vermutlich nicht direkt um 20 ms erhöht, sondern erst um 9 und dann um 11. Ansonsten sollten alle Angaben stimmen.
Updated by hidden almost 5 years ago
- Status changed from Customer Feedback Required to In Progress
- Department set to CC-DA/ESU
- Affected Products ADTF 2.13.3 added
- Platform Windows 7 64bit added
Updated by hidden almost 5 years ago
Hallo,
die Stream Time wird diskret vor jedem verschickten Sample erhöht. Der Kernel wird synchron über diesen Zeitsprung informiert und überprüft dann welche Timer in der Zeitspanne hätten laufen sollen. Leider hat er dafür nur den letzen und den neuen Zeitstempel zur Verfügung. Er kann also leider nur die Anzahl der notwendigen Timer-Aufrufe feststellen. Selbst wenn er dabei die Zeit interpolieren würde, kann er die Stream Time nicht mehr in die Vergangenheit zurücksetzen, damit ein pClock->GetStreamTime() im Anwender Code den passenden Zeitstempel liefert.
Also ja, die Genauigkeit, der Timer hängt von der maximalen Datenrate im DAT-File ab. (Das ist ein Punkt der in ADTF 3 besser gelöst wird, da hier auch die Trigger von Verarbeitungsketten mit aufgezeichnet werden).
Leider bleiben nur die zwei Möglichkeiten:
- zum einen den Algorithmus so anzupassen, dass eine Zeitdauer zwischen den Aufrufen von 0 kein Problem darstellt (das könnte theoretisch auch im Live-Betrieb auftreten wenn der OS-Kernel durch die Last nicht nachkommt)
- so wie beschrieben höherfrequente Datenströme mit aufzeichnen/einfügen. Da oft ein CAN oder Flexray Bus mit aufgezeichnet wird, kommt das Problem in anderen Use-Cases nicht so sehr zum tragen.
Es tut mir leid, dass es da im Moment in ADTF 2 keine besseren Möglichkeiten gibt.
Grüße,
Martin
Updated by hidden almost 5 years ago
Der Vollständigkeit halber: als unzureichende Alternative gibt es noch cCyclicThread.
Der läuft aber komplett losgelößt von der Stream Time (also vom Playbackspeed). Aber auch dort wird GetStreamTime() im Falle, dass zwei Sample mehr als einen Timer-Intervall auseinander liegen zweimal die gleiche Zeit zurückliefern, die diese ja nur diskret erhöht wird (auch da gibts in ADTF 3 neue Möglichkeiten zur Interpolation :-)).
Updated by hidden almost 5 years ago
- Status changed from In Progress to Customer Feedback Required
Updated by hidden almost 5 years ago
Hallo Stephan Stühmer,
wir haben kein Feedback erhalten.
Bitte bis spätestens 19.07. um ein Feedback.
Danke und Gruß
Matthias
Updated by hidden almost 5 years ago
Hallo,
Danke für die ausführliche Antwort.
Ein Umstieg auf ADTF3 ist zur Laufzeit des Projektes leider nicht möglich.
Werde also einen der Workarounds bemühen müssen.
Ein Gedanke noch: wir spielen Messdaten aus dem Fahrzeug ab, eine Aufzeichnung des Timer/Task-Schemas ist also auch mit ADTF3 nicht möglich, weil der Algo nicht mitläuft.
Könnte man evtl. die StreamTime Erhöhung vom Player abfangen, ermitteln wann die Timer/Threads dran wären, die StreamTime auf die ermittelten Zeitpunkte erhöhen und die Timer/Threads damit aufrufen, bevor auch die neuen Samples verschickt werden? Dann vor dem zweiten Timer-Aufruf die Samples losschicken. Klar, kein Update für ADTF2, aber vielleicht könnte so etwas in ADTF3 landen….
Ich habe hier nämlich auch noch nen Filter, der CAN-Busdaten einliest und auch mit nem 10 ms cKernelTimer den Algo aufruft. Der produziert immer unterschiedliche Ergebnisse. Wenn ich ihn statt mit Timer auf eine 10 ms zyklische Botschaft triggere, dann produziert er immer die gleichen Ausgangsdaten. Irgendwie scheint das Senden der MediaSamples und das Aufrufen des Timers nicht deterministisch…
Mit freundlichen Grüßen / Best regards
Stephan Stuehmer
Updated by hidden almost 5 years ago
- Status changed from Customer Feedback Required to In Progress
Updated by hidden over 4 years ago
- Product Issue Numbers set to ACORE-10107
Hallo Stephan Stuehmer,
ja, so ein Mechanismus ist sicher sinnvoll und auch schon mal angedacht worden. Im Moment passt es nicht ganz zur Architektur und Trennung von Player und Kernel Service. Dazu ist eine etwas gröbere Anpassung nötig und ich habe dafür das Ticket ACORE-10107 erstellt.
Deterministisch ist das Verhalten im Playback Fall aber auch jetzt schon, nur halt mit einer eventuellen Zeitdifferenz von 0. Aber die Timeraufrufe sollten jedes mal exakt in der gleichen Abfolge stattfinden.
Wann wird denn der cKernelTimer erzeugt, in Start() oder in Init()? In ADTF 2 übernimmt der Player das Streamtime-Handling erst nach Init(StageGraphReady). Wenn Ihr Filter vorher schon einen Timer registriert, beginnt der mit der Systemzeit zu laufen und wird dann "umgehangen", da ist aber der Intervallstartpunkt abhängig von der Systemzeit.
Grüße,
Martin
Updated by hidden over 4 years ago
- Status changed from In Progress to Customer Feedback Required
Updated by hidden over 4 years ago
Hallo Stephan Stuehmer,
ist die Information von Martin (13.08.) angekommen?
Bitte um ein kurzes Feedback
Danke und Gruß
Matthias
Updated by hidden over 4 years ago
Hallo Stephan Stuehmer,
bitte um Feedback bis zum 28.08.
Danach würden wir das Ticket sonst schließen.
Gruß
Matthias
Updated by hidden over 4 years ago
- Subject changed from StreamTime Vehalten in einer Playback Config to StreamTime acting in a Playback Config
- Description updated (diff)
- Status changed from Customer Feedback Required to To Be Closed
- Resolution set to No Customer Feedback
- Product Issue Numbers changed from ACORE-10107 to https://www.cip.audi.de/jira/browse/ACORE-10107
Updated by hidden almost 4 years ago
- Project changed from 5 to Public Support
- Private changed from Yes to No
- Support Level changed from 2nd Level to 3rd Level
Updated by hidden almost 4 years ago
- Status changed from To Be Closed to Closed