Zu schnelle CWs vom Reader verwerfen

[el_malto]

CEX ist zum pushen von CWs. Hast du nur eine Server- und eine Clientbox macht es wenig Sinn.

Das ist mir klar. Aber davon habe ich doch nicht geredet...

 

[geohei]

Zum "cacheex_cw_check", folgendes steht im Streamboard Wiki dazu:

Wenn ich das richtig deute, wird immer auf die wait_time gewartet. Also selbst wenn du 2 gleiche CWs nach 30ms hast, wird auf die wait_time gewartet.
Somit kann der CW Count auch deutlich über 2 steigen.

Das ist IMHO schlecht formuliert. Ich hab's auch mehrmals lesen müssen, um es schliesslich auszuprobieren (eindeutig zweideutig). Es scheint so, dass wenn counter vor wait_time erreicht ist, der CW rausgeht! Der Unterschied von mode 0 und 1 ist nur, dass nach Ablauf von wait_time bei mode 0 der CW mit dem höchsten counter rausgeht, und bei mode 1 der CW nicht geschickt wird, sondern die Reader befragt werden (wenn die das mit cacheex_allow_request erlauben).

Sie müssen registriert sein, um Links zu sehen.

Das mit awtime und dwtime habe ich nicht begriffen. Ausserdem sieht man dwtime in geposteten Configs selten. Oder soll dwtime sein über das wir gerade reden (wie @DarkStarXxX) schreibt, dass immer gewartet wird. Dann müssten aber beide Zeiten eingetragen sein, was in meinen Beispielen nicht der Fall ist.

wait_time        = 09C4:300
cacheex_cw_check = 09c4:0:3

1. (ecm) user (09C4@000000/025B/0083/A7:FB8D7F59B653E4F2B7E14447A6EE1279): cache3 (269 ms) by prx1 (cw count 3)
2. (ecm) user (09C4@000000/025B/0083/A7:B9127F9353C1966D6BB6A7A2D1EEF703): cache3 (291 ms) by prx1 (cw count 4)
3. (ecm) user (09C4@000000/025B/0083/A7:45A2E5A37987C32DE93C4888CEC980E2): cache3 (301 ms) by prx1 (wait_time over)
4. (ecm) user (09C4@000000/025B/0083/A7:D4311315F2E57AA47C181ABA420ECF21): cache3 (301 ms) by prx1 (wait_time over) (cw count 2)
5. (ecm) user (09C4@000000/025B/0083/A7:165F27ED77AD3A386A4485EFA1AB358E): cache3 (301 ms) by prx1 (wait_time over) (cw count 3)

Denke jetzt einmal laut ...
1. Der counter wurde erreicht und CW geht vor Ablauf von wait_time raus.
2. Wie (1.), aber das hier sollte m.M. nach nicht passieren. Nehme an Timing Problem zwischen den Task?!
3. Der counter ist 1 oder 0 ???
4. wait_time wurde überschritten und es waren nur 2 CWs zum Vergleichen da.
5. Wie (4.) aber wieder mit Timing problem von (2.)?
Was meint ihr?

Das ist mir klar. Aber davon habe ich doch nicht geredet...

Sorry ... falsch verstanden.

[/QUOTE]

Dann würde der Cache 1/2 doch auch keinen Sinn ergeben oder? Wenn man mehrere Clienten mit unterschiedlichen Gruppen hat, müsste ja nur ein Client einen Sender gucken den ein anderer aufgrund der unterschiedlichen Gruppen nicht sehen "darf" und schon könnten alle Clienten den Sender gucken obwohl diese in anderen Gruppen sind...?

Stimmt, meine ich auch!

Ich habe das mit der zweiten Box (Auslöser der Proxies) jetzt 2 Tage getestet. Box_1 befragt die Proxies, wo dann die CWs zur CE-Instanz gepushed werden. Box_2 erntet die "guten" CWs aus der CE-Instanz. Scheint zu klappen da ich auf Box_1 Freezer habe und auf Box_2 fast keine mehr.

 

[janni1]

Hi,
kurz mal was zu zu den Waittimes.
In den meisten Configs sieht man z.B. solche Waittimes 100:200
Syntax wäre hier:
wait_time = [caid][&mask][@provid][$servid][:awtime][:]dwtime,n
Es handelt sich dabei um dynamische Waittime, denn awtime ist [optional],
D.h. es wird nur gewartet, wenn Hits im Cache registriert sind (abhängig von "max_hit_time")

Mit z.B. 100:300:0 würde man immer warten, egal ob man während "max_hit_time" schon mal für diesen Sender Hits empfangen hat.

Cachex2 verursacht freezer,vielleicht config problem ??

hi zusammen wie mein Titel schon sagt habe ich freezer unter CacheEx2 mit cs378x als protocol !! Aktuelle OScam ist im einsatz Clienten sind Dreambox und Vu+ also keine krüppel CCcam etc ... Freezer sind unter Sky De und Sky Italy obwohl ich die per cline drin habe poste euch mal meine...

www.digital-eliteboard.com