AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!
... ihr habt es einfach noch nicht so richtig begriffen! DD
Der LB erstellt zwar die Stat.. aus CAID: ggf. IDENT:SID trotzdem von jeder Reader-Gruppe in deiner OScam.
Wenn eine CAID Anfrage kommt und der LB entscheidet sich für diese Readergruppe,
dann fragt er dort auch bei jeden Proxy der in der Gruppe steckt an,
dadurch gibt es jede Menge Traffic und ECM Request der nicht sein muss.
PS: ich rede hier von CCcam-Proxies mit Multi CAIDs (also nicht nur eine)
Für jeden ECM Request werden zuerst die gültigen reader ermittelt. Dies geschieht durch:
Gruppe des account passt zu Gruppe reader
reader ist enabled und nicht gelöscht
reader caids passen zu ECM request oder reader hat keine caids
reader services passen zu ECM request oder reader hat keine services
reader idents passen zu ECM request oder reader hat keine idents
reader chids passen zu ECM request oder reader hat keine chids
bei caid 0500 zusätzliche Prüfung auf nanos
Wenn all diese Prüfungen positiv sind, dann wird der reader für diesen ECM Request ausgewählt. Diese Prüfung wird für alle Reader durchgeführt und der Loadbalancer erhält so eine Liste aller möglichen reader für diesen ECM Request. Ist nun der loadbalancer aktiviert, so ermittelt er aus dieser Menge die Loadbalancer Werte (LB_WERT). Für jeden Reader (aus der Liste der gültigen) wird dann der LB_WERT ermittelt, indem lb_mode=1: die durchschnittliche Antwortzeit des readers für diesen service durch das lb_weight geteilt wird. lb_mode=2: die Letzte Antwortzeit relativ zur frühesten Antwortzeit gemessen wird. lb_mode=3: das usagelevel (Idlezeit im Verhältnis der ECM-Verarbeitungszeit) gemessen wird. Die ermittelten Reader werden dann nach diesem LB_WERT sortiert (kleinster zuerst) und zugeordnet:
Ist "Prefer local cards" aktiviert, werden zuerst lb_nbest Reader zugeordnet, die keine Proxies sind
Ist lb_nbest Reader noch nicht erreicht, so werden die verbleibenden Reader der reihe nach zugeordnet, bist lb_nbest Reader erreicht ist.
Danach werden lb_nfb Reader als Fallback-Reader zugeordnet
Normalerweise sollte lb_nbest readers = 1 sein, da es nicht notwendig ist, mehr als einen reader anzufragen. Nebenbedinungen, die zusätzlich Reader auswählen:
Keine Statistik vorhanden: Reader wird ausgewählt
Statistik vorhanden aber lb_min_ECMcount nocht nicht erreicht: Reader wird ausgewählt
Statistik vorhanden, ECM Anzahl > lb_max_ECMcount: Reader wird ausgewählt, wenn durchschnittliche Antwortzeit > lb_retrylimit und die Stats werden resetet.
Der ECM Request wird dann ausgeführt und an die entsprechenden reader geschickt. Antwortet ein Reader mit "not found", so wird dieser geblockt. Antwortet ein Reader 5x nacheinander nicht auf ECM-Requests (timeout), so wird dieser geblockt. (siehe lb_min_ecmcount) Antwortet ein Reader korrekt, so wird dessen Zeit für die Antwort gemessen und in die Statistik eingetragen. Sind Service oder Ident vorhanden, werden ECM-Requests für die zugeordneten Reader immer ausgeführt.
Ich werde es aber jetzt ab hier einfach mal sein lassen. Funktionieren wird es auf beide Arten
aber die Aussage das man jeden Proxy in eine eigene Gruppe Stecken muss halte ICH einfach
für FALSCH!
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!
Weiß jetzt nicht ob das zum Thema passt.
Aber ich lese immer hohe Prozentzahlen bei den Cache (janni 94% und Paz85 70% und höher).
Ich komme nie auf solche Werte.
Siehe Anhang.
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!
Ja das kann sein mit den Receivern von meinen Cliens ( habe ständig falsche Anfrage zB."xxx (0500&000000/9515/2073/89): invalid (0 ms) (invalid SID) "). Es geht hier Haupsächlich um Redlight Anfrage die falsch angefragt werden.
Ich selber nehme nur Dreamboxen da ist immer alles io.
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!
Hi
die IGN-Werte würden mir aber sehr zu Denken geben.
Durch deine Filtereinstellungen werden 75% aller Anfragen abgewiesen.
Da läuft ja eingentlich bei den Clients fast nichts, oder?
Also bei mir sieht das etwa so aus:
ECM's Positiv
ECM's Negativ
READERs / CACHE1,2,3
NOK / IGN / TOUT
4.47% / 95.53%
26.09% / 0.87% / 73.04%
358784 (99.68%)
1152 (0.32%)
Bei mir kommen die hohen Cache-Werte hauptsächlich zu Stande, weil ich gerade mal probiere, was so geht (mit wait_times jenseits von gut und böse). Deswegen auch der relative hohe Wert bei TIMEOUT.