Stotternde Maus unter FreeBSD 7.0: Die Lösung

[d4mi4n]

Scharf, das stottern habe ich nicht, aber weiterhin die nicht funktionierende Maus (und Keyboard) wenn ich nach dem Bootvorgang nicht den Stecker ziehe und wieder reinstöpsel, naja etl geht das Problem dann bei 7.1 weg...
Edit: oh sorry ist ja dann ein USB Problem, liegt ja nciht direkt an der Maus

 

[kmh]

VFS ist noch im Giant-Lock?

Sollte dies nicht spätestens in 7.0 nicht mehr im Giant-Lock sein?
Jedenfalls wird das in allen möglichen Quellen im Netz gesagt.

Ich habe genau aus dem Grund den Kernel mit ULE kompiliert, aber eine merkliche Verbesserung konnte ich hier auf einem Pentium-M (R51) nicht bemerken.

 

[j_t]

@d4mi4n: Du hast "USB legacy support" im Bios aktiv, richtig? Deaktiviere das zum Test einmal...

 

[Yamagi]

Das VFS ist nicht mehr direkt im Giant-Lock, es nutzt allerdings nicht globale Lockstrukturen. Diese sind bis jetzt nicht auf SMP angepasst worden, was in dem hochparallelisierten Kernel von FreeBSD 7.0 ein starkes Handycap ist. Falls es euch beruhigt, lockmgr() selbst und das ganze Locking des VFS sind in 8.0-CURRENT reimplementiert worden, dort laufen Festplattenzugriffe deutlich flüssiger, sogar flüssiger als unter Linux. Gewisse dd(1)-Zeilen führen nicht mehr zu sofortigen Zusammenbruch des Systems. Natürlich wird es noch bis FreeBSD 8.0 - geplant für irgendwann 2009, realistisch wohl 2010 - dauern, bis diese Verbesserungen den Endkunden erreichen.

Wenn das Mausruckeln so nervt, dass es unerträglich ist, würde ich einmal ein Update auf 7.0-STABLE probieren. Dort sind Verbesserungen an moused(1) vorgenommen worden, noch einmal extra Verbesserungen an SCHED_ULE und an weiteren Systemkomponenten, die die Leistung auf UP-Maschinen verbessern sollen. Wie weit das in der Realität auch passiert, kann ich mangels Erfahrung leider nicht sagen.

 

[d4mi4n]

j_t: hatte ich schonmal probiert.

Off: Maus und Tastatur können beim Bootloader nciht benutzt werden, komischerweise meckert das bios aber nicht, dass keine Tastatur angeschlossen sei.

Auto: schaltets das Bios immer an.

On: Tastatur und Maus funktionieren bei jedem Bootloader, Bei FreeBSD funktioniert jedoch nach dem Laden des kernels nichts mehr bis zum neu Einstöpseln.

Bemerkt habe ich, dass die erkennung des USBHUB1 und 2 ca. 10 Sekunden hängt beim Booten von FreeBSD. An den Ports an denen nichts dranhängt gibts keine Pause.

Die USB Tastatur hatte keinen PS2 Adapter mitgeliefert, mit meinem vorhandenen funktioniert sie nicht am PS2 Port.


Edit:

Nen PR gibts http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/116699
Leider ist rausziehen und wieder reinstecken keine dauerhafte Lösung....

 

[mapet]

dasselbe hatte ich auch, allerdings funktioniert es an bestimmten ports direkt. vielleicht gibts bei dir ja auch ports, an denen das geht (bei mir hatte ich vorher gamepads an den ports dran und mich gewundert, dass die beim booten gefunden wurden aber maus und tastatur nicht). s-tlk hatte mir zu kbdcontrol geraten, wenn es so nicht funktioniert hätte; vlt. hilft's dir ja weiter.

 

[Eisenfaust]

Das VFS ist nicht mehr direkt im Giant-Lock, es nutzt allerdings nicht globale Lockstrukturen. Diese sind bis jetzt nicht auf SMP angepasst worden, was in dem hochparallelisierten Kernel von FreeBSD 7.0 ein starkes Handycap ist. Falls es euch beruhigt, lockmgr() selbst und das ganze Locking des VFS sind in 8.0-CURRENT reimplementiert worden, dort laufen Festplattenzugriffe deutlich flüssiger, sogar flüssiger als unter Linux. Gewisse dd(1)-Zeilen führen nicht mehr zu sofortigen Zusammenbruch des Systems. Natürlich wird es noch bis FreeBSD 8.0 - geplant für irgendwann 2009, realistisch wohl 2010 - dauern, bis diese Verbesserungen den Endkunden erreichen.

Wenn das Mausruckeln so nervt, dass es unerträglich ist, würde ich einmal ein Update auf 7.0-STABLE probieren. Dort sind Verbesserungen an moused(1) vorgenommen worden, noch einmal extra Verbesserungen an SCHED_ULE und an weiteren Systemkomponenten, die die Leistung auf UP-Maschinen verbessern sollen. Wie weit das in der Realität auch passiert, kann ich mangels Erfahrung leider nicht sagen.

Beruhigend zu hören, daß etwas passiert. Sehr beunruhigend hingegen das geschätze Zeitfenster! Mag 8.0-CURRENT auch noch so gut sein - der Vergleich mit Linux hinkt, denn in den aktuellen Linux-Versionen, die als stabil gelten, ist das Datei-Handling des Betriebssystems einfach flüssiger und unter Linux steht nunmal die (Entwicklungs-)Zeit auch nicht still! Zu hoffen ist, daß in 7.X ein Backport vollzogen wird, der es uns, den jetzigen Anwendern des FreeBSD Systems, ermöglicht, diesen wirklich nervigen "Ruckelmechanismus" bei hoher I/O-Last loszuwerden.

Ich habe nun alle nur erdenklichen 'Patches' und Behelfsmaßnahmen durchprobiert und viel Unsinn mitgemacht. Seit ich FreeBSD 7.0 einsetze, ist meine UP-Maschine (reines 64-Bit System mit einem Athlon64 3500+/2,2 GHz und 2GB RAM sowie vier SATA II-Platten, davon zwei ZFS) bei hoher HD I/O Last und hoher Netzwerklast so gut wie gar nicht mehr benutzbar (auf ihr läuft X und Windowmaker für meine Bequemlichkeit). Ein Fileserver, der ohne X11 mit 8GB RAM und einem Q6600 Quad-Core unter demselben FBSD 7.0-STABLE wie meine heimische Maschine läuft, zeigt unter hoher Plattenlast ebenfalls eigenartige Leistungseinbrüche auf der Konsole - diese stockt und friert desöfteren ein. Ganz wie ein X11-basiertes GUI.
Derzeit versuche ich auf eben besagter Quadcoremaschine mit PostgreSQL Modelldaten aus einem Modellierungsprozeß abzuspeichern bzw. astronomische Daten aus einer DB des JPL mit einem Skript in Tabellen in PGSQL einzulesen. Auf meinem lokalen Q6600, der die Daten auf ein ZFS oder ein UFS2 (wahlweise, zum Test) Dateisystem abspeichert, dauert dieses Procedere etwa doppelt so lange wie auf einem Quad Core XEON, der nur mit 1,83 GHz läuft und nur 4GB RAM zur Verfügung hat, allerdings unter RedHat arbeitet. Die Konfigurationen des postgres Serverdämons sind in etwa gleich - was die Buffer und Speicherparameter betrifft. Der FreeBSD Kernel ist gemäß diverser Ratschläge zur Verwendung von PostgreSQL entsprechend angepaßt (und ich bin es mitlerweile leid zu hören, es sei lediglich ein Anpassungsproblem ...).
Meine FreeBSD Maschinen sind auf dem neuesten Stand (7.0-STABLE, SCHED_ULE) und ich kann sagen, daß sich seit Einführung von 7.0-RELEASE für mich einiges zum Unguten gewandt hat. Auf meinen 64 Bit Maschinen sind durchweg die sattsam bekannten Hänger zu beobachten, zwar werden die i386-Systeme (davon habe ich noch zwei in Betrieb) ebenfalls heimgesucht, aber lange nicht so ausgeprägt wie unter 64Bit.

Nun ja, wenn ich bis 2010 warten müßte, um ein stabiles System (8.0 mit jenen sagenumwobenen Verbesserungen) zu haben, wo wird man dann unter Linux sein?
Nichts für ungut. Aber im HPC-Bereich hat FreeBSD (leider) nichts mehr zu melden und die einst mit 3.X und 4.X gesammelten Meriten 'The Power to serve" kann man jetzt ohne Skrupel getrost auf den Dachboden legen.

 

[s-tlk]

Nichts für ungut. Aber im HPC-Bereich hat FreeBSD (leider) nichts mehr zu melden und die einst mit 3.X und 4.X gesammelten Meriten 'The Power to serve" kann man jetzt ohne Skrupel getrost auf den Dachboden legen.

Dies kann ich absolut nicht nachvollziehen, denn auf 2 Dual-core Xeons läuft ein nicht optimiertes Freebsd 7.0 etwa 2 GFlops schneller als wie unter Linux, wo schon einige Paramter angepasst und getuned sind. Und 14 Gflops gegenüber 12 finde ich schon ohne jegliches Tuning mit einer einfachen Standardinstallation (nur Scheduler getauscht) schon enorm.
Entweder liegt bei dir eine Fehlkonfiguration vor, oder du hast eine merkwürdige Hardwarekombination, die sich da nicht verträgt. Anders kann ich mir das nicht erklären.

Dies soll jetzt auch nicht so gemeint sein, wie einige das falsch verstehen, das man hier keine kritischen Worte gegenüber FreeBSD aussprechen darf, oder das man versucht deine Probleme zu relativieren. Andererseits kann es aber auch nicht sein, das auf einigen System es so viel besser läuft und auf anderen überhaupt nicht. Wenn Linux bei dir so überlegen läuft und du damit arbeiten musst, spricht auch nichts dagegen das zu benutzen. Jedoch wäre es schon interessant zu erfahren woran das liegt, oder haben wir einfach nur so unterschiedliche Auffassungen vom Thema "Schnelligkeit"?
Welche Anwendungen benutzt du jetzt neben PostgreSQL genau und ein paar detailiertere Information zu deinem System könnten sicherlich auch nicht schaden, beispielsweise SATA Controller etc....

 

[FreeBSDuser]

Ist ja wieder das Spiel mit der IO Performance... GFlops sagen darüber wenig aus.

 

[s-tlk]

Eben. Er beschwerte sich darüber das seine Maus ruckelt/Konsole stockt und bei einem HPC Rechner/Cluster ist mir das völlig egal, wenn die Werte in Ordnung sind. Das soll nicht heißen, das es in Ordnung ist. Im Gegenteil, aber es beeinflusst nicht die Leistungsfähigkeit des Os.

 

[Eisenfaust]

Mea culpa.

Natürlich darf man, streng genommen, Äpfel mit Birnen nicht vergleichen, wenn man eine allgemeingültige Aussage machen will.
Allerdings ist es eine nachvollziehbare Tatsache, daß Fanboys immer einen falschen Krümel suchen und finden werden!

Zur I/O-Performance: egal ob Desktop oder HPC-System, FreeBSD 7 krankt an einem Problem, das in beiden Anwendungsbereichen Auswirkungen hat, unabhängig von der verwendeten Hardware.

Die GFlops Leistung, die angeblich auf einem FBSD System besser sein soll, kann ich nicht bestätigen (allerdings sind meine Meßversuche schon eine Weile her und betreffen 7.0-REL, wenn es um FreeBSD geht). Das liegt wohl eher daran, daß ich unter Linux nativ Intel- oder PGI-Compiler einsetzen konnte, während ich unter FreeBSD in C lediglich GNU gcc oder den NAG C Compiler nutzen kann.
Linux und FreeBSD nur mit gcc habe ich (noch) nicht getestet. Mir fehlt einfach im Moment die Zeit.

Problematisch ist, daß sowohl meine Desktop-Systeme, Midrange- und Cluster-Server, sofern unter FreeBSD, alle ein immer noch nicht gelöstes I/O-Problem haben, wenn die Last auf dem Netzwerkinterface und/oder SATA-Controller hoch wird. Das betrifft dann sowohl ZFS- als auch UFS2-Dateisysteme. Und da kann ein FreeBSD auf der selben Hardware noch so viel GFLOPs mehr als Linux haben, wenn die Kiste beim Speichern großer Datenmengen bockt, hab ich ein Problem.

 

[s-tlk]

Das liegt wohl eher daran, daß ich unter Linux nativ Intel- oder PGI-Compiler einsetzen konnte, während ich unter FreeBSD in C lediglich GNU gcc oder den NAG C Compiler nutzen kann.

Ich wollte gerade sagen, das dies aber nun wirklich kein fairer Vergleich ist. Da sollte man schon versuchen den gleichen Compiler und die gleiche Version mit den selben Makefiles auf den beiden Systemen zu übersetzen, um da jedenfalls vergleichbare Bedingungen zu schaffen. Und selbst da können diverse Parameter immernoch dazwischen funken, was aber auf unterschiedlichen Systemen klar sein sollte. Naja wie auch immer...

Problematisch ist, daß sowohl meine Desktop-Systeme, Midrange- und Cluster-Server, sofern unter FreeBSD, alle ein immer noch nicht gelöstes I/O-Problem haben, wenn die Last auf dem Netzwerkinterface und/oder SATA-Controller hoch wird. Das betrifft dann sowohl ZFS- als auch UFS2-Dateisysteme. Und da kann ein FreeBSD auf der selben Hardware noch so viel GFLOPs mehr als Linux haben, wenn die Kiste beim Speichern großer Datenmengen bockt, hab ich ein Problem.

Wie gesagt, kann ich diese Probleme nicht nachvollziehen, da ich ein FreeBSD auf mehreren (ältern Dual-Core Xeons testweise) installiert habe und zb gromacs darauf laufen lasse, das zuerst mehrere 100MB große Testfiles einlesen muss und gegen Ende der Berechnung einige GB wieder wegschreibt. Auf der Konsole (allerdings über ssh) habe ich da keine Verzögerung, oder die besagten Ruckler feststellen können.

Privat habe ich aber auch diese Ruckler schon mal bemerkt, allerdings unter X11 und bei sehr hoher I/O Last. Kopieren von Dateien, während er andere noch am hashen war etc. Störend ist es auf jeden Fall, aber so extrem waren sie jetzt bei mir sicher nicht. Nichtsdestotrotz ist das ein (nerviger) Bug, daran besteht kein Zweifel, aber eine Rückportierung auf 7.x wird es wohl leider nicht geben. Dafür waren die Änderungen am VFS Framework zu umfangreich. :-/

 

[Yamagi]

Also, ich könnte jetzt noch einmal die ganze Leiher von wegen mangelnder Manpower, ca. 1000 Kernelentwickler am Linux gegen 250 FreeBSD-Entwickler am ganzen System, abspulen, aber das bringt uns hier nicht weiter und wäre am Thema vorbei. Daher erst einmal ein kleines Update. FreeBSD hat im großen und ganzen noch 4 Teilsysteme in der Lockorder. Das sind einmal kleine Teile des Netzwerkstacks, deren Auswirkungen allerdings gering sind. Diese werden in FreeBSD 8.0 behoben sein, Robert Watson schwingt gerade die Axt und holzt alles, was nicht angepasst wurde, ab. Dann ist da das VFS. Der hier schuldige lockmgr() ist komplett reimplementiert worden, das VFS ist damit zeitgemäß schnell. Ein MFC dieser Änderungen ist allerdings unwahrscheinlich, sie sind schlicht zu umfangreich und brechen die KPI. Das dritte Subsystem ist TTY, in solchen Diskussionen gern vergessen. Das halbe System hängt daran, von Teilen des Netzwerks (SLIP), über die ganze Nutzerschnittstelle, bis hin zu X11. TTY wird gerade von Ed Schouten reimplementiert und soll wohl in der nächsten Zeit nach und nach commitet werden. Der Reimplementierung wird höchstwahrscheinlich eine ganze Reihe Probleme mit der Nutzerschnittstelle lösen, angefangen bei den sich wiederholenden Tastendrücken bis hin zur absolut kranken Mausimplementierung. Ein MFC dürfte auch hier sehr unwahrscheinlich sein, da die KPI gebrochen wird, die Änderungen extrem umfangreich sind und das halbe System betreffen. Das letzte Subsystem ist die Dauerkatastrophe USB. Hier ist man wohl soweit, dass der HPS-Stack als Alternative gesehen wird und es wohl wirklich konkrete Pläne gibt, ihn als komplett neues USB-Subsystem zu integrieren. In wie weit das geschehen wird, wird die Zeit zeigen. Auch hier wieder eher kein MFC. Also kurz gesagt, alle hier und in anderen Threads immer wieder angesprochene Probleme sind bekannt und dürften in 8.0 gelöst sein. Ist übrigens für den Sommer 2009 geplant. Es ist also reichlich sinnlos jetzt hier die nächste Grundsatzdskussion zu starten, sie bringt eh nichts, da dadurch nichts schneller geht. Da allerdings auch 8.0 keinesfalls auf irgendwelche UP-Systeme optimiert sein wird und auf ihnen genau die selben Probleme haben wird wie ein 7.0 - was vor dem Hintergrund, dass UP gerade reihenweise auf den Müll fliegt durchaus sinnvoll ist - wird auch ein 6.4 immer wieder mal gern diskutiert.

Ansonsten kann ich zu HPC nur sagen, du hast bei Linux und FreeBSD die Wahl zwischen Pest und Cholera. FreeBSD hat Probleme mit dem IO und kann die Topologie deiner Maschine nur im für die Praxis irrelevanten -current beachten. Gehst du zu Linux, werde diese beiden Dinge schon gut funktionieren, allerdings bekommt man dafür ein absolut bescheuertes Scheduling, was sich ständig selbst blockiert, solange man nicht mit Unmengen nice(1) um sich wirft und ein nach wie vor teil wirklich inperformantes SMP, was sich auch gern mal verheddert und verklemmt. Daher ist es doch recht einfach. Unter FreeBSD mit konkreten Problemen leben, die behoben werden. Unter Linux mit eher schwer zu fassenden Problemen leben und auf eine zukünftige Kernelversion hoffen, wo diese verschwunden sind. Beides ist nicht optimal. Daher kann man sich gleich sagen, dass im Bereich HPC und wirklich große Kisten beides im Moment nur Kompromisse sind und lieber auf ein klar dafür ausgelegtes System wie Solaris setzen, was in fast allen Punkten besser ist, auf diesen Workload bezogen.

 

[jtsn]

Irgendwie ist das ganze sehr witzig. U. a. wegen Mausruckeln bin ich anno dunnemals von Linux zu FreeBSD gekommen. Geschichte wiederholt sich.

 

[Kamikaze]

Selbst auf meinem ollen P4 mit 1.6 GHz (deutlich langsamer als der Pentium-M mit 1.3 GHz, bevor der in Rauch aufging) braucht man unter RELENG_7 schon einen echt harten Workload um störende Einbrüche festzustellen. Soweit ich das sehe, setze ich den Rechner uneingeschränkt ein.

 

[Eisenfaust]

Dies kann ich absolut nicht nachvollziehen, denn auf 2 Dual-core Xeons läuft ein nicht optimiertes Freebsd 7.0 etwa 2 GFlops schneller als wie unter Linux, wo schon einige Paramter angepasst und getuned sind. Und 14 Gflops gegenüber 12 finde ich schon ohne jegliches Tuning mit einer einfachen Standardinstallation (nur Scheduler getauscht) schon enorm.
Entweder liegt bei dir eine Fehlkonfiguration vor, oder du hast eine merkwürdige Hardwarekombination, die sich da nicht verträgt. Anders kann ich mir das nicht erklären.

Nun habe ich einige Zeit damit verbracht Informationen zu sammeln, die Deine Aussage der 2 GFLOPS Differenz unterfüttern könnten und habe nichts Vernünftiges finden können. Bislang nur belangloses Gerede, unsaubere 'Tests' oder schlichtweg nur Lippenbekenntnisse einiger Fanboys.
Kannst Du mir sagen woher Deine Information stammt oder mir Näheres zur Konfiguration mitteilen?

Eine 'Fehlkonfiguration', wie Du sie vielleicht gerne sehen möchtest, liegt mit hoher Wahrscheinlichkeit nicht vor. Zumindest nicht in dem Sinne, daß ein eklatanter Fehler vorliegen könnte. Das Problem des 'stehenden Systems' trat mit Wechsel von FBSD 6 nach FBSD 7 auf. Und nochmals: für den X11-Anwender waren die beschriebenen Probleme offensichtlich, weil das 'haptische' System stockte. Nähere Betrachtungen bei headless-Servern aber zeigten ganz ähnliche Einbrüche bei hoher SATA-I/O und Einbrüchen im Bereich Netzwerk.
Das betrifft vor allem UP-Systeme unter 64Bit! Auf der gleichen Hardware unter 32Bit (AMD 3500+ bei 2,2 GHz und 2 oder 4 GB RAM) sind diese massiven Aussetzer zwar auch spürbar, allerdings nicht derart massiv und einschränkend wie unter 64Bit. Selbiges gilt für meine Dual- und Quad-Coresysteme, da tritt allerdings das Problem nicht nicht so empfindlich auf, Dank SMP. Eine P4-CPU mit SMT unter 32 Bit verhält sich noch flüssiger, wobei ich hier nicht wirklich ausreichend Tests durchgeführt habe, da 32Bit Systeme für mich mitlerweile außerhalb des Fokusses sind.

Während unter 6.2 ein 'build world' ca. 90 Minuten dauerte, nimmt es jetzt auf der gleichen Hardware (unverändert) 120 Minuten in Anspruch (AMD64, 2,2 GHz). Da sich mit 7.0 Compiler und System geändert haben, ist das natürlich kaum ein 'echtes' Maß, wohl aber der Umstand, daß ich vor 7.0 problemlos ein System UND einen Port bzw. Updates dieser ohne Störungen fahren konnte - das ist nicht mehr möglich, mit den bislang hier breitgewalzten Problemen.
Eine Vermutung ist, daß vielleicht der Compiler aggressiver arbeitet.

Wenn man unter FreeBSD 7.0-STABLE, der zu diesem Zeitpunkt aktuellen Xorg-Version, Windowmaker und mplayer (die Software ist auf dem aktuellsten Stand!) ein Musikstück hört oder einen Film schaut und mit dem Mauszeiger (USB und/oder PS/2 Maus) ein Fenster anfaßt und es größer oder kleiner macht und dann bei gedrückter Maustaste inne hält, hört die Musik einfach auf zu spielen oder der Film bleibt stehen. Und das bleibt nicht dabei, Platten I/O sowie Netzwerk-Verkehr brechen auch einfach ein! Und das kann ich auf zwei Maschinen reproduzieren, einem Quadcore und einer UP Maschine, beide 64Bit, SCHED_ULE, PREEMPTION. System gleicher Stand, Software (Ports) ebenfalls aktuell. Lustig, nicht ... In einem Fall ist es eine M-Audio PCI-Karte mit entsprechendem Treiber, im anderen Falle der HD-Audio Chip auf einem P35 basierten Board. eigentlich ist diese Info irrelevant, da auf unterschiedlichen Architekturen das Problem auftritt und damit als Betriebssystemproblem identifiziert werden kann.

Vielleicht kann jemand von euch diesen Fall nachvollziehen und darüberhinaus mir Informationen/Quellen über die interessanten GFLOPS-Diskrepanzen nennen.
Danke

 

[s-tlk]

Nun habe ich einige Zeit damit verbracht Informationen zu sammeln, die Deine Aussage der 2 GFLOPS Differenz unterfüttern könnten und habe nichts Vernünftiges finden können. Bislang nur belangloses Gerede, unsaubere 'Tests' oder schlichtweg nur Lippenbekenntnisse einiger Fanboys.
Kannst Du mir sagen woher Deine Information stammt oder mir Näheres zur Konfiguration mitteilen?

Meine Informationen stammen von eigenen Tests, weil das 'mein' Arbeitssystem ist. Es sind 2 Dual-Core Xeons mit 2,8GHz und 8Gb Ram pro Knoten. Es wird der Ule-Scheduler benutzt. Das Linux System ist Scientific Linux 5. Zum Testen wurde der Linpack Benchmark HPL benutzt.
Ich weiß jetzt auch nicht, was du genau von mir höhren willst? Einige Diagramme werde ich später mal erstellen müssen, da ich atm an einer anderen Sache arbeite. Aber in der Sache wirst du mir wohl glauben müssen....

Das es besonders auf Singlecore Maschinen zu solchen Leistungseinbrüchen kommen kann ist längst bekannt, da FreeBSD 7.0 für SMP Systeme optimiert worden ist. Dort fährt man halt noch besser mit einem 6.x.

Vielleicht kann jemand von euch diesen Fall nachvollziehen und darüberhinaus mir Informationen/Quellen über die interessanten GFLOPS-Diskrepanzen nennen.
Danke

Mh ich verstehe jetzt aber auch nicht was das damit zu tun haben soll? Welche Rechenleistung das System erzielt und wie "userfreundlich" es dabei ist, sind doch 2 unterschiedliche Dinge. Ich hab das nur mal angeführt, um zu zeigen, das es beim User "ruckelt" nichts damit zu tun hat, das das System langsam läuft. Es legt halt nur andere Prioritäten. Wobei hier die I/O Einbrüche ja durch das kaputte VFS Interlocking verursacht werden.