Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Oscam CacheEx mode 2 tutorial

AW: Oscam CacheEx mode 2 tutorial

Hi,
so sieht es bei mir ungefähr auf der CE-Instanz aus:
[cache]
max_time = 12
max_hit_time = 30
wait_time = 0:10000:0,09:450,18:1500,0B:3500,17:3500,01:1500,05:1500:0,06:2500
csp_allow_request = 0
wait_until_ctimeout = 1
Auf der Haupt-Instanz sind dann die richtigen Waittimes und der Cyclecheck mit den Fallbacks, ähnlich wie bei @hwmmc.

Gruß
janni1
 
AW: Oscam CacheEx mode 2 tutorial

Hi,
bitte laßt bei euren Überlegungen über die Höhe der Waittime nicht außer acht,
dass es sich bei den meisten hauptsächlich um "dynamische Waittime" handelt.
Also wenn der Sender nicht schon vorher irgendwie (max_hit_time) im Cache auftauchte, wird in der Regel überhaupt nicht gewartet.
Die Wahrscheinlichkeit ist dann ziemlich gering, dass was passendes im Cache auftaucht, weil keine der Partner gerade diesen Sender schaut.
Die Anfrage geht dann direkt an den Reader und somit wird dann auch der fehlende Cache für andere erzeugt und zwar mit Top-ECM-Zeiten.

Gruß
janni1

Das gibts bei mir nicht, da ist nur die reine wait_time der maßgebende Faktor. Bei 110ms kommen sehr genau 99%+ aus cache3 (über Wochen ausgetestet). Das trifft auch ohnehin eher bei kleinerem cache zu, weil mit größerem cache immer irgendwer rumzappt. Also wird die Geschichte mit größerem cache etwas komplexer.

Aber auch bei kleinerem cache kann wohl keiner Power-Zapper und allgemein das Zappen rausfiltern oder ausschließen und genau da liegt der Hase im Pfeffer begraben.
 
AW: Oscam CacheEx mode 2 tutorial

Hi,
so sieht es bei mir ungefähr auf der CE-Instanz aus:
[cache]
max_time = 12
max_hit_time = 30
wait_time = 0:10000:0,09:450,18:1500,0B:3500,17:3500,01:1500,0 5:1500:0,06:2500
csp_allow_request = 0
wait_until_ctimeout = 1


Auf der Haupt-Instanz sind dann die richtigen Waittimes und der Cyclecheck mit den Fallbacks, ähnlich wie bei @hwmmc.

Gruß
janni1

So hab ich es jetzt copy-paste übernommen, scheint sehr gut zu laufen!

Danke!
 
AW: Oscam CacheEx mode 2 tutorial

Hi,
@ maikyy
Sorry, ich kann dir leider nicht ganz folgen.
Wenn du 110er CWs im Cache hast, warum nutzt du sie dann nicht und erzeugst selber 140er ?
Wem nutzt das was? Das 140er CW geht mit in deinen Cache. Dort wird geschaut, ob es das schon mal gibt. Wenn ja wird nur der Count erhöht.
Dein Partner hat schon 30ms eher das 110er von dir bekommen, wenn es innerhalb seines Hops liegt.

Gruß
janni1
 
AW: Oscam CacheEx mode 2 tutorial

OFFTOPIC on

Jetzt WEISS ich, das ich keinen Schimmer habe... ^^

OFFTOPIC off

Vielen Dank nochmal für die Vorlagen, hocke gerade vorm Log, läuft 1A, erste Sahne! :emoticon-0157-sun:
 
AW: Oscam CacheEx mode 2 tutorial

Jetzt wird die Geschichte interessant. Ich gehe eigentlich davon aus, dass (real 65ms) im Cache landet oder beide und es damit nicht wertlos ist. Das kann dann wohl nur einer der im Code hängt aufklären.

Ohnehin habe ich im Streamboard schon die Zeilenlänge von wait_time bemängelt, aber bisher scheint es niemanden zu interessieren. Mit mehr zeichen könnte man sich nämlich Services sparen und stattdessen für jeden Sender eigene wait_times definieren.

Beispiel:

098C$0078:60,098C$014E:60,098C$00FE:60,098C$014B:60,098C$0141:60,098C$0137:60,098C$012D:60,098C:70

Das ist nur ein Auszug dessen, was möglich wäre.

Nachtrag:

Für mich ist das eine ganz klare Limitierung von Möglichkeiten, die nur mit 20 Instanzen umgangen werden kann und damit wird der Sinn und Zweck irgendwie verfehlt.
 
Zuletzt bearbeitet:
AW: Oscam CacheEx mode 2 tutorial

Mit mehr zeichen könnte man sich nämlich Services sparen und stattdessen für jeden Sender eigene wait_times definieren.

Bedeutet das nicht "übelsten" Konfigurationsaufwand irgendwo?

Sorry für die ggfs blöde Frage.
 
AW: Oscam CacheEx mode 2 tutorial

Hi,
@maikyyy
Ich hab es verfolgt im SB und finde den Ansatz sehr interessant.

Wann nun das CW im Cache auftaucht müßte man wirklich mal analysieren aber du könntest da durchaus Recht haben.
Ich werde das mal testen aber möglich wäre es schon so, wie du es annimmst. Ich hatte das so gar nicht auf dem "Schirm" :emoticon-0111-blush
Dann macht dein Vorgehen auch wieder Sinn.

Ich denke aber eher, dass Waittime abgewartet wird, bevor die Anfrage überhaupt an die Karte geht.
Also:
- ECM kommt vom Client rein
- abhängig von max_hit_time wird der Cache kontrolliert
- Waittime wird evaluiert
- es wird gewartet
- Ecm geht an die Karte
- CW kommt zurück und geht an den Clienten.

Also wäre die ECM-Zeit um Waittime verlängert worden und taucht auch mit dieser im Cache auf.
Sonst würde ja bei jeder Anforderung die Anfrage immer zuerst zum Reader gehen und danach würde dann Waittime gewartet.
Dann würde man ja nie seine Karte entlasten, oder?


Gruß
janni1
 
Zuletzt bearbeitet:
AW: Oscam CacheEx mode 2 tutorial

Bedeutet das nicht "übelsten" Konfigurationsaufwand irgendwo?

Sorry für die ggfs blöde Frage.

Ja und? Noch immer Sinnvoller als z.B. Select-Kanäle mit Services ganz rauszufiltern weil mir die allgemeine wait_time nicht passt und ich habe viele Cacher die gerne auch Select bestellen... UND das auch auf 1702 oder 09C4!

Ausserdem war das eben nur ein Auszug, denn z.B. möchte ich bei Spocht 1-X (1-X HD) oder BL 1-X (1-X HD) kurze wait_times und bei FILM,WELT u Co. längere nutzen.

Aber so sind einem die Hände gebunden!

@janni1: Eben, mein ich doch. Sonst würden mein Partner schon abkotzen weil sie keine Hits landen ;)
 
AW: Oscam CacheEx mode 2 tutorial

Also mich kleines Licht hat es fast den Verstand gekostet, die WAIT_TIME für die CAIDs zu definieren / hinzubasteln (trifft es wohl eher).

Sehr interessante Geschichte, freue mich hier mehr zu lesen. Anleitungen sind in dem Bereich leider "rar".
 
AW: Oscam CacheEx mode 2 tutorial

Wenn der Einstieg überstanden ist, wird es erstmal richtig interessant und die Möglichkeiten sind "fast" grenzenlos -.-
 
AW: Oscam CacheEx mode 2 tutorial

Hi
@maikyyy
hab mal oben editiert #368, zum Auftauchen im Cache ;)

@janni1: Eben, mein ich doch. Sonst würden mein Partner schon abkotzen weil sie keine Hits landen ;)
Hmmm, mal angenommen:
  • .... cache3 (263 ms) by ce2_yxz - ProSieben-HD (cw count 7) (cwc OK(CE))
Wer bekommt den Hit gutgeschrieben? Der Erste, der Schnellste, der Letzte? Auf keinen Fall aber alle Sieben!

Ich wäre da vorsichtig die Hitrate als Qualitätskriterium zu sehen.

Gruß
janni1
 
AW: Oscam CacheEx mode 2 tutorial

Danke nochmals, also ich hab mich schwer getan zugegebenermassen...

Allein diese Übersicht (nicht von mir) finde ich kompliziert (aber einleuchtend irgendwo):

Du musst angemeldet sein, um Bilder zu sehen.

Ich hoffe ich darf das posten
 
AW: Oscam CacheEx mode 2 tutorial

Hi.
@axfa77
so, wie auf der Grafik wäre es eine Möglichkeit.
Wattimes nur auf der CE-Instanz.

Viele, mich eingeschlossen, lösen es allerdings anders.
Man setzt sehr hohe Waittimes auf der CE-Instanz und regelt es dann mit passenden Waittimes auf der Hauptinstanz.
Das hat den Vorteil, dass man auch Partner per CE-Mode1 auf seine CE-Instanz lassen kann, ohne sie per Waittime zu beschneiden.
Die CE1-Partner können das dann individuell über ihre eigenen Waittimes regeln.

Gruß
janni1
 
AW: Oscam CacheEx mode 2 tutorial

Hey janni,

erstmal macht es wirklich Spaß sich mit Dir zu unterhalten. So, zurück zum Thema ;)

Wie und wem der Hit dann letztendlich gutgeschrieben wird, ist so eine Geschichte für sich. Jedenfalls geht es dabei definitiv nicht nach Gruppeneinteilung. Schätzungsweise wird das CW mit dem niedrigsten Timer genommen. Hits kann man also alles in allem sehr gut als Kriterium für die Qualität eines Cache-Partnes verwenden. Damit kann man gut einschätzen ob jemand lokalen Cache generiert, oder einfach nur über 2 Hops durchreicht und lediglich einen Nutzen daraus ziehen möchte.

Damit kommen wir wieder zu einem anderen Problem, was ich bei CE1 über einen längeren Zeitraum beobachten konnte. Bei CE1 wird offensichtlich komplett auf eine Gruppeneinteilung geschissen und einfach alles im Cache an den abfragenden User weitergeben, egal welche Gruppen diesem zugewiesen sind. Zum Beispiel wurde bei CE1 sogar mein lokaler in die Instanz gepushter Cache trotz nicht zugewiesener Gruppe des Users zurück gegeben als cache3. Seitdem war für mich CE1 direkt erstmal erledigt!

Warum sollte man auch cache3 wait_time abwarten wenn der cache lokal da ist ohne Verzögerung?
 
Zurück
Oben