Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

[supraracer]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Ich habe mit verschiedenen Devolo und Netgear getestet, WLAN Bridge mit Linksys und TP-Link. Da ich die Freezer provozieren wollte bewusst auf Kanälen auf denen schon viele Nachbarn sind.
Für produktive WLANs nehme ich natürlich Kanal 14.

-supraracer

 

[hwmmc]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Also mit Devolo habe ich immer gute Erfahrung gemacht,
da man ja mit Devolo Cockpit auch diese ggf. Firmware technisch aktuell halten kann.
Es kann auch gut sein, dass mache Router-Typen, mit manchen dLAN-Typen nicht zurecht kommt.

 

[freddchen]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

okay, dann hier mal meine zusammenfassung.
"Breitschwert" - Methode ist nicht erwähnenswert . Man konnte im Log nicht feststellen, wie oft genau hierdurch frezzer vermieden wurden. Das einzige was ich festellen konnte war, dass es 13 freezer gegeben hat, trotz 3 paralleler verbindungen.

Hab dann alles so wie in Post #1 gemacht. Wichtig vielleicht noch vorweg:
Wenn man in der oscam.dvbapi

I:0

macht funktionieren alle anderen Caids nicht mehr. Eigentlich total offensichtlich, aber ich hab lange gerübelt warum ORF usw. nicht mehr hell wurden :-D

Nun zum test mit den vorgebenen werten aus dem ersten post.
Nochmal kurz das wichtigste

oscam.conf
[global]
fallbacktimeout_percaid       = 098C:300,1830:1000

oscam.server
[cs357x reader]
fallback  = 1 [COLOR="#FF0000"]#fallback_percaid hat Oscam ums verrecken nicht angenommen, weder per webinterface noch per hand konfiguration. Aber kommt ja aufs selbe raus[/COLOR]

in den 20 Stunden Test gab es 15 vermeintliche Freezer, von denen 9 in etwa so abgefangen wurden:

2016/02/12 11:28:14 02AA3E4F c      (ecm) dvbapiau (098C@000000/025B/0083/98:): found (360 ms) by cs357x (F/2/2/2) (real 46 ms)

die, die nicht abgefangen wurden sahen zunächst so aus:

2016/02/11 23:49:09 7C800104 c      (ecm) dvbapiau (098C@000000/025B/0083/98:): timeout (5002 ms) by cs378x,cs357x (F/2/2/2)
oder so:
2016/02/11 23:12:09 7C800104 c      (ecm) dvbapiau (098C@000000/025B/0083/98:): found (1574 ms) by cs378x (F/2/2/2)

darauf habe ich nach ein paar stunden, in denen mir diese timeouts aufgefallen sind zusätzlich noch in der
oscam.conf

[global]
clienttimeout                 = 500

eingefügt. Danach gab es in den nächsten 12 Stunden nur einen Freezer. Die timeouts wurden in etwa so bewältigt:

2016/02/12 05:12:21 7C800104 c      (ecm) dvbapiau (098C@000000/025B/0083/98:): timeout (500 ms) by cs378x,cs357x (F/2/2/2)
2016/02/12 05:12:21 7C800104 c      (ecm) dvbapiau (098C@000000/025B/0083/98): found (67 ms) by cs378x (P/1/2/2)

damit werden drei Abfragen Zeitversetzt gesendet. Was soweit auch ganz gut aussah, bis ich auf HD+ gewechselt habe. Denn Theoretisch kann der Fallback da ja garnicht mehr eintreten(1000ms), da wir ja schon nach 500ms nen timeout erzeugen und das ecm neu rausschicken. Außer einer höheren Trafficbelastung und den nervigen timeouts im client log ist mir dadruch allerdings kein Nachteil aufgefallen. Vielleicht kann man mit dem clienttimeout wert von 500 auch nochmal ein wenig experimentieren, oder auch ganz weglassen. Muss jeder selbst wissen.

Zusmmenfassend kann ich sagen, dass ich mit dieser Methode zumindest bei meinem Netzwerk die Freezer so gut wie ausmertzen konnte.
Daher ein großes danke an supraracer für die Idee und Anleitung :emoticon-0137-clapp

 

[prangsta]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

jetzt ma ne frage ( ganz blöd von der seite - duck und weg )
wenn ich nen server hab - ich sag ma nen raspi -
der die karten aus liest und dahinter noch einen der sich mit 2 protokollen auf den server einwählt -
quasi als puffer -

würden dann nicht sehr viele anfragen aus dem cache beantwortet werden auf dem server ?
nur mal als dumme frage ?!?!

 

[supraracer]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Ich weiß nicht ob ich die Frage richtig verstanden habe.
Ein CW liegt im Cache wenn es Real von der Karte angefragt wurde, weitere Anfragen nach dem ECM werden mit dem CW aus dem Cache beantwortet. Ob das dann ein Receiver ist oder ein weiterer Server spielt dabei keine Rolle, das weiß und interessiert deinen Server mit den Karten ja gar nicht mehr.
Wie kommst du darauf, dass mehr (was überhaupt?) aus dem Cache beantwortet werden sollte?

-supraracer

 

[janni1]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Hi,
@freddchen
Fallback per Caid mit Ident angeben, dann müsste es auch klappen.
z.B.

fallback_percaid = 098C:000000;1830:000000

@prangsta
Richtig, die Doppelanfragen werden immer aus dem Cache 1/2 beantwortet und wenn Cache3 (CE) vorhanden ist, dann auch aus diesem.

Ich finde die Herangehensweise ganz gut, man hat sozusagen eine Art Fallbackanfrage bei der die Karte nicht einmal zusätzlich belastet wird, denn bei den möglichen Doppelanfragen kommt die Antwort aus dem Cache2 /1.

Gruß
janni1

 

[HarryHase]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

@prangsta :Die Anfrage aus dem Cache oder von der Karte ist aber gar nicht das beschriebene Problem; Aber klar wenn Du alle Sender anfragen kannst kommt es aus dem Cache (für eine gewisse Zeit).

Hier geht es darum dass das CW nicht schnell genug zurück kommt. Also die gesamte Laufzeit, die geht auf der Strecke kaputt nicht am Server selbst.

 

[ultrachaos]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Hi,

Leider habe ich mich zu früh gefreut und bin immer noch betroffen von den Freezes.

Mein Setup sieht wie folgt aus.
CS Server = Raspberry Pi1 mit neuesten Raspian Jessie.
CLient = VU+Zero mit oscam
TP Link dLan an GB Switch.


Die Freezes sind nach dem How To besser geworden, jedoch kommen sie immer wieder. Teilweise dauern sie bis zu 10 Sek und die ms gehen auf 600 hoch (laut anzeige am receiver)

im Log vom Oscam Server sehe ich leider nichts außer das eben die zweite line ab und an einspringt.

Ich habe auch schon die Clienttimeout auf 500 herabgesetzt, vorher war die auf 10000 eingestellt.

laut config von den dlan hab ich einen durchsatz von 70mbit das sollte ja eigentlich reichen oder? (obwohl ich meilenweit entfernt bin von den angeblichen 500mbit laut hersteller)

Jetzt hab ich schon ein bisschen den Raspi in Verdacht...kann es sein das dass ältere Modell ein wenig zu langsam ist ?

 

[supraracer]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Hi,

10 Sekunden sind natürlich zu viel, das kann man mit keiner Config abfangen. Das es am Raspi liegt kann ich mir nicht vorstellen, um es 100% auszuschließen müsstest du aber mal mit direkter LAN Verbindung testen.
Dein Problem wird an den dLANs liegen: Der Durchsatz spielt für CS kaum eine Rolle, da reicht generell auch 1 MBit locker (was bei dLAN natürlich wiederrum ein Indikator für schlechte Verbindungsqualität wäre). Leider sind die dLAN-Adapter (egal welcher Hersteller) ziemliche Blackboxen, man hat kaum die Möglichkeit etwas zu konfigurieren oder eine ordentliche Diagnose zu machen, kein Log, etc. pp.

Beim Rumspielen mit verschiedenen Adaptern war mir aufgefallen, dass die wohl gerne mal in eine Art Energiesparmodus gehen wenn wenig Traffic herrscht (wie bei CS), das resultiert dann in den 5-10 Sekunden Freezern. Bei zwei Netgear 200AV war das recht häufig, bei Devolo 200AV weniger aber auch noch vorhanden (mit verschiedenen Firmwares getestet). Die Lösung war dann, ein Devolo zusammen mit einem Netgear zu betreiben. Klingt erst mal Paradox, ich vermute die konnten gegenseitig kein Energiesparmodus mehr aushandeln. Nachteil davon war ein ziemlicher schlechter Datendurchsatz in der Bandbreite (Devolo-Devolo ~185 MBit brutto; Netgear-Netgear ~170 MBit brutto; Devolo-Netgear ~60 MBit brutto). Da kam es dann beim Kopieren von Aufnahmen der Box auf den PC via FTP zu Freezern beim gleichzeitig TV schauen, aber zum Glück lässt sich der max. Traffic in FTP Clients ja begrenzen...irgendeinen Tod muss man bei dLAN befürchte ich sterben. ;-)

-supraracer

 

[ultrachaos]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Ok, ich hatte bereits den Raspi in Verdacht.
Ich werds mal testen mit direkt Kabel.

Der Standby kann ja leider nicht überlistet werden denke ich. Ich habe mir auch schon überlegt einen Switch zwischen Client und dlan zu geben. Vielleicht fallen dann die Standbys aus.


Danke

 

[szonic]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Also bei meinen Schwiegereltern laufen uralt Devolo (die Blauen) mit maximal 14 Mbit können und da freezt nix.

Ich schlage einen eigenen Thread vor in dem Du Deine Configs mal offenbarst.

 

[supraracer]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

@szonic: Die ganz alten unterlagen bestimmt noch keinen schwachsinnigen EU Verordnungen zum Strom sparen / Standby ;-)

-supraracer

 

[beauty]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Um den Stromsparmodus zu überlisten gibts hier einige Threads mit Dauerping Schleifen etc.... Hab so bei meinem Clienten Vu+ Duo die Freezer minimiert. Werde aber die kommenden Tage diese möglichkeit hier mit dem Fallbackreader zusätzlich probieren.

 

[supraracer]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Dauerping hat bei meinen dLAN Adaptern nichts gebracht, sonst hätte ich das hier geschrieben, aber mag Modell/Herstellerabhängig sein.

-supraracer

 

[HarryHase]

AW: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Also bei meinen Schwiegereltern laufen uralt Devolo (die Blauen) mit maximal 14 Mbit können und da freezt nix.

Ich schlage einen eigenen Thread vor in dem Du Deine Configs mal offenbarst.

selbiges ggilt für die blauen 85'er und dazu kompatiblen Modellen, ich glaube erst mit den höheren Geschwindigkeiten kam der power-Wahn