Re: Prozessorzeit zusichern

On Mon, Oct 11, 2004 at 01:22:48PM +0200, Daniel Graupner wrote:
> Oliver Fromme schrieb:
> >Aber wenn man sowas wie rtprio(1) braucht, frage ich mich
> >immer, ob man nicht nur an den Symptomen eines Software-
> >Design-Problems herumdoktert.
>
> folgendes Beispiel:
>
> Ich administriere einen Streaming-Server für ein Internetradio. Darauf
> läuft der icecast als Audio-Streaming-Server. Das Audiosignal kommt von
> der Soundkarte und wird in "Echtzeit" in verschiedene Bitraten mp3 sowie
> ogg umgewandelt. Die Umwandlung übernimmt darkice, der verbrät sehr viel
> Prozessorzeit (hmm, das könnte natürlich ein Design-Problem sein) 8-).

Als Korektur - es muss in Echtzeit umgewandelt werden, aber alles was du
ereichen kannst ist eine mehr oder weniger hohe Wahrscheinlichkeit, dass
es schnell genug passiert.
Selbst mit rtprio kann es vorkommen das der Prozess auf I/O Warten
muss.
Z.B. weil ein ssh connect erst auf die Platte zugreifen muss und die
Maschine jenseits der CPU Leistung in den Keller zieht.

Eigendlich leistet ein nice gute Arbeit was die CPU Zeit angeht, wenn
du denoch mit scp Probleme hast, dann liegt eine andere Ursache vor.
Schon mal daran gedacht den Scheduler feiner einzustellen?
sysctl kern.sched.quantum ist dafür verantwortlich - der Wert ist in
µs und man kann den durchaus auf 10ms runter setzen.
Es geht zwar CPU Zeit durch die zusätzlichen Umschaltungen verloren,
aber bereits mit einer load von 10 hat man ansonsten einen Turnaround
von einer Sekunde - und ein einzelner scp mit idealer Anbindung macht
ja bereits eine load von 1 und damit Pausen von wenigstens 100ms aus.

> Nun kommt es aber eben doch manchmal vor, dass man Sicherheitspatches
> einspielen muß...also Kernel oder Welt neu baut. Dabei gräbt der gcc dem
> darkice ordentlich Prozessorzeit ab und es kann zu einem Ruckeln im
> Audio-Stream kommen. Gut, für diesen Fall reicht auch nice. Anderer
> Fall, manchmal werden größere mp3-Files auf den Rechner kopiert...via
> scp, bei hoher Bandbreite gräbt der sshd Prozessorzeit ab.

Kann nicht - nice legt deutlich fest was abgegraben werden darf.
Entweder sind deine anderen Prozesse nicht in der run Queue, weil
I/O dadurch blockiert wird, oder der Turnaround wird zu ungünstig.

> Nice ist ja wie schon erwähnt wurde keine harte Begrenzung, da spielen
> auch andere Faktoren mit rein (uptime des Dienstes etc.). Daher kommt
> mir rtprio recht gelegen.

Du bist dir aber durchaus darüber im klaren, dass ein hängender rtprio
Prozess die gesammte Maschine lahm legt?
Ich würde das bei komplexen Programmen wie MP3 encodern nicht in
Betracht ziehen - genaugenommen mag ich das Features überhaupt nicht.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message