Freezer beim lokalen Reader in oscam

[razorback]

AW: Freezer beim lokalen Reader in oscam

die retry-limits:
so wie ich es verstehe (ich setz es nicht ein, da nicht gebraucht) funktioniert es so:
lb_retrylimits = 09C4:0600
heißt, daß sobald die Antwortzeit bei einer 09c4 (sky V13) 600 ms überschreitet, sucht der lb für diese CAID einen schnelleren Reader.

lb_retrylimit = 0800
bei allen CAIDs, die nicht in lb_retrylimits behandelt werden, sucht der lb einen schnelleren Reader, sobald die Antwortzeiten > 800 ms werden.

LB und Services:
da mußt was falsch verstanden haben.
Diese Einschränkung hat es niemals gegeben - ganz im Gegenteil, es war immer schon eine Empfehlung die Services zu benutzen (wenn man weiß wie......)
Was es gibt ist die Tatsache, daß du im Reader keine "ident = " drin haben darfst, da dann der LB dafür nicht benutzt wird.

und ja, der betatunnel ist nur interessant/erforderlich bei 1833 -> 1702 und 1834 -> 1722
die NDS-karten (09xx) haben keinen solchen und brauchen ihn daher natürlich auch nicht.

R

 

[ako673de]

AW: Freezer beim lokalen Reader in oscam

Eieiei!!! Vergleicht mal was Ihr unter

Du musst dich Anmelden oder Registrieren um diesen link zusehen!

und

Du musst dich Anmelden oder Registrieren um diesen link zusehen!

über den "services"-Parameter zu lesen findet. Ich hab also nichts falsch verstanden, bin nur dummerweise dem Link aus OSCam heraus gefolgt, anstatt die Wiki per Browser anzusteuern :emoticon-0145-shake.

Sorry, aber Deine Erklärung zur "lb_prefer_Beta_over_Nagra"-Option hab ich nicht verstanden. Was wird da wie preferred?


So, mittlerweile bin ich mit meinen Freezern auch etwas weiter: Ich konnte einen Störenfried eliminieren, und das war "miniserv.pl" vom Paket "webmin"! Der hat wohl einen recht ressourcenhungrigen cronjob, der alle Nasen lang mal gestartet wird. Schau ich mir später an, derzeit brauch ich das Tool nicht.

Leider sind meine Probleme damit aber noch nicht gelöst. Hab mein System jetzt einen Tag unter Aufsicht von "sysstat" gestellt, und OSCam gestresst. Ergebnis ist z.B. dieses:

Auszug aus oscam.log:
System-Last im gleichen Zeitraum (mit Befehl "sar" ermittelt):

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Und hier noch der Ressourcenhunger PID-fein für den betr. Zeitraum (ermittelt mit "pidstat"):

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Jeweils fett markiert die Problemzonen.

Auffällig, dass 6s "iowait" stattfinden, bevor dann ein OSCam-Prozess fast 12s lang den Prozessor voll auslastet. Diesen Prozess gibt es übrigens danach nicht mehr! Und die ECM-Ausreisser fallen in die Zeit wo der OSCam-Prozess das System zu macht.
Interessant ist auch, dass die meisten Proxies sich davon nicht beeindrucken lassen, nur der lokale Reader meldet sich gleich zweimal hintereinander richtig spät.

Hat jemand eine Idee wie ich das abstellen kann? Bitte, ich bin am verzweifeln :emoticon-0179-headb...

Grüsse
ako673de

 

[bombadil]

AW: Freezer beim lokalen Reader in oscam

Hi @ako673de,

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Dieses gilt nicht für die Services, sondern für den Eintrag bei ident. Guckst du hier: oscam.server - Seite 3

Gruß

Bombadil

 

[ako673de]

AW: Freezer beim lokalen Reader in oscam

Wie gesagt, die englische Wiki ist hier fehlerhaft. Dein Link spiegelt praktisch 1:1 die deutsche Wiki wieder - leider, denn auch hier wäre es hübsch gewesen, so manche Option ein wenig detaillierter zu erklären...

Neues Ergebnis meiner "freezer" Analysen:
Ich stelle etwas fest, was wirklich reproduzierbar periodisch hohe Prozessorlast verursacht, und zwar (immer die gleichen!) zwei OSCam-Threads. Beide spiken alle 2 Minuten die Prozessorlast für ca. 0.5s an die 100% heran, und sind zueinander um konstant 1:50min zeitversetzt.

Irgendjemand eine Idee, welche OSCam-Threads so ein Verhalten zeigen könnten und warum? Verdächtig ist, dass es zwei Threads sind, und ich zwei lokale Karten drin habe. OK, es gibt noch mehr Dinge, die vorzugsweise paarweise auftreten, aber mein Verdacht geht einfach intuitiv in diese Richtung, weil meine lokale v13 im "smartreader"-Modus hier und da einmal crasht und dann die ganze NAS rebootet werden muss, um wieder normalen Betrieb herzustellen.

 

[razorback]

AW: Freezer beim lokalen Reader in oscam

...mein Gott, ako673de

warum nimmst dir nicht enfach einen Account beim streambord ??

Dort sitzen die Developer und dort solltest Deine schrulligen NAS-OSCam Requests auch reinkippen.

Ich schau dann dort auch mit Begeisterung mit......

R

 

[ako673de]

AW: Freezer beim lokalen Reader in oscam

...weil es mir von Anfang an hier am Besten aufgehoben vorkam. War der einzige Thread, der unerklärliche Freezer - speziell mit der v13 - beklagt.

Warum ist denn jeder so sch*** unfreundlich hier! Überlass es doch bitte einfach mir, was ich für sinnvoll halte und was nicht. Und wenn nicht, verkneif's Dir einfach trotzdem, und wenn doch nicht, dann mässige bitte Deinen Stil.

Für den (torty), den's interessiert:
- Ich hab noch ein paar mehr Prozesse aufgespürt, die den reibungslosen OSCam-Betrieb beeinträchtigen, und bei denen (z.B. sshd) war's dann nicht so günstig, die einfach abzudrehen. LÖSUNG: nice=-10 (Standard ist -1, und das reicht meinem System offenbar nicht)
- Das 4-Minuten-periodische Aufflackern zweier OSCam-Prozesse stammt vom cccam-Update-Intervall, das default alle 240s stattfindet. Ist mit steigender Anzahl Shares offenbar in steigendem Masse störend. LÖSUNG: Hab bei den Usern per CAID und IDENT Parameter die Anzahl Karten brutalst eingeschränkt, und weg ist dieses Problem!
- Übrig bleiben Freezer, wenn mind. zwei Clients zwei Sender gucken wollen, bei denen GLEICHZEITIG ECM-Requests gesendet werden (Bei der v13 hat ja - wie gesagt - scheinbar jeder Sender einen von einer sehr begrenzten Anzahl fester Zeitschlitze innerhalb des 7s ECM-Intervalls, und es gibt eindeutig mehr Sender als Zeitschlitze...). Jetzt, wo das eindeutig identifiziert ist, und auch gesichert nichts mit Systemlast zu tun hat, sondern eher mit meiner USB-Hardware und dem smartreader-Protokoll, hatte ich sowieso vor, mich an die Entwickler zu wenden...

Vielen Dank also für keine Hilfe und die abwertenden Kommentare. Auf wiedersehen.
ako673de

 

[ako673de]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Nachdem diese Optionen in der Praxis so rein gar nichts brachten, habe ich weiter recherchiert und da fand ich dann heraus, dass es leider nicht ganz genau so ist, wie du sagst:

Es wird nicht nach einem anderen Reader gesucht, sobald diese Zeiten überschritten wurden, sondern wenn diese Zeiten in einem "lb_max_ecmcount" Intervall überschritten werden

Offen bleibt, ob ein Ausreisser-ECM ausreicht, oder der Durchschnitt zählt, aber is eigentlich sowieso egal. Mit diesen Optionen kann man nicht SOFORT reagieren lassen, dazu dient vermutlich ausschliesslich die Option "fallbacktimeout" in der Global-Sektion der oscam.conf, und die gibt's nicht CaID-fein.

Zu "fallbacktimeout" schreiben die Jungs in obigem Link übrigens ganz relaxt, dass die meisten Leute hier 2500ms einsetzen. Das will ich sehen mit v13er Karten! Die müssen schätzungsweise bei spätestens 450ms weiter gehauen werden...

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Weil ich da 4 Wochen nix fragen kann (Probezeit). Ich sterbe wenn ich das Gschiss in 4 Wochen immer noch habe!