Dies ist eine mobil optimierte Seite, die schnell lädt. Wenn Sie die Seite ohne Optimierung laden möchten, dann klicken Sie auf diesen Text.

Warnung vor CacheEX Mode 1 Nutzung

    Nobody is reading this thread right now.
AW: Warnung vor CacheEX Mode 1 Nutzung

Eventuell hilft ja das hier weiter, aber wie so oft, hat das bestimmt noch keiner probiert!

cacheex_mode1_delay
Code: 
cacheex_mode1_delay  =  CAID1:time,[CAID2:time]...
Delay in Millisekunden für eine Anfrage an cache exchange mode 1 reader, default: kein delay
 
AW: Warnung vor CacheEX Mode 1 Nutzung

Das habe ich schon lange laufen.
Ändert aber nichts daran das es einen Waittime Bug gibt.

- - - - - - - - - -


Was denkst du warum es "Dynamische Waittime" heißt?
Weil die Waittime wieder auf 0 gehen soll wenn nichts mehr im Cache ist.
Und genau da liegt das Problem.
 
AW: Warnung vor CacheEX Mode 1 Nutzung

Dann stelle einfach in deiner Haupt-OScam auf prefer_local_cards = 2 um,
dann wird nur der Cache genutzt, wenn Reader/Proxies aussetzen bzw. sich stur stellen ...
 
AW: Warnung vor CacheEX Mode 1 Nutzung

DarkStarXxX schrieb:
Und das bleibt jetzt solange bis wieder Cache vorhanden ist in der CE Instanz.
Richtig wäre aber das die Waittime in der CE Instanz nach einiger Zeit auf 0 geht.
Zum Vergrößern anklicken....
Habe im oscam Wiki leider nichts darüber gefunden. Steht das im Streamboard, dass es so richtig ist?
 
AW: Warnung vor CacheEX Mode 1 Nutzung

Hi,
dafür sollte eigentlich "max_hit_time" zuständig sein und das klappt ja am Anfang auch.
Wenn von Anfang an auf der CE-Inst. nichts im Cache ist und man nur das eigene erzeugte CW reinpusht, wird auch keine Waittime ausgelöst.
Erst wenn "fremder Cache" einen Hit auslöst und dann ausbleibt und wir wieder unsere CWs reinpushen, geht Oscam davon aus,
dass unser eigenes, gepushtes CW ein potenzieller Hit gewesen wäre und löst die Waittime aus.
Normal sollte aber dann nach Ablauf von "max_hit_time" keine Waittime mehr ausgelöst werden und er dürfte unser CW dabei gar nicht beachten.

Die Ursache liegt also irgendwo am Handling der eigenen zurückgepushten CWs nach einem Hit. Wenn man nichts zurückpusht, läuft auch alles.

Man kann im CE-Mode1 nichts dagegen unternehmen.
"no_wait_time" bringt nichts, denn dann könnte man auch gleich aufhören CEX zu betreiben.

"cacheex_mode1_delay" ist eine Wartezeit für den CE1-Reader, um zu warten, ob vieleicht noch per CE2/3 was reinkommt, falls diese Modes in dieser Instanz auch noch laufen.
Aber sowas hat man ja auf seiner Haup-Inst. in der Regel nicht, sondern nur in Instanzen wo alles in einem läuft.
Dieser Parameter verschlimmert also den Effekt noch.

Auch diese Rechnung ist falsch.
Die eine Waittime hat mit der anderen nichts zu tun.
Nehmen wir an, die Waittime auf der CE-Inst wäre dynamisch bei 500ms, dann bekäme bei ausbleibendem Cache der CE1-User nach 500ms ein "not found (501 ms) (wait_time over)".
Auf der Haupt-Inst mit dynamischer Waittime von 200ms bekämen wir ein "found (300 ms) by xxx (P/2/2/2) (real 100 ms)"
Hier sollte die waittime bei CE1 auf der CE-Inst. etwas höher als auf der Haupt-Inst. sein, damit wir nicht vorher schon ein "not found" bekommen.

Gruß
janni1
 
Zuletzt bearbeitet:
AW: Warnung vor CacheEX Mode 1 Nutzung

Wo kommt der Cache eigentlich her? ... DD
Was ist wenn keiner da ist, wird dann der CE-Reader auf der Hauptinstanz angefragt?
Ganz klar ja, weil ja eigentlich jeder prefer_local_cards = 1 hat und somit entsteht Traffic.
... das Leben besteht nicht nur aus Cache
 
AW: Warnung vor CacheEX Mode 1 Nutzung

Hi,
ja genau. Das ist ja Sinn und Zweck vom CE-Mode 1.
Bei jeder Anfrage wird zuerst über den CE1-Reader geschaut, ob dort was passendes im Cache ist.
Wenn nicht, wird eine andere Quelle befragt. Woher sollte denn der CE1 Reader auch sonst wissen, ob da was im Cache des Partners ist.
Man lässt sich eben nicht alles pushen, sondern holt nur das, was man gerade braucht.
Und wenn wir schon beim Thema Traffic sind: im Gegensatz zu CE-Mode 1, bekomme ich bei CE-Mode 2 alles gepusht, ob ich es gerade brauch oder nicht.

Im übrigen geht es hier auch nicht darum, ob man diesen Mode nun gut findet oder nicht, sondern darum, dass er wahrscheinlich einen Bug hat.
Die, die ihn benutzt haben, wissen jetzt Bescheid und können reagieren.
Für die, die ihn nicht benutzt habe, ändert sich nichts.

Ist doch toll, dass es jemand bemerkt und mitgeteilt hat.

Gruß
janni1
 
AW: Warnung vor CacheEX Mode 1 Nutzung

janni1 schrieb:
Auch diese Rechnung ist falsch.

Hier sollte die waittime bei CE1 auf der CE-Inst. etwas höher als auf der Haupt-Inst. sein, damit wir nicht vorher schon ein "not found" bekommen.

Gruß
janni1
Zum Vergrößern anklicken....
Hi Janni,
verstehe es dnoch nicht ganz, aber mit deiner Hilfe wird es schon. Kannst du bitte mal erklären wie es aussieht Bsp.:

Hauptinstanz(zusätzlich noch lokale 098C Karte) 098C wait_time dynamisch 150ms
CE Instanz 098C wait_time dynamisch 100ms
Client fragt ab etwas, was nicht im Cache ist sondern nur lokal oder per proxy, dann wäre es für mich vom Verständnis her so:
Hauptinstanz -> fragt CE Instanz ab 100ms wait_time over -> geht zurück auf Hauptinstanz und wartet jetzt 150ms wait_time over -> fragt lokal Reader ab, der in 80ms antwortet: Summe bis Antwort kommt 330ms seit Anfrage. Ist das Falsch?

Danke schonmal.
 
AW: Warnung vor CacheEX Mode 1 Nutzung

Hi,
fast richtig, nur zwei kleine Fehler haben sich eingeschlichen.

- Die Waittimes sind verkehrt herum.
- Die Waittimes fangen auf beiden Instanzen, ab der Anfrage an zu laufen, also fast gleichzeitig.

In deinem Fall würde die CE-Inst. schon nach 100ms ein "not found" liefern aber
die Haupt-Inst. würde dann dummerweise noch weiter 50ms auf Cache warten, obwohl sie nirgendwo welchen herbekommen kann.
Danach fragt sie dann erst die Karte an.

Würde man es anders herum machen, würde die Haupt-Inst. nach 100ms aufhören zu warten und die Karte anfragen.
Die CE-Inst. würde 50ms später aufgeben. Das interessiert aber die Haupt-Inst. nicht mehr.

Vorausgesetzt ist dabei aber immer, dass die Waitime, durch max_hit_time auch ausgelöst wurde.

Normal sollte es so aussehen, bei ausbleibendem Cache, wenn alles läuft, wie es sollte. Bei mir mal mit 200/150ms im Testaufbau.

*_zyxel = Cacheserver/CE-Inst.
*-raspi = Haupt-Inst.
igel_* = Proxy/Karte
dream = normaler Client
cex-test = CE-Partner

CE-Inst. mit waittime = 200, max_hit_time = 15
  • 2015/07/30 10:11:34 14A878 c ce1-raspi (098C&000000/025B/0083/98:AB0E383C992E9D43AEF751640CE56600): cache3 (133 ms) by cex-test
  • 2015/07/30 10:11:42 14A878 c ce1-raspi (098C&000000/025B/0083/98:649B85EB3836DDA455105B084B6FAB81): not found (210 ms) (wait_time over)
  • 2015/07/30 10:11:49 14A878 c ce1-raspi (098C&000000/025B/0083/98:25230C9C41F111EA9EA14009EE981833): not found (204 ms) (wait_time over)
  • 2015/07/30 10:11:55 14A878 c ce1-raspi (098C&000000/025B/0083/98:B1AE0A33DE2A0254A9A789A1DDA407C5): rejected group (0 ms) (no matching reader)
  • 2015/07/30 10:12:02 14A878 c ce1-raspi (098C&000000/025B/0083/98:A9921BECB563FB9114F73D2CA6FAA4B9): rejected group (0 ms) (no matching reader)
Haupt-Inst. mit waittime = 150, max_hit_time = 10
  • 2015/07/30 10:11:34 300FA8 c (ecm) dream (098C&000000/025B/0083/98:AB0E383C992E9D43AEF751640CE56600): cache3 (136 ms) by ce1_zyxel (C/1/2/2)
  • 2015/07/30 10:11:42 300FA8 c (ecm) dream (098C&000000/025B/0083/98:649B85EB3836DDA455105B084B6FAB81): found (293 ms) by igel_cs357x (P/2/2/2) (real 143 ms)
  • 2015/07/30 10:11:49 300FA8 c (ecm) dream (098C&000000/025B/0083/98:25230C9C41F111EA9EA14009EE981833): found (284 ms) by igel_cs357x (P/2/2/2) (real 132 ms)
  • 2015/07/30 10:11:55 300FA8 c (ecm) dream (098C&000000/025B/0083/98:B1AE0A33DE2A0254A9A789A1DDA407C5): found (158 ms) by igel_cs357x (P/2/2/2) (real 156 ms)
  • 2015/07/30 10:12:03 300FA8 c (ecm) dream (098C&000000/025B/0083/98:A9921BECB563FB9114F73D2CA6FAA4B9): found (130 ms) by igel_cs357x (P/2/2/2) (real 127 ms)
Hier sieht man, dass die dynamische Waittime auf beiden Inst. wegfällt, wenn während "max_hit_time" keine Hits mehr registriert werden.
Aber genau das macht es eben nicht mehr, wenn man seine, so eben erzeugten CWs, zurück pusht.
Dort liegt irgendwo der Hund begraben.

Gruß
janni1
 
Zuletzt bearbeitet:
AW: Warnung vor CacheEX Mode 1 Nutzung

Hi jungs

im SB wurde ein tryfix bereitgestellt werde es testen wenn ich von der Arbeit kommen.

Vielleicht kann der ein oder andere das auch mal testen.

Gruss
 
Zuletzt bearbeitet:
AW: Warnung vor CacheEX Mode 1 Nutzung

Hi,
@Lui2004
Bin schon fleißig dabei!
Wer von den CacheExern auch mit testen will, hier mal der Patch.


Gruß
janni1
 
AW: Warnung vor CacheEX Mode 1 Nutzung

Sehr gut
darf ich fragen ob der tryfix verbesserungen mitbringt ?
 
AW: Warnung vor CacheEX Mode 1 Nutzung

Hi,
kann ich dir leider noch nicht sagen.
Muß erst mal wieder das Testsystem richtig stressen

Gruß
janni1
 
AW: Warnung vor CacheEX Mode 1 Nutzung

Funktionieren tut es anscheinend, aber irgendwie bekomme ich gerade verdächtig wenig CE3 Hits.

Edit: Es müssen beide Instanzen die neue Version drauf haben, dann sieht das ganze schon besser aus.


Code: 
    2015/07/31 17:09:39 03A21D93 c      (ecm) [CE1]-[DS]-[Test] (1702@000000/0000/001A/93:D1C97FDFE5DC5E805ABCC78D7D3F0CF3): cache3 (0 ms) by [x]-[CEX]-[Mode2]-[009]-[x] - Disney Junior (cwc OK)
    2015/07/31 17:09:46 03A21D93 c      (ecm) [CE1]-[DS]-[Test] (1702@000000/0000/001A/93:F1D7B1DF8FC7B3D71C959C0A8CCA0EB0): cache3 (1 ms) by [x]-[CEX]-[Mode2]-[009]-[x] - Disney Junior (cwc OK)
    2015/07/31 17:09:53 03A21D93 c      (ecm) [CE1]-[DS]-[Test] (1702@000000/0000/001A/93:17B5E18F87724C68016D7522DBB6A5DA): cache3 (1 ms) by [x]-[CEX]-[Mode2]-[009]-[x] - Disney Junior (cwc OK)
    2015/07/31 17:10:00 03A21D93 c      (ecm) [CE1]-[DS]-[Test] (1702@000000/0000/001A/93:6621FDF3858028411AA3F470C3487865): cache3 (0 ms) by [x]-[CEX]-[Mode2]-[009]-[x] - Disney Junior (cwc OK)
    2015/07/31 17:10:07 03A21D93 c      (ecm) [CE1]-[DS]-[Test] (1702@000000/0000/001A/93:87A0A4A3F66EFFE267C9ECF6B12DC03D): rejected group (0 ms) - Disney Junior (no matching reader)
    2015/07/31 17:10:14 03A21D93 c      (ecm) [CE1]-[DS]-[Test] (1702@000000/0000/001A/93:0B3D356E234C05E87419EC230BF4B48D): cache3 (0 ms) by [x]-[CEX]-[Mode2]-[009]-[x] - Disney Junior (cwc IGN)
    2015/07/31 17:10:21 03A21D93 c      (ecm) [CE1]-[DS]-[Test] (1702@000000/0000/001A/93:4F20647FE045BFFB6E8380C5937505AD): cache3 (0 ms) by [x]-[CEX]-[Mode2]-[009]-[x] - Disney Junior (cwc LEARN)
    2015/07/31 17:10:28 03A21D93 c      (ecm) [CE1]-[DS]-[Test] (1702@000000/0000/001A/93:1E3D72A6943E2E80E53A5E3293BBF9E8): cache3 (1 ms) by [x]-[CEX]-[Mode2]-[009]-[x] - Disney Junior (cwc OK)
    2015/07/31 17:10:35 03A21D93 c      (ecm) [CE1]-[DS]-[Test] (1702@000000/0000/001A/93:2E222C8E7C32C2A8D00F0E543F248D4E): cache3 (0 ms) by [x]-[CEX]-[Mode2]-[009]-[x] - Disney Junior (cwc OK)

Hmm da war noch Cache Delay Mode 1 gesetzt, ohne tut sich da nichts.

Oh glaube da ist jetzt ein neuer Bug. Sobald der CE User mehr wie eine Gruppe hat gibs keine Hits.
 
Zuletzt bearbeitet:
AW: Warnung vor CacheEX Mode 1 Nutzung

Hi,
@DarkStarXxX
Sobald der CE User mehr wie eine Gruppe hat gibs keine Hits.
Zum Vergrößern anklicken....
Kann ich bestätigen!
Bei mir sah es mit Patch am Anfang ganz gut aus. Genau wie es sein sollte.
Hab beim Test nur zwei passende CWs in den Cache gelassen, um zu schaun, ob die Waittime runter geht.

Haupt-Inst.
Config
[cache]
max_hit_time = 10
wait_time = 098C:150

[reader]
label = ce1_cex
protocol = cs378x
device = Ce-Inst,2223
user = ce1_main
password = ce1_main
keepalive = 1
cacheex = 1
group = 2

[reader]
label = V14_test
protocol = cs357x
device = Proxy/Karte,2222
user = V14_test
password = V14_test
caid = 098C
group = 1

[account]
user = dream
pwd = dream
group = 1,2

[account]
user = ce2_cex
pwd = ce2_cex
group = 1
cacheex = 2
Log
Code: 
2015/07/31 20:39:45 6D869433 c      (ecm) dream  (098C@000000/025B/0083/98:DE38F7749076169FA2F0A93D574ED74B): found (142  ms) by V14_test (P/2/2/2) - Sky Cinema HD (real 140 ms)
2015/07/31 20:39:52 6D869433 c      (ecm) dream  (098C@000000/025B/0083/98:185DA074D2517A65270F6C58F2744048): found (125  ms) by V14_test (P/2/2/2) - Sky Cinema HD (real 123 ms)
2015/07/31 20:39:59 6D869433 c      (ecm) dream  (098C@000000/025B/0083/98:18BA2A412797FF20D1D93AC91D8F2F2F): cache3 (139  ms) by ce1_cex (C/1/2/2) - Sky Cinema HD
2015/07/31 20:40:06 6D869433 c      (ecm) dream  (098C@000000/025B/0083/98:F9C50EA95021792FC9C4E645D38B021E): cache3 (125  ms) by ce1_cex (C/1/2/2) - Sky Cinema HD
2015/07/31 20:40:13 6D869433 c      (ecm) dream  (098C@000000/025B/0083/98:B4509C5F7B5F69AF74865981FACB9E95): found (267  ms) by V14_test (P/2/2/2) - Sky Cinema HD (real 117 ms)
2015/07/31 20:40:20 6D869433 c      (ecm) dream  (098C@000000/025B/0083/98:47018FFC88A590C303EE2112EEC5BB9C): found (275  ms) by V14_test (P/2/2/2) - Sky Cinema HD (real 125 ms)
2015/07/31 20:40:27 6D869433 c      (ecm) dream  (098C@000000/025B/0083/98:BD4BB35BFEB9C13CFECAF7035AC75FD0): found (141  ms) by V14_test (P/2/2/2) - Sky Cinema HD (real 139 ms)
2015/07/31 20:40:34 6D869433 c      (ecm) dream  (098C@000000/025B/0083/98:AC6FFDE81D743ABF8730BAA31B164EDB): found (133  ms) by V14_test (P/2/2/2) - Sky Cinema HD (real 130 ms)
2015/07/31 20:40:41 6D869433 c      (ecm) dream  (098C@000000/025B/0083/98:E1CF59D60C5289EF9C8B207B407378FB): found (124  ms) by V14_test (P/2/2/2) - Sky Cinema HD (real 123 ms)

Ce-Inst.
Config
[cache]
wait_time = 098C:500

[reader]
label = cex-test
protocol = cs378x
device = cache_partner.com,2224
user = test_ce2
password = test_ce2
keepalive = 1
cacheex = 2
cacheex_ecm_filter = 098C
group = 1

[reader]
label = ce2_main
protocol = cs357x
device = Haupt-Inst,2222
user = ce2_cex
password = ce2_cex
keepalive = 1
cacheex = 2
group = 2

[account]
user = ce1_main
pwd = ce1_main
group = 1
cacheex = 1
Log
Code: 
2015/07/31 20:39:45 686CE4A3 c      (ecm) ce1_main (098C@000000/025B/0083/98:DE38F7749076169FA2F0A93D574ED74B): rejected group (0 ms) (no matching reader)
2015/07/31 20:39:52 686CE4A3 c      (ecm) ce1_main (098C@000000/025B/0083/98:185DA074D2517A65270F6C58F2744048): rejected group (0 ms) (no matching reader)
2015/07/31 20:39:59 686CE4A3 c      (ecm) ce1_main (098C@000000/025B/0083/98:18BA2A412797FF20D1D93AC91D8F2F2F): cache3 (131 ms) by cex-test
2015/07/31 20:40:06 686CE4A3 c      (ecm) ce1_main (098C@000000/025B/0083/98:F9C50EA95021792FC9C4E645D38B021E): cache3 (118 ms) by cex-test
2015/07/31 20:40:13 686CE4A3 c      (ecm) ce1_main (098C@000000/025B/0083/98:B4509C5F7B5F69AF74865981FACB9E95): not found (500 ms) (wait_time over)
2015/07/31 20:40:20 686CE4A3 c      (ecm) ce1_main (098C@000000/025B/0083/98:47018FFC88A590C303EE2112EEC5BB9C): not found (501 ms) (wait_time over)
2015/07/31 20:40:27 686CE4A3 c      (ecm) ce1_main (098C@000000/025B/0083/98:BD4BB35BFEB9C13CFECAF7035AC75FD0): rejected group (0 ms) (no matching reader)
2015/07/31 20:40:34 686CE4A3 c      (ecm) ce1_main (098C@000000/025B/0083/98:AC6FFDE81D743ABF8730BAA31B164EDB): rejected group (0 ms) (no matching reader)
2015/07/31 20:40:41 686CE4A3 c      (ecm) ce1_main (098C@000000/025B/0083/98:E1CF59D60C5289EF9C8B207B407378FB): rejected group (0 ms) (no matching reader)
Sobald ich auf der CE-Inst. dem user "ce1_main" eine weitere Gruppe zu einem weiteren CE-Partner gebe, ist Schluß.
Code: 
2015/07/31 21:19:57 58F5D4BD c      (ecm) ce1_main (098C@000000/025B/0083/98:84CF24DE116DB98F59F4660C0489D4FD): rejected group (0 ms) (no matching reader)
2015/07/31 21:20:00 58F5D4BD c      (ecm) ce1_main (098C@000000/025B/0083/98:EDD531773DE09EDBFB725A6C434D256B): rejected group (0 ms) (no matching reader)
2015/07/31 21:20:07 58F5D4BD c      (ecm) ce1_main (098C@000000/025B/0083/98:EC951D1034EB8E9094577623A2BF2B43): rejected group (0 ms) (no matching reader)
2015/07/31 21:20:14 58F5D4BD c      (ecm) ce1_main (098C@000000/025B/0083/98:92A2A793319E0F7EB4C983CA5A4FD7B5): rejected group (0 ms) (no matching reader)

Steckt man dagegen beide CE-Partner in eine Gruppe und gibt dem CE1-User auch nur die eine, geht's wieder.
Code: 
2015/07/31 21:35:17 1E80C4B4 c      (ecm) ce1_main (098C@000000/025B/0083/98:B3B2A4687C650C8E3F3FDF81A68A616E): cache3 (124 ms) by cex-test2 (cw count 2)
2015/07/31 21:35:24 1E80C4B4 c      (ecm) ce1_main (098C@000000/025B/0083/98:E6F9320E064A379A2A1A49B99284C5C2): cache3 (128 ms) by cex-test2 (cw count 2)
2015/07/31 21:35:31 1E80C4B4 c      (ecm) ce1_main (098C@000000/025B/0083/98:5C57578D5148F7D6F584ECD0696F498A): not found (501 ms) (wait_time over)
2015/07/31 21:35:38 1E80C4B4 c      (ecm) ce1_main (098C@000000/025B/0083/98:BF6FBBBC74E0EAC14929DBE9C74A8E38): not found (501 ms) (wait_time over)
2015/07/31 21:35:45 1E80C4B4 c      (ecm) ce1_main (098C@000000/025B/0083/98:7B40C4543E34E8ECB0FE4DAB84F5277C): rejected group (0 ms) (no matching reader)
2015/07/31 21:35:52 1E80C4B4 c      (ecm) ce1_main (098C@000000/025B/0083/98:E96272B0A52F4FC95A5DC955C4023082): rejected group (0 ms) (no matching reader)

Gruß
janni1
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

L
Hilfe bei Config-Optimierung "CacheEX zwischen Haupt- & Cache-Instanz"
Antworten
2
Aufrufe
2K
Lillyann
L
L
oscam proxy als cacheex laufen lassen
Antworten
6
Aufrufe
2K
axel
T
dvbapiNET - mdvbapi Nachfolge
20 21 22
Antworten
325
Aufrufe
125K
twicko
T
R
*Verschoben* ChacheEx - Bei mir besteht das Problem mit den Freezern auch
Antworten
3
Aufrufe
953
Razor78
R
Neues CE-Feature um ggf. Load und Traffic zu minimieren
2
Antworten
29
Aufrufe
4K
janni1
Menü
Anmelden
Registrieren
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…