Re: System-Zeitgeber programmieren

Michaela Susan Buesing wrote:
> Oliver Fromme wrote:
> > Ich
> > persönlich stelle auf meinen Rechnern häufig absichtlich
> > niedrigere Werte ein (mein Notebook hat z.B. HZ=300, was
> > für das Abspielen von Videos günstiger ist als der Default
> > von HZ=1000).
>
> Oh! Das hoert sich interessant an! Kannst Du bitte evtl. ein kurzes
> Kochrezept posten? - Kann ich das in in /boot/loader.conf setzen, oder
> muss ich den Kern neu konigurieren und kompilieren?

Geht beides. Entweder »options HZ=xxx« in die Kernel-
config und dann den Kernel neu bauen, oder »kern.hz="xxx"«
in /boot/loader.conf. Einen Reboot muss man aber in beiden
Fällen machen; man kann den Wert nicht im laufenden Betrieb
ändern.

Nach dem Reboot kann man mit »sysctl kern.clockrate« über-
prüfen, dass der geänderte Wert aktiv ist.

> - Gibt es auch Nachteile, so man nicht irgendwelche speziellen
> Nah-Echtzeit-Anwendungen laufen hat?

Die durch HZ festgelegte Frequenz bestimmt die Granularität
von allem, was mit dem Prozess-Scheduling und sonstigen
Timing-Aktivitäten zu tun hat.

Angenommen HZ ist 100. Wenn man z.B. zwei Prozesse (mit
gleicher Priorität) auf einem UP-System laufen hat, die
beide 100% CPU wollen, dann wird 100 mal pro Sekunde zwi-
schen beiden gewechselt, d.h. jeder bekommt 50 mal pro Se-
kunde eine Zeitscheibe von 10 ms zugeteilt. Sind es 100
solcher Prozesse, kommt jeder nur einmal pro Sekunde dran,
bei ungleichmäßig verteilter Priorität evtl. sogar noch
seltener. Das ist natürlich nicht so toll, besonders bei
interaktiven Sachen oder bei Server-Prozessen, die schnell
auf eine neue Connection reagieren sollen. Daher wurde
der Default in FreeBSD vor einiger Zeit von 100 auf 1000
erhöht. Dadurch wird die »Auflösung«, mit der Prozesse
geschedulet werden, verzehnfacht. Dadurch wird das inter-
aktive Verhalten unter hoher Last verbessert, und die
durchscnittlichen Response-Zeiten auf externe Ereignisse
verkürzt. Bei den Geschwindigkeiten moderner Hardware
kann es schon einen Unterschied machen, ob ein Prozess
nach 10 ms oder schon nach 1 ms auf ein Signal reagiert.
Eine Millisekunde ist eine halbe Ewigkeit für heutige
Prozessoren (auf einem 3-GHz-Prozessor entspricht das
3 Millionen Taktzyklen).

Auch für dummynet(4) und polling(4) ist ein höherer HZ-
Wert bedeutsam. Bei Dummynet, um die Bandbreitenregelung
bei hohen Paketraten möglichst präzise auszuführen, und
bei Polling, um das Intervall zu verkürzen, in dem Inter-
rupts auf die Abarbeitung warten müssen.

Der Nachteil von höheren HZ-Werten ist, dass ein höherer
Interrupt-Overhead auftritt. Die ist aber nur auf älterer
Hardware interessant. Auf einem 15 Jahren alten 486 würde
ich den Wert von HZ auf nicht mehr als 100 einstellen.
(Es muss nicht unbedingt alte Hardware sein: Das gilt auch
für eine entsprechend langsame Soekris-Box oder sonstige
Embedded-Geräte mit langsamen Prozessor.) Auf aktueller
Hardware dagegen, deren Prozessoren im GHz-Bereich arbei-
ten, kann man HZ problemlos auf 10000 oder noch mehr er-
höhen, wenn man sich davon einen Vorteil verspricht (was
aber in der Praxis eher selten sein dürfte).

Aber Vorsicht, wenn man powerd(8) laufen hat oder sonst
einen Stromspar-Mechanismus, der den Prozessortakt senken
kann (z.B. auf Notebooks)! Setzt man HZ unnötig herauf,
und der Prozessortakt wird herabgesenkt, verringert sich
die Verarbeitungsgeschwindigkeit rapide, aber HZ bleibt
natürlich gleich, was dazu führen kann, dass plötzlich
ein erheblicher Teil CPU-Zeit für das Abarbeiten des
Clock-Interrupt-Handlers aufgewandt werden muss. Gerade
auf Notebooks würde ich daher empfehlen, moderate Werte
für HZ zu verwenden.

In der Praxis kann man wohl in 90% der Fälle den Default
unverändert lassen (100 bzw. 1000), ohne dass man einen
spürbaren Nachteil dadurch hat. Ein Absenken ist als
Tuning-Maßnahme auf besonders langsamen Rechnern denkbar.

Auf Rechnern, die als Multimedia-Player dienen, kann es
ratsam sein, HZ auf 300 oder 600 zu setzen. Das ist ein
ganzzahliges Vielfaches von 25, 50 und 60 (und 24 im Falle
von HZ=600), wodurch der Scheduler synchron ist mit den
(Halb-)Bildraten der üblichen Videodateien. Dadurch können
Ruckeleffekte u.ä. reduziert werden, wenn der Player-Pro-
zess mit anderen Prozessen um die CPU kämpft (was bei den
beliebten modernen Desktop-Systemen à la Gnome/KDE durchaus
häufig vorkommt).

Wieviel CPU-Zeit für Interrupt-Prozessing aufgebracht wird,
sieht man z.B. in top(1) oder mit »vmstat 5« (die erste
Zeile ignorieren, da sie nur den Durchschnitt seit Reboot
darstellt). Die Auslöseraten der Interrupts sieht man sehr
schön in »vmstat -i« (Durchschnitt seit Reboot). Übrigens
kann der Wert des Clock-Timers hier ein Vielfaches von HZ
sein (z.B. auf meinem Notebook mit HZ=300 läuft der Clock-
Timer mit 600 HZ), das ist normal und hängt von der Art der
verwendeten Clock-Hardware ab (bei der APIC-Clock ist der
Faktor 2).

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
Any opinions expressed in this message are personal to the author and may
not necessarily reflect the opinions of secnetix GmbH & Co KG in any way.
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als
wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen
pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht,
was ich damit soll." -- Frank Klemm, de.comp.os.unix.discussion
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message