Archiv verlassen und diese Seite im Standarddesign anzeigen : Hohe Systemlast beim Kopieren von Dateien
Hi,
ich wurde grade eben von DonSam auf etwas aufmerksam gemacht, über das ich vor ner ganzen Weile schonmal gestolpert bin, allerdings habe ich es damals als Messfehler abgetan;
Wenn ich Dateien auf meinem System kopieren, egal ob innerhalb einer Partition oder Platte oder zwischen Platten (auch zwischen EIDE und SATA) - also IMMER - kriege ich laut dem Cynapsis Superkaramba-Theme 100% Systemauslastung.
Früher hielt ich es wie schon gesagt für einen Messfehler - seit heute weiss ich, dass top die hohe Auslastung auch sieht - allerdings unter dem Punkt "wa".
"wa" steht wohl für sowas wie I/O Wait - allerdings ist mir nicht klar, wieso der Prozessor auf Festplatten warten muss, die mit DMA laufen :ugly:
Das Problem findet sich öfter wenn man ein bisschen sucht, allerdings keine Lösungen... :(
Ich hoff einfach mal ihr habt brauchbare Ideen.
Mein System ist slackware-current mit Kernel 2.6.11. Für Details bitte in meiner Sig auf "System" klicken.
Festplatten hab ich folgendes:
sda: WD360GD (Western Digital)
sdb: SP1614C (Samsung)
hdb: WD800JB (Western Digital)
Die ersten beiden sind SATA Platten und werden mit libata angesprochen, die letzte ist ne EIDE.
Das Problem tritt wie schon gesagt mit allen auf...
DMA ist aktiviert, allerdings bin ich mir bei den SATA-Platten nicht ganz sicher, da man da ja einiges an Fehlermeldungen beim Aktivieren vorgesetzt kriegt...
# hdparm -d /dev/hdb
/dev/hdb:
using_dma = 1 (on)
# hdparm -d1 /dev/sda
/dev/sda:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for device
# hdparm -d1 /dev/sdb
/dev/sdb:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for device
Da das Problem aber auch mit hdb besteht, vermute ich den Fehler nicht dort...
Bin ratlos...
Shutdown
Ja wie gesagt, das ist ein echt nerviges Problem. Folgendes kann ich dazu beisteuern:
Verhalten ist unabhängig von
- verwendetem Windowmanager
- Kernel (2.6.0 - 2.6.11)
- Außentemperatur
- Chipsatz
- SATA (habe nur ATA, macht keinen Unterschied)
DMA ist aktiviert, trotzdem könnte man meinen, dass die Platten mit PIO-Modus laufen.
Hier noch meine hdparm.conf:
/dev/hda {
mult_sect_io = 16
io32_support = 1
dma = on
transfer_mode = 69
interrupt_unmask = on
}
/dev/hdb {
mult_sect_io = 16
io32_support = 1
dma = on
transfer_mode = 69
interrupt_unmask = on
}
/dev/hde {
mult_sect_io = 16
io32_support = 1
dma = on
transfer_mode = 69
interrupt_unmask = on
}
/dev/hdf {
mult_sect_io = 16
io32_support = 1
dma = on
transfer_mode = 69
interrupt_unmask = on
}
/dev/hdg {
mult_sect_io = 16
io32_support = 1
dma = on
transfer_mode = 69
interrupt_unmask = on
}
hdparm -tT (Werte sind eigentlich bei allen Laufwerken sehr ähnlich)
/dev/hdb:
Timing cached reads: 864 MB in 2.00 seconds = 431.42 MB/sec
Timing buffered disk reads: 124 MB in 3.03 seconds = 40.90 MB/sec
Finde, dass das ganz ok ist, leider sieht es beim Kopieren von Dateien nicht so gut aus: durchschnittlich schlappe 7-11MB/s
Kernel-Config:
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDESCSI=m
#
# IDE chipset support/bugfixes
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_IVB=y
CONFIG_IDEDMA_AUTO=y
Ich mach an dem Problem schon ewig rum, habe bisher aber weder Usrache noch Lösung finden können.
Bei Fragen zu Rechnerkonfig: s. Profil
Noch eine kleine Bitte: es wäre echt super wenn man mal Vergleichswerte bei "wa" hätte. Falls also jemand Zeit und Lust hat: einfach eine Datei kopieren und mit "top" nachsehen, wie hoch der "wa"-Wert ist (steht in der 3. Zeile bei CPU:...)
MfG
Sam
Wenn man sich die Benchmarks auf http://www.namesys.com/benchmarks.html anguckt, so sind um die 10 MB/s bei journaled ext3-write (leider) normal...
Argh, das kann doch nicht wahr sein! Habe alle meine Platten mit ext3 + Journal formatiert. Dass die Übertragungsrate durch ext3 gebremst wird, würde in der Hinsicht Sinn machen, da bei hdparm -tT alles wunderbar flutscht.
Werde mir morgen mal in aller Ruhe die Benchmarks anschauen, die ja doch etwas ausführlicher sind.
Frage: ist das "reiser4" das reiserfs, welches man in Standardkernels findet, oder eine Erweiterung aus der mm Reihe?
MfG
Sam
Das Problem ist nicht das FS oder die Platte. Das Problem ist, dass sämtliche Kopieroperationen (I/O Operationen --> I/O Wait Spalte in top) bei einem normalen PC über die CPU laufen und nicht über einen eigenen Controller (einen richtigen Controller mit einem vernünftigen Chip drauf). Dazu kommt noch der IDE-Bus, der auch nicht für riesige Datenmengen geschaffen ist.
Macht euch keine sorgen: Das ist vollkommen normal.
Die beste (aber auch teuerste Lösung) wäre SCSI mit einem richtig guten Controller, aber das ist für einen Privatmensch ja leider unerschwingbar.
PS: Die Werte von hdparm -tT sind schön und gut, sagen aber im Endeffekt sehr wenig aus.
Das Problem ist nicht das FS oder die Platte.
Doch. genau das sind die Faktoren, die bei der Datentransferrate wirklich ins Gewicht fallen. Auf das andere Problem, 100% CPU-Auslastung beim kopieren, bin ich nicht eingegangen, da ich mit einem 2 GHz Athlon auf maximal 20% wa komme und das beim kopieren zwischen zwei Festplatten die loopaes128 verschlüsselt sind. Es handelt sich also _nicht_ um eine übliche 100% CPU-Auslastung beim kopieren.
Natürlich hast du Recht bezüglich der geringeren CPU-Last bei einem SCSI-System - wieder mal ist das bessere System weniger verbreitet. Der BUS dürfte bei den hier genannten Systemen auch kein entscheidender Faktor sein.
Beides spielt also kaum eine Rolle bei dem in diesem Thread genannten 10MB/s die wohl mehr durch die unangenehme Eigenschaften des ext3 journaling - 2x Write pro Schreiboperation - zustande kommen.
Frage: ist das "reiser4" das reiserfs, welches man in Standardkernels findet, oder eine Erweiterung aus der mm Reihe?
reiserfs = reiser3 = stable kernel
reiser4 ist im mm drin, ich würde von einer Verwendung auf Produktivsystemen bei aktuellem Entwicklungsstand jedoch abraten.
Hmm, also hier mal meine Daten:
debian:/home/zio# hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 448 MB in 2.01 seconds = 223.25 MB/sec
Timing buffered disk reads: 38 MB in 3.02 seconds = 12.59 MB/sec
Beim Kopieren einer 350MB großen Datei habe ich laut top eine Prozessorbelastung von 15% (Pentium2 400 MHz). Das Ganze läuft unter ReiserFS. Den Kopierbefehl habe ich über eine SSH-Konsole gegeben und auf dem Monitor dann top verfolgt.
Achja, das System ist E-IDE, 8,4GB HDD und 7 Jahre alt :rolleyes:
mfg
Ist das jetz normal oder nich? :confused:
Shutdown
~10 MB/s schreibend mit ext3 journaling sind (leider) normal. 100% Systemauslastung definitiv nicht.
OK - hat jemand ne Idee was man da machen kann um die Systemlast zu senken? :rolleyes:
Shutdown
Doch. genau das sind die Faktoren, die bei der Datentransferrate wirklich ins Gewicht fallen.
So groß sind die Unterschiede nicht zwischen den verschiedenen FSs. Es geht dabei um max. 2-4 Mb. Mehr nicht - jedenfalls nach meinen Erfahrungen.
~10 MB/s schreibend mit ext3 journaling sind (leider) normal. 100% Systemauslastung definitiv nicht.
das kann ich nicht nachvollziehen :confused: Hab gerade testweise 3 ISO-Images a 700-770MB von FAT32 auf ext3 kopiert.
Der Midnight Commander zeigt dabei konstante Übertragungsraten von 27 bis 31 MB/s.
Kopiert wurde zwischen 2 einfachen IDE-Platten, von hdc auf hda (also kein RAID).
System: 75-78%, CPU: 20-25% (es lief sonst nur xmms), System-load bis ca. 2.1 (angezeigt von top/qps).
Geschrieben wurde auf ext3, Kernel 2.6.10.
Gruss,
Wolfgang
Außerdem frage ich mich, was iowait generell mit der CPU Last zu tung haben soll.
Beim Kopieren eines 650MB ISO Images habe ich auch einen iowait Wert von ca 0,2 bis 90%, wobei die CPU Last, das entscheidende, maximal 13% beträgt. Die Übertragungsrate liegt dabei bei 35MB/s. Kopiert auf einer 120GB P-ATA Platte von einer Partition kurz vor dem Ende (FAT32) auf eine Partition ganz am Ende (ext3) bzw. meine /home Partition (reiserfs, liegt vor der ext3 Partition) also alles Partitionen im langsamsten Bereich der Platte, wo sich die angeblichen großen Unterschiede zwischen den FS besonders bemerkbar machen müßten. Kernel ist 2.6.11. Kopiert mit mc und cp. Immer das gleiche Ergebnis.
Der iowait Wert wird geringer, wenn ich das Image wieder auf die FAT32 Partition zurückkopiere. Klar, die Partition weiter zum Anfang hin schreibt schneller. Es scheint sich also um die Zeit zu handeln, die das System warten muß, bis im IO Puffer wieder Platz für neue Daten ist. Genaueres war auf die Schnelle nicht zu finden. Aber der Wert sollte evtl. gegen 0 gehen, wenn man mal den Puffer für die Festplatte abschaltet. Was dann der Beweis wäre, daß sich mal wieder jemand viel Gedanken um nichts macht und da Probleme sucht, wo keine sind. ;)
MfG
@sirmoloch && @tictactux
Natürlich lasse ich mich da gerne eines besseren belehren. Meine bisherigen Erfahrungen diesbezüglich zeigen gerade beim schreiben doch sehr enorme Unterschiede zwischen den Dateisystemen. Natürlich ist es schwer hier vergleiche gerade bezüglich der Geschwindigkeit anzustellen. Daher habe ich meine Aussage auf meine bisherigen Erfahrungen, den doch sehr einseitigen Benchmarks von namesys und Informationen wie http://www.novell.com/documentation/suse91/suselinux-adminguide/html/apas02.html gestützt. Dort heißt es so schön
The degree of “care” can be customized. Enabling Ext3 in the data=journal mode offers maximum security (i.e., data integrity), but can slow down the system as both metadata and data are journaled.
Das Problem, so wie ich es verstehe, besteht darin, daß ext3 journaling nun mal ext2+Erweiterungen ist. Guckt man sich Beiträge wie http://seclists.org/lists/linux-kernel/2005/Mar/0794.html an, so wird die Problematik deutlich.
Manche Artikel wie http://www-106.ibm.com/developerworks/linux/library/l-fs7.html gehen sogar so weit reiser bei kleinen/vielen Dateien (hier macht sich der Unterschied in der Implementierung von journaling wohl besonders bemerkbar) eine 10-15x schnellere Performance zuzuschreiben. Allerdings wage ich das aus eigenen Erfahrungen zu bezweifeln.
Das durchforsten der zahlreichen Informationen zu der Thematik, hat allerdings ziemlich wiedersprüchliche Informationen zutage getragen. Übrigens läßt sich mit einer Angabe wie "data=writeback" in der fstab die Performance von ext3 (angeblich enorm) steigern.
@tictactux
27 - 31 MB/s? Wow, mit welchen Parametern hast du hda den eingehängt??? Will auch solche Datentransferraten erreichen!
@frankpr
35MB/s sind auch nicht schlecht. Lässt sich leider schlecht vergleichen, da P-ATA. Hast du eventuell noch eine einfache IDE-Platte mit ext3 im Einsatz, um die Schreibperformance auf diese zu prüfen? Würde mich mal interessieren, in wie weit die hier erreichte 3x Datendurchsatzrate nun auf P-ATA zurückzuführen ist.
/edit
Noch ein sehr interessanter Benchmark der wiederum zu einem ganz anderen Schluß kommt; http://kerneltrap.org/node/715
Demnach ist xfs sogar langsamer als ext3 beim schreiben. reiser4 jedoch fast noch immer doppelt so schnell wie ext3.
Zwei weitere Dateisystem-Benchmark Versuche;
http://linuxgazette.net/102/piszcz.html
http://staff.osuosl.org/~kveton/fs/page2.php
Außerdem frage ich mich, was iowait generell mit der CPU Last zu tung haben soll.
Ups, stimmt. Hier ging es gar nicht um die CPU-Last. Wer lesen kann... Sorry. :ugly:
viel Gedanken um nichts macht und da Probleme sucht, wo keine sind. ;)
Dennoch interessant, daß so manch einer hier auf 3x Datendurchsatzraten gelangt. Wäre schön, wenn diejenigen ihre Konfiguration (davon ausgehend, daß das der Grund ist) mitteilen könnten, um anderen (z.B. mir :-) auch solche Geschwindigkeiten zugute kommen zu lassen.
@dipesh:
Es stimmt, dass reiserfs beim Zugriff auf kleine Dateien (lesend und schreibend) doch merkbar flotter als ext3 oder xfs ist. Aber meine Beobachtungen zeigen das nur in der Zugriffszeit, nicht im Durchsatz. Die Zugriffszeiten eines FS lassen sich auch gut durch die Mountoption noatime steigern - bei xfs und kleinen Dateien hat mir das aber leider auch nichts gebracht.
Wie gesagt: Das sind meine Erfahrungen. Ich lasse mich auch gerne eines Besseren belehren. ;)
@dipesh:
Es stimmt, dass reiserfs beim Zugriff auf kleine Dateien (lesend und schreibend) doch merkbar flotter als ext3 oder xfs ist. Aber meine Beobachtungen zeigen das nur in der Zugriffszeit, nicht im Durchsatz.
Ok. Zugriff ist natürlich etwas anderes und hier kann ich mir auch gut vorstellen, daß die Unterschiede zwischen den Dateisystemen nicht wirklich ins Gewicht fallen.
Ursprünglich ging es jedoch um Datentransferraten beim kopieren und dadurch bedingt die Durchsatzrate bei Schreiboperationen auf journaling Dateisystemen wie ext3 oder reiser. Bei meinen bisherigen Überlegungen hab ich einfach mal die Lese-/Zugriffsoperationen, welche ja auch zum kopieren gehören, außer acht gelassen, da imho diese nicht wirklich als bremsender Faktor beim kopieren zwischen zwei identischen Festplatten mit identischem Dateisystemen in Frage kommen. Ich würde hier mehr die Schreiboperationen als Ursache für geringe Datentransferraten sehen. Dies scheint mir gerade bezüglich der Notwendigkeit Journal und Daten zu pflegen wahrscheinlicher. Allerdings kann solch eine Betrachtung natürlich aufgrund von Caching und Tuningmöglichkeiten bei Lese-/Schreiboperationen auch der falsche Weg sein.
Dennoch interessant, daß so manch einer hier auf 3x Datendurchsatzraten gelangt. Wäre schön, wenn diejenigen ihre Konfiguration (davon ausgehend, daß das der Grund ist) mitteilen könnten, um anderen (z.B. mir :-) auch solche Geschwindigkeiten zugute kommen zu lassen.
Dann hänge ich mal die an, die ich für relevant halte.
Hardwaredaten sind aus der Signatur ersichtlich.
MfG
Dann hänge ich mal die an, die ich für relevant halte.
Hardwaredaten sind aus der Signatur ersichtlich.
Danke. Die Kernel-Konfiguration kann ich, nach testen, jedenfalls schon einmal ausschließen. Hat es übrigens einen besonderen Grund, warum du SMP mit 2 proz's einkompiliert hast obwohl laut Sig nur einer im Einsatz ist?
hdparm-Einstellungen sind ebenfalls identisch und brachten keinen Geschwindigkeitsschub :-/
Er hat einen P4 mit HyperThreading. Für das OS sieht es aus als hätte er zwei CPUs und braucht daher den SMP-Support für HT. ;)
@tictactux
27 - 31 MB/s? Wow, mit welchen Parametern hast du hda den eingehängt??? Will auch solche Datentransferraten erreichen!
Die Platten sind eine 120GB Samsung SP1213N und eine 80GB Maxtor 6Y080L0,
an einem ca. 4 Jahre alten i845 P4-Mainboard (also wirklich nichts Aufregendes :) ).
hdparm -Tt sagt: 883.69 MB/sec und 56.74 MB/sec.
Es sind keine besonderen Kernel- oder mount-Optionen im Einsatz.
Vergleichbare Werte hab ich auch auf anderen Rechnern, selbst mein Notebook
schafft zwischen 2 IDE-Platten über 20 MB/s auf ext3 (Platten mit 4200rpm).
Zum Thema reiserfs: das kann deutlich schneller/effektiver sein bei kleinen Dateien,
da solche direkt im "inode" gespeichert werden (das nutze ich z.B. bei
cddb-Server, wo reiserfs bei >800.000 Dateien eine *große* Platzersparnis
bringt).
Gruss,
Wolfgang
Um mal wieder etwas auf die ursprüngliche Problematik zurückzukommen, frage ich mal ganz konkret:
Ist es normal, dass während Dateien kopiert werden, ich nichts mit dem Rechner anfangen kann? Ich meine bei mir dauert in KDE der Wechsel von einer Arbeitsfläche auf einer andere während eines Kopiervorgangs ~10 Sekunden. Von parallelem Arbeiten wage ich erst gar nicht zu träumen.
Das nervt! :mad: Oder bin ich einfach nur zu ungeduldig :rolleyes: ?
Um noch mehr Verwirrung zu stiften: ich hab jetzt grad was mit dd probiert:
donsam@debian:/mnt/hda1$ dd if=/dev/zero of=/mnt/hda1/testfile bs=4M count=200
200+0 Datensätze ein
200+0 Datensätze aus
838860800 bytes transferred in 11,584523 seconds (72412200 bytes/sec)
Ja, 69 MB/s sind schon nicht schlecht. Konnte leider nicht mehr Daten testen, da dass 'ne ganz kleine Partition ist (für Testzwecke).
Aber: wo liegt dann das Probelm. Ok, so ein Test ist nicht gerade Aussagekräftig, aber immerhin hat das doch gezeigt, dass das System theoretisch 70MB/s schaffen könnte!
Noch ein schönes Rest-Wochenende wünscht
Sam
Ist es normal, dass während Dateien kopiert werden, ich nichts mit dem Rechner anfangen kann? Ich meine bei mir dauert in KDE der Wechsel von einer Arbeitsfläche auf einer andere während eines Kopiervorgangs ~10 Sekunden. Von parallelem Arbeiten wage ich erst gar nicht zu träumen.
es ist normal daß man die Belastung "merkt", auch daß deutliche Reaktionszeiten
bei einigen Operationen (z.B. auch Programmstart). Obige 10 s kann ich jedoch nicht
nachvollziehen (eher 2-4). Da kann aber auch die Rechnerkonfiguration eine
Rolle spielen (wenn große Datenmengen innerhalb einer Platte bewegt werden kann das schon einen Unterschied ausmachen). Auch bei einigen
IDE-Controller kann die Systemlast höher sein, als bei anderen (Intel :) ).
Hast Du getestet, ob es was bringt, solche Kopieraktionen in einem z.B. mit
nice -15 gestarteten Prozeß durchzuführen ?
Hast Du getestet, ob es was bringt, solche Kopieraktionen in einem z.B. mit
nice -15 gestarteten Prozeß durchzuführen ?
Du meinst wohl (+) 15. Hab ich schon probiert. Bringt aber nichts - es ist ja auch nicht der jeweilige Prozess, der die CPU-Last erzeugt, sondern dieser komische 'wa' Wert.
Gruß
Sam
donsam@debian:/mnt/hda1$ dd if=/dev/zero of=/mnt/hda1/testfile bs=4Msei vorsichtig mit solchen Interpretationen. /dev/zero liest sich "etwas" schneller
als eine echte Platte. Versuch mal auch: of=/dev/null :)
Meine Systemplatten sind auf 3 Rechnern immer SCSI-Platten, die IDE-Platten
sind nur als "Datengräber" da. Das wäre eine Möglichkeit, den IO-Flaschenhals
zu entschärfen.
Tipp: es könnte etwas helfen (konkret für GNOME/KDE/X...) das /tmp als tmpfs
(dynamische RAM-Disk) einzurichten, wenn die Anwendungen viele Lock-
Dateien, Sockets u.ä. in /tmp benutzen (KDE benutze ich nicht, könnte mir
aber vorstellen, daß es dafür auch zutrifft). Damit wäre die Kommunikation
über diese Sockets nicht durch Festplattenzugriffe "gestört".
EDIT: ich meinte buchstäblich -15 (was sinngemäß Deinem +15 entspricht,
denn sonst müßte es als root --15 heißen)
EDIT2: Was hast Du für IDE-Controller ? Es gab/gibt Diskussionen in den
kernel-Mailinglisten zum Thema IDE-Performance in 2.6er Kerneln,
vielleicht bringt eine Suche da etwas.
zu dem Problem: 100% CPU bei File-Operationen wie copy habe ich vor ca
4 Mon. in unterschiedlichsten Foren gelesen. In einem war die Mailing-List
der Kernel-Entwickler mit dem Beitrag von Linus Torwald verlink, -
da heißt es: die Probleme sind erst mit dem 2.6.x aufkommen und IDE-, bzw. einigen SCSI-Controller.
sei vorsichtig mit solchen Interpretationen. /dev/zero liest sich "etwas" schneller
als eine echte Platte. Versuch mal auch: of=/dev/null :)
Hab ich grad auch noch getestet, da sind es dann "nur" ~40MB/s.
EDIT2: Was hast Du für IDE-Controller ? Es gab/gibt Diskussionen in den
kernel-Mailinglisten zum Thema IDE-Performance in 2.6er Kerneln,
vielleicht bringt eine Suche da etwas.
Onboard: VIA KT333 Chipsatz.
PCI: Promise TX2-133
Habe auch schon mal was in 'ner Kernel-Mailingliste bezüglich dieses Problems gelesen, allerdings war das nicht sonderlich ergiebig.
Falls irgendwer noch einen möglicherweise interessanten Link zu dem Thema hat, immer her damit :)
Sam
Onboard: VIA KT333 Chipsatz.
PCI: Promise TX2-133
Ich hab VIA KT266, VT8366/A/7
Hast du preemp im Kernel aktiviert? Es mag ein Schuß ins blaue sein, ich selbst hab damit jedoch auch sehr unangenehme Effekte wie (milli-)sekundenlanges einfrieren festgestellt. Ohne funktioniert es einwandfrei.
Hab ich grad auch noch getestet, da sind es dann "nur" ~40MB/s.
hmm, hast Du dich nicht um eine Tausender-Stelle vertan ? denn bei mir:
# dd if=/dev/zero of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1.048.576.000 bytes transferred in 0.019185 seconds (54.656.132.905 bytes/sec)(hab nur tausender-Punkte eingefügt)
Ich hab VIA KT266, VT8366/A/7
Hast du preemp im Kernel aktiviert? Es mag ein Schuß ins blaue sein, ich selbst hab damit jedoch auch sehr unangenehme Effekte wie (milli-)sekundenlanges einfrieren festgestellt. Ohne funktioniert es einwandfrei.
Probleme mit dem preemptiven Kernel konnte ich noch nicht feststellen, im Gegenteil, das System läuft spürbar flüssiger, wenn viele Threads aktiv sind. Das ist ja auch Sinn und Zweck eines preemptiven Kernels, beim Umschalten zwischen den Threads die Latenzzeiten zu verkürzen. KDE profitiert z.B. deutlich davon.
Im Übrigen kann ich mich noch gut an die Probleme des VIA KT 133(A)/266(A) bei hoher PCI Buslast erinnern, VIA mußte seinerzeit jeweils mit Treiberpatches für Windows nachhelfen, die Symptome reichten von lahmer Performance bis zu kompletten Abstürzen, Sörgeräuschen auf Creative Soundkarten während Datentransfers der Festplatten, ... .
MfG
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.