[VFKD] FB6591C -> DVB-C -> HD-Filme werden mit Störungen wiedergegeben/aufgezeichnet

[Flole]

Keine Ahnung, aber da es sich wie gesagt um eine Race Condition handelt macht es auch mehr Sinn das ganze auf Assembler Ebene zu betrachten, allein schon aufgrund der Optimierung die ein Compiler vielleicht (und in diesem Falle ganz sicher) macht.

[robert_s]

Keine Ahnung, aber da es sich wie gesagt um eine Race Condition handelt macht es auch mehr Sinn das ganze auf Assembler Ebene zu betrachten, allein schon aufgrund der Optimierung die ein Compiler vielleicht (und in diesem Falle ganz sicher) macht.

Nein. Race Conditions entstehen nicht alleine durch den Compiler. Der Fehler liegt dann schon im Hochsprachen-Code, der nicht "thread-safe" ist, und kann und muss auch auf dieser Ebene behoben werden.

Wobei es bei der Fritz!Box mit ihren "zwei Herzen" sicherlich etwas komplexer ist, Abläufe zwischen beiden zu synchronisieren.

[Flole]

Nicht alleine (zumindest wenn man von einem fehlerfreien Compiler ausgeht), aber wenn man zum Beispiel nicht ausreichend lange wartet bis eine Variable gesetzt wurde und nur minimal zu schnell ist dann wäre die Optimierung da eher kontraproduktiv. Je nachdem wie das nun optimiert wird hat das unterschiedliche Auswirkungen, im C-Code würde man dort keinerlei Unterschiede sehen, im Assembly hingegen schon. Der eigentliche Fehler liegt da natürlich schon woanders, aber wenn er nicht sichtbar/spürbar wird dann wäre das wohl für alle auch in Ordnung. Somit ist es zumindest für mich einfacher das Assembly zu betrachten.

[robert_s]

Nicht alleine (zumindest wenn man von einem fehlerfreien Compiler ausgeht), aber wenn man zum Beispiel nicht ausreichend lange wartet bis eine Variable gesetzt wurde und nur minimal zu schnell ist dann wäre die Optimierung da eher kontraproduktiv. Je nachdem wie das nun optimiert wird hat das unterschiedliche Auswirkungen, im C-Code würde man dort keinerlei Unterschiede sehen, im Assembly hingegen schon.

Was Du beschreibst, ist schlichtweg fehlerhafter Code. Wenn der Programmcode schon so geschrieben ist, dass er es dem Zufall überlässt, ob eine Variable gesetzt wurde oder nicht, dann ist der buggy. Wenn der Programmcode nicht für eine korrekte Synchronisation einer Variable bei Zugriffen aus unterschiedlichen Thread sorgt, ist der buggy - es gibt das Keyword "volatile" aus einem Grund.

Der eigentliche Fehler liegt da natürlich schon woanders, aber wenn er nicht sichtbar/spürbar wird dann wäre das wohl für alle auch in Ordnung. Somit ist es zumindest für mich einfacher das Assembly zu betrachten.

Ins Assembly muss man eigentlich nur schauen, wenn ein Compiler- oder Hardwarefehler vorliegt, ansonsten kann ein findiger Programmierer den Bug auch schon im Hochsprachencode erkennen.

Als ich letztes mal auf Assembly-Ebene runter musste, war das, als eine Variable, die 1x auf 1 gesetzt wurde, beim Vergleich sporadisch als 0 gelesen wurde. Das war schon beeindruckend im Debugger, direkt nach dem mov-Befehl gestoppt, im Register steht eine 0, der Debugger liest aus der im mov-Befehl zuvor in dieses Register gelesenen Speicheradresse eine 1... Schließlich stellt jemand fest, dass die Speicheradresse im Dual-Port Memory lag, dessen SoC-Schnittstelle so konfiguriert war, dass der nur eine begrenzte Anzahl Zyklen auf eine Möglichkeit zum Auslesen einer Speicheradresse wartete, und danach sang- und klanglos eine 0 zurückgegeben wurde. Am Ende war's ein 1-Zeilen-Fix, um ein fehlendes Zurücksetzen eines #pragma für die Speicherzuordnung zu ergänzen, aber der Weg dahin war sehr aufwändig

[Flole]

Das was du schreibst mag ja alles stimmen wenn man normales Multithreading macht, aber wenn man keine Möglichkeit hat zu wissen ob eine Instruktion nun fertig ist oder nicht dann bleibt eben nur noch das hoffen (oder vorsichtshalber sehr lange warten, im Kernel aber generell eine blöde Idee). Wir haben es immerhin mit 2 CPUs zutun die hier zusammenarbeiten. Wenn man also weiß, dass es im schlimmsten Fall x Taktzyklen dauert dann kann man das im Assembler einfach auszählen und fertig (zumindest wenn man weiß, dass man nie yield()ed und nichts die Ausführung unterbricht). Im C Code geht das nicht so einfach, zumal man da nicht weiß was die Optimierung noch zaubern wird. Ich würde dann aber vermutlich das ganze direkt in Assembler schreiben anstelle da rum zu probieren wie der Compiler nun das was ich möchte in Assembler bastelt.

Ins Assembly muss man eigentlich nur schauen, wenn ein Compiler- oder Hardwarefehler vorliegt, ansonsten kann ein findiger Programmierer den Bug auch schon im Hochsprachencode erkennen.

Der in diesem Fall vermutlich auch Spuren von Assembler enthalten kann Teilweise sieht das zumindest so aus als ob der Ursprung keine C Instruktionen waren.

Aber wenn du es als "auf Assembly-Ebene runter müssen" ansiehst dann versuchst du das wohl eher zu vermeiden. Ich sehe das nicht so, zumal ich ja nicht mal weiß ob ein eventuell zur Verfügung gestellter Quellcode auch exakt das ist was dort nun wirklich ausgeführt wird. Dann lieber den Code im Disassembler anschauen und direkt Bescheid wissen was los ist und was da nun tatsächlich ausgeführt wird. Offensichtlich ist das auch erfolgsversprechend denn ich weiß ja wo der Fehler liegt, AVM scheinbar noch nicht oder zumindest haben sie es noch nicht zu nem Fix geschafft.

[robert_s]

Das was du schreibst mag ja alles stimmen wenn man normales Multithreading macht, aber wenn man keine Möglichkeit hat zu wissen ob eine Instruktion nun fertig ist oder nicht dann bleibt eben nur noch das hoffen (oder vorsichtshalber sehr lange warten, im Kernel aber generell eine blöde Idee).

Das ist schlichtweg ein grundfalscher Programmieransatz. Es gibt selbstverständlich auch im Kernel die geeigneten Mittel zur Synchronisation. Wer da anfängt, nach dem "Prinzip Hoffnung" Taktzyklen zu zählen (oder gar zu schätzen oder warum nicht gleich aus dem Horoskop zu lesen?), ist irgendwo im letzten Jahrtausend steckengeblieben. Das ist etwas für spannende Retro-Basteleien oder schön anspruchsvollen Denksport, aber nicht Produktentwicklung im 21. Jahrhundert.

Und man kann auch mit "einfachen Mitteln" wasserdicht synchronisieren. Ich habe einst mal den SAA7146A in eine "Bridge" für den MPEG-2 Transport verwandelt, der den Datenstrom per Scatter-Gather DMA auch in nicht zusammenhängende Speicherbereiche schreiben konnte, direkt in den Benutzerspeicher. Und das mit Markierung, welche Slots schon geschrieben wurden, sodass der Chip automatisch aufhörte, wenn die Host-CPU es mal versäumen sollte, den nächsten Speicherbereich rechtzeitig einzuprogrammieren. Und das obwohl der SAA7146A wirklich nur sehr primitive Befehle beherrschte.

Banalere Entwickler haben mit dem SAA7146A einfach einen Ringpuffer verwendet, und dann musste die Host-CPU eben zusehen, dass sie den rechtzeitig ausliest, und konnte nicht einmal feststellen, ob sie Daten schon verpasst hatten.

Aber wenn du es als "auf Assembly-Ebene runter müssen" ansiehst dann versuchst du das wohl eher zu vermeiden. Ich sehe das nicht so, zumal ich ja nicht mal weiß ob ein eventuell zur Verfügung gestellter Quellcode auch exakt das ist was dort nun wirklich ausgeführt wird. Dann lieber den Code im Disassembler anschauen

Das habe ich früher auch gerne gemacht, aber inzwischen ist dieser Schritt schlichtweg nicht mehr nötig, weil man bei "sauberer" Programmierung solche Fehler auch schon in der Hochsprache sieht. Und schmutziger "wird schon klappen" Code kriegt von mir einfach eine -2 im Code Review

[Flole]

Das ist schlichtweg ein grundfalscher Programmieransatz. Es gibt selbstverständlich auch im Kernel die geeigneten Mittel zur Synchronisation. Wer da anfängt, nach dem "Prinzip Hoffnung" Taktzyklen zu zählen (oder gar zu schätzen oder warum nicht gleich aus dem Horoskop zu lesen?), ist irgendwo im letzten Jahrtausend steckengeblieben. Das ist etwas für spannende Retro-Basteleien oder schön anspruchsvollen Denksport, aber nicht Produktentwicklung im 21. Jahrhundert.

Ja im Kernel schon, aber wenn man die CPU anweist etwas zu tun (bzw. an eine andere CPU weiterzugeben) und du keine Rückmeldung bekommst wann das fertig ist dann nützt dir die tollste Kernel Synchronisation nichts Da kannst du nur beim Hersteller vorstellig werden und ein Microcode Update anfragen, was aber in diesem Falle dann dafür sorgen würde das eine Instruktion sich völlig anders verhält als auf allen anderen CPUs und somit wohl nicht kommen wird. Nicht mal mit einem aktiven Warten kannst du da irgendwas erreichen, du weißt nämlich nicht ob die Daten die dort stehen nun aktuell oder alt sind.

Wenn man das geschickt anstellt dann kriegt man das mit Instruktionen zählen und geschickt anordnen maximal performant hin, alles andere würde die Performance schmälern (was vermutlich bei AVM nicht wirklich schlimm wäre, für mich aber schon). So kriege ich über 250Mbit/s an DVB-C Traffic verarbeitet (mehr hab ich noch nicht getestet) und als RTP versandt, da ist man für alles was man an Synchronisation (oder auch sonstigen Instruktionen) so einsparen kann sehr dankbar Jetzt kann man natürlich sagen, dass es sich beim Einsparen von wenigen Instruktionen eher um gefühlten als um tatsächlichen Performancegewinn handelt, aber wenn man schon alles andere auf maximale Performance ausgelegt hat dann kann man so noch ein kleines bisschen mehr herauskitzeln. Für AVM ist das alles natürlich irrelevant, alleine schon weil 4*55Mbit/s nicht größer als 250 ist, und nicht zuletzt weil man da viel größere Schwächen drin hat wo man deutlich mehr Performance verliert.

Ganz so falsch kann mein Ansatz also nicht sein Aber mal schauen wie AVM das Problem löst, vielleicht übersehe ich ja eine Möglichkeit die deinen Ansatz wiederspiegelt.... So langsam könnte man das ja mal reparieren.....

[robert_s]

Ja im Kernel schon, aber wenn man die CPU anweist etwas zu tun (bzw. an eine andere CPU weiterzugeben) und du keine Rückmeldung bekommst wann das fertig ist dann

...taugt die API ganz offensichtlich nichts.

nützt dir die tollste Kernel Synchronisation nichts Da kannst du nur beim Hersteller vorstellig werden und ein Microcode Update anfragen, was aber in diesem Falle dann dafür sorgen würde das eine Instruktion sich völlig anders verhält als auf allen anderen CPUs und somit wohl nicht kommen wird. Nicht mal mit einem aktiven Warten kannst du da irgendwas erreichen, du weißt nämlich nicht ob die Daten die dort stehen nun aktuell oder alt sind.

Sprich: Die Funktion ist von Hardware oder SDK her unbrauchbar, weil die Funktion nicht zuverlässig umsetzbar ist.

Wenn man das geschickt anstellt dann kriegt man das mit Instruktionen zählen und geschickt anordnen maximal performant hin,

Das wage ich zu bezweifeln. Bei modernen CPUs, die je nach branch prediction und cache hit/miss unterschiedliches Timing aufweisen, kriegst Du das doch nie und nimmer zuverlässig hin. Da kann man ja noch nicht mal alle Permutationen abtesten, weil es unendlich viele sind. Das ist doch alles nur "Prinzip Hoffnung" Murks, der nicht mehr als empirisch getestet werden kann.

Ganz so falsch kann mein Ansatz also nicht sein

Ich würde sagen, der ist grundfalsch.

[Karl.]

Die letzten Beiträge sind offtopic.

Back to the Topic:
Kann jemand, der mit der 7.23 @ 6660 das Problem aus dem Eingangspost hat, die 7.24 testen und schauen, ob das Problem weg ist?

viewtopic.php?p=688651#p688651

ftp.avm.de/firmware/6660/4424247314/FRITZ.Box_6660_Cable-07.24.image

[Flole]

Nein es ist nicht Offtopic über die Lösung des Problems zu sprechen bzw. darüber ob und wie man das überhaupt verhindern kann...... Man kann ja auch zu dem Ergebnis kommen, dass es gar nicht lösbar ist (bzw. die API/das Interface komplett unbenutzbar ist), und dann kannst du lange auf ein Update warten was es behebt.

Der Code der 6660 wurde anscheinend nicht wirklich verändert, insofern dürfte das Problem zumindest nicht bewusst gelöst worden sein. Es kann natürlich immer versehentlich durch irgendwelche Nebeneffekte gelöst werden, und dann auch später wieder auftauchen.