CacheEx Freezer Zeit senkt sich ?!

Anton65 · 17. März 2017

So jetzt war das im Log
Alle Drop cw

Code:

2017/03/17 09:30:18 00000000   (cwccheck) cyclecheck [Bad CW Cycle] for:  1830@000000/0000/EF10/92:05821299C4CA48D6AE6D425D5C2468E8 from: cache -> drop cw (ECM Answer)
2017/03/17 09:44:48 00000000   (cwccheck) cyclecheck [Bad CW Cycle] for:  1830@000000/0000/EF10/92:544F25C817D409F4DD3F5470F4A858F4 from: cache -> drop cw (ECM Answer)
2017/03/17 09:44:58 00000000   (cwccheck) cyclecheck [Bad CW Cycle] for:  1830@000000/0000/EF10/92:F0968107051A59788DFE3CC714BEBE90 from: cache -> drop cw (ECM Answer)
2017/03/17 09:47:48 00000000   (cwccheck) cyclecheck [Bad CW Cycle] for:  1830@000000/0000/EF10/92:B31408CF23C72C160CAE45FF77FF3EB4 from: cache -> drop cw (ECM Answer)
2017/03/17 13:37:25 1E491B06 c (cwccheck) cyclecheck [Bad CW Cycle] for:  1830@000000/0000/EF75/92:B931D6C0456042E71A8420BEF8D0B880 from: cache -> ECM Answer is too OLD -> drop cw (ECM Answer)
2017/03/17 13:37:26 40E83FED p (cwccheck) cyclecheck [Bad CW Cycle] for:  1830@000000/0000/EF75/92:B931D6C0456042E71A8420BEF8D0B880 from: HD01-3 -> ECM Answer is too OLD -> drop cw (ECM Answer)
2017/03/17 13:37:26 01FB4781 p (cwccheck) cyclecheck [Bad CW Cycle] for:  1830@000000/0000/EF75/92:B931D6C0456042E71A8420BEF8D0B880 from: HD01-2 -> ECM Answer is too OLD -> drop cw (ECM Answer)

Log vom user

Code:

2017/03/17 09:29:58 31F8D79C c      (ecm) (1830@000000/0000/EF10/92:784C31F52A069CCCC90A22F5DAAC4BD1): cache3 (313 ms) by Local-Cache - RTL HD (cwc OK)
2017/03/17 09:30:08 31F8D79C c      (ecm)  (1830@000000/0000/EF10/92:65B7F41019E0CCC5C90A22F5DAAC4BD1): cache3 (321 ms) by Local-Cache - RTL HD (cwc OK)
2017/03/17 09:30:18 00000000   (cwccheck) cyclecheck [Bad CW Cycle] for:  1830@000000/0000/EF10/92:05821299C4CA48D6AE6D425D5C2468E8 from: cache -> drop cw (ECM Answer)
2017/03/17 09:30:18 31F8D79C c      (ecm)  (1830@000000/0000/EF10/92:65B7F41019E0CCC59BCD94FC069807A5): cache3 (322 ms) by Local-Cache - RTL HD (cwc OK)
2017/03/17 09:30:28 31F8D79C c      (ecm)  (1830@000000/0000/EF10/92:40272188DD143D2E9BCD94FC069807A5): cache3 (313 ms) by Local-Cache - RTL HD (cwc OK)
2017/03/17 09:30:38 31F8D79C c      (ecm)  (1830@000000/0000/EF10/92:40272188DD143D2E54D7CEF93E023F7F): cache3 (321 ms) by Local-Cache - RTL HD (cwc OK)

Gab es dort jetzt einen freezer ?

janni1 · 17. März 2017

Hi,
nein, um 09:30:18 gab es beim Client keinen Freezer.
Das falsche CW wurde erkannt und gedropt.
Den Cycle sieht man sehr schön im Log.

...(1830@000000/0000/EF10/92:784C31F52A069CCCC90A22F5DAAC4BD1): cache3 (313 ms) by Local-Cache - RTL HD (cwc OK)
...(1830@000000/0000/EF10/92:65B7F41019E0CCC5C90A22F5DAAC4BD1): cache3 (321 ms) by Local-Cache - RTL HD (cwc OK)
... 1830@000000/0000/EF10/92:05821299C4CA48D6AE6D425D5C2468E8 from: cache -> drop cw (ECM Answer)
...(1830@000000/0000/EF10/92:65B7F41019E0CCC59BCD94FC069807A5): cache3 (322 ms) by Local-Cache - RTL HD (cwc OK)
...(1830@000000/0000/EF10/92:40272188DD143D2E9BCD94FC069807A5): cache3 (313 ms) by Local-Cache - RTL HD (cwc OK)
...(1830@000000/0000/EF10/92:40272188DD143D2E54D7CEF93E023F7F): cache3 (321 ms) by Local-Cache - RTL HD (cwc OK)

Auf dem Server müsstest du noch einen Fallback (Allow Bad Cycle from Fixed Fallback) einrichten, der im Ernstfall immer ein korrektes CW liefern kann, am besten eine Karte.
Dafür im WebIf unter Cache das Häkchen setzen und bei einem HDplus-Reader das Häkchen bei "Fallback" machen.

Anton65 · 18. März 2017

Würde es so reichen ?Soll ich den Fallback bei allen drei HD01 Karten aktivieren ? Und das mit dem Loadbalancer habe ich nicht ganze verstanden weil ich benutze den Loadbalncer für 3 HD01 Karten.

Das habe ich nicht verstanden ?

Gilt nicht, wenn Loadbalancing aktiviert ist!
Definiert diesen Reader als Fallback. Standard- und Fallback-Reader müssen in der selben Gruppe sein. Siehe group!

Passt die confic so oder muss ich noch was verändern ?

cache confic

Code:

[cache]
delay                         = 10
max_time                      = 10
max_hit_time                  = 300
wait_time                     = 0500:800,098C:250,09C7:320,0D95:800,1830:400,183D:800,1834:750
cacheexenablestats            = 1
cwcycle_check_enable          = 1
cwcycle_check_caid            = 1830
cwcycle_allowbadfromffb       = 1

Reader

Code:

[reader]
label                         = HD01-1
description                   = xxxxx
protocol                      = cs378x
device                        = xxxxx
user                          = xxxxx
password                      = xxxxx
services                      = hd+
lb_whitelist_services         = hd+
keepalive                     = 1
fallback                      = 1
caid                          = 1830
ecmwhitelist                  = 1830:92
group                         = 5

janni1 · 18. März 2017

Hi,
die Formulierung aus dem Wiki ist etwas veraltet

So, wie du es jetzt hast, wäre es richtig
nur max_hit_time ist etwas "gewagt". Dort solltest du wenigstens eine Null streichen.

Anton65 · 18. März 2017

max_hit_time kannst du mir das erklären was genau das ist. Weil vom wiki werde ich nicht schlau drauß

Code:

Maximale Zeit, die Treffer für cache exchange im cache verbleiben müssen um wait_time zu evaluieren, default: 15

Und soll ich den Falback bei allen HD01 Karten setzten ?

Und das Passiert auch manchmal was kann das bedeuten ?

Code:

2017/03/18 09:57:33 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:715241042CAC26FE44ED0738F17AFC67): cache3 (163 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:57:43 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:715241042CAC26FE6DB41C3D5B2BAF35): cache3 (149 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:57:53 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:7AFFE35C722030C26DB41C3D5B2BAF35): cache3 (348 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:58:03 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:7AFFE35C722030C2B5ABE74776328F37): cache3 (164 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:58:08 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:00000000000000000000000000000000): not found (831 ms) by Tivusat - Rai 1 HD (wait_time over)
2017/03/18 09:58:19 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:DA2B7E830C0E2E48B5ABE74776328F37): cache3 (10 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:58:23 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:DA2B7E830C0E2E4856447E185579CD9B): cache3 (161 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:58:33 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:46CFEAFFFC8E4BD556447E185579CD9B): cache3 (157 ms) by Local-Cache - Rai 1 HD

janni1 · 18. März 2017

Hi,
Mit "max_hit_time" bestimmt man, wie lang die Hits "gespeichert/registriert" werden, um z.B. auch nach "Lücken im Cache" die dynamische Waittime auszulösen.
Der Standardwert (15) geht da schon in Ordnung, das sind ja meist etwas mehr als zwei ECMs.

Bei 1830 sollte ein Fallback reichen, denk ich.

not found (831 ms) by Tivusat - Rai 1 HD (wait_time over)

bedeutet, einfach nichts passendes im Cache nach Ablauf der Waittime.
Evtl kannst du die Waittime etwas erhöhen, ansonsten ist es halt einfach eine Lücke im Cache.

Anton65 · 18. März 2017

Vielen Lieben Dank für die ganzen hilfreichen Tipps

Ein Frage hätte ich noch warum kommt das hier noch

Und das Passiert auch manchmal was kann das bedeuten ?

Code:

2017/03/18 09:57:33 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:715241042CAC26FE44ED0738F17AFC67): cache3 (163 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:57:43 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:715241042CAC26FE6DB41C3D5B2BAF35): cache3 (149 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:57:53 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:7AFFE35C722030C26DB41C3D5B2BAF35): cache3 (348 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:58:03 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:7AFFE35C722030C2B5ABE74776328F37): cache3 (164 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:58:08 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:00000000000000000000000000000000): not found (831 ms) by Tivusat - Rai 1 HD (wait_time over)
2017/03/18 09:58:19 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:DA2B7E830C0E2E48B5ABE74776328F37): cache3 (10 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:58:23 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:DA2B7E830C0E2E4856447E185579CD9B): cache3 (161 ms) by Local-Cache - Rai 1 HD
2017/03/18 09:58:33 7F2D6725 c      (ecm) xxxxxxxx (183D@000000/0000/0D49/91:46CFEAFFFC8E4BD556447E185579CD9B): cache3 (157 ms) by Local-Cache - Rai 1 HD

janni1 · 18. März 2017

siehe
Talk - CacheEx Freezer Zeit senkt sich ?!

Außerdem stimmt hier das Timing des Clienten nicht.
Die Anfrage hätte genau 09:58:13 kommen müssen, dann hätte alles geklappt.

Anton65 · 18. März 2017

Also sollte ich dan dort auch ein fallback setzten oder ?

Osprey · 27. März 2017

janni1 schrieb:
Hi,
dein Cyclecheck ist scheinbar nicht aktiv.

Die beiden FakeCws

könntest du aber in die oscam.fakecws schreiben und dann so verfahren,

Guten Morgen,

ich jetzt einige Tage die beiden FakeCws eingetragen und gestern gemerkt das kaum mehr gepusht wurde. Geschätzt ist die Rate 90% weniger. Habe das allerdings erst gestern gemerkt und so ist das paar Tage gelaufen. 1830 habe ich garnicht im CS2.

janni1 · 27. März 2017

Hi,
@Osprey,
auf welchem Gerät läuft bei dir CacheEx?
Manchmal ist das "nicht mehr pushen" ein Indiz für Überlastung des Systems.

Es werden bei eingetragenen .fakecws ALLE eingehenden CWs verglichen, das kann uU. einen hohen Load verursachen.

Osprey · 27. März 2017

Leistung dürfte kein Problem sein. Läuft mit 2gb Ram und 3.4ghz cpu. Es läuft nur 2x oscam und openvpn.

janni1 · 27. März 2017

Hi,
seltsam
wenn du die beiden CWs wieder löschst bzw.cacheex_block_fakecws deaktivierst, dann pushst du wieder 100% ?
Wenn nicht, dann nur noch 10% ?

Wie hoch ist dein CacheSize etwa?
Wieviel Gots/pushs hast du etwa pro Stunde?
Wie hoch ist dein Load, mit und ohne _block_fakecws ?
Welche oscam.version benutzt du zur Zeit?

Osprey · 28. März 2017

Guten Morgen,

janni1 schrieb:
wenn du die beiden CWs wieder löschst bzw.cacheex_block_fakecws deaktivierst, dann pushst du wieder 100% ?
Wenn nicht, dann nur noch 10% ?

habe das jetzt mal nochmal genau beobachtet und irgendwie hatte ich ein Fehler drinnen es wird zwar etwas weniger aber nicht viel mehr. Hier das Ergebnis von 1 Minute mit Block_FakeCw und einmal ohne:
Ohne:

Code:

System    last 1 minute: 0.05    last 5 minutes: 0.04    last 15 minutes: 0.06
                 push  Pushing 1196364    got  Getting 713989    hit: 0 (0.00 %)    size: 613
nach 1Minute      Pushing 1214270    got  Getting 724604    hit: 0 (0.00 %)    size: 557
                                    17906                      10615

Mit

Code:

System  last 1 minute: 0.02    last 5 minutes: 0.05    last 15 minutes: 0.05

                    push  Pushing 31564    got  Getting 19770    hit: 0 (0.00 %)    size: 537
nach 1Minute         Pushing 44367    got  Getting 27375    hit: 0 (0.00 %)    size: 546
                                       12803                      7605

janni1 · 28. März 2017

Hi,
ich denke das wäre dann normal so, denn dein Size hat sich ja kaum geändert.
Wenn ich mich recht erinnere, sammelst du doch auch die 1843

Diese ist ebenfalls von den beiden Fakes betroffen.

Durch die oscam.fakecws werden diese nun nicht mehr in deinen Cache gelassen und somit auch von dir nicht weiter gepusht.
Im CacheTab siehst du dann auch die Verursachen, nämlich die mit den höchste ERR-Anstiegen nach dem Eintragen der .fakecws.
Diesen Partnern würde ich an deiner Stelle eine oscam.fakcws ans Herz legen, um ebenfalls den Verursache herauszubekommen.... usw...usw...

Danach müsste es bei dir dann keinen Unterschied mehr machen, ob mit oder ohne .fakecws.

Vielleicht kommt man so mal an die Wurzel des Übels

Suche

Suche

CacheEx Freezer Zeit senkt sich ?!

Anton65

Guest

janni1

Anton65

Guest

janni1

Anton65

Guest

janni1

Anton65

Guest

janni1

Anton65

Guest

Osprey

janni1

Osprey

janni1

Osprey

janni1

Ähnliche Themen

Spenden Unterstützung