Hoe oscam de cache-EX functie in te stellen met een peer

[Hotzenwalder]

Ik ben benieuwd hoe de settings zijn voor de local cards (reader) op beide servers. Wordt op de local ook een cacheed ingesteld van 3? Verder hoe de beide servers gekoppeld zijn. Voor de user op server 1 die de cache uitwisselt met server B en de omgekeerde settings.

 

Als je cachex instelt voor een server met een local naar een server zonder dezelfde local, heb je dan nog voordeel aan cacheex? Ook schijnen de waardes belangrijk te zijn van hoe lang je iets in de cache laat zitten. Is die tijd te lang dan kun je freezes krijgen.

 

Ik zoek een voorbeeld voor Ziggo (5555) met twee CAID 0604 locals

[DBdrug]

Als je cachex instelt voor een server met een local naar een server zonder dezelfde local, heb je dan nog voordeel aan cacheex? Ook schijnen de waardes belangrijk te zijn van hoe lang je iets in de cache laat zitten. Is die tijd te lang dan kun je freezes krijgen.

 

Wat is te lang? Standaard is 15 sec., normaal is een ECM toch zo'n 10 seconden (bij Canal Digitaal) geldig, is 15 dan te lang? Iemand een idee wat de beste instelling hier is in combinatie met CacheEx?

[Hemant]

Ja inderdaad je config is zeker van belang.

 

Deze moet je hebben staan anders is je cache te laat:

 

max_cache_time = 8

cachedelay = 10

 

Ik zet liever niet de complete config omdat dit onderwerp over exchange met peers gaat.

 

Je kunt niet zomaar cache aanzetten en dan denken dat het werkt, je moet een exacte met hebben met de user die er tegenover staat.

 

 

Elke cache user heeft een Cache reader anders werkt het concept niet.

 

Hemant

[Hotzenwalder]

Waarom die 10ms delay? Je krijgt dan toch een ecm uit de cache die te oud is of begrijp ik hem verkeerd?

[DBdrug]

Ja inderdaad je config is zeker van belang.

 

Deze moet je hebben staan anders is je cache te laat:

 

max_cache_time = 8

cachedelay = 10

 

Hemant

 

 

max_cache_time moet lager dan levensduur ECM, waarom??

[DBdrug]

Optie: cacheex = 3

Als men dit geactiveerd heeft dan verloopt de cacheflow altijd maar door. Hierbij wordt niet een bepaalde ecm gevraagd maar krijg je alle ecms

Hierbij is het natuurlijk ook zaak dat je de settings goed hebt staan.

Veel mensen houden er geen rekening mee dat de cacheflow van user naar reader loopt net andersom als bij normaal gebruik.

Hierbij is het erg belangrijk dat je de group instelling goed hebt staan.

Heb je dit goed staan zul je merken dat je veel hits vanuit je cache zult krijgen.

 

Bij beide optie moet men er wel rekening mee houden dat data verbruik over LAN wel flink kan oplopen zowel up als down.

 

Mijn persoonlijke voorkeur gaat naar cacheex 3 met de juiste settings.

Hierbij heb ik gezien bij mensen dat hierdoor zelfs meer als 50% van je ecm uit cache komen en dat IGN ofwel ignore maar een paar is.

Daar integen zie het eerste bericht met cacheex 1 kan dit ( IGN ) flink oplopen, heb gezien tot boven de 75% van al je ecm aanvragen.

 

 

Wanneer krijg je nou een IGN, ik weet 'IGNORE', maar wat betekent dit bij OSCam, wanneer gebeurd dit?

16 april 2012 aangepast door DBdrug

[bas4000]

Ja inderdaad je config is zeker van belang.

 

Deze moet je hebben staan anders is je cache te laat:

 

max_cache_time = 8

cachedelay = 10

 

Ik zet liever niet de complete config omdat dit onderwerp over exchange met peers gaat.

 

Je kunt niet zomaar cache aanzetten en dan denken dat het werkt, je moet een exacte met hebben met de user die er tegenover staat.

 

 

Elke cache user heeft een Cache reader anders werkt het concept niet.

 

Hemant

 

Waarom zou je je cache een delay geven ?

Oscam wacht dan 10 ms met het antwoord reactie tijd wordt dus 10ms langer

Zie hier niet echt doel van.

max_cache_time waarom zou je die 8 seconden maken als normaal ecm al 10 seconden duurt.

Heb hem zelf op 12 seconden staan heb geen problemen met freezes etc.

Enigste wat van groot belang is. Zorg ervoor dat je een van de laatste builds hebt hierin werkt cacheex pas goed

[Hemant]

@Bas,

 

als je die op 0 zet dat zal oscam geen tijd hebben om de cache op te bouwens alvorens weg te geven.

 

immers heb je ook en cache_write delay die parameter moet wel in sync zijn met de cache die je uitgeeft anders geef je veel minder cache hits.

 

Wat is het nut van 12 seconden als je ecm maar 10 seconden geldig is? krijg je een ecm uit cache die al velopen is dus lijkt me niet vestandig. indien je die op 8 seconden houd blijven je ecm caches altijd valid.

 

en waarom onder de 10 omdat de clock van je smartreader net even sneller tikt dna 1 echte seconde.

 

Hemant

[DBdrug]

Hierbij nog even een opmerking over cacheex mochten mensen hier toch mee willen gaan werken. (schrijf hier mijn mening)

Even klein beetje uitleg over cacheex 1 en 3 aangezien 1 en 2 erg op elkaar lijken

 

Optie: cacheex = 1

Als men deze optie op een reader ---> user activeert zal je alleen maar ecms krijgen die bij server in het cache staan daar in tegen stuur de oscam user wel alle ecm die aangevraagd worden op de server van de user naar de server. Zijn er 2 grotere servers met elkaar verbonden dan kunnen er makkelijk 25 ecms per seconden gevraagd worden. Heeft men de settings niet goed staan van oscam kan dit aantal van 25 al snel oplopen naar 10 of 20 keer zoveel. Dit ligt eraan of men zijn timout settings goed heeft staan. --> elke keer als oscam server antwoord geeft, dat hij ecm niet in het geheugen heeft staan timeout staat bv op 50ms dan krijgt user na 50ms antwoord terug dat het niet in cache staat dit doet hij net zolang totdat zijn ingestelde timeout ofwel timeout van de user verlopen is. Daarnaast loopt op deze manier je log lekker vol waarbij je oscam het drukker krijgt wegschrijven etc

 

Optie: cacheex = 3

Als men dit geactiveerd heeft dan verloopt de cacheflow altijd maar door. Hierbij wordt niet een bepaalde ecm gevraagd maar krijg je alle ecms

Hierbij is het natuurlijk ook zaak dat je de settings goed hebt staan.

Veel mensen houden er geen rekening mee dat de cacheflow van user naar reader loopt net andersom als bij normaal gebruik.

Hierbij is het erg belangrijk dat je de group instelling goed hebt staan.

Heb je dit goed staan zul je merken dat je veel hits vanuit je cache zult krijgen.

 

Bij beide optie moet men er wel rekening mee houden dat data verbruik over LAN wel flink kan oplopen zowel up als down.

Daarnaast zie ik persoonlijk bij de optie cacheex = 1 niet echt een toegevoegde naast gewoon gebruik van oscam alsmede cacheex 2 --> mocht oscam een ecm in het geheugen hebben staan zal hij deze toch gebruiken en niet weer een nieuwe ecm op je kaart aanvragen. Zie niet echt de toegevoegde waarde plus het vele extra gebruik van data, log dat vol loopt.

Mijn persoonlijke voorkeur gaat naar cacheex 3 met de juiste settings.

Hierbij heb ik gezien bij mensen dat hierdoor zelfs meer als 50% van je ecm uit cache komen en dat IGN ofwel ignore maar een paar is.

Daar integen zie het eerste bericht met cacheex 1 kan dit ( IGN ) flink oplopen, heb gezien tot boven de 75% van al je ecm aanvragen.

 

Houd er rekening mee dat dit cacheex veel geheugen inneemt niet echt iets wat je op je STB ( dreambox ofzo) wil hebben.

 

 

@bas4000

 

Na zelf uitgebreid getest te hebben met de Cache Exchange, ben ik van mening dat jouw uitleg wat rammelt, het klopt niet allemaal wat je schrijft.

 

Bij optie 1 wacht OSCam niet de timeout van de user af, maar alleen de tijd die staat ingesteld bij 'Cache ex waittime' (Configuration). De user timeout is niet van toepassing, OSCam geeft of direct antwoord indien hij de juiste ECM in cache heeft staan, of wacht de 'Cache ex waittime' af en geeft dan de juiste ECM of 'not found'. De ECMs worden actief opgevraagd door de reader, waarbij alleen antwoord kan komen uit cache van de server of een 'not found', er komen geen ECM antwoorden van een lokale kaart of connected server. Bij 2 servers (ontvangers) heb je aan beide kanten apart een user + reader nodig voor dit type cache exchange, en zowel user als reader op beide servers ingesteld op mode 1. Dus user + reader speciaal voor de cache exchange.

 

Bij optie 3 lopen de ECMs permanent van reader naar user, terwijl normaal de ECMs lopen van user (server kant) naar reader (client kant). Daarom heet het ook 'reverse cache push', ECMs worden gepusht van reader naar user. Het permanent laten lopen van de ECMs geeft ook bij mij betere resultaten dan zoals bij optie 1, al neemt het wel bandbreedte in beslag wat lang niet altijd nodig is (er worden ook ECMs gepusht die de andere kant helemaal niet gebruikt/nodig heeft). Bij 2 servers heb je aan beide kanten apart een user + reader nodig voor dit type cache exchange, en zowel user als reader op beide servers ingesteld op mode 3. Dus user + reader speciaal voor de cache exchange.

 

Bij optie 2 lopen de ECMs permanent van user naar reader, zoals normaal. Alleen vraagt de reader niet de ECM op, maar stuurt de user permanent de ECM cache van de server naar de reader toe. Ook hier geldt: het permanent laten lopen van de ECMs geeft vaak betere resultaten dan zoals bij optie 1, al neemt het wel bandbreedte in beslag wat lang niet altijd nodig is (er worden ook ECMs gepusht die de andere kant helemaal niet gebruikt/nodig heeft). Bij mode 2 krijgt de reader alle ECMs al van de server, maar kan toch ook nog ECMs bij de server actief opvragen, die het niet zelf in cache heeft of lokale kaart voor beschikbaar (zoals normale werking van een reader is). Bij 2 servers heb je aan beide kanten geen aparte user + reader nodig voor dit type cache exchange. Bij de 'gewone' user + reader die beide servers verbindt, Cache EX Mode instellen op 2, aan beide kanten uiteraard.

 

Optie 2 en 3 lijken dus meer op elkaar dan optie 1 en 2. Bij 2 en 3 lopen de ECMs permanent, alleen bij 3 andersom.

 

Welke mode je nu het best kunt gebruiken, hangt af hoe groot de servers zijn die je met elkaar verbindt. In een lokaal netwerkje met een paar ontvangers en lokale kaarten zou je mijns inziens prima af kunnen met mode 2, deze ene user en reader kan dan best al het ECM verkeer (de permanente stroom en de actieve aanvragen) aan.

 

Verbind je 2 'grotere' servers, dan is een aparte user en reader voor de cache exchange een betere optie i.c.m. mode 3. Dan hoeven de actieve ECM aanvragen niet via dezelfde user te lopen als de cache exchange.

 

TIP: kijk op de OSCam webinterface bij CACHEX, dit geeft je inzicht in wat er gebeurd en hoe succesvol de cache exchange is!

7 mei 2012 aangepast door DBdrug

[martjeB]

Ik heb ook de speciale cache reader en user aangemaakt en wat geprobeerd.

 

Als ik beiden op optie1 zet, krijg ik alleen beeld op de zender die in de cache staat. Dat lijkt me goed.

Zet ik beiden op optie3 dan krijg ik geen beeld op de film1 zenders ondanks de cache, waarschijnlijk omdat de user zelf deze zenders niet kan decoderen omdat die kaart een lager pakket heeft.

 

Als je 2 kaartjes hebt met verschillend pakket is 3 dus kennelijk geen goede keuze?

 

Als ik beide kaartlezers (dus met card) in hetzelfde netwerk op push (1) zet, hoef ik, volgens mij, geen speciale cache instellingen te doen maar pushed de reader weldegelijk de cache naar de andere kaartlezer.

Is die cache ex dan alleen zinvol bij het gebruik van een centrale server en niet bruikbaar voor 2 oscam servers onderling?