Stiftung: Stabiler sectionsd

[tHec@]

Hi all,

ich weis nicht, obs für Euch relevant ist... trotzdem: habe seit jeher 3 Kabel-Sagems am Laufen, die sich eigentlich schon immer dadurch auszeichneten, dass nach absolut unterschiedlichen Zeitabständen das Bild schwarz wird. Oft bleibt Ton ok. In nahezu fast allen Fällen kommt alles wieder ins Lot, wenn auf einen anderen Kanal geschaltet wird. Dieser Effekt trat sowohl bei JtG-, Yadi-, DietmarW- und Yadd-Images bis zum 7.12.2005 auf (DietmarW vielleicht etwas weniger häufig). Die Meldungen im seriellen dbox-log deuteten dann stets auf den Demuxxer hin (der -allerdings ohne dass das Bild wieder kam- restartet wurde).
Hierbei sind stärker diejenigen Boxen betroffen, auf denen öfter gezappt wird.
Seit dem 8.12. (genauer gesagt seit ca. 20 Std) läuft auf der einen Box ne tagesgenerierte Yadd ("Neutrino_Enigma_LCars_yadd_Day4[1].tar.bz2") ohne Hänger und mit funktionierendem EPG einwandfrei (allerdings ohne allzu viel Zapping-Gedöns).
Da ich derzeit an meinem dbox-Monitor werkele und momentan an der Log-Funktion bin, hab ich das log mal mitlaufen lassen. Was mir hier auffällt, ist der RAM-Verlauf. Hier scheint häufiger bzw. in größeren Brocken als vorher was alloziert und auch wieder freigegeben zu werden. Könnt ihr das bestätigen?

Gruss Thomas[/img]

[gmo18t]

@GMO

Also wir kriegen ja so wie es aussieht langsam Dreh an die Sache. Meine jetzige Version läuft m.E. schon echt gut. Die kann ich nur schocken, wenn ich von 3 Satelliten wirklich alle Events in den Speicher kloppe.

ja, ihr habt da wirklich schon viel geschafft - und bestimmt auch ne Menge dabei über das Thema gelernt (ich bin da leider noch nicht so weit).
Wenns irgendwann mal drum geht sectionsd, zapit oder sonstwo bei neutrino neu anzufangen, bin ich gerne mit dabei...

Was für mich auch wichtig wäre, wäre auch eine Abkehr von den sections hin zu den Tables. Ich würde eigentlich lieber ein Filter-Interface haben, dem ich sage: Gib mir die Table XY von PID XYZ. Und dann melde dich bitte erst wieder wenn sich die Table ändert. So hat sich das DVB nämlich eigentlich gedacht.

... glaub das ist in enigma ähnlich gemacht !

- GMo -

[Houdini]

Falls wer mal damit testen will:
http://home.arcor.de/houdini/dbox/secti ... 2-09.patch
Konfiguration des 'HoursToCache' unter <Einstellungen-Diverse...-EG Speicher in Stunden>
Irgendetwas ist aber komisch mit den Umlauten in den locales (durch den diff?)

Houdini

[DrStoned]

Ich habe jetzt den aktuellen JtG-Snap vom 09.12.2005 drauf.
Ein Fehler, der bis jetzt noch nicht behoben ist:

Wenn ich auf einem Sender bin, der kein EPG ausstrahlt, z.B. ORF 1 oder XXP (Kabel-BW) und schalte ich dann das Tuxtext-Plugin ein, um mich über die laufende Sendung zu informieren.
Wenn ich dann Tuxtext verlasse, wird die Box unbedienbar, bis ich den sectionsd über Telnet abschieße. Seltsamerweise erzeugt er bei top keine Prozessorlast mehr.

Code: Alles auswählen

 11:18pm  up 52 min,  0 users,  load average: 0.14, 0.20, 0.27
46 processes: 45 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   5.5% user,   7.7% system,   0.0% nice,  86.7% idle
Mem:     30916K total,    22816K used,     8100K free,     2588K buffers
Swap:        0K total,        0K used,        0K free,     7064K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1994 root      16   0   796  796   636 R     7.3  2.5   0:07 top
  216 root       9   0   424  420   340 S     0.5  1.3   0:07 telnetd
 2048 root       9   0   344  340   280 S     0.5  1.0   0:00 sleep
  124 root       9   0  2016 1204   612 S     0.1  3.8   0:03 clock
    1 root       8   0   536  536   516 S     0.0  1.7   0:02 init
    2 root       9   0     0    0     0 SW    0.0  0.0   0:00 keventd
    3 root      19  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd_CPU0
    4 root       9   0     0    0     0 SW    0.0  0.0   0:00 kswapd
    5 root       9   0     0    0     0 SW    0.0  0.0   0:00 bdflush
    6 root       9   0     0    0     0 SW    0.0  0.0   0:00 kupdated
    7 root       9   0     0    0     0 SW    0.0  0.0   0:00 mtdblockd
    9 root       9   0   536  536   516 S     0.0  1.7   0:00 init
   10 root       9   0   528  524   444 S     0.0  1.6   0:00 rcS
   13 root      15  10     0    0     0 SWN   0.0  0.0   0:00 jffs2_gcd_mtd3
   23 root       9   0   588  584   488 S     0.0  1.8   0:00 inetd
   35 root       9   0   804  804   660 S     0.0  2.6   0:02 tuxmaild
   36 root       9   0   804  804   660 S     0.0  2.6   0:00 tuxmaild
   39 root       9   0   804  804   660 S     0.0  2.6   0:00 tuxmaild

Dies passiert aber nur, wenn der sectionsd vorher auf einem Sender mit EPG stand. Der sectionsd läuft aber noch, erzeugt aber bei top keine Prozessorlast mehr.

Code: Alles auswählen

~ > ps -A
  PID TTY          TIME CMD
    1 ?        00:00:02 init
    2 ?        00:00:00 keventd
    3 ?        00:00:00 ksoftirqd_CPU0
    4 ?        00:00:00 kswapd
    5 ?        00:00:00 bdflush
    6 ?        00:00:00 kupdated
    7 ?        00:00:00 mtdblockd
    9 vc/1     00:00:00 init
   10 vc/1     00:00:00 rcS
   13 ?        00:00:00 jffs2_gcd_mtd3
   23 ?        00:00:00 inetd
   35 ?        00:00:03 tuxmaild
   36 ?        00:00:00 tuxmaild
   39 ?        00:00:00 tuxmaild
   82 vc/1     00:00:00 start_neutrino
  104 ?        00:00:00 timerd
  106 ?        00:00:00 timerd
  107 ?        00:00:00 timerd
  112 ?        00:00:00 kdvb-fe-0:0
  113 ?        00:00:02 zapit
  116 ?        00:00:00 camd2
  118 ?        00:00:00 controld
  120 ?        00:00:00 controld
  121 ?        00:00:00 controld
  122 ?        00:00:02 nhttpd
  124 vc/1     00:00:04 clock
  126 vc/1     00:01:54 neutrino
  128 vc/1     00:00:00 neutrino
  129 vc/1     00:00:01 neutrino
  140 vc/1     00:00:04 woltimerd
  147 vc/1     00:00:00 nettraf
  150 ?        00:00:00 nhttpd
  158 vc/1     00:00:03 .wols
  165 vc/1     00:00:00 neutrino
  216 ?        00:00:08 telnetd
  217 pts/0    00:00:00 sh
 2095 ?        00:00:00 sectionsd
 2096 ?        00:00:00 sectionsd
 2097 ?        00:00:00 sectionsd
 2098 ?        00:01:19 sectionsd
 2099 ?        00:00:00 sectionsd
 2100 ?        00:00:03 sectionsd
 2101 ?        00:00:00 sectionsd
 2102 ?        00:00:00 sectionsd
 2369 vc/1     00:00:00 ping
 2375 pts/0    00:00:00 ps
~ >

Greetz von DrStoned

[Innuendo]

Falls wer mal damit testen will:
http://home.arcor.de/houdini/dbox/secti ... 2-09.patch
Konfiguration des 'HoursToCache' unter <Einstellungen-Diverse...-EG Speicher in Stunden>
Irgendetwas ist aber komisch mit den Umlauten in den locales (durch den diff?)

Houdini

danke fürs 'komische' diff - magst du nicht gleich oldeventsare genauso einstellbar machen?

edit: die änderung eventstocache funktioniert soweit bestens - nur das #else

Code: Alles auswählen

+	return ;
+}
+#else
 static void removeNewEvents(void)

musste ich ersetzen durch ein #endif - sonst lief der compiler nicht durch. fehlt da noch was oder ..?

[Homar]

[eitThread] adding 23 events [table 0x50] (begin)
dmxNIT: no new data for 5 seconds
--> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 8156.281000
--> 'changeDMX: after pthread_mutex_lock(&start_stop_mutex)' 0.753000
dmxSDT: waking up again - requested from .change()
dmxNIT: going to sleep...
dmx.read timeout - filter: 50 - timeout# 0[sdtThread] adding 25 services [table
0x42] (begin)
dmx.read timeout - filter: 50 - timeout# 1Connection from UDS
version: 5, cmd: 14, numbytes: 1
data length: 0
Starting command 14
Request of TV event list (IDs).

@Nirvana: wenn auf einem Sender gestartet wird ohne EPG, hängt sich die sectionsd auf
Komischerweise zeigt TOP keine CPU-Last an, hängt aber in einer Endlosschleife

Das Log von oben zeigt das verhalten an, wenn mann von einem Sender kommt, wo alle events eingelesen wurden und auf einem Sender schaltet ohne EPG

[Nirvana]

@Homar

Automatische Kanalsuche wirklich aus? Weil "eigentlich" darf dmxSDT/dmxNIT nicht aufwachen.
Also wenn es aus ist, kann ich mit und ohne EPG starten. Die beiden wachen nicht auf.

[Innuendo]

@nirvana: könntest du gegen die aktuelle sectionsd 1.215 ein diff mit deinen letzten änderungen erstellen?

[Innuendo]

@houdini
box mit std einstellung gebootet (EPG Speicher in Stunden 504) und ein bisschen laufen lassen - kaum gezappt.

Code: Alles auswählen

/ # uptime
 09:18:58 up 50 min, load average: 0.01, 0.09, 0.08
/ # free
              total         used         free       shared      buffers
  Mem:        30884        24628         6256            0         2928
 Swap:            0            0            0
Total:        30884        24628         6256

im menü auf 96 Stunden EPG Speicher geändert

Code: Alles auswählen

[neutrino] EpgSecondsToCache changed to 96 hours
/ # free
              total         used         free       shared      buffers
  Mem:        30884        24796         6088            0         2928
 Swap:            0            0            0
Total:        30884        24796         6088

sollte dadurch nicht der freie speicher eher größer als kleiner werden?

Code: Alles auswählen

if (newhtc < secondsToCache) {
	secondsToCache = newhtc;
	removeNewEvents();
} else {

innu

[Nirvana]

Mal angenommen, wir glauben ein Memory Leak im eit-thread zu haben. Wie könnte man das am einfachsten beweisen bzw. finden? Könnte man testweise die events per addEvent hinzufügen und gleich wieder löschen lassen? Müsste dann nicht bei jedem Durchlauf der for-Schleife der Speicher konstant sein? Oder optimiert so etwas der Compiler gleich wieder weg? Oder könnte man in den beteiligten Klassen SIeitsection, SIEvents, SIEvent mal riesige Brocken von Speicher grapschen und dann kucken wer ihn nicht wieder rausrückt.

[mb405]

@Houdini
ich hab mal das patch eingespielt.
du hast da ein umlautproblem in den deutsch.locale. das ist ein grund, warum ich immer noch suse 9.1 verwende. zum anderen klappt das neutrino menü und die anzeige dessen im log einwandfrei. nur scheint es den sectionsd nicht zu jucken, was man da einstellt.

ich hab mal 168stunden eingestellt. dann sagt er im log ganz brav

Code: Alles auswählen

[neutrino] EpgSecondsToCache changed to 168 hours

bei epgreset kommt dann folgendes

Code: Alles auswählen

$Id: sectionsd.cpp,v 1.213 2005/12/08 18:41:40 metallica Exp $
caching 504 hours
events are old 180min after their end time

irgendwie ist da wohl noch der wurm drin ??
kannst du den patch mal aktualisieren ? da ja sectionsd.cpp 1.215 draussen ist ?

ich hab mal die meldugen beim patchen der sectionsd 1.215

Code: Alles auswählen

patching file sectionsd_1215.cpp
Hunk #1 FAILED at 351.
Hunk #3 FAILED at 534.
Hunk #4 FAILED at 547.
Hunk #5 succeeded at 1125 (offset 6 lines).

[Houdini]

@Homar

-#define MAX_SIZE_BIGEVENTLIST 128*1024
- char *evtList = new char[MAX_SIZE_BIGEVENTLIST]; // 256kb..? should be enough and dataLength is unsigned short
- long count=0;
+#define MAX_SIZE_BIGEVENTLIST 64*1024
+
+ char *evtList = new char[MAX_SIZE_BIGEVENTLIST]; // 128k müssen reichen... schaut euch mal das Ergebnis für loop an, jedesmal wenn die Senderliste aufgerufen wird
+ long count=0, loop=0;

64kB haben letztens bei der eventlist nicht ausgereicht für z.B ZDF Info, deswegen gab es Abstürze (Heap corruption) und die Änderung von sowohl der Größe als auch der Überprüfung, dass nicht mehr als diese Größe geschrieben wird.

@mb405

irgendwie ist da wohl noch der wurm drin ??

jein , neutrino schickt beim starten den aktuellen konfigurierten HoursToCache Wert zum sectionsd. Wenn du sectionsd neu startest fällt das halt aus, hab nicht gesagt das alles schon fertig ist bei dem patch

kannst du den patch mal aktualisieren ?

kann ich später heute machen.

@Innuendo

sollte dadurch nicht der freie speicher eher größer als kleiner werden?

ich dachte schon...

musste ich ersetzen durch ein #endif - sonst lief der compiler nicht durch. fehlt da noch was oder ..?

Hmm da ist wohl was durcheinandergegengen, heute abend mehr..

Houdini

[Homar]

@Houdini: die Abfrage steckt noch drin, nur die eventlist muss sich nun mit 64k begnügen; d.h. alles was nicht reinpasst, muss aussen vor bleiben.
Das ist im Grunde nicht weiter schlimm.

btw. die gesammte Routine suckt ziemlich.
Da muss mann wirklich ändern.
Es kann ja nicht sein, das jedesmal wenn mann auf OK klickt, die gesammte tabelle ausgewertet werden muss, nur um den aktuellen event zu ermitteln.

Alleine im Kabelbereich, bei den wenigen Bouquetts, werden wenn alle events eingelesen sind, die For()-schleife ca. 40000 durchlaufen.
Wie gesagt, jedesmal wenn mann Bouquett wechseln möchte.

Im SAT-Bereich würde früher oder später der gesammte Speicher allokiert werden und es würden trotzdem nicht alle events reinpassen.

Es müsste entweder eine Vorabfilterung stattfinden, oder noch besser eine Bouquett basierende Verkettete Liste mit einer art index-Tabelle für die aktuellen Events innerhalb der Liste.

Ich denke, das so der Zugriff auf die events ziemlich zu beschleunigen wäre.

[Nirvana]

http://s47.yousendit.com/d.aspx?id=14LY ... YV0OX5LZVZ

- Patch gegen 1.215.
- Limitiert die Events auf 20000 (MAX_EVENTS) Bei mir gibts ab 25000 Probleme. Sinnvollerweise sollte das noch mit HourstoCache kombiniert werden. Nach dem Motto: Wenn man sich dem Limit nähert verkleinere HourstoCache. Vorerst werden eben keine Events mehr aufgenommen bis alte removed werden.
- Probiert Homars Problem zu lösen. Keine Ahnung ob es genutzt hat. Kann es bisher nicht nachvollziehen.

[Houdini]

d.h. alles was nicht reinpasst, muss aussen vor bleiben.

ist ok für mich,

Wie gesagt, jedesmal wenn mann Bouquett wechseln möchte.

Jep, das ist aber kein Problem vom sectionsd sondern von Neutrino zumal Neutrino immer die gleiche Liste bekommt.
Ich habe da bei mir auch schon einen Änderung wo die Liste nur nach zappen neu angefordert wird, aber der Geschwindigkeitsvorteil ist kaum spürbar

Houdini

[mb405]

@Houdini
nicht mal beim starten sendet der das. es kommen immer die fest eingestellten werte von der sectionsd.

aber wenn du das fertig hast, und es einwandfrei bei dir funktioniert, kannst du das dann ja heute oder morgen einchecken, mit den änderungen auch für den anderen wert.

[Houdini]

Limitiert die Events auf 20000 (MAX_EVENTS)

hab mir den Patch nicht angeschaut, aber da seh ich ein Problem: was ist wenn die anzahl erreicht ist und du auf einen neuen Sender zappst, dann bekommst du dafür keine events, hast aber woanders events, die Tage in der zukunft liegen

Houdini

[Nirvana]

Ich sage ja, dass das sinnvollerweise mit HoursToCache kombiniert werden muss. Nur wenn du nur mit HourstoCache arbeitest, hast du auch ein Problem. Dann sammelst du als Extrembeispiel eben schon für einen Tag zu viele Events und die Box semmelt weg. Also macht ein HardLimit schon Sinn, finde ich.

[tha_haze]

Ein Ansatz wäre dann: immer das am weitesten entfernteste Event zu löschen wenn man ein Neues bekommt und das Limit schon erreicht ist.

[Homar]

oder grundsätzlich für die nächsten zwei Tage cachen und erst wenn mann in der Übersicht für einen Kanal reinguckt und sich die entferntesten Einträge anschaut, werden die events für diesen Kanal eingelesen, aber auch nur temporär.

So kann mann bei JTG die events programmieren, ohne das der Speicher dauerhaft belegt wird.

[Nirvana]

Ja, sind schon einige Lösungen denkbar. Erstmal aber checken, ob es überhaupt was nutzt.

[Houdini]

Hier mal der diff, stand von gestern, gegen das aktuelle cvs:
http://home.arcor.de/houdini/dbox/secti ... 2-10.patch
Hab aber auch gesehen, dass sich der Speicherbedarf beim Heruntersetzen von HoursToCache nicht verringert...

Diesmal sind die LOCALES OK, das lag wahrscheinlich am <Kompare>

Edit:
Hier mal der Speicherbedarf vor und nach removeNewEvents()
Der Speicher der von malloc zur Verfügung gestellt wird sinkt wenn die cached hours reduziert werden, aber der zweite Wert bleibt beim Maximalwert...

[neutrino] EpgSecondsToCache changed to 84 hours
total size of memory occupied by chunks handed out by malloc: 1588768
total bytes memory allocated with `sbrk' by malloc, in bytes: 1621008 (1583kb, 1.55MB)
total size of memory occupied by chunks handed out by malloc: 1588768
total bytes memory allocated with `sbrk' by malloc, in bytes: 1621008 (1583kb, 1.55MB)
[neutrino] EpgSecondsToCache changed to 74 hours
total size of memory occupied by chunks handed out by malloc: 1785264
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)
total size of memory occupied by chunks handed out by malloc: 1775752
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)
[neutrino] EpgSecondsToCache changed to 64 hours
total size of memory occupied by chunks handed out by malloc: 1824824
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)
total size of memory occupied by chunks handed out by malloc: 1605592
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)
[neutrino] EpgSecondsToCache changed to 54 hours
total size of memory occupied by chunks handed out by malloc: 1605592
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)
total size of memory occupied by chunks handed out by malloc: 1389968
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)
[neutrino] EpgSecondsToCache changed to 44 hours
total size of memory occupied by chunks handed out by malloc: 1389968
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)
total size of memory occupied by chunks handed out by malloc: 1165736
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)
[neutrino] EpgSecondsToCache changed to 34 hours
total size of memory occupied by chunks handed out by malloc: 1165736
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)
total size of memory occupied by chunks handed out by malloc: 947216
total bytes memory allocated with `sbrk' by malloc, in bytes: 1887248 (1843kb, 1.80MB)

[PauleFoul]

@ All

Ich denke wenn das löschen der alten Einträge nicht funktioniert, bringt
es auch nur bedingt was die Vorschauzeit zu verkürzen.

Hab mit dem JtG-Snap vom 08.12. immer noch das Prob das EPG Einträge
von gestern drin sind. Ab der Zeit als ich die Box eingeschaltet habe...

Das kann ja net lange gut gehen


Gruß
____Paule

[Nirvana]

@ Paule

Das klappt aber hier tadellos. Also der Fehler ist nicht aktuell.

[mb405]

also ich hab den aktuellen patch eingespielt. den interressiert die eingabe der zeit überhaupt nicht. beim start kommt immer die fest eingestellte zeit aus der sectionsd.