DVB-C Qualität - QAM 256

Zitat

Original von Dr. Seltsam
hört sich gut an
wenn das klappt, sollte es ins hg kommen. Wegen der fehlenden Resonanz auf der ML: das brauchst Du nicht persönlich nehmen, es ist erstaunlich, was da alles im Raum stehen bleibt. Wenn`s eine klare Verbesserung bringt, sollten alle Nutzer an die ML mailen und die Integration einfordern.

Kannst Du Dir eine Konstellation vorstellen, bei der der Patch nachteilige Auswirkungen haben könnte?

Die Frage ist, ob es
a) wirklich klappt (d.h. für einen nennenswerte Zahl von Leuten, die derzeit Probleme haben)
b) nicht bei anderen Probleme verursacht.

Ich habe den Patch gesehen. Da ich keine solche Karte habe und der Patch nicht "offensichtlich korrekt" ist, erwarte ich, daß sich andere mit entsprechender HW dazu äußern. Also z.B.
- Hatte noch nie Probleme, funktioniert jedoch auch mit Patch.
- Patch löst meine Probleme mit QAM256.
- Empfang ist mit Patch schlechter.
- usw.

Wenn es hier wirklich um ein Timing-Problem geht, dann kratzt der Patch nur an der Oberfläche des Problems. Der Demod muß sich auch mit reduzierter I2C-Geschwindigkeit programmieren lassen. (Werden evtl. Register in der falschen Reihenfolge beschrieben?)

Ich kann nicht einfach Voodoo-Code in den Treiber integrieren.
Wenn es ein Timing-Problem ist: Haben evtl. sogar Kernel-Optionen (HZ=100/250/1000, preemptible Kernel) Einfluß auf das Verhalten?

CU
Oliver

Also, ich habe jetzt den Test Kernel vom Doc. verwendet. Ich habe jetzt auf allen Kanälen (qam256) fast ein Bild. Vorher war über qam256 gar nichts zu machen und jetzt habe ich zumindest schon mal ein Bild. Das umschalten klappt auch problemlos und das bild ist gleich da.
Leider liefert femon keine vernünftigen Daten. Ich vermute es liegt an der TT. Da bei den anderen Sendern auch nichts Vernünftiges an Werten ruas wirft.
Das Bild ist immer gleich gut bzw. gleich schlecht, unabhängig von der Frequenz. Also auch bei 113 Mhz.
Ich vermute mal, dass ich jetzt mit einem Verstärker etwas erreichen könnte.

Zitat

Original von UFO

Wenn es hier wirklich um ein Timing-Problem geht, dann kratzt der Patch nur an der Oberfläche des Problems. Der Demod muß sich auch mit reduzierter I2C-Geschwindigkeit programmieren lassen. (Werden evtl. Register in der falschen Reihenfolge beschrieben?)

Genaugenommen geht es um zwei Probleme:

Problem 1:
Irgendetwas stimmt nicht mit der Initialisierung vom Demodulator (falsche Reihenfolge, Timing zeitkritisch, ..). Das läßt sich nur mit Hilfe der Spec vom stv0297 klären.

Problem2:
Das Timeout- bzw. Busy-Handling in der I2C-Routine vom SAA7146 ist etwas 'schräg'. Das Timout nach dem beschreiben des Transferregisters ist immer 10ms lang, unabhängig von der programmierten Geschwindigkeit. Dabei wird das Statusregister am Anfang 20 mal alle 10us gepollt und danach alle 1ms (unabhängig von der Geschwindigkeit). Bei der normalen Geschwindigkeit dauert der Transfer ca. 100us und bei halbierter ca. 200us. Bei halbierter Geschwindigkeit wird bei ca. der Hälfte der Schreibzugriffe eine Wartepause von 1ms angehängt. Das kürzere Pollingintervall ist auch noch stärker last- und laufzeitabhängig. Das führt dazu, daß auf QAM256 Kanäle synchronisiert werden kann, wenn der PC unter 'Last' läuft. Vermutlich haben langsamere PCs auch weniger Probleme.

Zitat

Ich kann nicht einfach Voodoo-Code in den Treiber integrieren.

Das soll ja auch so nicht unbedingt in den Treiber rein. Bisher sind es zwei (mittlerweile drei) Fälle, wo das Sync/Lock Problem aufgetreten ist, und wo der Patch hilft.

Gruß
e9hack

Zitat

Original von e9hack

Genaugenommen geht es um zwei Probleme:

Problem 1:
Irgendetwas stimmt nicht mit der Initialisierung vom Demodulator (falsche Reihenfolge, Timing zeitkritisch, ..). Das läßt sich nur mit Hilfe der Spec vom stv0297 klären.

Da die Spec wohl nicht zu bekommen ist, bleibt nur, den I2C-Bus unter Windows zu sniffen...

Zitat

Problem2:
Das Timeout- bzw. Busy-Handling in der I2C-Routine vom SAA7146 ist etwas 'schräg'. Das Timout nach dem beschreiben des Transferregisters ist immer 10ms lang, unabhängig von der programmierten Geschwindigkeit.

Der 10ms-Timeout ist imho unkritisch, denn der Upload sollte praktisch sofort erfolgen.

Zitat

Dabei wird das Statusregister am Anfang 20 mal alle 10us gepollt und danach alle 1ms (unabhängig von der Geschwindigkeit). Bei der normalen Geschwindigkeit dauert der Transfer ca. 100us und bei halbierter ca. 200us. Bei halbierter Geschwindigkeit wird bei ca. der Hälfte der Schreibzugriffe eine Wartepause von 1ms angehängt.

Dieser Code ist allerdings suboptimal. Was passiert, wenn man es probehalber mal so macht?

if (short_delay)
                                udelay(10);
                        else
                                msleep(1);

Unsauber ist auch, daß saa7146_i2c_status bei jedem Schleifendurchlauf zweimal aufgerufen wird...

Zitat

Das kürzere Pollingintervall ist auch noch stärker last- und laufzeitabhängig. Das führt dazu, daß auf QAM256 Kanäle synchronisiert werden kann, wenn der PC unter 'Last' läuft. Vermutlich haben langsamere PCs auch weniger Probleme.

Na ja, udelay macht busy-waiting in einer Schleife. Dies ist zwangsläufig lastabhängig. Jeder Interrupt, Taskswitch etc. verlängert das Intervall...

Unter Last wird bei halbierter Geschwindigkeit das 20x10us-Intervall vermutlich so gedehnt, daß der 1ms-Fall nicht auftritt. Dadurch wird der Zugriff insgesamt schneller...

CU
Oliver

Nur noch mal so zur Info.
Bei mir in der Wohnung wird das Kabel vom Büro über das Schlafzimmer in das Wohnzimmer durchgeschleift. Da ich natürlich im Büro am probieren bin. Habe ich hier das "stärkste" Signal.
Da hier ja auch schon die Empfehlung von lngen Kabeln kam, habe ich einfach mal den VDR ins Wohnzimmer gestellt und siehe da ein fast Störungsfreies Bild.
Den Rest sollte ich mit einem Rauschfilter oder wie sich das ding nennt eigentlich in den Griff bekommen. Fazit: Mein VDR läuft jetzt mit der Modulation des Treibers.
Vielen Dank an den Doc.

Zitat

Original von UFO

Da die Spec wohl nicht zu bekommen ist, bleibt nur, den I2C-Bus unter Windows zu sniffen...

Ich habe beim TT Treiber unter Windows belauscht, was er vom/zum SAA7146 liest/schreibt. Die Initialisierung des Demodulators bzw. der AGC vom STV0297 ist nicht so viel anders. Da hat vermutlich schon mal jemand gesnifft. Wenn ich die Unterschiede einbaue, bleibt das Problem bestehen. Erst das Erhöhen der I2C-Bus-Geschwindigkeit hilft.

Zitat

Dieser Code ist allerdings suboptimal. Was passiert, wenn man es probehalber mal so macht?

Code

if (short_delay)
                                udelay(10);
                        else
                                msleep(1);

Das hilft genauso wie das Erhöhen der I2C-Bus-Geschwindigkeit.

Da der Tuner über den STV0297 als Gate vom I2C-Bus abgekoppelt ist, würde ich jedoch meine Variante vorziehen. Das Polling läßt sich ganz vermeiden, wenn der I2C-Transfer im Interruptmodus vom SAA7146 läuft.

Gruß
e9hack

Zitat

Original von e9hack

Das hilft genauso wie das Erhöhen der I2C-Bus-Geschwindigkeit.

Aha! Also liegt das Problem doch in Wirklichkeit darin, daß bei reduzierter Geschwindigkeit die Delays in den SAA7146-I2C-Routinen aus dem Ruder laufen. Dies ist ein grundsätzliches Problem im saa7146-Treiber!

Zitat

Da der Tuner über den STV0297 als Gate vom I2C-Bus abgekoppelt ist, würde ich jedoch meine Variante vorziehen.

Diese dynamische Geschwindigkeitsumschaltung erzeugt bei mir Bauchschmerzen. Es ist nicht vorgesehen, die Bitrate dynamisch zu ändern. Dies verursacht möglicherweise subtile Reentrancy-Probleme. Man muß _unbedingt_ sicherstellen, daß immer nur genau ein Prozeß "Bitrate setzen/I2C-Zugriff durchführen/Bitrate zurücksetzen" kann (-> Semaphor, Spinlock o.ä.). Müßte man sich sehr genau ansehen.
Aber warum kompliziert, wenn's auch einfach geht?

Btw, imho ist verdächtig, daß die Bitrate halbiert werden mußte. Dies deutet entweder auf ein schlechtes Kartenlayout (Störungen auf dem I2C-Bus) oder einen weiteren obskuren Bug hin.

Zitat

Das Polling läßt sich ganz vermeiden, wenn der I2C-Transfer im Interruptmodus vom SAA7146 läuft.

Wenn Du den Interrupt-Modus zum Laufen bekommst, bin ich sofort dafür. Iirc hat mal jemand behauptet, es würde bei den FF-Karten nicht funktionieren....

CU
Oliver

Zitat

Original von UFO
Btw, imho ist verdächtig, daß die Bitrate halbiert werden mußte. Dies deutet entweder auf ein schlechtes Kartenlayout (Störungen auf dem I2C-Bus) oder einen weiteren obskuren Bug hin.

Der PLL-Chip im Tuner (TDA6404?) kann laut Spec nur 150kHz. Da ist der Standartwert von 275kHz zu viel. Daher kommt die Halbierung.

Gruß
e9hack

Zitat

Original von e9hack

Der PLL-Chip im Tuner (TDA6404?) kann laut Spec nur 150kHz. Da ist der Standartwert von 275kHz zu viel. Daher kommt die Halbierung.

Oops - ok.

Zitat

Dabei wird das Statusregister am Anfang 20 mal alle 10us gepollt und danach alle 1ms (unabhängig von der Geschwindigkeit). Bei der normalen Geschwindigkeit dauert der Transfer ca. 100us und bei halbierter ca. 200us. Bei halbierter Geschwindigkeit wird bei ca. der Hälfte der Schreibzugriffe eine Wartepause von 1ms angehängt.

Btw, wie hast Du die Zeiten gemessen?

Auf meinem - relativ langsamen - PIII-System wird mit DVB-S-Karten udelay(10) nur 2-3 mal aufgerufen.
Rechnerisch entspricht 275kHz 3,6us Periodendauer, bei 137,5kHz also 7,2us pro Bit. Damit 200us nicht ausreichen, muß der Demod also auch noch den I2C-Zugriff verlangsamen, oder?

CU
Oliver

Zitat

Original von UFO

Btw, wie hast Du die Zeiten gemessen?

Ich habe keine realen Zeiten gemessen. Ich habe einen zweiten Counter eingebaut, der die Aufrufe von msleep() in der Schleife mitzählt und dann beide Zähler am Ende per printk() ausgegeben.

Zitat

Auf meinem - relativ langsamen - PIII-System wird mit DVB-S-Karten udelay(10) nur 2-3 mal aufgerufen.
Rechnerisch entspricht 275kHz 3,6us Periodendauer, bei 137,5kHz also 7,2us pro Bit. Damit 200us nicht ausreichen, muß der Demod also auch noch den I2C-Zugriff verlangsamen, oder?

Der SAA7146 kann per Registerzugriff maximal 3 Byte übertragen. Das ergibt mindestens 3 x 9 + 2 Takte = 210us bei 137,5kHz. Die 2 zusätzlichen Takte sind für Start/Stop. Möglicherweise werden noch Wartetakte zwischen den einzelnen Bytes eingeschoben. So wie es aussieht, bremst ein NOP auch um 9 Takte. Ein 1 Byte Lesezugriff überträgt 2 x 2 Byte, ein Schreibzugriff 1 x 3 Byte. Bei mir rennt ein Athlon64-3500.

Gruß
e9hack

Zitat

Original von e9hack

Ich habe keine realen Zeiten gemessen. Ich habe einen zweiten Counter eingebaut, der die Aufrufe von msleep() in der Schleife mitzählt und dann beide Zähler am Ende per printk() ausgegeben.

Ok.

Zitat

Der SAA7146 kann per Registerzugriff maximal 3 Byte übertragen. Das ergibt mindestens 3 x 9 + 2 Takte = 210us bei 137,5kHz. Die 2 zusätzlichen Takte sind für Start/Stop. Möglicherweise werden noch Wartetakte zwischen den einzelnen Bytes eingeschoben. So wie es aussieht, bremst ein NOP auch um 9 Takte. Ein 1 Byte Lesezugriff überträgt 2 x 2 Byte, ein Schreibzugriff 1 x 3 Byte. Bei mir rennt ein Athlon64-3500.

Hm, offenbar ist meine Kiste so langsam, daß sie nicht so viele delays braucht. Dies würde auch erklären, warum es mit schnelleren Maschinen eher Probleme gibt.

Wie wäre es mit folgendem Patch?

diff -r 1743615a44e1 linux/drivers/media/common/saa7146_i2c.c
--- a/linux/drivers/media/common/saa7146_i2c.c  Thu Oct 19 13:17:43 2006 +0200
+++ b/linux/drivers/media/common/saa7146_i2c.c  Thu Oct 26 02:40:05 2006 +0200
@@ -218,11 +218,9 @@ static int saa7146_i2c_writeout(struct s
                }
                /* wait until we get a transfer done or error */
                timeout = jiffies + HZ/100 + 1; /* 10ms */
+               /* first read usually delivers bogus results... */
+               saa7146_i2c_status(dev);
                while(1) {
-                       /**
-                        *  first read usually delivers bogus results...
-                        */
-                       saa7146_i2c_status(dev);
                        status = saa7146_i2c_status(dev);
                        if ((status & 0x3) != 1)
                                break;
@@ -233,10 +231,10 @@ static int saa7146_i2c_writeout(struct s
                                DEB_I2C(("saa7146_i2c_writeout: timed out waiting for end of xfer\n"));
                                return -EIO;
                        }
-                       if ((++trial < 20) && short_delay)
+                       if (++trial < 50 && short_delay)
                                udelay(10);
                        else
-                       msleep(1);
+                               msleep(1);
                }
        }

Das Verschieben des Dummy-Zugriffes aus der Schleife reduziert die Zahl der I/O-Zugriffe.

CU
Oliver

Zitat

Original von UFO

Wie wäre es mit folgendem Patch?

Diff

diff -r 1743615a44e1 linux/drivers/media/common/saa7146_i2c.c
--- a/linux/drivers/media/common/saa7146_i2c.c  Thu Oct 19 13:17:43 2006 +0200
+++ b/linux/drivers/media/common/saa7146_i2c.c  Thu Oct 26 02:40:05 2006 +0200
@@ -218,11 +218,9 @@ static int saa7146_i2c_writeout(struct s
                }
                /* wait until we get a transfer done or error */
                timeout = jiffies + HZ/100 + 1; /* 10ms */
+               /* first read usually delivers bogus results... */
+               saa7146_i2c_status(dev);
                while(1) {
-                       /**
-                        *  first read usually delivers bogus results...
-                        */
-                       saa7146_i2c_status(dev);
                        status = saa7146_i2c_status(dev);
                        if ((status & 0x3) != 1)
                                break;
@@ -233,10 +231,10 @@ static int saa7146_i2c_writeout(struct s
                                DEB_I2C(("saa7146_i2c_writeout: timed out waiting for end of xfer\n"));
                                return -EIO;
                        }
-                       if ((++trial < 20) && short_delay)
+                       if (++trial < 50 && short_delay)
                                udelay(10);
                        else
-                       msleep(1);
+                               msleep(1);
                }
        }

Alles anzeigen

Das Verschieben des Dummy-Zugriffes aus der Schleife reduziert die Zahl der I/O-Zugriffe.

Ich habe vor einer reichlichen Woche die Abbruchgrenze auf 100 hoch gesetzt. Das läuft ohne Probleme. Die 50 sollte aber auch reichen, da ja der kritische Wert bei ca. 20 liegt.

Ich habe auch die IRQ-Variante probiert. Da hing der VDR nach 3..4 mal zappen. Im Log stand irgendeine Timeout-Fehlermeldung. Ich denke mal, daß die I2C-Routine auf den falschen Interrupt fom SAA7146 reagiert hat.

Gruß
e9hack

Zitat

Original von e9hack

Ich habe vor einer reichlichen Woche die Abbruchgrenze auf 100 hoch gesetzt. Das läuft ohne Probleme. Die 50 sollte aber auch reichen, da ja der kritische Wert bei ca. 20 liegt.

Dann machen wir das so.

@all:
Könnt ihr bestätigen, daß die QAM256-Problematik dadurch entschärft wird? Oder gibt's da noch weitere Probleme?

Zitat

Ich habe auch die IRQ-Variante probiert. Da hing der VDR nach 3..4 mal zappen. Im Log stand irgendeine Timeout-Fehlermeldung. Ich denke mal, daß die I2C-Routine auf den falschen Interrupt fom SAA7146 reagiert hat.

Ich bin nicht sicher, ob der Interrupt-Code überhaupt jemals funktioniert hat.
Wenn Du es hinbekommst, wäre diese Variante natürlich vorzuziehen...

CU
Oliver

Kann ich den Sinn des Patches derart zusammenfassen: Er verbessert das Tunen von Qam256-Kanälen auf TT 2300 DVBc-Kanälen?

Wie sieht es mit der Empfangsqualität (BER/UNC) mit und ohne Patch aus?

arghgra

P.S.: Kann leider nicht testen, da sich keine 2300 in meinem Besitz findet.

Zitat

Original von arghgra
Kann ich den Sinn des Patches derart zusammenfassen: Er verbessert das Tunen von Qam256-Kanälen auf TT 2300 DVBc-Kanälen?

Ich würde die Funktion mal so zusammenfassen:

1) Bei langsamen PCs mit TT-2300C ändert sich nichts.
2) Bei schnelleren PCs mit TT-2300C, bei denen QAM256 bisher nicht empfangbar war, ermöglicht der Patch das Synchronisieren des Demodulators.

Der Patch verbessert prinzipiell nichts, wenn das Signal zu schlecht ist (Pegel oder Störabstand).

Zitat

Wie sieht es mit der Empfangsqualität (BER/UNC) mit und ohne Patch aus?

Der Patch hat darauf keinen Einfluß. Damit BER/UNC bei Karten mit STV0297 überhaupt Werte liefert, ist ein weiterer Patch notwendig.

Gruß
e9hack

Zitat

Original von UFO

Ich bin nicht sicher, ob der Interrupt-Code überhaupt jemals funktioniert hat.
Wenn Du es hinbekommst, wäre diese Variante natürlich vorzuziehen...

So wies aussieht, müssen nur die Zugriffe auf IER und IEN vom SAA7146 per Spinlock interruptfest gemacht werden. Dann bleibt der VDR beim zappen nicht mehr hängen. Aufnehmen scheint auch zu funktionieren.

Gruß
e9hack

Zitat

Der Patch verbessert prinzipiell nichts, wenn das Signal zu schlecht ist (Pegel oder Störabstand).

Diese Aussage ist eben relativ ...

Aber worum es mir eigentlich geht: Technotrend hat zumindest einen Treiberpatch für Budget-Karten nachgelegt, der deren Empfangsverhalten für Qam256 verbessert (verbessern soll). Für FF-Karten soll es wohl auch was geben - ich konnte jedoch keine neue Treiberversion identifizieren (alles aus dem Announcement aus dem dvbshop-Supportfurom).

Deshalb stellt sich mir die Frage: Wie bekommen wir Kontakt zu den Technotrend-Treiber-Entwicklern, dass wir diese Verbesserungen auch für den Linux-Treiber nutzen können.
Da ja ein Hauptentwickler der Linux-Treiber bei Hauppauge zu arbeiten scheint, frage ich mich, ob das vielleicht ein Weg wäre ...

Just my ideas ....

arghgra

Zitat

Original von arghgra

Diese Aussage ist eben relativ ...

Aber worum es mir eigentlich geht: Technotrend hat zumindest einen Treiberpatch für Budget-Karten nachgelegt, der deren Empfangsverhalten für Qam256 verbessert (verbessern soll). Für FF-Karten soll es wohl auch was geben - ich konnte jedoch keine neue Treiberversion identifizieren (alles aus dem Announcement aus dem dvbshop-Supportfurom).

Es gibt keinen Treiber-Patch von Technotrend für QAM256. Technotrend hat lediglich eine Ini-Datei geändert, damit QAM256 in der Auswahl der Sendersuche erscheint. Was da nachgetragen wurde, konnte man auch selber ändern, da alle nötigen Infos in der Ini-Datei dokumentiert sind.

Gruß
e9hack

Zitat

Original von e9hack

Es gibt keinen Treiber-Patch von Technotrend für QAM256. Technotrend hat lediglich eine Ini-Datei geändert, damit QAM256 in der Auswahl der Sendersuche erscheint. Was da nachgetragen wurde, konnte man auch selber ändern, da alle nötigen Infos in der Ini-Datei dokumentiert sind.

Gruß
e9hack

Ouch - das war alles?

Nunja: vielleicht kriegen wir ja trotzdem nochmal Infos von denen.

arghgra

Zitat

Original von e9hack

Der Patch hat darauf keinen Einfluß. Damit BER/UNC bei Karten mit STV0297 überhaupt Werte liefert, ist ein weiterer Patch notwendig.

Sorry, wenn Patches ins HG rein sollen, brauchen wir ein "Signed-off-by:" vom Patch-Autor. Außerdem wäre eine englische Patch-Beschreibung nicht schlecht. Dies gilt nun mal für alle Patches, die in den Kernel rein sollen.

Also bitte auf der ML posten mit
- Patch-Beschreibung und
- Signed-off-by.

CU
Oliver