Hi,
bitte laßt bei euren Überlegungen über die Höhe der Waittime nicht außer acht,
dass es sich bei den meisten hauptsächlich um "dynamische Waittime" handelt.
Also wenn der Sender nicht schon vorher irgendwie (max_hit_time) im Cache auftauchte, wird in der Regel überhaupt nicht gewartet.
Die Wahrscheinlichkeit ist dann ziemlich gering, dass was passendes im Cache auftaucht, weil keine der Partner gerade diesen Sender schaut.
Die Anfrage geht dann direkt an den Reader und somit wird dann auch der fehlende Cache für andere erzeugt und zwar mit Top-ECM-Zeiten.
Das gibts bei mir nicht, da ist nur die reine wait_time der maßgebende Faktor. Bei 110ms kommen sehr genau 99%+ aus cache3 (über Wochen ausgetestet). Das trifft auch ohnehin eher bei kleinerem cache zu, weil mit größerem cache immer irgendwer rumzappt. Also wird die Geschichte mit größerem cache etwas komplexer.
Aber auch bei kleinerem cache kann wohl keiner Power-Zapper und allgemein das Zappen rausfiltern oder ausschließen und genau da liegt der Hase im Pfeffer begraben.
Hi,
so sieht es bei mir ungefähr auf der CE-Instanz aus:
[cache]
max_time = 12
max_hit_time = 30
wait_time = 0:10000:0,09:450,18:1500,0B:3500,17:3500,01:1500,0 5:1500:0,06:2500
csp_allow_request = 0
wait_until_ctimeout = 1
Auf der Haupt-Instanz sind dann die richtigen Waittimes und der Cyclecheck mit den Fallbacks, ähnlich wie bei @hwmmc.
Hi,
@ maikyy
Sorry, ich kann dir leider nicht ganz folgen.
Wenn du 110er CWs im Cache hast, warum nutzt du sie dann nicht und erzeugst selber 140er ?
Wem nutzt das was? Das 140er CW geht mit in deinen Cache. Dort wird geschaut, ob es das schon mal gibt. Wenn ja wird nur der Count erhöht.
Dein Partner hat schon 30ms eher das 110er von dir bekommen, wenn es innerhalb seines Hops liegt.
Jetzt wird die Geschichte interessant. Ich gehe eigentlich davon aus, dass (real 65ms) im Cache landet oder beide und es damit nicht wertlos ist. Das kann dann wohl nur einer der im Code hängt aufklären.
Ohnehin habe ich im Streamboard schon die Zeilenlänge von wait_time bemängelt, aber bisher scheint es niemanden zu interessieren. Mit mehr zeichen könnte man sich nämlich Services sparen und stattdessen für jeden Sender eigene wait_times definieren.
Für mich ist das eine ganz klare Limitierung von Möglichkeiten, die nur mit 20 Instanzen umgangen werden kann und damit wird der Sinn und Zweck irgendwie verfehlt.
Hi,
@maikyyy
Ich hab es verfolgt im SB und finde den Ansatz sehr interessant.
Wann nun das CW im Cache auftaucht müßte man wirklich mal analysieren aber du könntest da durchaus Recht haben.
Ich werde das mal testen aber möglich wäre es schon so, wie du es annimmst. Ich hatte das so gar nicht auf dem "Schirm" :emoticon-0111-blush
Dann macht dein Vorgehen auch wieder Sinn.
Ich denke aber eher, dass Waittime abgewartet wird, bevor die Anfrage überhaupt an die Karte geht.
Also:
- ECM kommt vom Client rein
- abhängig von max_hit_time wird der Cache kontrolliert
- Waittime wird evaluiert
- es wird gewartet
- Ecm geht an die Karte
- CW kommt zurück und geht an den Clienten.
Also wäre die ECM-Zeit um Waittime verlängert worden und taucht auch mit dieser im Cache auf.
Sonst würde ja bei jeder Anforderung die Anfrage immer zuerst zum Reader gehen und danach würde dann Waittime gewartet.
Dann würde man ja nie seine Karte entlasten, oder?
Ja und? Noch immer Sinnvoller als z.B. Select-Kanäle mit Services ganz rauszufiltern weil mir die allgemeine wait_time nicht passt und ich habe viele Cacher die gerne auch Select bestellen... UND das auch auf 1702 oder 09C4!
Ausserdem war das eben nur ein Auszug, denn z.B. möchte ich bei Spocht 1-X (1-X HD) oder BL 1-X (1-X HD) kurze wait_times und bei FILM,WELT u Co. längere nutzen.
Aber so sind einem die Hände gebunden!
@janni1: Eben, mein ich doch. Sonst würden mein Partner schon abkotzen weil sie keine Hits landen
Hi.
@axfa77
so, wie auf der Grafik wäre es eine Möglichkeit.
Wattimes nur auf der CE-Instanz.
Viele, mich eingeschlossen, lösen es allerdings anders.
Man setzt sehr hohe Waittimes auf der CE-Instanz und regelt es dann mit passenden Waittimes auf der Hauptinstanz.
Das hat den Vorteil, dass man auch Partner per CE-Mode1 auf seine CE-Instanz lassen kann, ohne sie per Waittime zu beschneiden.
Die CE1-Partner können das dann individuell über ihre eigenen Waittimes regeln.
erstmal macht es wirklich Spaß sich mit Dir zu unterhalten. So, zurück zum Thema
Wie und wem der Hit dann letztendlich gutgeschrieben wird, ist so eine Geschichte für sich. Jedenfalls geht es dabei definitiv nicht nach Gruppeneinteilung. Schätzungsweise wird das CW mit dem niedrigsten Timer genommen. Hits kann man also alles in allem sehr gut als Kriterium für die Qualität eines Cache-Partnes verwenden. Damit kann man gut einschätzen ob jemand lokalen Cache generiert, oder einfach nur über 2 Hops durchreicht und lediglich einen Nutzen daraus ziehen möchte.
Damit kommen wir wieder zu einem anderen Problem, was ich bei CE1 über einen längeren Zeitraum beobachten konnte. Bei CE1 wird offensichtlich komplett auf eine Gruppeneinteilung geschissen und einfach alles im Cache an den abfragenden User weitergeben, egal welche Gruppen diesem zugewiesen sind. Zum Beispiel wurde bei CE1 sogar mein lokaler in die Instanz gepushter Cache trotz nicht zugewiesener Gruppe des Users zurück gegeben als cache3. Seitdem war für mich CE1 direkt erstmal erledigt!
Warum sollte man auch cache3 wait_time abwarten wenn der cache lokal da ist ohne Verzögerung?