# [solved] Welche Werte habt ihr für iowait beim Kernelbau?

## pir187

Moin,

ihr könnt mein Problem sicher schon erahnen. Mein System erzeugt extrem hohe Werte für iowait unter 

```
top
```

. Dies tritt bei allen I/O-lastigen Aktionen wie 

```
emerge, make && make install, gunzip usw.
```

 auf.

Sagt bitte nicht: "RTFM" oder "Nutz' mal die SuFu!" - ich hätte gerne erst einmal Vergleichswerte!

Zur Info:

```
root@pir187> emerge info

Portage 2.0.54-r2 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.6-r3, 2.6.16-gentoo-r7 i686)

=================================================================

System uname: 2.6.16-gentoo-r7 i686 AMD Athlon(tm) XP 3200+

Gentoo Base System version 1.6.14

dev-lang/python:     2.3.5-r2, 2.4.2

dev-python/pycrypto: [Not Present]

dev-util/ccache:     [Not Present]

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.12

sys-devel/autoconf:  2.13, 2.59-r7

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1

sys-devel/binutils:  2.16.1

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS=""

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d"

CXXFLAGS="-O2 -mcpu=i686 -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"

LANG="de_DE@euro"

LC_ALL="de_DE@euro"

LINGUAS="de"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage/overlay/local"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="x86 3dnow 3dnowext 7zip X a52 aac alsa apm arts audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdr cli crypt cups curl dri dts dvb dvdr eds emboss encode exif expat fam ffmpeg flac foomaticdb fortran gd gdbm gif glut gpm gstreamer gtk2 hal idn imagemagick imlib ipv6 isdnlog java jpeg junit kde lcms libg++ libwww live lm_sensors mad matroska mikmod mmx mmxext mng motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pcre pdflib perl png pppd python qt quicktime readline real recode reflection samba scanner sdl session spell spl sse sse2 ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev usb v4l vorbis win32codecs wxwindows xine xml2 xmms xorg xv xvid zlib linguas_de userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
```

```
root@pir187> hdparm /dev/hda

/dev/hda:

 multcount    = 16 (on)

 IO_support   =  1 (32-bit)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 19457/255/63, sectors = 312581808, start = 0
```

```
root@pir187> hdparm -tT /dev/hda

/dev/hda:

 Timing cached reads:   2000 MB in  2.00 seconds = 1000.26 MB/sec

 Timing buffered disk reads:  206 MB in  3.01 seconds =  68.47 MB/sec
```

Im Kernel habe ich folgende wie ich finde relevante Optionen fest einkompiliert aktiviert:

```
[x] ATA/ATAPI/MFM/RLL support

    [x] Enhanced IDE/MFM... support

    [x] Include IDE/ATA-2 DISK support

    [x] Use multi-mode by default

    [x] Include IDE/ATAPI CDROM support

    [x] generic/default IDE chipset support

    [x] PNP EIDE support

    [x] PCI IDE chipset support

            [x] Generic PCI IDE support

            [x] Generic PCI bus-master DMA support

            [x] Use PCI DMA by default when available

            [x] AMD and nVidia IDE support
```

Mit diesen Settings habe ich die hohen Werte für iowait. Wie schauen Eure Werte, evtl. bei gleichem Grundsystem, aus?

Danke schon mal, pir187

----------

## schmutzfinger

Wo steht diese böse hohe Zahl in top? Was ist hoch? In meinem top hab ich kein iowait gefunden und in der manpage steht dieses Wort auch nicht drinne. Ich hab kein vergleichbares System aber ich denke mal das viele nicht wissen welchen Wert du meinst, und mit dem Wert "hoch" vergleichen ist sowieso schonmal ziemlich schwer.

----------

## hoschi

Bei deinem IDE-Kramm kannst du aber einiges rausschmeissen. Generic-IDE etc.

----------

## think4urs11

 *pir187 wrote:*   

> Mein System erzeugt extrem hohe Werte für iowait unter 
> 
> ```
> top
> ```
> ...

 

Definiere 'hoch' bitte.

Ich hab je nach System irgendwo zwischen 0.0-0.5% wa und 90% wa (SCSI-System), beschweren kann ich mich über deren Performance aber trotzdem nicht.

----------

## Fauli

Du kannst auch mal einen anderen I/O-Scheduler testen, beispielsweise mit:

```
echo deadline >/sys/block/hda/queue/scheduler
```

Der Scheduler muss natürlich fest im Kernel oder als Modul geladen sein.

```
CONFIG_IOSCHED_NOOP=y

CONFIG_IOSCHED_AS=y

CONFIG_IOSCHED_DEADLINE=y

CONFIG_IOSCHED_CFQ=y

CONFIG_DEFAULT_IOSCHED="anticipatory"
```

----------

## pir187

Hallo @all.

Sorry für die ungenaue Angabe. Also, mit den genannten Kerneloptionen befindet sich das System, wenn ich z.B. gerade ein 

```
emerge
```

 ausführe und der Zähler am Ende des Vorganges dann von 0 bis 100% läuft, so locker im Bereich von 70% wait-Auslastung. Das ist der Anteil, zu dem das System auf IO-Vorgänge warten muss.

```
top - 23:38:26 up 9 min,  5 users,  load average: 0.80, 1.68, 1.21

Tasks: 108 total,   1 running, 106 sleeping,   0 stopped,   1 zombie

Cpu(s):  2.2% us,  0.4% sy,  0.0% ni,  0.0% id, [b]96.6% wa[/b],  0.6% hi,  0.2% si

Mem:    904600k total,   728700k used,   175900k free,    46348k buffers

Swap:  2008084k total,        0k used,  2008084k free,   498588k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

  202 root      15   0     0    0    0 D  0.2  0.0   0:00.09 pdflush

11806 kay       18   0  1804  444  300 D  0.2  0.0   0:03.44 gunzip

  949 root      10  -5     0    0    0 D  0.0  0.0   0:00.00 reiserfs/0

11823 kay       16   0  2084 1128  856 R  0.0  0.1   0:00.04 top

11835 root      18   0  2660 1608  508 D  0.0  0.2   0:00.00 hddtem
```

Dieser Anteil (Auszug zeigt Stand während Entpackens einer 5GB gzip-Datei) schwankt so um 70%.

Vorhin habe ich einen Test gemacht und habe mal 

```
AMD and nVidia IDE support
```

 aus der Konfig rausgenommen. Plötzlich gab es im Schnitt nur noch ca. 10% wait-States, dafür war die Platte arschlahm. hdparm -tT brachte eine Wertekombination von 1150MB/s zu 4MB/s. Da stehen sonst 1100MB/s zu 70MB/s. reiserfsck meckerte aber beim Start rum, dass kein DMA verfügbar wäre. Es muss also irgendwie an dem nVidia-Treiber liegen. Vielleicht beisst er sich mit dem generic-Treiber? Ich teste das gleich mal weiter aus.

@fauli: ich habe schon sämtliche Scheduler getestet, es war jedes Mal das selbe. Wenn ich z.B. mit XMMS Webradio höre und nebenbei ein emerge-Vorgang ausführe, stockt der Radioempfang manchmal, wenn die Netzlast des Vorganges schon vorbei ist und dann von 0 bis 100% gezählt wird. Deutet auch auf IO-Probleme hin.

Deshalb nehme ich den anticipatory-Scheduler. Der interne Timer des Kernels steht auf 1000Hz und ist als Preemptible Kernel eingestellt. Preempt Big Kernel Lock ist ebenfalls gewählt.

Der Kernel kompiliert gerade neu...

----------

## pir187

Ein neuer Kernel ohne 

```
generic/default IDE chipset support
```

 und 

```
Generic PCI IDE support
```

 hat keine Verbesserung gebracht. Die iowait-Rate liegt beim Entpacken eines gzip2-Archives bei 100%! Das ist sicher nicht normal, oder?

*ratlos*

pir187

----------

## pepinot

Hallo pir187.

Deine Kernel-Config scheint IMHO in Ordnung zu sein. Dagegen machen mich deine HD-Einstellungen etwas stutzig.

 *Quote:*   

> root@pir187> hdparm /dev/hda
> 
> /dev/hda:
> 
>  multcount    = 16 (on)
> ...

 

Versuch doch zunächst einmal, etwas "konservativere" Werte einzustellen ("unmaskirq = 0 (off)", "IO_support = 0 (16-bit)"), auch wenn dies zunächst auf Kosten der Leistung geht. Vielleicht liegt hier ein Problem. Just a guess.

Gruß,

pepinot

----------

## sschlueter

 *pir187 wrote:*   

> Die iowait-Rate liegt beim Entpacken eines gzip2-Archives bei 100%! Das ist sicher nicht normal, oder?

 

Natürlich ist das normal. Es kann entweder die CPU oder die Festplatte der limitierende Faktor sein. In diesem Fall ist das halt die Festplatte. Das bedeutet, dass die CPU die Daten schneller entpacken kann als sie auf die Platte geschrieben werden können.

----------

## misterjack

edit: müll geschrieben

----------

## pir187

@misterjack: unter kubuntu dapper drake flight7 habe ich beim gzippen eines tar-files 100% cpu-last und 0% iowait-states.

das ist genau das gegenteil von dem, was ich unter gentoo erlebe. wenn ich einen i/o-lastigen vorgang starte, ist das ganze system dann zeitweise lahm gelegt. für emerge nutze ich tmpfs (siehe wiki-eintrag "emerge beschleunigen") und niceness 19! trotzdem stockt das system, wenn ich software aktualisiere. das ist auf keinen fall normal! ich bin kein gentoo-dev, aber mein bisheriges it-leben hat mir soviel intuition beigebracht, um das festzustellen.

jetzt müsste ich nur noch wissen, woran es liegen könnte. wie gesagt, unter kubuntu rennt das system, unter gentoo stockt es i/o-mäßig.

ich bin für alle vorschläge offen, die mir helfen könnten! danke schon mal.

vg, pir187

----------

## mrsteven

Hmm, hast du CONFIG_PREEMPT aktiviert? Damit sollte das System etwas reaktionsschneller werden...

----------

## pir187

Ja, das habe ich:

```
root@pir187> cat /usr/src/linux/.config | grep PREEMPT

# CONFIG_PREEMPT_NONE is not set

# CONFIG_PREEMPT_VOLUNTARY is not set

CONFIG_PREEMPT=y

CONFIG_PREEMPT_BKL=y
```

.

Ist schon so, seit ich mein System neu installiert hatte. Leider reagiert es auch seit damals so träge unter Last  :Sad:  .

pir187

----------

## sschlueter

 *pir187 wrote:*   

> unter kubuntu dapper drake flight7 habe ich beim gzippen eines tar-files 100% cpu-last und 0% iowait-states.

 

Das ist auch normal. In diesem Fall ist eben die CPU der limitierende Faktor.

Das bedeutet, dass das Komprimieren CPU-intensiver ist als das De-Komprimieren.

----------

## pir187

 *Quote:*   

> 
> 
> ```
> unter kubuntu dapper drake flight7 habe ich beim gzippen eines tar-files 100% cpu-last und 0% iowait-states.
> ```
> ...

 

Ja, das ist ja auch richtig, dass die CPU ausgelastet wird - soll sie ruhig. Aber hier tritt eben nicht das Phänomen auf, dass so lange auf die Festplatte gewartet werden muss. Ich habe jetzt mehrere Systeme getestet: meins mit Gentoo und Kubuntu, mein Notebook (Samsung P35 XVM 1600 III) und einen Rechner an meiner Hochschule. Kein anderer Rechner stockt so und erzeugt so oft solch hohe iowait-Werte. Es ist also definitiv ein Problem meiner aktuellen Kernelkonfiguration.

Ich nutze einen monolithischen Kernel, der alle Funktionen einkompiliert hat. Aber daran sollte es nicht liegen, oder?

Unter Kubuntu werden die Module 

```
ide_generic, ide_cd, ide_disk, generic und scsi_mod
```

 geladen. Komisch, denn das Modul für "AMD/nVidia chipset" wird von Kubuntu nicht als benötigt erkannt. Als ich es unter Gentoo weggelassen habe, hatte sich auch nichts verändert  :Sad:  .

Ich bin echt ratlos, ich dachte, ich habe das Thema "Kernel kompilieren" halbwegs im Griff...

*ratlos* pir187

----------

## sschlueter

 *pir187 wrote:*   

> Ja, das ist ja auch richtig, dass die CPU ausgelastet wird - soll sie ruhig. Aber hier tritt eben nicht das Phänomen auf, dass so lange auf die Festplatte gewartet werden muss. Ich habe jetzt mehrere Systeme getestet: meins mit Gentoo und Kubuntu, mein Notebook (Samsung P35 XVM 1600 III) und einen Rechner an meiner Hochschule. Kein anderer Rechner stockt so und erzeugt so oft solch hohe iowait-Werte. Es ist also definitiv ein Problem meiner aktuellen Kernelkonfiguration.

 

Mir ist das alles ehrlich gesagt viel zu schwammig. Erst hast du vom Komprimieren gesprochen, dann vom De-Komprimieren. Dann hast du von Ubuntu gesprochen und nicht geschrieben, welche Befehle du auf welchem System ausgeführt hast.

Du kannst Gentoo und Ubuntu hinsichtlich IO-lastiger Aktionen nur vergleichen, wenn du 

(1) beide Systeme auf derselben Hardware laufen lässt

(2) bei beiden Systemen der DMA-Modus funktioniert

(3) wenn du darauf achtest, dass die Systeme vor dem Test jeweils idle sind

(4) für den Test denselben Befehl mit denselben Eingabedaten verwendest.

Grundsätzlich kann man bei der Kernelkonfiguration hinsichtlich der Festplatte nicht viel falsch machen. Es ist absolut ausreichend, wenn der DMA-Modus beim Festplattenzugriff funktioniert. Alles andere ist für einen einzelnen Test unerheblich. Für das Komprimieren oder das De-Komprimieren einer einzelnen Datei auf einem System, das ansonsten idle ist, ist die Wahl des IO-Schedulers beispielsweise völlig unerheblich.

Hier ein paar Beispiele für einzelne Tests:

* Auf einem idle-System updatedb laufen lassen. Das ergibt im wesentlichen 0% CPU und 100% iowait auf allen Systemen, egal wie schnell CPU und Festplatte sind.

* Auf einem idle-System emerge --metadata laufen lassen. Ist für den Test nicht geeignet, weil unter Ubuntu nicht möglich, aber auch hier wird bei den meisten Systemen die Festplatte der limitierende Faktor sein, wenn auch nicht ganz so krass wie bei updatedb.

* auf einem idle-System gzip für eine einzelne Datei, die Zufallsdaten enthält, laufen lassen. Anschliessend dann gunzip. Hier kann der limitierende Faktor je nach Hardware entweder die CPU oder die Festplatte sein. Aber das Komprimieren ist CPU-intensiver als das De-Komprimieren. Und gzip -9 ist CPU-intensiver als gzip -1. Und bzip2 hat Modi, die noch CPU-intensiver als gzip selbst bei höchster Kompressionsstufe sind.

Wenn du also sowohl unter Ubuntu als auch unter Gentoo auf derselben Hardware jeweils mit funktionierendem DMA-Modus und jeweils 100% idle denselben Befehl mit denselben Eingabedaten ausführst, und du dann während der Ausführung des Befehls eine signifikante Abweichung bei %cpu und %iowait feststellst, dann stimmt etwas nicht. Aber ich würde mal vermuten, dass du so etwas nicht festellen wirst!

Ein ganz anderes Thema ist das "Gefühl" bezüglich der Desktop-Reaktionszeit bzw. der "Interaktivität". Das ist alles andere als trivial und läßt sich nicht mal eben mit top oder vmstat messen. Auch die relevanten Kernel-Optionen sind in diesem Fall vielfältiger.

Ich würde aus diesem Grund vorschlagen, diese beiden Themen in der Diskussion zu trennen.

Edit: Stockende Soundausgabe ist übrigens wieder ein anders Thema, denn das kann etwas mit der Desktop-Interaktivität zu tun haben, muss aber nicht. Es kann sich auch um Treiber- oder Interrupt-Probleme handeln, obwohl die Desktop-Interaktivität grundsätzlich in Ordnung ist.

----------

## pir187

 *Quote:*   

> Mir ist das alles ehrlich gesagt viel zu schwammig. Erst hast du vom Komprimieren gesprochen, dann vom De-Komprimieren. Dann hast du von Ubuntu gesprochen und nicht geschrieben, welche Befehle du auf welchem System ausgeführt hast.

 

Ich habe das seltsame Verhalten meines Systems bei mehreren Aufgaben (tar, gzip, gunzip), aber unter Verwendung der selben Befehle beobachtet. Auch die verwendeten Befehle auf den jeweiligen Linux-Maschinen waren jeweils die selben.

 *Quote:*   

> Du kannst Gentoo und Ubuntu hinsichtlich IO-lastiger Aktionen nur vergleichen, wenn du
> 
> (1) beide Systeme auf derselben Hardware laufen lässt
> 
> (2) bei beiden Systemen der DMA-Modus funktioniert
> ...

 

zu (1): Gentoo ist fest installiert, die Live-CD von Kubuntu lief auf diesem System - nutzt also dieselbe Hardware.

zu (2): Ist gegeben, siehe obere Ausgabe von hdparm.

zu (3): Waren sie. System gebootet, KDE fertig geladen, zu Konsole gewechselt, CPU idle, Befehl ausgeführt -> Beobachtung gemacht

zu (4): siehe erste Antwort

 *Quote:*   

> Grundsätzlich kann man bei der Kernelkonfiguration hinsichtlich der Festplatte nicht viel falsch machen. Es ist absolut ausreichend, wenn der DMA-Modus beim Festplattenzugriff funktioniert. Alles andere ist für einen einzelnen Test unerheblich. Für das Komprimieren oder das De-Komprimieren einer einzelnen Datei auf einem System, das ansonsten idle ist, ist die Wahl des IO-Schedulers beispielsweise völlig unerheblich.
> 
> 

 

Anscheinend reicht es nicht aus oder es klemmt noch woanders, denn die Konfiguration habe ich nun zig Mal geändert (generische Treiber rein/raus, nVidia-Treiber zusätzlich/allein rein/raus)

 *Quote:*   

> Hier ein paar Beispiele für einzelne Tests:
> 
> * Auf einem idle-System updatedb laufen lassen. Das ergibt im wesentlichen 0% CPU und 100% iowait auf allen Systemen, egal wie schnell CPU und Festplatte sind.
> 
> * Auf einem idle-System emerge --metadata laufen lassen. Ist für den Test nicht geeignet, weil unter Ubuntu nicht möglich, aber auch hier wird bei den meisten Systemen die Festplatte der limitierende Faktor sein, wenn auch nicht ganz so krass wie bei updatedb.
> ...

 

Dass die CPU der limitierende Faktor ist, sehe ich ja, wenn ich die selbe Datei per Kubuntu (Gentoo-Partition nach Kubuntu gemountet) gunzippe. Dann rennt die CPU auf Anschlag und es gibt 0% waitstates. Das ist ok und mir egal. Unter Gentoo dreht die CPU aber Däumchen und die Zeit wird in den waitstates verbraten.

 *Quote:*   

> Wenn du also sowohl unter Ubuntu als auch unter Gentoo auf derselben Hardware jeweils mit funktionierendem DMA-Modus und jeweils 100% idle denselben Befehl mit denselben Eingabedaten ausführst, und du dann während der Ausführung des Befehls eine signifikante Abweichung bei %cpu und %iowait feststellst, dann stimmt etwas nicht.

 

Nun sind wir uns endlich einig. Denn das habe ich nun einmal beobachtet.

 *Quote:*   

> Aber ich würde mal vermuten, dass du so etwas nicht festellen wirst!

 

Leider habe ich das festgestellt. Sonst würde mein Topic nicht existieren.

 *Quote:*   

> Ein ganz anderes Thema ist das "Gefühl" bezüglich der Desktop-Reaktionszeit bzw. der "Interaktivität". Das ist alles andere als trivial und läßt sich nicht mal eben mit top oder vmstat messen. Auch die relevanten Kernel-Optionen sind in diesem Fall vielfältiger.

 

Die Trägheit, die ich an meinem Gentoo-System feststelle, finde ich nicht auf anderen Systemen. Sonst wäre es mir nicht aufgefallen.

Beispiel: ich lasse ein 

```
emerge -pvuD world
```

 laufen. Während 

```
Calculating world dependencies
```

 geschrieben steht, dauert es z.B. 5s, bis ein neues Konsolenfenster in xterm geöffnet wird. Dabei ist die CPU-Last ca. 10%, der Rest waitstates. Die Platte macht 70MB/s im Zugriff (siehe hdparm-Ausgabe weiter oben). Auch ein Klick auf das K-Menü wird nicht unter 2s ausgeführt. Sorry, aber bei einem halbwegs aktuellen System mit 2,2GHz, konfiguriert als "Low latency Desktop", mit Preemptive Kernel und dem ganzen Spaß ist das sowohl subjektiv und objektiv langsam! Da kannst Du sagen, was Du willst. Das ist nicht nomal.

 *Quote:*   

> Ich würde aus diesem Grund vorschlagen, diese beiden Themen in der Diskussion zu trennen.

 

Das ist nicht nötig, da ich meinen subjektiven Eindruck sehr wohl in den zwischen mehreren System unterschiedlichen Ausgaben von top bei Ausführung der selben Aufgaben bestätigt sehe.

pir187

----------

## pir187

@pepinot: habe dies auch schon mal versucht. Es hat aber leider nichts gebracht. Zumal Kubuntu die selben "scharfen" Einstellungen nutzt.

pir187

----------

## sschlueter

 *pir187 wrote:*   

> Die Trägheit, die ich an meinem Gentoo-System feststelle, finde ich nicht auf anderen Systemen. Sonst wäre es mir nicht aufgefallen.
> 
> Beispiel: ich lasse ein 
> 
> ```
> ...

 

Für mich klingt das alles nicht ungewöhnlich. Wenn man nur eine einzelne IDE-Platte benutzt, kommt man schnell an die Grenzen. Du kannst in einer solchen Situation ja mal 

```
iostat -d -x hda 5
```

laufen lassen. In der Spalte await kann man ablesen, wie lange es durchschnittlich dauert, bis die Festplatte eine Anfrage abgearbeitet hat. Bei einer IDE-Platte ohne NCQ stauen sich die Anfragen schnell (avgqu-sz), und so kommt es, dass es 5 s dauert, bis ein xterm geladen wird. Da kann man halt nichts machen, ausser mehr Daten im RAM zu cachen oder die Zugriffe auf mehrere Festplatten zu verteilen.

 *pir187 wrote:*   

> 
> 
>  *Quote:*   Ich würde aus diesem Grund vorschlagen, diese beiden Themen in der Diskussion zu trennen. 
> 
> Das ist nicht nötig, da ich meinen subjektiven Eindruck sehr wohl in den zwischen mehreren System unterschiedlichen Ausgaben von top bei Ausführung der selben Aufgaben bestätigt sehe.
> ...

 

Hör mal, es geht doch nicht darum, dass ich dir nicht glaube oder sowas. Es geht darum, dass diese beiden Dinge technisch gesehen total unterschiedlich sind, dass sie unterschiedliche Auswirkungen haben und auch andere Lösungen. Und bis jetzt habe ich noch keinen Hinweis darauf gefunden, dass es etwas mit "Desktop-Interaktivität" zun tun hat. So wie ich es sehe, bringt es zu diesem Zeitpunkt nichts, mit CONFIG_PREEMPT zu experimentieren. Das kann einer IDE-Platte ohne NCQ auch nicht helfen.

Aber mir ist das alles immer noch zu unkonkret. Aus diesem Grund würde ich vorschlagen, dass du einen kleinen Test sowohl unter Gentoo als auch unter Ubuntu machst und die Messwerte hier postest. Lasse "vmstat 5" oder "iostat -d -x hda 5" laufen. Und dann führe die folgenden Befehle aus und poste die Ausgaben der Befehle sowie jeweils mindestens eine Zeile der vmstat- oder iostat-Ausgabe während der Ausführung eines jeden Befehls.

```
# time dd if=/dev/urandom of=random.data bs=1M count=100

# time gzip -1 random.data

# time gunzip random.data.gz

# time gzip -9 random.data

```

Mein System ist gerade alles andere als idle, aber wenn das später mal idle ist, poste ich meine Ergebnisse inklusive der groben Eckdaten der Hardware.

----------

## pir187

 *Quote:*   

> Aber mir ist das alles immer noch zu unkonkret. Aus diesem Grund würde ich vorschlagen, dass du einen kleinen Test sowohl unter Gentoo als auch unter Ubuntu machst und die Messwerte hier postest. Lasse "vmstat 5" oder "iostat -d -x hda 5" laufen. Und dann führe die folgenden Befehle aus und poste die Ausgaben der Befehle sowie jeweils mindestens eine Zeile der vmstat- oder iostat-Ausgabe während der Ausführung eines jeden Befehls.

 

OK, mache ich gleich mal.

Bis dann, pir187

----------

## pir187

@sschlueter: könntest Du bei Deinem nächsten 

```
emerge -uD world
```

 gleichzeitig mal 

```
top
```

 laufen lassen und mir sagen, welcher Wert dort angezeigt wird, wenn z.B. 

```
Calculating world dependencies...
```

 oder 

```
>>> Updating Portage cache
```

auf den Bildschirm steht? Das würde mir wenigstens mal einen Vergleichswert mit einem weiteren System geben.

Den Test mit den Programmen aus Deinem letzten Post mache ich gleich noch...

VG, pir187

----------

## sschlueter

Das verwendete System hat einen Athlon XP 1600+ mit 1Gb RAM und einer 80GB Seagate Barracuda IV.

```
# hdparm -tT /dev/hda

/dev/hda:

 Timing cached reads:   872 MB in  2.00 seconds = 435.19 MB/sec

 Timing buffered disk reads:  104 MB in  3.02 seconds =  34.48 MB/sec
```

Wenn ich "emerge --metadata" ausführe, dann habe ich 80% iowait, wenn das System vorher halbwegs idle gewesen ist.

Ich habe auch "iostat -x hda 5" laufen lassen, um zu überprüfen, warum dieser Befehl so unperformant ist. Das Performance-Problem bei "emerge --metadata" scheint daher zu kommen, dass relativ viele, relativ kleine Leseanfragen an die Festplatte gestellt werden, so dass diese ausgelastet ist, obwohl sie nur eine Netto-Leserate von 250-500KB/s schafft. Hier macht sich dann die Seek-Time der Platte bemerkbar.

Ich muss dazu sagen, dass ich keinerlei Massnahmen ergriffen habe, um Portage zu beschleunigen, insbesondere verwende ich keine tmpfs Laufwerke dafür.

Damit das Ergebnis nicht vom Filesystem Cache des Kerns verfälscht wird (Wenn ich "emerge --metadata" zweimal direkt hintereinander aufrufe, geht es beim zweiten Mal aufgrund gecachter Daten wahnsinnig schnell), habe ich den Cache vorher mit "dd if=/dev/hda of=/dev/null bs=1M count=1000" durcheinander gebracht.

Nebenbemerkung: Das ist auch der Grund, warum ich für den g(unzip) Test Zufallsdaten gewählt habe. Diesen Test kann man nämlich problemlos wiederholen, ohne den Filesystem Cache explizit durcheinander bringen zu müssen, indem man random.data(.gz) einfach löscht und durch Zufallsdaten erneut erzeugen lässt.

----------

## pir187

Hier mal vorweg die einfachen Tests:

```
root@pir187> time dd if=/dev/urandom of=random.data bs=1M count=100

100+0 Datensätze ein

100+0 Datensätze aus

104857600 Bytes (105 MB) kopiert, 22,7636 Sekunden, 4,6 MB/s

real    0m22.819s

user    0m0.002s

sys     0m21.818s

---

root@pir187> time gzip -1 random.data

real    0m8.687s

user    0m7.628s

sys     0m0.562s

---

root@pir187> time gunzip random.data.gz

real    0m1.510s

user    0m0.979s

sys     0m0.419s

---

root@pir187> time gzip -9 random.data

real    0m8.761s

user    0m7.892s

sys     0m0.558s
```

pir187

----------

## sschlueter

Auf welchem System ist das gewesen? Gentoo oder Ubuntu? Und wir brauchen auch die vmstat-Ausgaben während und kurz nach der Ausführung der einzelnen Tests. Kurz danach deshalb, weil die Schreibzugriffe auf die Platte eventuell etwas versetzt stattfinden, zumindest ist das bei mir so gewesen. Bei diesem Punkt bin ich mir nicht ganz sicher, ob das eine grundsätzliche Eigenschaft des Kernels oder eine Eigenschaft von ReiserFS ist. Ich vermute jedoch letzteres.

----------

## pir187

Das Ergebnis wurde auf meinem Gentoo-System erzielt. Kritisch oder zumindest nachdenklich finde ich den ersten Test: 4MB/s auf 'ner IDE-Festplatte (als Master ohne weiteres Gerät)? Scheint mir etwas wenig...

Ich melde mich am Donnerstag abend wieder, bin bis dahin nicht zu Hause.

Es wäre schön, wenn Ihr mir dann weiter helfen könntet, dem Problem auf den Grund zu gehen.

VG, pir187

----------

## sschlueter

 *pir187 wrote:*   

> Das Ergebnis wurde auf meinem Gentoo-System erzielt. Kritisch oder zumindest nachdenklich finde ich den ersten Test: 4MB/s auf 'ner IDE-Festplatte (als Master ohne weiteres Gerät)? Scheint mir etwas wenig...
> 
> 

 

Aus diesem Grund hatte ich ja nach der vmstat-Ausgabe gefragt.

Auf meinem System kommen aus /dev/urandom nur 3MB/s raus. Die Festplatte könnte natürlich auch schneller schreiben, aber die Daten werden eben nicht schneller erzeugt. Das Resultat: 100% CPU-Auslastung (und zwar vom Kernel, nicht vom Userland) und 0% iowait.

----------

## pir187

 *Quote:*   

> Das Resultat: 100% CPU-Auslastung (und zwar vom Kernel, nicht vom Userland) und 0% iowait.

 

Ja, bei mir ebenfalls: us ~5%, sy 100%, wa 0%, restl. Werte unbedeutend.

Hmm, wie gesagt kann ich die Ergebnisse erst Donnerstag posten.

Bis dahin...

VG, pir187

----------

## pir187

Hallo,

sorry, hatte wenig Zeit seit dem letzten Post. Bringe die Werte noch hier ein.

In dem Zusammenhang eine Frage: wie lange dauert es bei Euch im KDE, bis sich eine neue Konsole bei Klick auf ein Icon im Kicker öffnet?

Will keinen neuen Thread wegen der Frage aufmachen, hängt ja sicher alles zusammen  :Crying or Very sad:  !

Viele Grüße, pir187

----------

## freigeist

Konsole über kicker öffnen (inkl. eyecandy von AIGLX und compiz) ca. 2,5 Sekunden auf einem Pentium M 1,7

Ohne eyecandy (AIGLX false) < 1 Sekunde...

----------

## freigeist

Ergebnisse des Tests auf meinem Notebook:

```

hdparm -Tt /dev/hda

/dev/hda:

 Timing cached reads:   2740 MB in  2.00 seconds = 1369.60 MB/sec

 Timing buffered disk reads:  104 MB in  3.04 seconds =  34.24 MB/sec

time dd if=/dev/urandom of=random.data bs=1M count=100

100+0 records in

100+0 records out

104857600 bytes (105 MB) copied, 32.3565 seconds, 3.2 MB/s

real    0m32.392s

user    0m0.001s

sys     0m31.409s

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 1  0      0 237824 179024 403196    0    0     8   756 1301  1519 15 41 43  1

 1  0      0 221984 179040 419584    0    0     0  3299 1201   521  2 98  0  0

 1  0      0 205508 179056 435968    0    0     0  3294 1097   346  0 100  0  0

 1  0      0 189148 179068 452352    0    0     0  3290 1099   293  0 100  0  0

 1  0      0 172780 179076 468736    0    0     0  3290 1114   282  0 100  0  0

 1  0      0 156288 179076 485120    0    0     0  3394 1188   300  0 100  0  0

time gzip -1 random.data

real    0m8.438s

user    0m7.915s

sys     0m0.444s

 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 1  0      0  93264 179116 542256    0    0    20    70 1176  1044 13  2 84  2

 1  0      0 123652 179116 512016    0    0     0  4491 1300  1382 46  4 50  0

 1  0      0  60692 179116 574800    0    0     0 12438 1344   799 94  5  0  1

time gunzip random.data.gz

real    0m3.372s

user    0m1.713s

sys     0m0.438s

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 0  0      0 133928 179136 501512    0    0    20    73 1177  1044 13  2 84  2

 1  0      0  44200 179140 591212    0    0     0 17178 1426   685 32  8 37 23

 0  0      0 133844 179152 501496    0    0     0  3398 1246   460  7  2 91  0

time gzip -9 random.data

real    0m8.632s

user    0m8.114s

sys     0m0.433s

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

 1  0      0  96404 179152 539112    0    0     0  7322 1285   702 65  3 32  0

 1  0      0  34884 179152 600552    0    0     0 12322 1356   788 94  6  0  0

```

----------

## pir187

@freigeist: hmm, mein rechner braucht 6 sekunden für so einen käse! da ist wirklich etwas faul, wenn so einfaches zeug so dauert. ach langsam nervt es wirklich, weiß im moment nicht, was da was bringen kann.

würde es helfen, meinen kernel noch einmal komplett neu zu konfigurieren? also eine blanke installation nehmen und alle optionen neu auswählen anstatt immer 

```
make oldconfig
```

 zu nutzen?

pir187

----------

## freigeist

Warum nimmst du nich einfach erstmal die kernel config von ner live cd (z.B. koroora)? Ich teste die iowaits gleich nochmal auf meinem Desktop (Athlon 64 und Nforce 3 Chipsatz).

----------

## freigeist

Also...mein Desktop sieht anders aus als mein Notebook...ziemlich viele IO Waits...dachte erst es liegt an dem deutlich schnelleren Prozessor, aber dafür waren die Ergebnisse zu schlecht...der Hauptunterschied zwischen Notebook und Desktop ist das Filesystem, mein Desktop hat Reiser4, mein Notebook das "alte" Reiser...die Datenplatte auf meinem Desktop ist aber auch noch altes Reiser und baugleich zur Reiser4...eigentlich müssten die Messwerte also gleich sein, sind sie aber nicht:

Reiser4:

```

time dd if=/dev/urandom of=random.data bs=1M count=100

100+0 records in

100+0 records out

104857600 bytes (105 MB) copied, 29.6866 seconds, 3.5 MB/s

real    0m29.689s

user    0m0.002s

sys     0m22.698s

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa

 1  0      0  10700  15296 807964    0    0     0  2478 1119  372  0 64 19 16

 1  0      0  15036  15284 803500    0    0     0  3342 1133  360  0 78  4 19

 0  0      0  11068  15284 807160    0    0     0  4163 1157  405  1 78  5 16

 1  0      0  16356  15272 801492    0    0     0  3351 1183  360  0 74  5 22

 1  0      0  14332  15272 803684    0    0     0  3346 1173  358  0 76  5 19

 1  0      0  11040  15272 806960    0    0     0  3338 1110  354  0 81  3 16

```

Reiserfs:

```

time dd if=/dev/urandom of=random.data bs=1M count=100

100+0 records in

100+0 records out

104857600 bytes (105 MB) copied, 22.2277 seconds, 4.7 MB/s

real    0m22.238s

user    0m0.002s

sys     0m21.725s

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa

 1  0      0  13612  14960 810780    0    0     2  3072 1113  259  0 76 15  9

 1  0      0  12124  15028 812448    0    0     0  4954 1177  260  0 100  0  0

 1  0      0  10792  15108 813860    0    0     0  4910 1130  250  0 100  0  0

 1  0      0  15720  15192 809124    0    0     0  4963 1250  262  0 100  0  0

```

Fazit: Das Filesystem scheint bzgl. der IOWaits (und wie man sieht damit vmtl. auch für die Performance) eine nicht unerhebliche Rolle zu spielen

----------

## freigeist

In diesem Zusammenhang ist vielleicht auch folgender Vergleich im Bezug auf IO Waits von xfs, reiserfs, ext2/3 interessant: http://www.squid-cache.org/mail-archive/squid-dev/200504/0033.html

----------

## pir187

@freigeist:

kannst du bei deinem system auch sehen, dass firefox-bin z.b. beim laden einer neuen seite fast 100% der cpu-zeit benötigt? das gleiche tritt bei mir auf, wenn ich eine neue konsole in eigenem fenster (aus kicker, nicht innerhalb des selben konsolenfensters) starte.

es kann doch nicht sooo schwer sein, diese kleine konsole zu öffnen, oder? 100% cpu-zeit?

btw: ich habe eine komplett neue .config erstellt, weil ich dachte, etwas beißt sich in der alten. aber es hat sich nichts geändert  :Crying or Very sad:  .

pir187 *erstaunt*

----------

## pir187

hallo noch einmal,

ich habe mittels einer top-instanz auf der konsole festgestellt, dass alle programme, die eine grafische ausgabe auf dem x-server benötigen, stets 100% cpu-last beim starten verursachen. starte ich aber z.b. kubuntu von der live-cd, so ist dies nicht der fall. also muss doch da der hund begraben liegen, oder?

werde meinen x-server neu kompilieren. meine config dürfte ja nicht allzu ungewöhnlich ausschauen, oder?

```
Section "Module"

   SubSection "extmod"

      Option   "omit xfree86-dga"   # don't initialise the DGA extension

   EndSubSection

   Load   "dbe"

   Load   "type1"

   Load   "freetype"

   Load   "glx"

EndSection

Section "Files"

   RgbPath      "/usr/lib/X11/rgb"

   FontPath   "/usr/share/fonts"

   FontPath   "/usr/share/fonts/100dpi/:unscaled

   FontPath   "/usr/share/fonts/100dpi/

   FontPath   "/usr/share/fonts/75dpi:unscaled"

   FontPath   "/usr/share/fonts/75dpi/

   FontPath   "/usr/share/fonts/TTF"

   FontPath   "/usr/share/fonts/Type1"

   FontPath   "/usr/share/fonts/corefonts"

   FontPath   "/usr/share/fonts/cyrillic"

   FontPath   "/usr/share/fonts/default/ghostscript"

   FontPath   "/usr/share/fonts/local"

   FontPath   "/usr/share/fonts/misc"

   FontPath   "/usr/share/fonts/ttf-bitstream-vera"

   FontPath   "/usr/share/fonts/ukr"

   ModulePath   "/usr/X11R6/lib/modules"

EndSection

Section "InputDevice"

   Identifier   "Keyboard0"

   Driver      "kbd"

   Option      "AutoRepeat"   "500 30"

   Option      "XkbRules"   "xfree86"

   Option      "XkbModel"   "pc105"

   Option      "XkbLayout"   "de"

   Option      "XkbVariant"   "basic"

EndSection

Section "InputDevice"

   Identifier   "Mouse0"

   Driver      "mouse"

   Option      "Protocol"   "imps/2"

   Option      "ZAxisMapping"   "4 5"

   Option      "InputFashion"   "Mouse"

   Option      "Device"   "/dev/input/mice"

EndSection

Section "Modes"

   # erstellt am 21.03.2004, Quelle www.sh.nu/nvidia/gtf.php

   # separiert am 07.04.2006

   Identifier   "Modes0"

   Modeline   "800x600_120.00" 83.95 800 856 944 1088 600 601 604 643 -HSync +VSync

   Modeline   "1024x768_100" 113.31 1024 1096 1208 1392 768 769 772 814 -HSync +VSync

   Modeline   "1280x960_100" 178.99 1280 1376 1520 1760 960 961 964 1017 -HSync +VSync

   Modeline    "1280x1024_100.00" 190.96 1280 1376 1520 1760 1024 1025 1028 1085 -HSync +Vsync

EndSection

Section "Monitor"

   Identifier   "Monitor0"

   VendorName   "Samsung"

   ModelName   "SyncMaster 959NF"

   HorizSync      30-110

   VertRefresh    50-160

   UseModes   "Modes0"

   # eingefügt am 07.04.2006

   Option      "DPMS"

EndSection

Section "Device"

   Identifier   "GraphicCard0"

   VendorName   "ASUS"

   Driver         "nvidia"

   VideoRam   131072

   Option      "NoLogo"      "true"

   # folgende Einstellungen nötig, sonst fehlerhafter Cursorschatten in Overlay-Bereichen

   # bzw. flackernde Cursoranimationen

   #Option      "RenderAccel"      "true"

   #Option      "CursorShadow"      "false"

   #Option      "HWCursor"      "false"

   #Option      "Coolbits"      "true"

EndSection

Section "Screen"

   Identifier   "Screen0"

   Device      "GraphicCard0"

   Monitor      "Monitor0"

   DefaultDepth   24

   Subsection    "Display"

       Depth   24

       Modes   "1280x1024_100.00" "1280x960_100" "1024x768_100" "800x600_120.00"

   EndSubsection

EndSection

Section "ServerLayout"

   Identifier   "ServerLayout0"

   Screen      "Screen0"

   InputDevice   "Mouse0"   "CorePointer"

   InputDevice   "Keyboard0"   "CoreKeyboard"

EndSection
```

ich bin für alle vorschläge bzgl. einer lösung dankbar! pir187

----------

## freigeist

Firefox braucht bei mir keine 100% beim start (mal abgesehen davon, dass er eh nach ca. 1 Sekunde da ist, wenn er vorher schoneinmal gestartet war)

----------

## pir187

habe jetzt einmal kanotix 2005.4 auf meinem arbeitsnotebook (ibm thinkpad t41) gebootet und die konsole braucht dort <1s zum starten. firefox zieht keine 100% beim start, auch konqueror oder andere programme nicht.

also wird es wohl doch an meinem x-server liegen. hmm, naja, ob sich das ändert, wenn x neu kompiliert wird? habe auch "nur" 

```
march=athlon-xp -O2 -pipe -fomit-framepointers
```

 als CFLAGS gesetzt. könnte es daran liegen, dass die einstellungen schon zu kritisch sind?

also es ist schon traurig, dass ich mein sys nicht ausnutzen kann  :Crying or Very sad:  . werde morgen x neu übersetzen und dann wieder posten.

schönen abend noch, pir187

----------

## freigeist

wie verhält sich denn kanotix auf deinem Desktop?

----------

## pir187

das teste ich morgen, aber es lief zuletzt normal, also besser in der reaktion als mein aktuelles gentoo. ich teste es morgen vormittag, bin gerade nicht @home. auch kubuntu 6.06 läuft snappy auf dem sys, nur eben gentoo nicht.

ein distriwechsel kommt nicht in die tüte, notfalls mache ich das system komplett neu... aber vorher probiere ich doch lieber noch etwas. ein neuinstallieren dauert immer recht lange...

pir187

----------

## freigeist

was das starten von Programmen angeht...hast du mal prelink probiert, insb. mit -zdynsort -hashvals in den LDFLAGS (gepatchte binutils notwendig)...-Bdirect ist auch ne Möglichkeit allerdings gibt es im Moment wohl einige Diskussionen über Bdirect und das neue --hash-style...-zdynsort -hashvals --as-needed und -Bdirect (ja man kann auch alle 4 nutzen) haben das Starten von Programmen enorm beschleunigt (mind. halbiert)

----------

## pir187

prelink habe ich noch nicht probiert. das sys muss doch auch ohne solche sehr speziellen eingriffe flüssig laufen. das sehe ich ja mit den live-cds. das muss gehen, bevor ich solch speziellen techniken zusätzlich noch einsetze.

vielleicht downgrade ich mal meinen x-server oder gehe auf die stable treiber von nvidia zurück. ich bin nicht wirklich einer, dessen system immer mit dem neuesten vom neuen laufen muss.

wie gesagt, ich werkele morgen daran weiter.

gute n8.

p.s. allez les bleus!

----------

## pir187

habe mein system jetzt noch einmal unter kubuntu 6.06 lts getestet. das ergebnis ist folgendes:

```
ubuntu@ubuntu:~$ sudo hdparm /dev/hda

/dev/hda:

 multcount    =  0 (off)

 IO_support   =  1 (32-bit)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 19457/255/63, sectors = 312581808, start = 0

ubuntu@ubuntu:~$ time dd if=/dev/urandom of=./random.data bs=1024k count=100

100+0 records in

100+0 records out

104857600 bytes (105 MB) copied, 24,8575 seconds, 4,2 MB/s

real    0m24.863s

user    0m0.004s

sys     0m24.760s

ubuntu@ubuntu:~$ time gzip -1 random.data

real    0m8.257s

user    0m7.791s

sys     0m0.351s

ubuntu@ubuntu:~$ time gunzip random.data

real    0m1.316s

user    0m0.951s

sys     0m0.286s

ubuntu@ubuntu:~$ time gzip -9 random.data

real    0m8.543s

user    0m8.120s

sys     0m0.338s
```

also gibt es da doch irgendwo ein problem mit meinem x-server, denn die leistung entspricht unter kubuntu der, die ich gerne unter gentoo hätte  :Sad:  . ich boote jetzt gentoo und kompiliere x neu...

pir187

----------

## pir187

verstehe das wer will, aber jetzt läuft die grafische darstellung wieder so, wie sie auch unter kubuntu ist. konsole startet in weniger als 1s, programme beanspruchen nicht 100% cpu-zeit beim start bzw. wie ff auch während der darstellung neuer seiten oder scrollen.

deshalb setze ich den thread vorerst einmal auf [solved].

danke an alle, die mir mit ihren vorschlägen geholfen haben!

pir187

----------

