ves1820 micro optimization

[Striper]

Hab mal ein paar kleine Änderungen am Nokia Kabeltreiber durchgeführt weil er mir bei QAM256 ein bisschen langsam war. Freundin sagt er ist nun etwas fixer beim Umschalten. Wer testen will: http://www.file-upload.net/download-139 ... t.zip.html

Ist gegen 2.4.37 kompiliert.

[rhabarber1848]

Hast Du auch einen Sourcecode-Patch?

[bellum]

Hab mal ein paar kleine Änderungen am Nokia Kabeltreiber durchgeführt weil er mir bei QAM256 ein bisschen langsam war. Freundin sagt er ist nun etwas fixer beim Umschalten. Wer testen will: http://www.file-upload.net/download-139 ... t.zip.html

Ist gegen 2.4.37 kompiliert.

Ich würde das gerne mal ausprobieren, auf meinen Nokias läuft aber noch 2.4.36.6 und außerdem habe ich die Dir auch bekannten Änderungen von http://forum.tuxbox-cvs.sourceforge.net ... 59#p343032 drin (die auch leicht Änderungen am ves1820 machen).

Kannst Du nicht mal ein diff Deiner Änderungen posten?

Gleichwohl habe ich mal versucht die Kernel-Versionen direkt in der Datei mit einem Hex Editor zu patchen (very ugly) und einen Testlauf gemacht. Das Ergebnis war aber nicht wirklich aussagekräftig, mal ging das Umschalten meklich schneller und mal hat das Umschalten 10sek gedauert und man hatte den Eindruck die Box hängt.

Ich würde das gerne noch mal auf einer sauberen basis versuchen...

Gruß bellum

[Striper]

Das diff is aus meiner SVN. Also nicht Wundern ;)
Is nix Weltbewegendes geändert worden... Nur ein Paar kleine Sachen:

Code: Alles auswählen

--- C:\DOKUME~1\striper\LOKALE~1\Temp\ves1820.c-rev848.svn004.tmp.c	Mo Jan 26 11:06:17 2009
+++ E:\_Development\trunk\testsourcen\ves1820.c	Mo Jan 26 09:56:43 2009
@@ -100,8 +100,8 @@
 	.name = "VES1820 based DVB-C frontend",
 	.type = FE_QAM,
 	.frequency_stepsize = 62500,
-	.frequency_min = 51000000,
-	.frequency_max = 858000000,
+	.frequency_min = 47000000,
+	.frequency_max = 862000000,
 	.symbol_rate_min = (XIN/2)/64,     /* SACLK/64 == (XIN/2)/64 */
 	.symbol_rate_max = (XIN/2)/4,      /* SACLK/4 */
 #if 0
@@ -119,7 +119,7 @@
 
 static u8 ves1820_inittab [] =
 {
-	0x69, 0x6A, 0x9B, 0x1A, 0x12, 0x46, 0x26, 0x1A,
+	0x69, 0x6A, 0x93, 0x1A, 0x12, 0x46, 0x26, 0x1A,
 	0x43, 0x6A, 0xAA, 0xAA, 0x1E, 0x85, 0x43, 0x20,
 	0xE0, 0x00, 0xA1, 0x00, 0x00, 0x00, 0x00, 0x00,
 	0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
@@ -144,7 +144,6 @@
 			"(reg == 0x%02x, val == 0x%02x, ret == %i)\n",
 			fe->i2c->adapter->num, __FUNCTION__, reg, data, ret);
 
-	dvb_delay(10);
 	return (ret != 1) ? -EREMOTEIO : 0;
 }
 
@@ -241,7 +240,7 @@
 	 *  check lock and toggle inversion bit if required...
 	 */
 	if (INVERSION_AUTO == inversion && !(ves1820_readreg (fe, 0x11) & 0x08)) {
-		mdelay(50);
+		mdelay(10);
 		if (!(ves1820_readreg (fe, 0x11) & 0x08)) {
 			reg0 ^= 0x20;
 			ves1820_writereg (fe, 0x00, reg0 & 0xfe);
@@ -267,7 +266,7 @@
 	ves1820_inittab[2] &= ~0x08;
 #endif
 
-	for (i=0; i<53; i++)
+	for (i = 0; i < sizeof(ves1820_inittab); i++)
                 ves1820_writereg (fe, i, ves1820_inittab[i]);
 
 	ves1820_writereg (fe, 0x34, GET_PWM(fe->data));
@@ -316,14 +315,12 @@
                 BDRI = 0xFF;
 
         SFIL = (SFIL << 4) | ves1820_inittab[0x0E];
-
         NDEC = (NDEC << 6) | ves1820_inittab[0x03];
 
         ves1820_writereg (fe, 0x03, NDEC);
         ves1820_writereg (fe, 0x0a, BDR&0xff);
         ves1820_writereg (fe, 0x0b, (BDR>> 8)&0xff);
         ves1820_writereg (fe, 0x0c, (BDR>>16)&0x3f);
-
         ves1820_writereg (fe, 0x0d, BDRI);
         ves1820_writereg (fe, 0x0e, SFIL);
 
@@ -357,7 +354,7 @@
 
 	/* yes, this speeds things up: userspace reports lock in about 8 ms
 	   instead of 500 to 1200 ms after calling FE_SET_FRONTEND. */
-	mdelay(50);
+	mdelay(10);
 
 	return 0;
 }

Bissl was is an Linux-TV angelehnt und mit den mdelays hab ich einfach rumgespielt. Sie ganz zu entfernen führt in seltenen Fällen bei mir zu Hängern beim Umschalten. Mit 10ms ist aber alles OK.

[Striper]

Und, läufts bei euch besser? Oder eh nur Makulatur?

[Striper]

...außerdem habe ich die Dir auch bekannten Änderungen von http://forum.tuxbox-cvs.sourceforge.net ... 59#p343032 drin (die auch leicht Änderungen am ves1820 machen).

bellum, hast du die Änderungen aus dem anderen Thread schon mal zusammen mit meinen getestet? Hab das gestern mal gemacht, jedoch hatte meine Box dann arge Probleme mit QAM256 Sendern. Das Umschalten dauerte tlw. 20 Sekunden lang. Nokia Kabel AVIA 500.
Liegt das an meinen Änderungen (habs ohne noch nicht getestet)?

[bellum]

bellum, hast du die Änderungen aus dem anderen Thread schon mal zusammen mit meinen getestet? Hab das gestern mal gemacht, jedoch hatte meine Box dann arge Probleme mit QAM256 Sendern. Das Umschalten dauerte tlw. 20 Sekunden lang. Nokia Kabel AVIA 500.
Liegt das an meinen Änderungen (habs ohne noch nicht getestet)?

Bin im Moment leider viel unterwegs und habe am Wochenende ebenfalls viel um die Ohren. Deshalb bin ich leider noch nicht zum Testen gekommen. Habe es aber noch im Hinterkopf und werde zu gegebener Zeit hier Feedback geben...

Please stand by...

Gruß bellum

[Striper]

Ich würde die Änderungen gern im CVS sehen. Mit meinen Mikrooptimierungen schaltet die Box einfach wesentlich schneller um. Vor allem auf QAM256 Sendern merkt man den Unterschied recht deutlich. Probleme habe ich damit absolut keine.

Schade das bisher quasi 0 Feedback kam...

[GetAway]

Du hast doch Schreibrechte.

[Striper]

Ja, aber ich möchte ungern einfach was einchecken das nicht wenigstens von zumindest einem anderen erfolgreich getestet wurde. Konkret sehe ich vor allem bei den mdelays die Gefahr das bei Leuten mit extrem miesem Empfang der Tuner nicht mehr ordentlich locked.

[PauleFoul]

Du hast doch Schreibrechte.

Jo

[rhabarber1848]

- mdelay(50);
+ mdelay(10);

Da war wohl jemand 2003 anderer Meinung: http://cvs.tuxbox-cvs.sourceforge.net/c ... 51&r2=1.52

[rhabarber1848]

- 0x69, 0x6A, 0x9B, 0x1A, 0x12, 0x46, 0x26, 0x1A,
+ 0x69, 0x6A, 0x93, 0x1A, 0x12, 0x46, 0x26, 0x1A,

Im 2.6er-Treiber sieht das so aus:

0x69, 0x6A, 0x93, 0x12, 0x12, 0x46, 0x26, 0x1A,

Was passiert, wenn Du in Deinem 2.4er-Treiber den vierten Wert änderst?

PS: Habe keine Nokia-Box, kann daher nicht selber testen.

[Striper]

- mdelay(50);
+ mdelay(10);

Da war wohl jemand 2003 anderer Meinung: http://cvs.tuxbox-cvs.sourceforge.net/c ... 51&r2=1.52

Um solch hohe Delaywerte nötig zu machen muss man imho schon wirklich extrem schlechten Empfang haben. Selbst wenn ich die mdelay's komplett raus nehme kommt es nur ganz selten vor das der tuner nicht korrekt locked.

Was passiert, wenn Du in Deinem 2.4er-Treiber den vierten Wert änderst?

Das würde ich dir nicht raten. Das ist der "Kassel/Bielefeld-Fix". IMO sollte das mal im 2.6er nachgezogen werden.

[rhabarber1848]

Das ist der "Kassel/Bielefeld-Fix". IMO sollte das mal im 2.6er nachgezogen werden

Done: http://cvs.tuxbox-cvs.sourceforge.net/c ... 2=1.53.2.5

[rhabarber1848]

- 0x69, 0x6A, 0x9B, 0x1A, 0x12, 0x46, 0x26, 0x1A,
+ 0x69, 0x6A, 0x93, 0x1A, 0x12, 0x46, 0x26, 0x1A,

http://forum.tuxbox-cvs.sourceforge.net ... 50#p348150

Die Linux TV Leute haben jedoch statt der 0x9B eine 0x93

Ich denke, der obige Patch geht in Ordnung.

Hier ist der 47/51-858/862-Patch: http://linuxtv.org/hg/v4l-dvb/diff/22b0 ... /ves1820.c
der ist auch ok.

Hier wurde delay auf 50 gesetzt
http://linuxtv.org/hg/v4l-dvb/rev/602db0c7e1cd

increase mdelay from 30 to 50 to be more reliable with bad reception quality

[rhabarber1848]

Die IMHO unkritischen Teiles des Patches sind im CVS:
http://cvs.tuxbox-cvs.sourceforge.net/c ... 54&r2=1.55

Was die delays angeht, sollten noch mehr Rückmeldungen anderer User
vorliegen, bevor am CVS-Code Änderungen vorgenommen werden.

[Striper]

Die Optimierung der Schleife und das entfernen des dvbdelay kannst auch ruhigen Gewissens einchecken. Ist alles von Linux-TV geklaut. ;)

Einzig die mdelays hab ich selber geändert. Allerdings denke ich das mitunter genau diese die spürbare Verbesserung ausmachen. ^^

[rhabarber1848]

Die Optimierung der Schleife und das entfernen des dvbdelay kannst auch ruhigen Gewissens einchecken. Ist alles von Linux-TV geklaut.

committed: http://cvs.tuxbox-cvs.sourceforge.net/c ... 55&r2=1.56

Einzig die mdelays hab ich selber geändert. Allerdings denke ich das mitunter genau diese die spürbare Verbesserung ausmachen. ^^

Modulparameter daraus machen, default 50?

[bellum]

bellum, hast du die Änderungen aus dem anderen Thread schon mal zusammen mit meinen getestet? Hab das gestern mal gemacht, jedoch hatte meine Box dann arge Probleme mit QAM256 Sendern. Das Umschalten dauerte tlw. 20 Sekunden lang. Nokia Kabel AVIA 500.
Liegt das an meinen Änderungen (habs ohne noch nicht getestet)?

Bin im Moment leider viel unterwegs und habe am Wochenende ebenfalls viel um die Ohren. Deshalb bin ich leider noch nicht zum Testen gekommen. Habe es aber noch im Hinterkopf und werde zu gegebener Zeit hier Feedback geben...

Please stand by...

Gruß bellum

Nach einem geschlagenen dreiviertel Jahr (Job und Nachwuchs sei Dank ) bin ich mal zum Testen der Sache gekommen und habe genau das gleiche Verhalten mit Deinem (neuen) Frontend Patch.
Das Umschalten dauert sehr lange.
Habe dann etwas mit den Werten gespielt und ab einem Wert von 25 ging es dann wieder. Habe mit etwas Sicherheitsabstand 30 gewählt und meine auch ein etwas schnelleres Umschalten bemerkt zu haben und wohl auch 2003 schon so war (http://cvs.tuxbox-cvs.sourceforge.net/c ... 51&r2=1.52).

Damit mache ich jetzt erst mal weiter...

Gruß bellum

[bellum]

... und um das ganze noch korrekt zum Abschluß zu bringen - ohne den ZigZag Frontend Patch funktioniert auch ein mdelay von 10 bei mir zuverlässig mit kürzeren Umschaltzeiten...

Gruß bellum

[Striper]

Bin derzeit mit 20 und dem Patch unterwegs. Meine Nokia hat nie schneller umgeschalten. ;)

[PauleFoul]

Kann man die Zeit nicht einstellbar machen bzw. an die Empfangsqualität kopplen??

Ist doch blöd das alle langsamer Umschalten, nur damit Leute mit schlechter
Antennenzuführung keine Probleme haben...