neutrino Prozess-Prioritäten

Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

neutrino Prozess-Prioritäten

Beitrag von Günther »

Gab eigentlich schon einmal Überlegungen hinsichtlich der Prozess-Prioritäten bei Neutrino?

Zumindest bei newmake werden alle Prozesse in der neutrino_start gleichwertig gestartet (behandelt Linux das eigentlich als Round-Robin ?), was nicht unbedingt ideal ist.

Auf welchen Prioritäten laufen eigentlich die Treiber (AVIA, IDE, ect)? Vermutlich mit der Prio der aufrufenden Applikation, bzw. als Interrupt mit der höchsten Prio???

Ich denke grundsätzlich sollte man Echtzeit- (oder besser Rechtzeit)- Tasks entsprechend hoch priorisieren und Datensammler-Tasks dagegen möglichst niedrig.

Zu den Rechtzeit-Tasks würde ich die AVIA, IDE und Ethernet-Treiber sowie neutrino zählen. Neutrino eigentlich nur wegen der Aufnahmebuffer und für die Bedienung (da reichen aber 200ms-1000ms ).

Zu den anderen Tasks würde ich vor allem Debug-Ausgabe, Console, sectionsd, Timer, dann http und ftp server (sofern hierdrüber nicht gestreamt wird) zählen.

So könnte das dann z.B. in der neutrino_start aussehen (wobei ich z.T. aber nicht im Detail alle Aufgaben der Task kenne z.B. controld ):

Code: Alles auswählen

nice -n 10 sectionsd
nice -n 6 timerd
camd2
nice -n 4 zapit
nice -n 2 controld
nice -n 8 nhttpd
neutrino
(Prioritäten 15: niedrigste bis -15: höchste)

Macht es sinn Neutrino etwas anzuheben (also auf z.B. -2)? Weiß jemand welche Prioritäten Nummern sinnvoll sind oder ist das alles relativ. Ich vermute das Linux normalerweise (abgesehen von den Interrupts) selbst auf Prio 0 läuft? Kenn sich jemand im Detail damit aus?

Eventuell lassen sich hiermit schon so manche sporadischen Probleme (Aufnahme-IDE, mp3 von SD-Flash, ect.) zumindest eindämmen....

Günther
Zuletzt geändert von Günther am Sonntag 4. Februar 2007, 13:01, insgesamt 1-mal geändert.
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

interessanter wäre es doch die unterprozesse (z.B. von neutrino) zu renicen wenn Diese "Last" kriegen. Z.B. kann man mit Top sehr gut beobachten das beim Streamen andere PID's oben stehen als bei wiedergabe. Dummerweise weiß man ja die PID des Moviebrowsers/players (threads) nicht vorher :-? oder kriegt man die raus?
Wenn man den sectionsd mit renice 10 in die wüßte schickt und neutrino mit -19 und zapit mit -18 eine höhere prio gibt verhält sich die box wie ein 486er mit gedrückter Turbotaste ;-)
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Tommy hat geschrieben:interessanter wäre es doch die unterprozesse (z.B. von neutrino) zu renicen wenn Diese "Last" kriegen. Z.B. kann man mit Top sehr gut beobachten das beim Streamen andere PID's oben stehen als bei wiedergabe. Dummerweise weiß man ja die PID des Moviebrowsers/players (threads) nicht vorher :-? oder kriegt man die raus?
Ja wie ist das denn mit den Threads, laufen deren Prio den nur relativ zum 'Erzeuger' oder ganz normal wie bei den Prozessen? Ein Prozess müßte man doch auch bei der Erstellung also im c-code) mit einer Prio belegen können, oder? Das wären dann der Aufnahmeprocess in stream2file.cpp und der Wiedergabetask in movieplayer.cpp. Muß ich mir mal in der Doku anschauen...
Tommy hat geschrieben: Wenn man den sectionsd mit renice 10 in die wüßte schickt und neutrino mit -19 und zapit mit -18 eine höhere prio gibt verhält sich die box wie ein 486er mit gedrückter Turbotaste ;-)
Genau so isses ;)
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

wie setzt man eigentlich eine PID auf "Standard" zurück? Wenn ich z.B. in der recording.start schreibe

Code: Alles auswählen

renice -19 `pidof neutrino`
dann setze ich ja alle neutrino threads an die erste Stelle. Logischerweise müßte ja

Code: Alles auswählen

renice 0 `pidof neutrino`
den Ursprungszustand wiederherstellen - ist das so? Oder kann man im Vorfeld einen Wert (defaultwert) auslesen den man dann anwenden kann?
Gorcon
Tuxboxer
Tuxboxer
Beiträge: 5873
Registriert: Samstag 23. Februar 2002, 22:46

Beitrag von Gorcon »

So könnte das dann z.B. in der neutrino_start aussehen (wobei ich z.T. aber nicht im Detail alle Aufgaben der Task kenne z.B. controld ):
Code:

nice -n 10 sectionsd
nice -n 6 timerd
camd2
nice -n 4 zapit
nice -n 2 controld
nice -n 8 nhttpd
neutrino


(Prioritäten 15: niedrigste bis -15: höchste)
Kann man diese Werte auch zwischendurch ändern?
Wenn ja, könnte man doch zB. in der record.start oder moviolpayer.start die Prioritäten entsprechend ändern?

Gruß Gorcon
Muttersöhnchen
Interessierter
Interessierter
Beiträge: 73
Registriert: Samstag 31. Juli 2004, 18:15

Beitrag von Muttersöhnchen »

Günther hat geschrieben:Ein Prozess müßte man doch auch bei der Erstellung also im c-code) mit einer Prio belegen können, oder?
Wenn um threds geht:
man pthread_getschedparam bzw pthread_setschedparam

bei program:
man getpriority bzw setpriority.
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

du kannst mir renice jederzeit die prios ändern (so wie ich es einen Eintrag drüber geschrieben hab.) Leider ist zwar renice aber nicht nice im letzten JTG Schuß drin. Da bei renice der Prozeß schon eine PID haben muß kann man alle daemons schon in der start_neutrino renicen nur letztendlich neutrino nicht (da nach dem start von neutrino die start_neutrino wartet) da müßte man entweder mit nice oder aus einem anderen skript ran.
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Am besten gleich mit nice, ist seit heute z.B. in newmake drinnen. Denke das Jtg-Riker das auch ins JTG-Image einbauen kann, sind ja nur wenig kbytes.

Wenn man sinnvolle Werte wählt, sollte man das auch nicht im Betrieb ändern müssen. Anonsten hatte DrStoned soetwas ähnliches in die start und stop scripte eingebaut.
dietmarw
Contributor
Beiträge: 1833
Registriert: Mittwoch 10. April 2002, 15:39

Re: neutrino Prozess-Prioritäten

Beitrag von dietmarw »

Code: Alles auswählen

nice -n 10 sectionsd
.
.
immer noch dafür
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Re: neutrino Prozess-Prioritäten

Beitrag von Tommy »

dietmarw hat geschrieben:

Code: Alles auswählen

nice -n 10 sectionsd
.
.
immer noch dafür
sehr brutal - heute mit

Code: Alles auswählen

renice 5 `pidof sectionsd`
in der start_neutrino (direkt vor dem start von neutrino - damit er noch ein bissel zeit auf normalmode hat) getestet - dauert dann schon sehr lange bis die box ihre uhrzeit hat. Und "now/next" kommt auch erst mit dem 3. "?"
Ich glaube letztendlich sollte Günther mal rausfuchsen wie er den stream2file prozess und den movieplayer aus dem source selbst ganz hoch bringt. Alles andere wird ja automatisch hintendran gestellt.
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Re: neutrino Prozess-Prioritäten

Beitrag von Günther »

Tommy hat geschrieben:[dauert dann schon sehr lange bis die box ihre uhrzeit hat. Und "now/next" kommt auch erst mit dem 3. "?"
Stimmt, habe ich auch beobachtet. Trotzdem gehört der sectionsd als Hintergrundtask eingeordnet. Die Verzögerung kommt auch nur deshalb zustande, weil die anderen Task nach dem sectionsd mit höherer Prio gestartet werden, und beim starten natürlich 100% verbrauchen.

Dann ist eine zeitlang 10% Proz.-Last, bis die Uhrzeit da ist und der sectionsd mit 80% zu arbeiten anfängt.

Versuche doch mal folgendes. Sectionsd mit hoher prio starten (also z.B. -5) und dann kurz vor neutrino runtersetzen (z.b. auf 10). Oder wir erstellen ein Neutrino_post_startup Skript, in dem das gemacht werden kann. Dann sollte die Zeit schnell da sein, und der sectionsd würde trotzdem nicht weiter stören ....
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Re: neutrino Prozess-Prioritäten

Beitrag von Tommy »

Günther hat geschrieben:
Tommy hat geschrieben:[dauert dann schon sehr lange bis die box ihre uhrzeit hat. Und "now/next" kommt auch erst mit dem 3. "?"
Stimmt, habe ich auch beobachtet. Trotzdem gehört der sectionsd als Hintergrundtask eingeordnet. Die Verzögerung kommt auch nur deshalb zustande, weil die anderen Task nach dem sectionsd mit höherer Prio gestartet werden, und beim starten natürlich 100% verbrauchen.
Da stimm ich Dir voll zu - im Normalbetrieb sollte demn sectionsd eher eine untergeordnete Rolle zukommen. Die Frage ist nur ob neutrino die Topposition verdient.
Irgendeiner hate auch mal angeregt die stream2file und evtl (neu zu erfinden) file2stream als daemonen auszulagern. Ich glaube über die Zeit hat man einfach vergessen das neutrino ja "nur" die GUI ist
Günther hat geschrieben: Dann ist eine zeitlang 10% Proz.-Last, bis die Uhrzeit da ist und der sectionsd mit 80% zu arbeiten anfängt.

Versuche doch mal folgendes. Sectionsd mit hoher prio starten (also z.B. -5) und dann kurz vor neutrino runtersetzen (z.b. auf 10). Oder wir erstellen ein Neutrino_post_startup Skript, in dem das gemacht werden kann. Dann sollte die Zeit schnell da sein, und der sectionsd würde trotzdem nicht weiter stören ....
Ich kann zwar selber bauen, aber es ist so furchbar bequem auf Riker zu warten :-? deswegen ists erstmal nur renice. Ich habe hier den WAF und den Teletubbie CAF Faktor zu beachten. ->no Way für Fehlflash a'la "kein System"
für eine neutrino_running bin ich natürlich. Da könnte man ja auch mal checken "ist Datum noch 1.1.1970 (wird glaub ich irgendwo gesetzt) - nein ->renice sectionsd"
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
Houdini
Developer
Beiträge: 2183
Registriert: Mittwoch 10. Dezember 2003, 07:59

Beitrag von Houdini »

der sectionsd könnte sich ja auch selber die prio runtersetzen wenn er die "Uhrzeit eingesammelt hat"
new.life
Erleuchteter
Erleuchteter
Beiträge: 797
Registriert: Sonntag 19. Februar 2006, 01:17

Beitrag von new.life »

kleine Verständnisfrage:Linux ist doch kein Realtime-OS und es kann imo keine sichere Vorhersage getroffen werden ob ein Task wirklich zu einer bestimmten Zeit die Rechenleistung bekommt die bei einem vielleicht 'schlecht' programmierten Task (zB. polling anstatt IRQ/DMA) benötigt wird, oder?
Imo lassen sich solche zeitkritischen Sachen nur durch eine genaue Analyse herausfinden um dann zB. direkt am Treiber etwas zu ändern. Nice/Renice bringt vielleicht über einen endlichen Beobachtungszeitraum eine Verbesserung, aber imo nicht grundsätzlich. Zusätzlicher individueller intensiver Gebrauch von 'genialen' Plugins die imo keiner wirklich braucht oder/und der heimliche Gebrauch einer 'alternativen' camd wird dieses Thema niemals verstummen lassen.
just my 2C
Nirvana
Erleuchteter
Erleuchteter
Beiträge: 646
Registriert: Mittwoch 16. April 2003, 14:12

Beitrag von Nirvana »

Im Prinzip habe ich ja nix dagegen, aber erklärt mir bitte noch mal was ihr damit bezwecken wollt.
Schaltet Neutrino dann schneller um oder welche Vorteile habe ich, wenn schon die Events nicht so schnell gesammelt werden dürfen?

Wollt ihr nicht eher die Rechenzeit nur dann, wenn ihr andere Aufgaben als Fernsehen wahrnehmt? Z.B. Movieplayer. Dann solltet ihr nämlich dem sectionsd zu der Zeit das Sammeln verbieten und ggf. anweisen den Speicher freizugeben, falls er benötigt wird.
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

Nirvana hat geschrieben:Im Prinzip habe ich ja nix dagegen, aber erklärt mir bitte noch mal was ihr damit bezwecken wollt.
Schaltet Neutrino dann schneller um oder welche Vorteile habe ich, wenn schon die Events nicht so schnell gesammelt werden dürfen?

Wollt ihr nicht eher die Rechenzeit nur dann, wenn ihr andere Aufgaben als Fernsehen wahrnehmt? Z.B. Movieplayer. Dann solltet ihr nämlich dem sectionsd zu der Zeit das Sammeln verbieten und ggf. anweisen den Speicher freizugeben, falls er benötigt wird.
Also wie schon oben gesagt wenn man neutriono und zapit mehr prio zuweist läuft die GUI wesentlich flüssiger.
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
new.life
Erleuchteter
Erleuchteter
Beiträge: 797
Registriert: Sonntag 19. Februar 2006, 01:17

Beitrag von new.life »

Tommy hat geschrieben:Also wie schon oben gesagt wenn man neutriono und zapit mehr prio zuweist läuft die GUI wesentlich flüssiger.
..bei mir läuft Neutrino nur sehr kurz nach dem Einschalten etwas zäh...voll normal und für mich kein Problem. Nach kurzer Zeit (<1min) schnuckelt alles, obwohl sectionsd den Prozessor weiterhin bis zum Anschlag belastet. Die Priorität von sectionsd scheint niedrig zu sein und das ist imo gut so. Ich möchte in erster Linie vernünftig TV schauen können und _sicher_ auch aus deep standby auf ein NAS-Device aufnehmen und genau das funktioniert in der letzten Zeit/seit mehreren Monaten absolut problemlos und hoffe, daß diese Stabiltät weiterhin erhalten bleibt.
Vielleicht sollte man sich den Movieplayer/Audiplayer direkt vornehmen und wie hier auch schon von Nirvana geschrieben _sicher_ dafuer sorgen daß keine Daten mehr gesammelt werden wenn der Audio/Movieplayer oder ein Aufnahme läuft...scheint mir nicht so zu sein zumindest bei Aufnahme, obwohl sectionsd waehrend der Aufnhme angeblich deaktiviert sein sollte. Und der Speicher sollte natürlich auch freigegeben werden...mir macht es persönlich nix aus wenn nach Aufnahme/Movie-Audioplayer Betrieb der EPG neu eingelesen werden muss.
Zuletzt geändert von new.life am Montag 5. Februar 2007, 15:50, insgesamt 1-mal geändert.
Nirvana
Erleuchteter
Erleuchteter
Beiträge: 646
Registriert: Mittwoch 16. April 2003, 14:12

Beitrag von Nirvana »

new.life hat geschrieben:
Tommy hat geschrieben:Also wie schon oben gesagt wenn man neutriono und zapit mehr prio zuweist läuft die GUI wesentlich flüssiger.
..bei mir läuft Neutrino nur sehr kurz nach dem Einschalten etwas zäh...voll normal und für mich kein Problem. Nach kurzer Zeit (<1min) schnuckelt alles, obwohl sectionsd den Prozessor weiterhin bis zum Anschlag belastet.
So würde ich das Verhalten auch beschreiben. Ich denke nicht, dass das Verhalten nach einer Minute noch unterschiedlich ist, egal ob ich sectionsd kille oder nicht.
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Nirvana hat geschrieben:Im Prinzip habe ich ja nix dagegen, aber erklärt mir bitte noch mal was ihr damit bezwecken wollt.
Schaltet Neutrino dann schneller um oder welche Vorteile habe ich, wenn schon die Events nicht so schnell gesammelt werden dürfen?.
Nur ganz kurz angeschnitten:
Durch die Prioritätsverchiebung wird der sectionsd als solches ja nicht unbedingt langsamer. Er darf halt nur nicht sofort wenn er will sondern vielleicht ein paar Sekunden später. In Summe bleibt aber alles beim Alten.

Die Prioritäten machen Sinn, wenn man das Echtzeitverhalten ein wenig steuern will. Linus ist kein Echtzeitsystem , das stimmt (brauchen wir aber auch nicht wirklich), aber man kann mit den Prioritäten sehr wohl das Ansprechverhalten steuern.

Beim Sectionsd würde ich das Echtzeitverhalten vielleicht auf 30 Sekunden schätzen. Bei der GUI so auf 200ms und beim Streaming liegt es nochmal deutlich höher. Entsprechend sollte auch die Prioritäten vergeben werden, damit die Gui nicht auf den sectionsd warten muß, was der auch ein paar Sekunden später machen könnte.

Das ganze wird gerade dann interessant, wenn man den EPG speicher löscht, und der sectionsd voll beschäftigt ist. Das bisschen Rechenzeit, welche die Gui benötigt, bekommt sie auch sofort und der Anwender erhält sofort Feedback. Hierbei bleibt auch die zeit die selbe, welcher der Sectionsd werkelt, weil die Processzeit der GUI sich nur um ein paar Sekungen verschiebt.

Und warum darf der sectionsd während der Aufnahme keine Daten sammeln? Die richtige Priorität vorausgesetzt kommt er nur zum Zuge, wenn der Prozessor nichts zu tun hat (auf jedemfall bei einem streng prioritätsorientieren OS, Linux hat da glaube ich aber noch ein paar Latenszeiten, beziehungsweise erlaubt auch niederprioren Task hin und wieder ein wenig zu werkel, auch wenn sie gar nicht dran wären?).

Und mit der Sicherheit/Stabilität hat das alles nicht wirklich was zu tun (rein theoretisch könnten natürlich vermehrt dead-locks auftreten, die sollten aber von Linux aufgelöst werden können) sondern nur etwas mit den Response-Zeiten.

Ich habe allerdings vorwiegend Erfahrungen mit embedded (Echtzeit) Betriebsysteme - bei Linux bewege ich mich noch auf recht dünnem Eis (lese mich da aber gerade ein wenig durch ... )

Übrigens gibt es für Linux sehr wohl Echtzeiterweiterungen und Treiber lassen sich auch recht echtzeitnah verwirklichen, das ist aber jetzt wirklich ein anderes Thema ;) ...

Günther
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Ach ja, das mit den Priorität en bei Threads scheint kein großes Problem zu sein. Linux behandelt diese hier wie Prozesse. Das werde ich mal ausprobieren ...

Generell könnte man auch das stream2file in einen eigenen Damon auslagern, sollte noch nicht einmal allzu viel Arbeit sein ...
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Hier ein diff zum spielen mit den thread prios. Den 'File' Thread habe ich in der Gui ausgeblendet, da er seltsamerweise nach dem prio verstellen abschmiert.

DMX Thread und Movieplayer Thread funzen aber

Die Prioritäten und die Policy können unter den Einstellungen Aufnahme verändert werden. Normal ist SCHED_OTHER, hier spielt die Prio keine Rolle, Die beiden anderen sind dann 'realtime' mit der entsprechenden Prio.

Keine Ahnung ob es jetzt besser geht, hatte ja auch vorher wenig Probleme ;)

Ev. könnte jtg-Riker ja ( bei Bedarf) einen Testsnap für die Tester von der IDE2-Abteilung machen 8).

Hier noch ein paar infos:

policy
The scheduling class. The values permitted are:

SCHED_FIFO== 1
A First-In, First-Out real-time process. When the scheduler assigns the CPU to the process, it leaves the process descriptor in its current position in the runqueue list. If no other higher-priority real-time process is runnable, the process will continue to use the CPU as long as it wishes, even if other real-time processes having the same priority are runnable.

SCHED_RR== 2
A Round Robin real-time process. When the scheduler assigns the CPU to the process, it puts the process descriptor at the end of the runqueue list. This policy ensures a fair assignment of CPU time to all SCHED_RR real-time processes that have the same priority.

SCHED_OTHER == 0
A conventional, time-shared process.

priority (0-99)
The base time quantum (or base priority) of the process.

siehe auch hier:
http://www.oreilly.de/homepage/catalog/ ... l/chapter/
(bin ich aber auch noch nicht ganz durch)

Code: Alles auswählen

Index: apps/tuxbox/neutrino/src/neutrino.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/src/neutrino.cpp,v
retrieving revision 1.840
diff -u -b -B -r1.840 neutrino.cpp
--- apps/tuxbox/neutrino/src/neutrino.cpp	26 Jan 2007 23:57:38 -0000	1.840
+++ apps/tuxbox/neutrino/src/neutrino.cpp	6 Feb 2007 01:41:01 -0000
@@ -2562,6 +2562,15 @@
 	{ CNeutrinoApp::RECORDING_FILE  , LOCALE_RECORDINGMENU_FILE   }
 };
 
+//THREADTEST
+extern int recording_dmx_thread_prio ;
+extern int recording_dmx_thread_policy  ;
+extern int recording_file_thread_prio ;
+extern int recording_file_thread_policy  ;
+extern int movieplayer_thread_prio ;
+extern int movieplayer_thread_policy  ;
+
+
 void CNeutrinoApp::InitRecordingSettings(CMenuWidget &recordingSettings)
 {
 	CIPInput * recordingSettings_server_ip = new CIPInput(LOCALE_RECORDINGMENU_SERVER_IP, g_settings.recording_server_ip, LOCALE_IPSETUP_HINT_1, LOCALE_IPSETUP_HINT_2);
@@ -2707,6 +2716,23 @@
 	directRecordingSettings->addItem(mf11);
 	directRecordingSettings->addItem(mf12);
 
+	//THREADTEST
+	directRecordingSettings->addItem(GenericMenuSeparatorLine);
+	
+	CMenuOptionNumberChooser* num1 = new CMenuOptionNumberChooser(LOCALE_FLASHUPDATE_TITLEREADFLASH, &recording_dmx_thread_policy, true, 0, 2, 0, 0, NONEXISTANT_LOCALE, "rec dmx policy");
+	CMenuOptionNumberChooser* num2 = new CMenuOptionNumberChooser(LOCALE_FLASHUPDATE_TITLEREADFLASH, &recording_dmx_thread_prio, true, 0, 99, 0, 0, NONEXISTANT_LOCALE, "rec dmx prio");
+	CMenuOptionNumberChooser* num3 = new CMenuOptionNumberChooser(LOCALE_FLASHUPDATE_TITLEWRITEFLASH, &recording_file_thread_policy, true, 0, 2, 0, 0, NONEXISTANT_LOCALE, "rec file policy");
+	CMenuOptionNumberChooser* num4 = new CMenuOptionNumberChooser(LOCALE_FLASHUPDATE_TITLEWRITEFLASH, &recording_file_thread_prio, true, 0, 99, 0, 0, NONEXISTANT_LOCALE, "rec file prio");
+	CMenuOptionNumberChooser* num5 = new CMenuOptionNumberChooser(LOCALE_MAINMENU_MOVIEPLAYER, &movieplayer_thread_policy, true, 0, 2, 0, 0, NONEXISTANT_LOCALE, "mp policy (0:norm,1:realFIFO,2:realRR");
+	CMenuOptionNumberChooser* num6 = new CMenuOptionNumberChooser(LOCALE_MAINMENU_MOVIEPLAYER, &movieplayer_thread_prio, true, 0, 99, 0, 0, NONEXISTANT_LOCALE, "mp prio (0-99)");
+
+	directRecordingSettings->addItem(num1);
+	directRecordingSettings->addItem(num2);
+	//directRecordingSettings->addItem(num3);
+	//directRecordingSettings->addItem(num4);
+	directRecordingSettings->addItem(num5);
+	directRecordingSettings->addItem(num6);
+
 	recordingstatus = 0;
 }
 
Index: apps/tuxbox/neutrino/src/driver/stream2file.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/src/driver/stream2file.cpp,v
retrieving revision 1.21
diff -u -b -B -r1.21 stream2file.cpp
--- apps/tuxbox/neutrino/src/driver/stream2file.cpp	29 Dec 2005 17:22:32 -0000	1.21
+++ apps/tuxbox/neutrino/src/driver/stream2file.cpp	6 Feb 2007 01:41:02 -0000
@@ -57,6 +57,12 @@
 #define INC_BUSY_COUNT busy_count++
 #define DEC_BUSY_COUNT busy_count--
 
+//THREADTEST
+//SCHED_RR  SCHED_FIFO
+int recording_dmx_thread_prio = 20;
+int recording_dmx_thread_policy = SCHED_OTHER ;
+int recording_file_thread_prio = 20;
+int recording_file_thread_policy = SCHED_OTHER ;
 
 //#include <transform.h>
 #define TS_SIZE 188
@@ -287,6 +293,16 @@
 
 	pthread_create(&file_thread, 0, FileThread, &filename_data);
 
+	//THREADTEST
+	if(recording_file_thread_policy != SCHED_OTHER)
+	{
+		sched_param param;
+		int policy = recording_file_thread_policy ;
+		param.sched_priority  = recording_file_thread_prio;
+		int ret = pthread_setschedparam (file_thread,  policy, &param);
+		printf("!!!!!!!!! FILE pthread_setschedparam :ret %d,  policy %d,  param %d\n",ret,policy,param.sched_priority );
+	}
+	
 	if (v_arg == &dvrfd)
 		while (exit_flag == STREAM2FILE_STATUS_RUNNING)
 		{
@@ -501,6 +517,15 @@
 		}
 		exit_flag = STREAM2FILE_STATUS_RUNNING;
 		pthread_create(&demux_thread[0], 0, DMXThread, &dvrfd);
+		//THREADTEST
+		if(recording_dmx_thread_policy != SCHED_OTHER)
+		{
+			sched_param param;
+			int policy = recording_dmx_thread_policy ;
+			param.sched_priority  = recording_dmx_thread_prio;
+			int ret = pthread_setschedparam (demux_thread[0],  policy, &param);
+			printf("!!!!!!!!! DMX pthread_setschedparam :ret %d,  policy %d,  param %d\n",ret,policy,param.sched_priority );
+		}
 	}
 	else
 	{
Index: apps/tuxbox/neutrino/src/gui/movieplayer.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/src/gui/movieplayer.cpp,v
retrieving revision 1.138
diff -u -b -B -r1.138 movieplayer.cpp
--- apps/tuxbox/neutrino/src/gui/movieplayer.cpp	31 Dec 2006 13:51:16 -0000	1.138
+++ apps/tuxbox/neutrino/src/gui/movieplayer.cpp	6 Feb 2007 01:41:23 -0000
@@ -403,6 +403,7 @@
 
 	// Stop sectionsd
 	g_Sectionsd->setPauseScanning (true);
+    	g_Sectionsd->freeMemory();  // ??? More Memory for playback
 
 	isBookmark=false;
 	startfilename = "";
@@ -3023,6 +3024,10 @@
 //===============================
 int CMoviePlayerGui::lastParental = -1;
 
+//THREADTEST
+int movieplayer_thread_prio = 20;
+int movieplayer_thread_policy = SCHED_OTHER ;
+
 void CMoviePlayerGui::PlayFile (int parental)
 {
 	neutrino_msg_t      msg;
@@ -3356,6 +3361,15 @@
 				g_playstate = CMoviePlayerGui::STOPPED;
 				break;
 			}
+			//THREADTEST
+			if(movieplayer_thread_policy != SCHED_OTHER)
+			{
+				sched_param param;
+				int policy = movieplayer_thread_policy ;
+				param.sched_priority  = movieplayer_thread_prio;
+				int ret = pthread_setschedparam (rct,  policy, &param);
+				printf("!!!!!!!!! MOVIE pthread_getschedparam :ret %d,  policy %d,  param %d\n",ret,policy,param.sched_priority );
+			}
 		}
 
 		//-- audio track selector                  --
Nirvana
Erleuchteter
Erleuchteter
Beiträge: 646
Registriert: Mittwoch 16. April 2003, 14:12

Beitrag von Nirvana »

Günther hat geschrieben: Durch die Prioritätsverchiebung wird der sectionsd als solches ja nicht unbedingt langsamer. Er darf halt nur nicht sofort wenn er will sondern vielleicht ein paar Sekunden später. In Summe bleibt aber alles beim Alten.
Na dann macht ruhig. Ich habe nur den Timeout der Infobar extrem kurz, ich glaube sogar nur eine Sekunde. Und trotzdem werden beim Umschalten (nein, die Events sind noch nicht im Speicher) die Infos so schnell gelesen, dass ich sie noch präsentiert bekomme und lesen kann.
Wenn sich das ändert, bekommt ihr ein scharfes Veto. ;)