av7110 übertakten...

Geht soweit ich weiss nicht, weil der Takt fest mit dem Takt des TV-Signals gekoppelt ist.

evt. geht es doch.
der prozessor hat soweit ich weiß einen eigenen takt,der streaming und signalteil einen anderen.
90 mhz und 27 mhz glaub ich.
ob es was bringt den prozessortakt zu steigern müßte man halt ausprobieren.

falls alle takte aus einem oszilator generiert werden hat shf recht.
an den 27 mhz kann man nicht drehen da aus diesem laut datenblatt u.a. die videosignale generiert werden.
möglich wäre auch noch der pci-bus als zweite taktquelle.
bedarf gibt es eigendlich nur bei der streamingwiedergabe über das mplayer-plugin weil bei hoher qualität die datenraten des mpg-layer1-streams vom lavc-encoder zu groß für eine ruckelfreie wiedergabe werden und layer2 nicht implementiert ist.
woher genau das ruckeln bei zu großen datenraten des streams kommt ist aber strittig und die meinungen darüber gehen auseinander.
ob ein übertakten des prozessors dabei irgend etwas bringen würde ist fraglich.
auf jeden fall hängt die performance bei diesem problem von pci-takt ab denn wenn man diesen variiert so verändert sich auch die ruckelgrenze bei der wiedergabe.
die beste lösung des ganzen wäre zweifelsfrei ein mpeg layer2-echtzeitencoder für mplayer aber darauf warte ich schon seit jahren vergebens.
halbherzig angekündigt war es zumindest mal.

Zitat

...falls alle takte aus einem oszilator generiert werden...

Das scheint so zu sein: Oszillator Bug auf Nexus als Ursache für ARM Boot-Fehler!?

Zitat

möglich wäre auch noch der pci-bus als zweite taktquelle

Der kommt nicht direkt zum AV7110, da hängt ein Dualport-RAM dazwischen.

Ausserdem sind alle Takte (40,5MHz, 81MHz), die ich im Datenblatt gefunden habe, ein vielfaches von 27Mhz.

Hi,

Übertakten kann man imho vergessen. Nicht der av7110 ist das Problem, sondern das DPRAM. Der ARM kann jetzt schon nicht full-speed auf dieses zugreifen, sondern muß Wait-States einlegen.

Die einzige HW-Modifikation, die imho alle Performance-Probleme schlagartig lösen würde, wäre die Verwendung des HSDI (High Speed Data Interface). Wenn man dem Datenblatt glauben kann, müßte die Datenrate für den gesamten Transponder ausreichen.

Verglichen damit ist der 4MB-Mod allerdings ein Kinderspiel. Damit müßten sich mal die HW-Expertren auseinandersetzen. IMHO wäre eine IEEE1394- oder SCSI-Anbindung die Lösung aller Probleme...

CU
Oliver

Zitat

Die einzige HW-Modifikation, die imho alle Performance-Probleme schlagartig lösen würde, wäre die Verwendung des HSDI (High Speed Data Interface). Wenn man dem Datenblatt glauben kann, müßte die Datenrate für den gesamten Transponder ausreichen.

Verglichen damit ist der 4MB-Mod allerdings ein Kinderspiel.

HW-Modifikation? Das kommt eher einem kompletten Neudesign der Karte gleich .

Die "Modifikation" ist IMHO zu gross, dass sie der Masse der FF-Besitzer helfen kann.
Einen schnelleren DPRAM aufzulöten halte ich da für realistischer.
Auf meiner Karte ist nur einer mit 20ns bestückt und Cypress hat auch 15er und 12er, da müsste auch ein kompatibler dabei sein.

Die zweite Lösung die mir noch im Kopf rumgeistert währe ein aufgebohrter Budgetpatch, bei dem der HW-Dekoder aktiv bleibt. Ich bin nur noch nicht sicher ob es machbar ist.
Btw. gibt es eigentlich irgendwo Infos zum Budgetpatch (besonders zur Hardwareseite), ausser in den Mailinglisten meine ich, die lesen sich nämlich echt zäh.

Ein CI an der FF wird dann zwar nicht mehr gehen, ich kann aber darauf verzichten, da ich ohnehin keins hab.
Und auch bei den Videodaten (für /dev/videoX) muss man wohl zumindestens mit Einschränkungen rechnen, doch auch damit könnte ich leben

Zitat

Original von SHF
Einen schnelleren DPRAM aufzulöten halte ich da für realistischer.
Auf meiner Karte ist nur einer mit 20ns bestückt und Cypress hat auch 15er und 12er, da müsste auch ein kompatibler dabei sein.

Viel würde das nicht bringen.

Wenn man schon das DPRAM austauschen möchte, dann sollte man gleich eins mit doppelter oder vierfacher Größe einbauen. Habe dazu früher schon mal was geschrieben:
[ANNOUNCE] OSD picture in picture plugin 0.0.5 (osdpip-0.0.5)
(Müßte man nochmal verifizieren.)

Zitat

Die zweite Lösung die mir noch im Kopf rumgeistert währe ein aufgebohrter Budgetpatch, bei dem der HW-Dekoder aktiv bleibt. Ich bin nur noch nicht sicher ob es machbar ist.

Ich sehe keinen Grund, wieso der HW-Decoder bei einer FF-Karte mit Budget-Patch nicht mehr funktionieren sollte. Das ist höchstens eine Frage der Treiberanpassung.

Zitat

Btw. gibt es eigentlich irgendwo Infos zum Budgetpatch (besonders zur Hardwareseite), ausser in den Mailinglisten meine ich, die lesen sich nämlich echt zäh.

http://www.linuxtv.org/downloads/budget-patch/

Zitat

Ein CI an der FF wird dann zwar nicht mehr gehen, ich kann aber darauf verzichten, da ich ohnehin keins hab.
Und auch bei den Videodaten (für /dev/videoX) muss man wohl zumindestens mit Einschränkungen rechnen, doch auch damit könnte ich leben

Wenn man sich die Daten nicht vom Tuner holt, sondern vom Treiberbaustein, der zum av7110 geht, könnte evtl. sogar das CI gehen. Mit diesen HW-Details kann sich mal jemand befassen, der CI+CAM besitzt.

CU
Oliver

Zitat

Original von UFO
http://www.linuxtv.org/downloads/budget-patch/

Danke.
Aber der Budgetpatch noch eine menge Löterei an der Karte. Ich hatte die anderen Beschreibungen so verstanden, dass die Datenleitungen schon liegen und es nur um das vsync ginge.
Ausserdem scheint der Autor auch gewisse Stabilitätsprobleme zu haben, wobei das inzwischen auch gelöst worden sein kann.

Zitat

Original von UFO
Wenn man sich die Daten nicht vom Tuner holt, sondern vom Treiberbaustein, der zum av7110 geht, könnte evtl. sogar das CI gehen. Mit diesen HW-Details kann sich mal jemand befassen, der CI+CAM besitzt.

Ich dachte der av7110 ist mit für einen Teil der Entschlüsselung zuständig. Im Datenblatt stand was von "on-chip European Common Descrambler hardware" wobei halt die Frage ist, ob die überhaupt genutzt wird.

Zitat

Original von SHF

Danke.
Aber der Budgetpatch noch eine menge Löterei an der Karte. Ich hatte die anderen Beschreibungen so verstanden, dass die Datenleitungen schon liegen und es nur um das vsync ginge.

IIRC hat mal jemand geschrieben, daß die Leitungen bei einer Rev 2.2(?) schon vorhanden sind.
Da ich so eine Karte nicht habe, kann ich das nicht bestätigen.

Zitat

Ausserdem scheint der Autor auch gewisse Stabilitätsprobleme zu haben, wobei das inzwischen auch gelöst worden sein kann.

SW-Probleme sind sicher lösbar.

Zitat

Ich dachte der av7110 ist mit für einen Teil der Entschlüsselung zuständig. Im Datenblatt stand was von "on-chip European Common Descrambler hardware" wobei halt die Frage ist, ob die überhaupt genutzt wird.

Wird nicht genutzt. Das CAM ist für die Entschlüsselung zuständig. Wenn man alsio an den dekodierten Datenstrom vom CI rankäme, könnte man ihn direkt an den saa7146 weitergeben.

CU
Oliver

Zitat

IIRC hat mal jemand geschrieben, daß die Leitungen bei einer Rev 2.2(?) schon vorhanden sind.

Ich hab' ebnen noch mal nachgeschaut, bei der 1.5 sind die mit grosser Sicherheit nicht vorhanden.

Zitat

Wird nicht genutzt. Das CAM ist für die Entschlüsselung zuständig. Wenn man alsio an den dekodierten Datenstrom vom CI rankäme, könnte man ihn direkt an den saa7146 weitergeben.

Wenn das so ist, ist es wirklich nicht schwer.
Das Signal sollte rechts an den 3 unteren Widerstandsnetzwerken anliegen, die sich links des av7110 befinden. Kontrolliert hab ich das zwar nicht, ist aber die einzige Stelle, die imho in Frage kommt.

Da bleibt dann eigentlich nur noch das Problem, wie man beide Videoports des SAA7143 gleichzeitig betreiben kann.
Mit einer Budget müsste sich das ja eigentlich probieren lassen, ohne vorher was an der Hardware ändern zu müssen.

Zitat

Original von SHF

Ich hab' ebnen noch mal nachgeschaut, bei der 1.5 sind die mit grosser Sicherheit nicht vorhanden.

Bei meinen Rev 1.3 und 2.1 gibt es die Leiterbahnen nicht.

Zitat

Wenn das so ist, ist es wirklich nicht schwer.
Das Signal sollte rechts an den 3 unteren Widerstandsnetzwerken anliegen, die sich links des av7110 befinden. Kontrolliert hab ich das zwar nicht, ist aber die einzige Stelle, die imho in Frage kommt.

Ack, dies wäre der richtige Abgreifpunkt. Hier gehen die Daten zum ARM. Sie kommen entweder vom Tuner (unteres 573 Latch) oder über die Durchkontaktierungen/Rückseite der Platine vom CI.

Zitat

Da bleibt dann eigentlich nur noch das Problem, wie man beide Videoports des SAA7143 gleichzeitig betreiben kann.

Port A wird ja nur für /dev/video gebraucht. Zur Not müßte man ihn halt abschalten. Möglicherweise geht auch beides. Jedenfalls braucht man nach dem Mod. DMA3 und BRS an Port B.

CU
Oliver

Zitat

Original von UFO
Port A wird ja nur für /dev/video gebraucht. Zur Not müßte man ihn halt abschalten.

Die Lösung wird den Athmolight, avads, fbtv, tvtime, ... Usern aber gar nicht gefallen.

Zitat

Original von UFO
Möglicherweise geht auch beides. Jedenfalls braucht man nach dem Mod. DMA3 und BRS an Port B.

Was die Auswahl beim HPS auf 8-bit Videomodes beschränkt. Sofern V4L mit solchen Daten überhaupt was anfangen kann müsste das aber zumindestens für Athmolight und avads reichen.

Die Top-Lösung währe es aber wenn man den kompletten TS irgendwie durch den HPS bekommt, ich hatte sowas ja schon mal angedacht:

Zitat

Die einzige Chance die Daten da unbeschadet durch zu bekommen sehe ich beim "Y8G (Only Y)"-Mode, bei dem nur das Luminanz-Signal (d.h. es handelt sich um ein SW-Video) ausgegeben wird.
Wenn man jedes Byte vom Tuner zwei mal hintereinander sendet müsste die Hälfte der davon, also das was man eigentlich haben will, im Video-FIFO 1 landen.

Ob das klappt müsste bei einer Budget sogar ohne Hardware-Modifikation herauszufinden sein:
Wenn man HPS und BRS gleichzeitig auf den Videoport, an dem der Tuner hängt, schaltet, müsste, wenn es geht, jedes 2. Byte, was vom BRS kommt auch vom HPS kommen.
Später braucht man nur den Takt am LLC-Pin des Videoports, von dem der HPS gespeist wird, zu verdoppeln um den kompletten TS zu bekommen.
Leider hapert es bei mir schon bei der Umsetzung des Versuches daran, wie man Stücke der beiden Datenströme gleichzeitig in je eine Datei bekommt. Für derart tief greifende Änderungen fehlt mir da einfach der Überblick.

Zitat

Original von SHF

Die Lösung wird den Athmolight, avads, fbtv, tvtime, ... Usern aber gar nicht gefallen.

Was die Auswahl beim HPS auf 8-bit Videomodes beschränkt. Sofern V4L mit solchen Daten überhaupt was anfangen kann müsste das aber zumindestens für Athmolight und avads reichen.

Ich habe nicht viel Ahnung davon, wie der Port A des SAA7146 für /dev/video eingestellt wird. Das Eingangsformat ist ja durch den av7110 vorgegeben. Außerdem habe ich keine Zeit, mich tiefer mit v4l zu beschäftigen. Das soll jemand anders machen. Meine Baustelle ist DVB und der av7110.

Zitat

Die Top-Lösung währe es aber wenn man den kompletten TS irgendwie durch den HPS bekommt, ich hatte sowas ja schon mal angedacht:

Wieso möchtest Du denn die Daten durch den HPS schicken?
Afaik ist der HPS durch /dev/video belegt. Wir brauchen den BRS, und der ist ja frei!

CU
Oliver

Zitat

Original von UFO
Hi,

Übertakten kann man imho vergessen. Nicht der av7110 ist das Problem, sondern das DPRAM. Der ARM kann jetzt schon nicht full-speed auf dieses zugreifen, sondern muß Wait-States einlegen.

Ich habe mal ein paar Zeilen Code zur Messung der Transfergeschwindigkeit eingebaut. Über das DEBI-Interface bekommt man gerade mal 6MB/s lesend und 8MB/s schreibend. Die Transferleistung des ARM vom DPRAM ins DRAM ist auch nicht brauschend, geade mal 8MB/s. Wenn man die Wait-States von 5 auf 0 setzt, werden 13MB/s draus.

Sep  4 21:59:47 very-new-darkstar kernel: ===== DEBI performance test =====
Sep  4 21:59:48 very-new-darkstar kernel: DEBI write: 8.4MB/s (blk_size=8192)
Sep  4 21:59:48 very-new-darkstar kernel: DEBI write: 8.1MB/s (blk_size=2048)
Sep  4 21:59:48 very-new-darkstar kernel: DEBI write: 7.6MB/s (blk_size=1024)
Sep  4 21:59:48 very-new-darkstar kernel: DEBI write: 6.9MB/s (blk_size=512)
Sep  4 21:59:48 very-new-darkstar kernel: DEBI write: 5.0MB/s (blk_size=188)
Sep  4 21:59:49 very-new-darkstar kernel: DEBI write: 414kB/s (blk_size=8)
Sep  4 21:59:49 very-new-darkstar kernel: DEBI read:  6.4MB/s (blk_size=8192)
Sep  4 21:59:49 very-new-darkstar kernel: DEBI read:  6.2MB/s (blk_size=2048)
Sep  4 21:59:49 very-new-darkstar kernel: DEBI read:  5.9MB/s (blk_size=1024)
Sep  4 21:59:49 very-new-darkstar kernel: DEBI read:  5.5MB/s (blk_size=512)
Sep  4 21:59:50 very-new-darkstar kernel: DEBI read:  4.2MB/s (blk_size=188)
Sep  4 21:59:50 very-new-darkstar kernel: DEBI read:  359kB/s (blk_size=8)
Sep  4 21:59:50 very-new-darkstar kernel: ===== non increment mode (not usable) =====
Sep  4 21:59:50 very-new-darkstar kernel: DEBI write: 17.2MB/s (blk_size=8192)
Sep  4 21:59:50 very-new-darkstar kernel: DEBI write: 15.7MB/s (blk_size=2048)
Sep  4 21:59:50 very-new-darkstar kernel: DEBI write: 14.2MB/s (blk_size=1024)
Sep  4 21:59:50 very-new-darkstar kernel: DEBI write: 11.3MB/s (blk_size=512)
Sep  4 21:59:50 very-new-darkstar kernel: DEBI write: 7.1MB/s (blk_size=188)
Sep  4 21:59:51 very-new-darkstar kernel: DEBI write: 392kB/s (blk_size=8)
Sep  4 21:59:51 very-new-darkstar kernel: DEBI read:  16.5MB/s (blk_size=8192)
Sep  4 21:59:51 very-new-darkstar kernel: DEBI read:  15.2MB/s (blk_size=2048)
Sep  4 21:59:51 very-new-darkstar kernel: DEBI read:  13.8MB/s (blk_size=1024)
Sep  4 21:59:51 very-new-darkstar kernel: DEBI read:  11.1MB/s (blk_size=512)
Sep  4 21:59:51 very-new-darkstar kernel: DEBI read:  7.3MB/s (blk_size=188)
Sep  4 21:59:51 very-new-darkstar kernel: DEBI read:  383kB/s (blk_size=8)
Sep  4 21:59:51 very-new-darkstar kernel: ARM copy speed (DPRAM to DRAM): 8.3MB/s

Ich habe auch die Transferrate im normalen Betrieb gemessen. Das sieht dann so aus:

Sep  4 22:05:15 very-new-darkstar kernel: DEBI rx: 938(1578)kB/s size=188/1508/3948 cnt=637/s, tx: 389(967)kB/s size=20/1762/2048 cnt=226/s
Sep  4 22:05:25 very-new-darkstar kernel: DEBI rx: 940(1518)kB/s size=188/1755/3948 cnt=548/s, tx: 481(786)kB/s size=21/1748/2048 cnt=282/s
Sep  4 22:05:35 very-new-darkstar kernel: DEBI rx: 1001(1419)kB/s size=188/1790/3948 cnt=572/s, tx: 534(1014)kB/s size=14/1775/2048 cnt=308/s
Sep  4 22:05:45 very-new-darkstar kernel: DEBI rx: 987(1417)kB/s size=188/1778/3948 cnt=568/s, tx: 499(911)kB/s size=19/1747/2048 cnt=292/s
Sep  4 22:05:55 very-new-darkstar kernel: DEBI rx: 917(1266)kB/s size=188/1655/3948 cnt=567/s, tx: 351(573)kB/s size=14/1649/2048 cnt=218/s
Sep  4 22:06:05 very-new-darkstar kernel: DEBI rx: 880(1373)kB/s size=188/1604/3948 cnt=561/s, tx: 381(720)kB/s size=10/1684/2048 cnt=232/s
Sep  4 22:06:15 very-new-darkstar kernel: DEBI rx: 968(1604)kB/s size=188/1793/3948 cnt=553/s, tx: 424(878)kB/s size=16/1711/2048 cnt=254/s
Sep  4 22:06:25 very-new-darkstar kernel: DEBI rx: 1074(1564)kB/s size=188/2016/3948 cnt=545/s, tx: 583(1070)kB/s size=15/1788/2048 cnt=334/s

Die Werte sind getrennt nach Lesen und Schreiben. Die Transferrate ist über ein Zeitintervall (hier 10sec) gemittelt. Der Wert in Klammern ist der Spitzenwert. Die Blockgrößen sind Min-, Mittel- und Max-Wert. Bis ca. 2,2MB/s Summentransferrate gibt es keine Aussetzer. Wer glaubt, während einer Aufnahme mit dem femon-Plugin die Bitrate beobachten zu müssen, tut sich nichts gutes. Das Plugin benötigt 245kB/s Sendetransferrate. Wenn man in den Grenzbereich kommt, steigt die mittlere Blockgröße beim Lesen auf >3kB an und die Interruptrate nimmt ab. Die DPRAM Adresse ist beim Lesen (bzw. Schreiben) immer gleich. Wenn der ARM weniger als die möglichen 4k abschickt, muß er immer Warten, bis der Treiber die Daten gelesen hat und den Puffer als frei markiert. Möglicherweise sollte man den Lese-Puffer in zwei Bereiche aufteilen. Wenn der Treiber Daten liest, kann der ARM bereits neue Daten in den zweiten Puffer schreiben.

Gruß
e9hack

Zitat

Original von e9hack

Ich habe mal ein paar Zeilen Code zur Messung der Transfergeschwindigkeit eingebaut. Über das DEBI-Interface bekommt man gerade mal 6MB/s lesend und 8MB/s schreibend. Die Transferleistung des ARM vom DPRAM ins DRAM ist auch nicht brauschend, geade mal 8MB/s. Wenn man die Wait-States von 5 auf 0 setzt, werden 13MB/s draus.

Das DPRAM muß mit min. 3 Wait-States betrieben werden. Weniger führen zu Bitfehlern bei der Kommunikation zw. ARM und PC. (Selbst getestet!) Das war die Ursache des sog. RTL-Bugs. Mit DRAM-Waitstates habe ich noch nicht gespielt.

Zitat

Ich habe auch die Transferrate im normalen Betrieb gemessen. Das sieht dann so aus:
Die Werte sind getrennt nach Lesen und Schreiben. Die Transferrate ist über ein Zeitintervall (hier 10sec) gemittelt. Der Wert in Klammern ist der Spitzenwert. Die Blockgrößen sind Min-, Mittel- und Max-Wert. Bis ca. 2,2MB/s Summentransferrate gibt es keine Aussetzer.

Wer glaubt, während einer Aufnahme mit dem femon-Plugin die Bitrate beobachten zu müssen, tut sich nichts gutes. Das Plugin benötigt 245kB/s Sendetransferrate.

Lol, das OSD will halt auch übertragen werden.

Zitat

Wenn man in den Grenzbereich kommt, steigt die mittlere Blockgröße beim Lesen auf >3kB an und die Interruptrate nimmt ab. Die DPRAM Adresse ist beim Lesen (bzw. Schreiben) immer gleich. Wenn der ARM weniger als die möglichen 4k abschickt, muß er immer Warten, bis der Treiber die Daten gelesen hat und den Puffer als frei markiert. Möglicherweise sollte man den Lese-Puffer in zwei Bereiche aufteilen. Wenn der Treiber Daten liest, kann der ARM bereits neue Daten in den zweiten Puffer schreiben.

In diese Richtung geht das, was ich mit einer verbesserten Pufferverwaltung erreichen möchte. Die Puffer sollen interleaved und bidirektional verwendet werden können (vgl. auch Refactoring-Thread). Ist allerdings eher etwas für lange Winterabende...

Bzgl. der Datenrate wäre der "Budget-Patch" natürlich sehr interessant:
- Der ARM braucht die zu empfangenden Daten nicht mehr durch's DPRAM zu schieben.
- Die volle Transferleistung kann für Replay und OSD eingesetzt werden.
Damit wäre der DPRAM-Flaschenhals Geschichte.

Wenn, dann sollten wir den "Budget-Patch" allerdings auch besser machen:
- einen Teiler wie auf der Budget-Karte vorsehen (RPS-Gedöns entfällt).
- Daten wie weiter oben beschrieben abgreifen -> CAM funktioniert weiterhin.

Gibt es eigentlich so etwas wie Platinenverbinder oder Flachbandkabel im SAA7146-Rastermaß?

CU
Oliver

Zitat

Original von UFO
Das DPRAM muß mit min. 3 Wait-States betrieben werden.

Das kann eigentlich nicht sein. Das DPRAM muß per Ready signalisieren, wenn die Daten bereit stehen. Es ist daher egal, ob zusätzliche Wait-States eingefügt werden oder nicht. Ich habe den Copy-Code so verändert, daß zuerst die Wait-States auf 0 gesetzt werden. Wenn es beim kopieren zu Bitfehlern gekommen wäre, hätte der ARM irgendwann Müll machen müssen.

Zitat

Lol, das OSD will halt auch übertragen werden.

Ich messe nur die Daten, die per DMA übertragen werden. Es geht daher nur um die Balken, die scheinbar als Bitmap übertragen werden.

Zitat

In diese Richtung geht das, was ich mit einer verbesserten Pufferverwaltung erreichen möchte. Die Puffer sollen interleaved und bidirektional verwendet werden können (vgl. auch Refactoring-Thread). Ist allerdings eher etwas für lange Winterabende...

Ich habe die Transfertests auch mit dem Refactoring-Treiber gemacht. Der Treiber verbessert nichts bezüglich der max. möglichen Transferraten. Der Refactoring-Treiber wird sicherlich bei 'schmalbrüstigen' Systemen helfen.

Zitat

Bzgl. der Datenrate wäre der "Budget-Patch" natürlich sehr interessant:
- Der ARM braucht die zu empfangenden Daten nicht mehr durch's DPRAM zu schieben.
- Die volle Transferleistung kann für Replay und OSD eingesetzt werden.
Damit wäre der DPRAM-Flaschenhals Geschichte.

Das ist aber nur was für Leute, die mit einem SMD tauglichen Lötkolben umgehen können.

Zitat

Gibt es eigentlich so etwas wie Platinenverbinder oder Flachbandkabel im SAA7146-Rastermaß?

Der SAA7146 hat nur 0,65mm Pin-Abstand. Da lassen sich doch locker Fädeldrähte anlöten.

Gruß
e9hack