Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben
Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
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.
ü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):
Code:
[FONT=courier new]22:52:17 CPU %user %nice %system %iowait %steal %idle
22:52:17 all 2.97 0.00 4.95 0.00 0.00 92.08
22:52:18 all 3.96 0.00 14.85 2.97 0.00 78.22
22:52:19 all 5.94 0.00 5.94 0.00 0.00 88.12
22:52:20 all 0.99 0.00 4.95 0.00 0.00 94.06
22:52:21 all 0.99 0.00 6.93 19.80 0.00 72.28
22:52:22 all 3.96 0.00 5.94 0.00 0.00 90.10
22:52:23 all 1.98 0.00 9.90 13.86 0.00 74.26
[B]22:52:24 all 3.96 0.00 14.85 81.19 0.00 0.00
22:52:25 all 8.91 0.00 21.78 69.31 0.00 0.00
22:52:26 all 4.95 0.00 5.94 89.11 0.00 0.00
22:52:27 all 3.96 0.00 2.97 93.07 0.00 0.00
22:52:28 all 3.96 0.00 3.96 [/B][/FONT][FONT=courier new][B]92.08 0.00 0.00
22:52:29 all 2.97 0.00 3.96 [/B][/FONT][FONT=courier new][B]93.07 0.00 0.00
22:52:30 all 93.14 0.00 3.92 [/B][/FONT][FONT=courier new][B]2.94 0.00 0.00
22:52:31 all 93.07 0.00 6.93 0.00 0.00 0.00
22:52:32 all 86.14 0.00 13.86 0.00 0.00 0.00
22:52:33 all 95.05 0.00 4.95 0.00 0.00 0.00
22:52:34 all 95.05 0.00 4.95 0.00 0.00 0.00
22:52:35 all 96.04 0.00 3.96 0.00 0.00 0.00
22:52:36 all 94.06 0.00 5.94 0.00 0.00 0.00
22:52:37 all 92.08 0.00 7.92 0.00 0.00 0.00
22:52:38 all 90.10 0.00 9.90 0.00 0.00 0.00
22:52:39 all 96.04 0.00 3.96 0.00 0.00 0.00
22:52:40 all 90.10 0.00 9.90 0.00 0.00 0.00
22:52:41 all 85.15 0.00 14.85 0.00 0.00 0.00
22:52:42 all 51.49 0.00 24.75 0.00 0.00 23.76[/B]
22:52:43 all 3.96 0.00 2.97 0.00 0.00 93.07
22:52:44 all 2.97 0.00 3.96 0.00 0.00 93.07
22:52:45 all 4.95 0.00 3.96 0.00 0.00 91.09
22:52:46 all 3.96 0.00 9.90 0.00 0.00 86.14
22:52:47 all 1.98 0.00 6.93 0.00 0.00 91.09
22:52:48 all 8.91 0.00 21.78 3.96 0.00 65.35
22:52:49 all 2.97 0.00 5.94 0.00 0.00 91.09
22:52:50 all 3.96 0.00 5.94 0.00 0.00 90.10
22:52:51 all 1.98 0.00 5.94 0.00 0.00 92.08
22:52:52 all 1.98 0.00 8.91 0.00 0.00 89.11
22:52:53 all 23.76 0.00 12.87 0.00 0.00 63.37
22:52:54 all 0.99 0.00 5.94 0.00 0.00 93.07
22:52:55 all 4.95 0.00 2.97 0.99 0.00 91.09
22:52:56 all 1.98 0.00 5.94 10.89 0.00 81.19
22:52:57 all 3.96 0.00 3.96 0.00 0.00 92.08
22:52:58 all 1.98 0.00 4.95 0.00 0.00 93.07
22:52:59 all 2.97 0.00 5.94 0.99 0.00 90.10
22:53:00 all 6.93 0.00 6.93 10.89 0.00 75.25
22:53:01 all 1.98 0.00 4.95 0.00 0.00 93.07
22:53:02 all 0.99 0.00 12.87 0.00 0.00 86.14
22:53:03 all 1.98 0.00 5.94 0.00 0.00 92.08
22:53:04 all 1.98 0.00 6.93 0.99 0.00 90.10
22:53:05 all 1.98 0.00 5.94 10.89 0.00 81.19
22:53:06 all 1.98 0.00 5.94 0.00 0.00 92.08
22:53:07 all 3.96 0.00 4.95 0.00 0.00 91.09
22:53:08 all 1.98 0.00 3.96 0.00 0.00 94.06
22:53:09 all 0.99 0.00 5.94 0.00 0.00 93.07
22:53:10 all 2.97 0.00 3.96 0.00 0.00 93.07[/FONT]
Und hier noch der Ressourcenhunger PID-fein für den betr. Zeitraum (ermittelt mit "pidstat"):
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...
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.
...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
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.
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...
Diese Seite verwendet Cookies, um Inhalte zu personalisieren und dich nach einem Login angemeldet zu halten, wenn du registriert bist.
Durch die weitere Nutzung unserer Webseite erklärst du dich damit einverstanden.
Das Digital Eliteboard ist ein kostenloses Forum und ist auf Spenden angewiesen, um sich auch in Zukunft selbst zu finanzieren. Wenn auch du mit dem Digital Eliteboard zufrieden bist, würden wir uns über jede Unterstützung freuen.
?
