Welke 'max_cache_time' met CD NL?

[DBdrug]

Op welke waarde kan je de 'max_cache_time' nou het beste zetten in combinatie met een oranje CD NL kaart?

 

Heb de waarde een poos gehad op 8 (sec.), maar krijg de laatste weken regelmatig zwart beeld op verschillende zenders (o.a. RTL4 HD, SBS6 HD, Net5 HD). Oscam geeft dan wel ECM OK, maar beeld freezed. Het lijkt er dan op dat ik een verkeerde (te oude) ECM uit de cache krijg. Met instelling op 6 lijkt het beter, maar ook dan nog weleens freezers, dus de 100% oplossing is dit niet. Zes seconden lijkt me ook aan korte kant voor CD NL.

 

Vraag me verder nog af wanneer je de instellingen 'cachedelay' zou willen danwel kunnen gebruiken. Wanneer is dit toepasbaar en met welke reden? Ligt hier misschien de oplossing voor de freezers?

 

[theparasol]

Settings waar je geen verstand van hebt zoek je op in de oscam wiki en moet je verder voorlopig maar gewoon default laten staan.

Ik ga het niet eens meer toelichten. Dat knutselaars problemen tegenkomen is een reden om ipv oscam maar cccam te gaan gebruiken.

[DBdrug]

Settings waar je geen verstand van hebt zoek je op in de oscam wiki en moet je verder voorlopig maar gewoon default laten staan.

Ik ga het niet eens meer toelichten. Dat knutselaars problemen tegenkomen is een reden om ipv oscam maar cccam te gaan gebruiken.

 

Uiteraard heb ik de wiki gelezen. De vraag is toch ook welke waarde de max_cache_time het beste kan krijgen met een CD NL kaart, niet wat deze instelling doet?! Antwoord hierop staat echt niet op de wiki..!!

 

De uitleg van de cachedelay setting volg ik ook, maar zie niet in wanneer dit nuttig zou kunnen zijn. Is dit nou zo'n gekke vraag? Staat op de standaard '0' bij mij.

 

Ik zie geen reden mij een knutselaar te noemen, ben juist iemand die OSCam wil finetunen. Ben dan ook teleurgesteld in je antwoord, sorry.

20 februari 2013 aangepast door DBdrug

[Toppers]

Tot revisie 8369 gebruikte ik max_cache_time = 13 !!

 

Met de komst van CW-cycle patch in de trunk zelf (af 8370) zijn de instellingen compleet veschillend en hebben we een

verandering in oscam.conf naar de rubriek [cache] waarbij alle instellingen naartoe zijn verhuisd.

 

@theparasol is denk ik met het verkeerde been uit bed gestapt. Normaal is hij veel aardiger en behulpzaam. Maar hij is de weg in het bos ook een beetje kwijt denk ik. Hij weet als oscam-developer donders goed dat het nu nog een beetje aanklooien is met de Oscam-WiKi speciaal voor het gedeelte cache. Zelfs zijn develop-collega's (voor de rubriek cache) zijn nog aan het experimenteren/zoeken (nog) naar de juiste parameters.

[Hotzenwalder]

Veel succes met zoeken in de WIKI.... OScam is zo aan veranderingen onderheving dat de WIKI het soms niet kan bijhouden. Feit is wel dat je een bovengemiddelde kennis en interesse in softcams moeten hebben om OScam goed aan de praat te krijgen en te houden. Wil je daar geen tijd insteken dan kun je het beste met CCcam blijven werken. Dat is zo goed als uitontwikkeld en werkt meestal.

 

Freezes komen meestal door peers die hun CNL kaarten niet goed hebben ingesteld met OScam Geen SID limiet etc. Wat de cachetijd betreft is het gewoon een kwestie van experimenteren tot de juiste balans hebt gevonden tussen maximale cachehits en minimale freezes.

[DBdrug]

Veel succes met zoeken in de WIKI.... OScam is zo aan veranderingen onderheving dat de WIKI het soms niet kan bijhouden. Feit is wel dat je een bovengemiddelde kennis en interesse in softcams moeten hebben om OScam goed aan de praat te krijgen en te houden. Wil je daar geen tijd insteken dan kun je het beste met CCcam blijven werken. Dat is zo goed als uitontwikkeld en werkt meestal.

 

Freezes komen meestal door peers die hun CNL kaarten niet goed hebben ingesteld met OScam Geen SID limiet etc. Wat de cachetijd betreft is het gewoon een kwestie van experimenteren tot de juiste balans hebt gevonden tussen maximale cachehits en minimale freezes.

 

Ben behoorlijk onderlegd qua OSCam kennis inmiddels, loop al tijd mee op diverse forums. CCcam is prima en simpel op clients, voor de server en een (wat) meer geavanceerde configuratie ben je toch op OSCam aangewezen!

 

Het feit dat ik deze waarde opvraag, is om niet 'eindeloos' te hoeven proberen. Ik ga ervan uit dat iemand wel de 'meest ideale' instelling inmiddels had gevonden i.c.m. de (oranje) CD NL kaart. Met de waarde van 8 had ik lang geen problemen, maar vermoedelijk heb ik inmiddels 'stafpunten' op mijn kaart, met freezes tot gevolg. Zie hier: http://openpli.org/forums/topic/27856-history-hd-dut-hangt/page__st__60

 

De freezes hebben dus zeer waarschijnlijk niets met de max_cach_time te maken, laat deze (voorlopig) mooi op 8. Tenzij iemand betere ervaringen heeft met andere waardes. 

21 februari 2013 aangepast door DBdrug

[theparasol]

Wat wil je nu bereiken? met het verhogen van de max_cache_time (standaard 15) worden controlwords langer dan 15 seconden bewaart in de cache. Dat is in elk geval niet nuttig voor canaldigitaal want daar zijn ze slechts 10 seconden houdbaar. Dus elke waarde hoger of gelijk aan 10 is prima. Ga je lager zitten kan dat nadelig zijn omdat dan controlwords opgeruimd worden die mogelijk nog bruikbaar zijn.

 

De cache-delay (standaard 0) alleen zinvol als er een cachehit gevonden is, dan delay je de uitgifte ervan met waarde X.

Hierdoor vertraag je dus alleen het controlword antwoord op een ecm aanvraag van een client. En ook alleen in geval dat die al in de cache stond en dus al eens opgevraagd was door een andere client of aangeleverd door een cache-exchange node.

 

Het ontgaat me dus compleet wat je hiermee denkt te kunnen finetunen aan oscam.

[Toppers]

Wat wil je nu bereiken? met het verhogen van de max_cache_time (standaard 15) worden controlwords langer dan 15 seconden bewaart in de cache. Dat is in elk geval niet nuttig voor canaldigitaal want daar zijn ze slechts 10 seconden houdbaar. Dus elke waarde hoger of gelijk aan 10 is prima. Ga je lager zitten kan dat nadelig zijn omdat dan controlwords opgeruimd worden die mogelijk nog bruikbaar zijn.

 

De cache-delay (standaard 0) alleen zinvol als er een cachehit gevonden is, dan delay je de uitgifte ervan met waarde X.

Hierdoor vertraag je dus alleen het controlword antwoord op een ecm aanvraag van een client. En ook alleen in geval dat die al in de cache stond en dus al eens opgevraagd was door een andere client of aangeleverd door een cache-exchange node.

 

Het ontgaat me dus compleet wat je hiermee denkt te kunnen finetunen aan oscam.

Je hebt gelijk, 10 of meer is het beste voor max_time in [cache]  welke tezamen met de "nieuwe" voorziening van CW cycle check af r8370 of hoger kan worden toegepast. Cache-delay hoef je niet toe te passen, vertraagd onnodig de cacheex3 behandeling.

 

@DBdrug

Jammer van @theparasol dat hij maar niet wil begrijpen dat je enkel wil finetunen en om extra hulp vraagt.

Denk dat ook het "andere been" wederom (voor de 2e keer) verkeerd uit bed is gestapt.

Natuurlijk moet je denken in allerlei richtingen/mogelijkheden, dat je je dan concentreert in de richting van cachetiming is logisch.

 

Ik denk zelf dat je de cardreader onder de loep moet nemen, ikzelf heb ook problemen gehad met "de strafpunten" op m'n oranje Seca3 card. Na een nachtje parkeren in de M7 "garage" geen problemen meer gehad, wel de volgende readerinstelling in gebruik (op Ubuntu)

 

[reader]

label                         = SecaOranje

description                   = kaartlezer

protocol                      = pcsc

device                        = 2

ecmwhitelist                = 0100@00006A:64

ecmheaderwhitelist    = 0100@00006A:803061006A00075C00,813061006A00075C00,800061006A00075C00,810061006A00075C00

detect                        = cd

mhz                           = 480

cardmhz                     = 357

group                         = 1

emmcache                 = 1,1,1

lb_weight                    = 500

auprovid                     = 00006A

ratelimitecm                = 4

ratelimitseconds         = 11

cooldown                    = 60,600

 

21 februari 2013 aangepast door Toppers

[DBdrug]

Ik begrijp dat ik de 'cache time' dus het beste op 10 (of hoger) kan zetten. Als ik kijk op de Wiki staat er nog het volgende bij:

maximum time CWs resist in cache after 1st client request, the time must be 2 seconds higher than the parameter clienttimeout. 

 

Oftewel de instelling 'cache time' beïnvloed dus indirect de client timeout instelling, dus moet dan dus naar 8 (uitgaande van 10 voor de cache time)? Of is de Wiki ook hierop niet actueel?

Zoals ik zelf ook al schreef, de freezes hebben vermoedelijk te maken met dat de 'stafpunten' teller voor mijn kaart te hoog staat/komt, niet de cache instelling (waaraan ik in eerste instantie wel zat te denken).

 

4/11 is volgens jou de meest ideale instelling? Maar aangezien ECMs maar een levensduur hebben van 10 sec. bij CD, wat gebeurt er dan in de seconde waarin je de reader nog niet mag bevragen, maar de ECMs wel zijn verlopen? 4/10 zie ik ook vaak voorbijkomen, maar ook wel 4/12. Wat is wijsheid?

 

De nieuwe CW Cycle Check, nog weinig info hierover te vinden, op de Wiki staat nog helemaal niets. Wat doet dit precies en welke voordelen biedt dit? Standaard staat het enabled bij versies > 8370, heb het op mijn 'test' server nu als volgt staan:

 

[cache]

delay                         = 0

max_time                      = 10

cwcycle_check_caid            = 0100

cwcycle_keeptime              = 10

cwcycle_onbad                 = 1

cwcycle_dropold               = 1

 

De laatste 3 parameters zijn mij niet helemaal duidelijk en dit komt natuurlijk vooral omdat de functie van de CW Cycle Check mij niet echt duidelijk is. Standaard staan deze waardes allemaal op 0, eigenlijk zou ik me bij de standaard moeten houden bedenk ik me, aangezien ik niet precies weet wat ik hiermee verander. Echter gevoelsmatig lijken me bovenstaande waardes beter. Waarom zou je de keeptime namelijk op 0 houden? Dan onthoudt OSCam niet de 'geleerde'  CW Cycle time voor X min., wat heb je er dan nog aan? En waarom zou een je bad of old ECM bewaren? Klinkt ook niet logisch, dus daarom beide op 1 gezet. Maar wellicht zit ik gewoon fout hierin, ik hoor het dan graag.

22 februari 2013 aangepast door DBdrug

[DBdrug]

@Toppers

 

Ik zie in jou ecmheaderwhitelist, 2 headers staan die hier niet te vinden zijn: http://www.streamboard.tv/oscam/wiki/HeaderWhitelist

 

Het gaat om: 800061006A00075C00,810061006A00075C00

 

Wat doen deze?

 

 

Ook heb ik  0100@00006A er niet voor staan, maar het lijkt altijd prima te werken. Biedt dat voorvoegsel ook meerwaarde?

22 februari 2013 aangepast door DBdrug

[DBdrug]

Config 'uitleg' van de CW Cycle Check:

 

oscam.conf (>= svn 8370)

[cache]
cwcycle_check_eanble = 0 or 1
cwcycle_check_caid = caid to check
cwcycle_maxelist = max Count of Cyclelist Entrys *Default 500 ** max 4000 Entrys*
cwcycle_keeptime = min Keep Learned Cycletime in Memory *Default 0 ** max 15 Min*
cwcycle_onbad = 0 only log ; 1 drop ECM
cwcycle_dropold = 0 or 1

[Aysun]

max_cache_time kan je gerust op 15 sec zetten (default). Canal Digitaal gebruikt voor haar eigen zenders 10 seconden, maar sommige zenders die gedeeld worden met buitenlandse providers kunnen korter of langer zijn. Ik geloof dat AutomotorsportHD 15 seconden is. Bij een aanvraag past maar 1 antwoord, dus een 2e aanvraag zal nooit beantwoord worden door het eerste antwoord (omdat die nog in de cache zit), omdat de aanvraag niet matcht met het antwoord. Dat snapt Oscam, dus het beste is om dit gewoon op 15 seconden te laten staan. Freezes ontstaan dus niet doordat een nieuwe aanvraag door een oud antwoord wordt beantwoord.

 

Wat betreft wait_time: dit is alleen nuttig als je cache uitwisselt met andere Oscam servers via de cacheexchange functionaliteiten. Je eigen Oscam zal dan een bepaalde periode wachten (die je instelt) voordat ie het zelf maar gaat oplossen. Tijdens het wachten is bij cache uitwisseling namelijk de kans aanwezig dat een andere Oscam server ook dezelfde zender al aan het decoderen is. Is na de wachttijd geen antwoord gekomen via de cache, dan zal Oscam het zelf aan een reader/peer vragen. Als je wait_time voor Canal Digitaal op 500 ms zet, dan zal de aanvraag dus binnen 500 + de tijd die de kaart normaal nodig heeft om een antwoord te geven (circa 300ms) beantwoord worden, indien er geen cache hit is. Dus in het geval van 500ms + 300ms is dat dus 800ms. Een volgende aanvraag wacht ie dan niet meer op een antwoord uit de cache voor deze zender. Pas als ie merkt dat er via de cache weer antwoorden binnenkomen voor deze zender zal ie weer overgaan op cache. Antwoord uit de cache zal gemiddeld zo'n 300ms zijn + de tijd die het nodig heeft om van de externe Oscam server naar je eigen Oscam server te komen (ruwweg de tijd die een ping naar de andere server kost).

Ik heb het zo ingesteld, voor CAID 0100 (CDS/TVV/en nog wat andere) wacht ik 500ms.

wait_time                     = 0100:500

 

Cachedelay is dus ook niet echt een nuttige toepassing.

 

CW Cycle is net nieuw in de trunk versie van Oscam, en vraag me ook niet hoe het precies werkt  Het enige dat ik weet is dat het kan voorkomen dat 'foute' antwoorden gebruikt worden. Bijv. omdat een kaart in de anticardshare modus is gesprongen. Deze instellingen gebruik ik en die werken prima:

 

cwcycle_check_caid            = 0100 (alleen CDS/TVV/en nog wat andere dus)

cwcycle_maxlist               = 4000 (maximaal 4000 items, dat is de max, en ik zie niet in waarom je dat lager zou willen zetten)

cwcycle_keeptime              = 15 (15 minuten lang onthouden wat de cycletijd was voor een zender, anders moet ie dat bij elke zap uitvinden)

cwcycle_onbad                 = 1 (indien een 'fout' antwoord is gevonden wil ik die dus niet gebruiken, dus droppen)

cwcycle_dropold               = 1 (en tevens oude antwoorden zijn niet meer nuttig en wil ik ook droppen)

 

En nog even wat betreft de 4/10, 4/11, 4/20, etc... Het belangrijkste is dat ie op 4 staat, dat voorkomt dat ie te veel gaat decoderen.

22 februari 2013 aangepast door Aysun

[DBdrug]

Yasun, bedankt voor je uitgebreide uitleg! Daarmee de anderen die gereageerd hebben niet tekort te doen, elke reactie is welkom!

[Toppers]

@Yasun, een heerlijke en correcte uitleg ! Zeer verhelderend

 

@DBdrug,  4/11 heb ik uiteindelijk proefondervindelijk gekozen omdat ik daarmee niet op het "strafbankje" kom.

Met 4/10 had ik soms freezes, met 4/11 lukt het bij mijn kaart 100% freeze-vrij (en de kaartlezer configregels zoals eerder gegeven)

[DBdrug]

@Yasun, een heerlijke en correcte uitleg ! Zeer verhelderend

 

@DBdrug,  4/11 heb ik uiteindelijk proefondervindelijk gekozen omdat ik daarmee niet op het "strafbankje" kom.

Met 4/10 had ik soms freezes, met 4/11 lukt het bij mijn kaart 100% freeze-vrij (en de kaartlezer configregels zoals eerder gegeven)

 

Maar met 4/11 en een ECM die maar 10 sec. geldig is, wat dan in die ene seconde die ertussen zit? Dus je vraagt 4 streams op, deze hebben elk elke 10 sec. een nieuwe ECM nodig, maar de rate limiter laat pas na 11 sec. toe?! Dit geeft geen freezes?? 

 

Andere vraag, als je maar 4 SIDs koppelt aan 1 kaart, heb dan ook nog iets als 4/11 nodig? Lijkt me niet, maar? Of geen maar?!

22 februari 2013 aangepast door DBdrug