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.

LABERTHREAD zum Thema: Umstellung der SAT-Verschlüsselung bei Sky (Geschlossen)

Status
Für weitere Antworten geschlossen.
@p1ngb4ck , das passt schon was du schreibst, wenn hier alle ihren Cache aus einer Pay Line in einen freeserver pushen würden wäre es jetzt schon alles stabil und man würde den Payserver den Geldfluss abschneiden. Das wäre mal was
 
Das Ganze mit dem CacheEx sorgt übrigens auch dafür, dass man anhand der CW-Antwortzeiten etc eben nicht, auf eine "Entfernung zur Quelle" schließen kann. Dieser Gedankenweg schließt einfach etwas Essentielles aus : Die CacheEx WaitTime-Configs.

Was ist das/was soll das :

Wenn ein (zB kleinerer) PS seine Karten entlasten will, kann er das super per CE machen: alles was er tun muss, ist die Wait-Time kennen die für die jeweilige Karte/CAID gilt. Diese WaitTime gibt an, wie lange eine CW im Cache gesucht werden soll, bevor andere Quellen (Lines oder Lokale) angefragt werden). Wenn jmd zB darauf wert legt, dass es keine Minifreezes etc gibt, muss er wissen
- ab welcher Antwortzeit freezed es genau (maximale "saubere" found time).
- wie lang ist die latenz zum client
- wie lang braucht die karte (was nicht so einfach ist wie auf den 1. blick gedacht - da es ja möglich ist, dass diese ja auch gerade mehrere ECMs beantworten muss und daher die Antwortzeit der Karte auch in dieser Situation als dynamisch zu betrachten ist)

Man zieht dann von der "sauberen" max found time die latenz und die vorraussichtliche antwortzeit der lokalen/line ab, und hat die wait time, die man "safe" auf eine CW im Cache warten kann, ohne freezer zu erzeugen.

Wenn der CacheEx jetzt nicht sauber seine Peers und Configs im Griff hat, sind unter Umständen auch die CE-Peers von dynamischen WaitTimes etc betroffen, was die Antwortzeiten dann beeinflusst.

Kurzum : ECM-Antwortzeit != Entfernung zur Quelle. Dazu haben die Einstellungen zu viel Einfluss auf die Zeiten.

@chrisie : nope. für vernünftiges schauen muss cache immer mit line/local gebackupped sein.

schon wenn nur 5% der ecms nicht im cache gefunden werden, nervt das gucken nur noch mit freezern alle 10 mins
 
Zuletzt bearbeitet:
@p1ngb4ck ich glaube wir beide haben eine andere Ansicht wenn wir von "Kunden eines PS" reden. Ich würde sagen wenn hier im Thread von "Kunden eines PS" gesprochen wird, sind das die Endverbraucher/Endkunden die einfach nur TV gucken.
Daher bin ich in deiner Erklärung an lordalex (der anhand seines Posts wohl eher ein Endverbraucher ist) im Post #20.578 davon ausgegangen, dass du meinst die Endverbraucher/Endkunden eines PS speisen den CacheEx des PS ein.
Daher auch mein Kommentar zum einlesen in CacheEx. Der war aber nicht frech von mir gemeint.

Das du mit "Kunden eines PS" aber wohl eher die Leute meinst die sich keine normale "Endverbraucher/Endkunden" Line kaufen sondern welche die ihren Cache mit dem PS tauschen und auch selber einen PS betreiben, hat sich für mich erst aus deinen anderen Posts ergeben. Da gebe ich dir über die Arbeitswiese der PS auch absolut recht und die ist mir auch durchaus bekannt.

Immer wenn du von CacheEX gesprochen hast, hat es sich für mich so angehört, dass du der Meinung bist das es einen "großen" gibt. Das viele PS ihren Cache untereinander tauschen sieht man ja allein schon daran das aus allen ecken berichtet wird das eine V15 in den Shares rumgeistert.
 
Hat den den hier schon mal einer ein CW mit „lg“ im Cache gehabt ? Dann weißt du doch das es nur ein Hop ist

Ich behaupte mal das in den meisten kleinen Payservern nichtmal eine Lokale Karte ist
 
@el_malto : es gibt auch (wenn auch wenige) schlichtweg versiertere User, die einfach CacheEx und Line verbinden.

Beispiel : lokale HD+ Karte kann man sich mit ein paar Cache Peers komplett(!) sparen. die ist so sicher im Cache ... damit kann man dann zB mehrere Aufnahmen parallel fahren, ohne hypernervöse PS-Anbieter zu viel abzufragen, die einem bei zu hoher Auslastung mal schnell die Line sperren.

und ja. es gibt so etwas ähnliches wie einen "großen cache". lies dich in multics ein, dann weißt du was ich meine.


@chrisie : jeder der wirklich "freezefree" haben will, braucht echtes lokales Backup via lokaler Karte oder stabiler Hop1 Line - wobei die Hop1 - Line schon wieder dafür sorgen würde, dass man die WaitTime runterdrehen muss, was kontraproduktiv ist wieder ... ganz ohne Lokale geht es einfach nicht, wenn man es "sauber" haben will.

Manche Leute können vlt mit Freezern alle 10 Mins leben - ich nich
 
Zuletzt bearbeitet:
Ich behaupte mal Nachts ists kälter als draußen. Und Cola schmeckt besser als aus der Dose.
Und am wichtigsten: Zu Fuss ist schneller als übern Berg.

Ich glaub ich hab den Tenor vom Thema perfekt getroffen.
 
Es unterhalten sich hier gerade Leute vernünftig und sachlich über ein (wichtiges) Thema und dann kommt jemand völlig deplaziert mit Bullshit um die Ecke.
Und dann wundert man sich über zig Seiten und dass nix rumkommt.
Selbst schuld mit solchen Aktionen ...
@Shortycc
Sorry aber der Treffer ging völlig vorbei.
 
und ja. es gibt so etwas ähnliches wie einen "großen cache". lies dich in multics ein, dann weißt du was ich meine.
Sowas ähnliches wie der "große" Cache entsteht halt nur, weil viele PS untereinander CahceEx betreiben. Sieht man ja an der aktuellen V15. Das dieser "große" Cache aber expliziet MultiCS durch zustande kommt würde ich nicht sagen. Ob du jetzt über OSCam oder MultiCS deinen Cache tauscht spielt keine Rolle.
 
Zuletzt bearbeitet:
@Shortycc ah ja. Ich würde stattdessen mal behaupten - wenn du nicht verstehst, inwiefern das Thema in diesem Zusammenhang so interessant ist, dann brauchst du eigentlich gar nicht mitreden
@el_malto : aha. Eine CacheEx basierte Softcam, die automatisch ansonsten untereinander unbekannte Peers automatisch miteinander verknüpft, spielt also keine Rolle bei einem möglichen "großen Cache" ?

Genau die MultiCS-User mit ner Line bei dem / den PS werden es nämlich sein, die bei euch 098D hell werden lassen so btw. Ganz genau jene.

Und ich lehne mich auch mal sehr weit aus dem Fenster und behaupte, es gibt sehr viele kleine "pseudo-private" PS, die zwei - drei echte Locals und genug Fachwissen haben, mit einem Server 100 Leute zu versorgen - ohne das dann per Internet an die große Glocke zu hängen, weil das schlicht zu heikel wäre - das bitte als Behauptung betrachten, die ich nicht weiter belegen oder kommentieren werde.
Die "verbinden" dann wieder alle Quellen (gute OSCam CE Peers, CSP bei CAIDS bei denen CW Check möglich ist, MultiCS) zu einem größeren CachePool, den sie dann für ihre Clients als Quelle und für ihre Peers bereitstellen.
Von der Verteilung der User würde ich sogar sagen 80% User bei privaten kleinen PS, 20% bei den 2-3 großen
 
Zuletzt bearbeitet:
aha. Eine CacheEx basierte Softcam, die automatisch ansonsten untereinander unbekannte Peers automatisch miteinander verknüpft, spielt also keine Rolle bei einem möglichen "großen Cache" ?
Ich hatte mir von einiger Zeit mal zum spielen eine MCS Instanz installiert und damit rumgespielt. Wirklich mal nur von der Einspeisung her betrachtet, ist der einzige Unterschied zu OSCam, dass MCS keine Karten lesen kann. Du kannst das Ding halt nur extern mit CacheEx oder Lines usw. füttern. Von den anderen Funktionen jetzt mal ganz abgesehen. Das die aber automatisch mit irgendwelches unbekannten Peers alles hin und her tauscht wäre mir neu. Oder ist da jetzt irgendwas hardcoded versteckt? War schon ein paar Jahre her als ich damit rumgespielt habe.
 
Cache-EX steht für 'Cache Exchange' und ist einfach eine Methode, um den Cache von oder zu einem anderen Oscam-Server zu übertragen.

"Cache" - wie es in der Cardsharing-Szene verwendet wird, ist eine Sammlung bereits verwendeter, gültiger ECM's, die von den Karten- und Proxy-Lesern gesammelt werden.
Die "Cache-EX"-Funktion in Oscam ermöglicht es, lokal gesammelten Cache mit anderen Oscam-Servern auszutauschen und zusammenzuführen. Auch wenn der Cache-EX nicht aktiviert ist, erstellt Oscam standardmäßig einen Cache. Jede von einem Client gestellte ECM-Anfrage wird an einen Karten- oder Proxy-Leser weitergeleitet.
Alle beantworteten ECMs verbleiben für eine bestimmte Zeit im Speicher von Oscam und werden entfernt, wenn die TTL (Time to Live) abläuft.
Auf einem ausgelasteten Server im Speicher sind eine ganze Reihe gültiger ECMs gespeichert, zusammen werden sie "Cache" genannt.
Wenn ein anderer Benutzer gleichzeitig ein ECM für denselben Kanal anfordert, gibt Oscam automatisch das kopierte/gespeicherte/zwischengespeicherte ECM aus seinem lokalen Cache zurück, ohne einen Leser anzufordern.
Jedes angeforderte ECM wird immer zuerst mit dem verfügbaren Cache verglichen. Das Ergebnis ist eine Ersparnis von 50 % auf der Karte, basierend auf den beiden Benutzern, die dasselbe ECM anfordern.
Auf diese Weise empfängt und speichert ein zweiter Server die gesammelten zwischengespeicherten ECMs in seinem eigenen Speicher, und Clients können sie auf die gleiche Weise wie oben beschrieben anfordern und verwenden.
Auch der gesamte Cache auf dem zweiten Server (sein eigener + vom ersten Server empfangener) kann an einen dritten Server weitergeleitet werden.
Wenn viele ausgelastete Server alle zwischengespeicherten ECMs zusammenführen, wird ein riesiger Cache verfügbar sein, der Kartenanfragen auf allen verbundenen Servern speichert.
AMEN

Du musst Regestriert sein, um das angehängte Bild zusehen.
 

Anhänge

Du musst angemeldet sein, um die Anhangsliste zu sehen.
@el_malto : doch, multics macht genau das.
Installier es dir mal, konfigurier das Profil sauber und schau dann ins Webinterface von MultiCS, mal sehen was dir dabei auffällt Und das ist nicht hardcoded versteckt, sondern das Grundprinzip vom MCS Cache. Stell es dir einfach vor wie eine P2P Tauschbörse für Cache

Das Schaubild von dr. alzheimer sehe ich btw als nahezu perfekt - manche würden noch eine separate reader instanz betreiben, aber für das prinzip äußerst gut gemacht. Danke dafür !
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…