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 mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!

    Nobody is reading this thread right now.
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!

... ihr habt es einfach noch nicht so richtig begriffen! :DDD
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)
 
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!

Nein macht er nicht! Dann stimmt etwas mit deinen configs nicht.
-->Eventuell retrylimit zu klein oder der Loadbalancer auf 10 oder 0?!

Und ja das geht auch mit Proxys im MultCaid betrieb.

Ich suche es heute Abend mal im Streamboard raus.




Wie ermittelt OSCam einen gültigen Reader?

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.


... ihr habt es einfach noch nicht so richtig begriffen!

Oder du?


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!
 
Zuletzt bearbeitet:
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!

Hi,
HT-Cache ist eingecheckt.
@[-SONIC-] brauchst also zukünftig nicht mehr patchen.

Wen es interessiert, hier mal eine Erklärung von blueven dazu:
Hi people!
Finally, after 3 months we got a stable HT implementation!
This patch make changes mainly over cache handler, but also add other usefull stuff in oscam.

These are overall changes:

- Cache is now stored in Hash Table! Cpu load dropped!
The "TommyDS" library ( ) is used for hash tables implementation.
It implments a chained linear hash table, called "tommy_hashlin".
Anyway, it should be tested on different systems.

- Cache is stored in HT using only csp_hash. To match ecm with cws, we use only csp_hash without check on caid/prid/srvid!

- Now, cheking cw in cache is done each 10ms. So, answer from cache could happen at any time, if ecm not answered yet.
By default, each different cw (max 10) for same hash is stored in cache, and only cw with highest counter (that is, most received cw) is served at checking cache.
This help avoid fake cws. Obviously, we should have more than one cacheex peer to let counters increase.
It will works only with cacheex cws, cw from normal reader have priority and are considered good!
To force a specific counter, we can handle it with these new parameters in cache section:
- "check_cw_count" : set minimum cw counter to allow cw is used.
Default=1, use default behaviour: use cw with highest counter when cache is checked.
e.g. check_cw_count=2 -> use cw only if its counter is equal 2 (That is, 2 same cw received)
- "check_cw_count_mode" : specify behaviour for "check_cw_count".
Possible values:
0: when wait_time expires, serve highest counter's cw got anyway, even if no check_cw_count reached.
1: never serve cw (coming from cacheex) stored in cache if its counter not reaches check_cw_count. When wait_time expires, requests will go to normal readers! Only when a cw reaches check_cw_count, it can be served to clients.
Default 0.

- Each different cw is now pushed to cacheex peers only ONE time! No more risk same cw is pushed twice for same client!
Anyway this depends on max_time parameter, because if a cw arrives after its ecm hash is freed from cache, we lost pushing out informations for clients. So, you should set max_time as cw life at least to be sure this works properly.

- CAMD35 and CS378X:
- add keepalive stuff (handled only by reader).
Parameter: "keepalive", 1 to enable it, 0 disabled (default).
When keepalive is used, reconnetiontimeout is set to 60s, because it cannot be checked before keepalive exchange (each 30s).
On server side, the clientmaxidle parameter > 30-40s should be used (deafult is 120s, so can you leave default value). If not, client will close connection and reader will reopen it each 30s.
- fix a bug (existing in svn) reading packets.
- Revisited all packets exchange in cacheex mode 2 and 3.

Compatibility with svn oscam is ok.

- Added in cache and in cacheex protocols(camd35 and cccam) odd/even byte info.
As bowman told me, this will let CSP able to fix problem in 0963, because now oscam send odd/even byte to it.
In fact, in CSP, it's required all cws sent trough UDP port oscam->CSP have this byte set. If not, CSP cannot detect correct cw part to swapp.
So, if you send cache (from cacheex) to CSP, make sure you and all your peers (and peers of yours peers...) run this version, to correctly send 0963 cache to CSP.
Anyway this require a new CSP plugin, that use this new byte for correctly swap cws. Ask to CSP developers fot it.
Atm, commit at #9036 is keeping here, until this patch will be spreaded. After, it could be removed without problems, because now CW swapp for cache is done in cache handler itself, using odd/even byte.

- Fix cacheex mode 2 for camd35.
REAL problem of mode 2 was that without CONNECTED status, clients would not push cws, because starting connection is done by reader and (if cacheex_allow_request=0) it does not send nothing (ecm requests) for initializing connection.
This is reason mode 2 camd35 readers are NOT WORKING CORRECT in svn atm. They receive nothing if NOT connected.
With cccam this is not a problem, because it connects at startup and have keepalive stuff.
For this reason i add "keepalive" parameter in reader section to work with camd35(tcp and udp) readers. It will connect reader at startup and will take connection alive. It works for all camd35(tcp and udp) readers, cacheex and "normal".
Keepalive stuff is mandatory for cacheex mode 2 readers. ("keepalive=1" for camd35, and "ccckeepalive=1" for cccam)
For cacheex (mode 2/3) camd35 (tcp and udp) readers, it is now enabled by default.
Camd35 keepalive send msg and check connection each 30s, and if network failure, it will re-conenct reader.
When used on a cacheex mode 2/3 readers, it will send its nodeid as keepalive msg. So nodeid is updated each 30s. No more request/answer keepalive msgs each 256 cws pushed as svn.
This decrease network traffic and make communication more cleaned.
On server side, the clientmaxidle parameter > 30-40s should be used (deafult is 120s, so can you leave default value). If not, client will close connection and reader will reopen it each 30s.

- To filter incoming and outgoing cache, now we use caid, ident and services parameters.
"cacheex_ecm_filter" is leaved for compatibility with svn oscam. But we can use caid/ident/services now.
Take attention, filters on prid will be ignored for cache coming from csp, because csp cache not send prid information (prid=0 always).

- Added check on block_same_name and block_same_ip to avoid cacheex loopback in cacheex mode 1.

- Added new parameter "no_wait_time" in user section. E.g. If we would a client that ask real readers without wait for cache, we could use this parameter.
This could be also usefull e.g. for cacheex mode 2 client when cacheex_allow_request=1. If client receive ecm request (when cacheex_allow_request=1), it should not wait because no cw was pushed to it and it would search for real readers. But obviously, thid depends from configuration.
Possible values:
0: use wait_time set in cache config
1: no use wait_time
Default 0.


- Added config parameter "reconnectdelay" for max tcp connection block delay, in milliseconds (reader section). Default 60000 ms (1min, as always been in svn)

- check in cache for "oscam.cacheex" file for mode1 readers removed. Miss documentation about it and maybe no one use that file.

- Fix always accept prid=000000 for services. It has to be explicity set.

- added column to show number of requests per minute in webif user page.

- move reader table pending to max 4096. So now you can set -p4096 when start oscam.

- In webif, if one of stats overflow (become negative), reset all stats automatically.

- Try fix some random crashes found in svn too.

- This patch revert CWC Check changes in svn #9037, #9059, #9061, #9062: code changes are not compatible with this new code. New re-code is nedeed.

- ATM, this patch revert changes in svn #9066, #9067, #9070, #9071: See my posts here:


Most of the new parameters are not in the webif (yet), it will be added later by me or by some voluntary
Du musst angemeldet sein, um Bilder zu sehen.



Considerations:
Initially i thinked to remove cacheex mode 3, because now mode 2 works great. But, for compatibility with svn oscam, i leave it in code.
My advise: use cs378x protocol and cacheex mode 2! It is more clean and light. Now cacheex works very well with it!
With this patch, you will see your cache size grown than svn, be quite that all is normal because now oscam process MORE cws per second and cws are taken more time in cache, because free happens at (last cw got time+max_time), while before was (first cw got time+max_time).
Also, you can see now cw diff increases more, it is normal because now each new cw is compared with the heighest "counted" cw, that can be change at each cw arrived.

Special thanks goes to Capncook, support me in development ideas and tests. A lot of nights without sleep!
Du musst angemeldet sein, um Bilder zu sehen.

Also thanks to Gorgone, Mo0211 and mumbua, helped me a lot with tests.



This is an example how reader and client could be configured for cacheex mode 2 communication:

[TABLE="width: 98%, align: center"]
[TR]
[TD] [TABLE="class: tableinborder, width: 100%"]
[TR="class: smallfont"]
[TD="class: tablecat, colspan: 2"]code:[/TD]
[/TR]
[TR="class: smallfont"]
[TD="class: inposttable, align: right"]1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:[/TD]
[TD="class: inposttable, align: left"]***** CACHEEX MODE 2 ******
Reader receive cws (and if cacheex_allow_request=1 send ecm requests too):

[reader]
label =
protocol =
device =
user =
password =
group =
keepalive = 1 //if camd35/cs378x it is useless, because is enabled by deafult. For cccam,use ccckeepalive=1.
cacheex = 2
cacheex_allow_request = //allow send ecm requests (default=1, as svn)
#####cacheex incoming filter#####
cacheex_maxhop = //max incoming cw hop (default=10, as svn)
cacheex_drop_csp = //drop incooming cache from csp (deafult=0, as svn)
caid = //incoming caid filter (default all)
ident = //incoming ident filter (default all)
services = //incoming services filter (default all). Take attention: if we have too much sids to check, incoming push could slowly!


User send cws (and if cacheex_allow_request=1, answer to ecm requests too):

[account]
user =
pwd =
group =
no_wait_time = //ignore wait_time at incoming ecm request (it works for not cacheex users too)
cacheex = 2
cacheex_allow_request = //allow incoming ecm requests (default=1, as svn)
#####cacheex outgoing filter#####
cacheex_maxhop = //max outgoing cw hop (default=10, as svn)
cacheex_drop_csp = //not send cache recived from csp (deafult=0, as svn)
caid = //outgoing caid filter (default all)
ident = //outgoing ident filter (default all)
services = //outgoing services filter (default all). Take attention: if we have too much sids to check, outgoing push could slowly![/TD]
[/TR]
[/TABLE]
[/TD]
[/TR]
[/TABLE]


Patch in trunk at commit #9093
Hab es seit ca. 4 Tagen laufen und geht wie geschmiert.
ca. 60% weniger CPU-load und CE mode2 läuft jetzt auch wie er sollte.

Gruß
janni1
 
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!

Nein, noch immer 70% oder mehr (mit 2 Instanzen und waittime -->1702:5:1900,1830:5:490)

Aber mal schauen was sie "drüben" als Antwort für dich haben. Bin mal gespannt!

€: In der UserInstanz allerdings noch die 9065, vielleicht gehts deshalb noch.
 
Zuletzt bearbeitet:
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!

Na toll. Da lernt man was dazu und schon kommt es offiziel im trunk :)
Trotzdem geil. Und danke fuer die info.

Weis jemand zufaellig wo die datei header ist beim simplebuild? Weis noch früher konnte ich z.b den titel in der web if aendern von oscam.


Gesendet von meinem GT-I9505 mit Tapatalk 2
 
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!

Hi,
unter
simplebuild/oscam-svn/webif/include/
hast du die header.html
dort findest du auch die
css.css um Schriftgröße und Farbe usw. zu ändern.

@Link Removed
bei mir läuft auch alles wie immer mit 2 Instanzen 94% Cache (r9072 mit HT-Patch).

Gruß
janni1
 
Zuletzt bearbeitet:
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!

So endlich daheim.

9096 (Patch habe ich rausgenommen von den einstellungen) lüppt 1 A!

Macht ihr Supress CMD08 an bei cs378x??
 
Zuletzt bearbeitet von einem Moderator:
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.





Könnte das ein Einstellungsfehler sein von mir?

MfG
solo1999
 
AW: Oscam mit CacheEX und Loadbalancer. Bild bleibt beim Switchen stehen!

Bei deinen Ignore Werten gehe ich mal davon aus das du viele Billig Receiver dran hast ;)
Und dadurch wird deine Rechnung so verfälscht!

Und wenn du dann mal zurück rechnest dann kommst du auch auf gute Werte.

100 / ("Alle OK" + "Alle Cache") * "Alle Cache" = Echte Prozentwerte

Bei dir wurden 28,03% vom Cache beantwortet.
 
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:

[TABLE="class: ECM_totals"]
[TR]
[TH]ECM's Positiv[/TH]
[TH]ECM's Negativ[/TH]
[/TR]
[TR]
[TH]READERs / CACHE1,2,3[/TH]
[TH]NOK / IGN / TOUT[/TH]
[/TR]
[TR]
[TD="class: centered"]4.47% / 95.53%[/TD]
[TD="class: centered"]26.09% / 0.87% / 73.04%[/TD]
[/TR]
[TR]
[TD="class: centered"]358784 (99.68%)[/TD]
[TD="class: centered"]1152 (0.32%)[/TD]
[/TR]
[/TABLE]

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.

Gruß
janni1
 
Zuletzt bearbeitet:
Zurück
Oben