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,
Parameter zap_no_wait_time hatte mal der "Erfinder" (blaky) von Anticascading over Sid Count (ACoSC) mit in seinen Patch gepackt.
this patch includes also the zap_no_wait_time for cacheex/cwc users
Es war für User gedacht die Cacheex auf ihrem Reciever betreiben.
i made acosc as a second option to existing ac.. and think it works much straighter and is easyer to understand.. and btw i can use the very usefull zap_no_waittime (indispensable if cacheex and dvbapi works on the same machine)
Ob es es aber jemals mit in den Trunk geschafft hat, weiß ich nicht. In der taucht es jedenfalls nicht mit auf.

Zu wait_until_ctimeout:
Einem CE1- User wird bei wait_until_ctimeout = 0 nach Ablauf der wait_time, ein not_found geschickt wenn nichts passendes da ist.
not found (1500 ms) - Sky Select 00FB (wait_time over) # z.B. bei wait_time 17:1500
Bei wait_until_ctimeout = 1, wird ihm nach Ablauf von clienttimeout ein timeout geschickt, wenn nichts passends vorhanden.
rejected group (5001 ms) (F/0/0/0) - Sky Select 0105 # z.B. bei clienttimeout 5000 (wait_time over)
Gruß
janni1
 
AW: Oscam CacheEx mode 2 tutorial

Ob es es aber jemals mit in den Trunk geschafft hat, weiß ich nicht. In der taucht es jedenfalls nicht mit auf.

Scheinbar nicht.

Einem CE1- User wird bei wait_until_ctimeout = 0 nach Ablauf der wait_time, ein not_found geschickt wenn nichts passendes da ist.

Bei wait_until_ctimeout = 1, wird ihm nach Ablauf von clienttimeout ein timeout geschickt, wenn nichts passends vorhanden.

Ich tuhe mich schwer den Sinn zu verstehen, beides macht im Prinzip das gleiche. Außer bei 1 wird 5 Sekunden lang gewartet ob noch irgendwas im Cache landet und danach der Timeout. Aber kann man einen Client 5s + evtl. 150ms + Latenz für eine neue Anfrage zumuten?
 
AW: Oscam CacheEx mode 2 tutorial

Hi,
du mutest dem CE1-Partner die 5 sec ja nicht zu, sondern gibst ihm die Möglichkeit, das selbst über seine eigenen Waittimes individuell zu regeln.
Mit wait_until_ctimeout = 1 greifen dann in der Regel eben seine eigenen Timings und nicht ,wie mit wait_until_ctimeout = 0, deine Waittimes.

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

Es gibt noch ein paar andere Parameter für die Configs,
die leider nicht im Wiki oder WebIF auftauchen, aber sinn machen.
z.B. so was ...
Code:
lb_force_fallback              = 1

### http://www.streamboard.tv/oscam/changeset/9725
 
AW: Oscam CacheEx mode 2 tutorial

Vielleicht darf ich auch noch etwas zu meinem Verständnis Fragen. Eine hohe Waittime erhöht nur die Wahrscheinlichkeit ein ECM im Cache zu haben weil länger gewartet wird. Eine kurze Waittime sorgt dafür, dass meine Umschaltzeiten niedriger sind aber weniger ECM aus dem Cache genommen wird weil kürzer gewartet wird. Hab ich das richtig verstanden?
Was ich leider nicht verstanden habe ist der Aufbau von CacheEx CW Check. Ich verstehe bitte den Sinn des mittleren Wertes nicht. Z.b 098c:1:1. Was genau macht die 1 in der Mitte?
 
AW: Oscam CacheEx mode 2 tutorial

Habe halt das Problem, dass bei CacheEx CW Check: Caid:1:1 echt lange Umschaltzeiten entstehen. Vieleicht bin ich einfach zu blöd um das zu verstehen :-(
Beim umschalten wird halt die angegebene Waittime + die Abfragedauer der Karte/Cache addiert so wie ich verstanden habe.
Waittime habe ich bei mir jetzt so eingestellt: 1830:400,1831:900,1835:900,1838:900,1833:900,1843:500,09C4:160,098C:140,098E:120,1722:800,1702:800
Habe überlegt jetzt mal nur 2 Caids zu definieren bei denen ich weiß, dass die Antwortzeiten gering sind. Also z.Bsp. 180 und 098c.
Was haltet ihr davon. Die Antwortzeiten sind teilweise so hoch, dass ich denke der Sender läuft nicht. Beispielsweise bei einem Wechsel von RTL HD auf Atlantic HD
 
AW: Oscam CacheEx mode 2 tutorial

Was bedeutet hoch? ... Bsp.

Wie schnell sind deine lokalen Reader denn?
 
AW: Oscam CacheEx mode 2 tutorial

hoch nicht in ms am Server gemessen sondern im Schlafzimmer auf dem Receiver Subjektiv. Lokal habe ich ja nicht alle Caids. Die 098C habe ich lokal die liegt bei 75ms. Die 1830 bei 280ms und die 098e bei 120ms
 
AW: Oscam CacheEx mode 2 tutorial

Waittime habe ich bei mir jetzt so eingestellt:
1830:400,1831:900,1835:900,1838:900,1833:900,1843: 500,09C4:160,098C:140,098E:120,1722:800,1702:800
Lokal habe ich ja nicht alle Caids.
Die 098C habe ich lokal die liegt bei 75ms. Die 1830 bei 280ms und die 098e bei 120ms
098C real 75 ms (WT 140) = 215 ms
1830 real 280 ms (WT 400) = 680 ms
098E real 120 ms (WT 120) = 240 ms
... an deinen Server, am Client kommt noch die Latenz hinzu ...
 
AW: Oscam CacheEx mode 2 tutorial

Du hast natürlich Recht. Bei diesen Karten kann man es noch verkraften aber wenn über den Proxy eine 1702 reinkommt das schon eine andere Größenordnung. Aber ohne Waittimes geht es ja nicht
 
AW: Oscam CacheEx mode 2 tutorial

Es gibt noch ein paar andere Parameter für die Configs,
die leider nicht im Wiki oder WebIF auftauchen, aber sinn machen.
z.B. so was ...
Code:
lb_force_fallback              = 1

### http://www.streamboard.tv/oscam/changeset/9725

Code:
Setting lb_force_fallback=1 on same reader, with one of above  parameters, we force LB to set reader ALWAYS as fallaback, and without  consider its stats (ignore fails).

Also das bereitet mir nun auch wieder Kopfschmerzen. Im "lb_mode = 1" antwortet bereits der schnellste Reader und alle Reader sind mit einbezogen.

Durch "lb_whitelist_services" im Reader sagt man dem LB, der Reader kann diesen Service immer, also guckt der auch nicht nach den Stats.

Mit "lb_retrylimits" "Caid:xxx" legt man für die Caid quasi ein Limit fest, nach diesem Wert soll die Anfrage auf den nächstmöglichen Reader springen um ein überladen dieses Readers zu vermeiden (Freezer oder Artefakte).

Das funktioniert bei mir bisher sehr gut, einzelne Clienten springen bei jeder Anfrage teilweise quer durch alle Reader oder eben nicht, weil Cache vorhanden.

Deswegen ist diese Funktion "lb_force_fallback" unnötig, weil man im LB eigentlich keinen 100% sicheren Fallback festlegen kann.

Lege ich einen als Forced Fallback fest und weise Oscam an das so zu machen, aber der Reader hat zum Zeitpunkt der Anfrage bereits eine hohe Auslastung, wird es wieder zum Verhängnis und der Client hat einen Freeze oder Artefakte.

Es sei denn, ich weise alle gleichen Reader ausser dem Forced Fallback einen höheren "lb_weight" zu und bevorzuge diese dem FB gegenüber. Das macht bei gleichen Karten aber überhaupt keinen Sinn, da beschneide ich mich quasi wieder selbst.


EDIT: Was bringt eigentlich der Parameter "no_wait_time" im User unter CacheEX. Dazu finde ich auch nichts im Wiki.
 
Zuletzt bearbeitet:
AW: Oscam CacheEx mode 2 tutorial

Hi,
gehört zwar nicht ganz hier her aber vieleicht hilft dir das hier weiter:

lb_force_fallback


und hier noch was von blueven dazu:
  • add new parameter "lb_force_fallback" (default=0) Normally, if a reader has fallback and fallback_percaid parameters setted, LoadBalancing? chooses it as fallback or as not-fallback reader, after evaluating its stats. Setting lb_force_fallback=1 on same reader, with one of above parameters, we force LB to set reader ALWAYS as fallaback, and without consider its stats (ignore fails). This could be usefull for secure fallback readers, that we want use as latest secure chance of decoding. It is same behaviour with LB off (mode 0).

  • Fix for nfb_readers parameter: now, LB cannot selects more fallback readers than nfb_readers value. The fallbacks are choosen with this priority:
    1. readers with fallbacks paramters (fallback or fallback_percaid) and lb_force_fallback=1
    2. readers with fallbacks paramters (fallback or fallback_percaid) and lb_force_fallback=0, if not already used as best readers
    3. readers with best lb_value, if not already used as best readers
"no_wait_time" nutzt man bei Usern, deren Anfragen nie um wait_time verlängert werden sollen.
Wenn zum Zeitpunkt der Anfrage nichts passendes im Cache ist, geht diese dann sofort an den zuständigen Reader.
Es geht hier um Partner, die das so wollen, wegen der sonst schlechterer ECM-Zeiten und
damit man nicht generell auf Waittimes verzichten muß, setzt man diesen Parameter dann nur speziell bei diesen Usern.

Gruß
janni1
 
Zuletzt bearbeitet:
Zurück
Oben