Von fetter-linuxnerd am Di, 22. September 2009 um 15:50 #
endlich, dann passt sich der linuxkernel, vom aussehen her also den linuxnutzern an :P
das wäre auch eine erklärung dafür, wieso nach all den vielen releases, für mich persönlich, noch immer 2.6.24 am "schnellsten" rennt.
gabs da nicht mal nen test drüber, das seit 2.6.24 irgendwas irrsinnige performanceverluste verursacht?
beispiel: ich betreibe mein system nur mithilfe von live cds.
knoppix mit 2.6.24 ist superflüssig. sidux mit 2.6.27 jedoch, spielt videos schon nicht mehr so flüssig ab UND die hd performance fühlt sich irgendwie langsamer an.
Ist doch schon arm dass man alte versionen benutzen muss weil die neueren so beschissen programmiert wurden dass selbst fluessiges video abspielen unmoeglich ist
Von fetter-linuxnerd am Di, 22. September 2009 um 16:30 #
es ist eher so, dass die videos mit 2.6.27 und 2.6.30 zwar abgespielt werden, es jedoch immer wieder zu kleinen mikrorucklern kommt und sich imemr wieder ein paar asynchronitäten einschleichen. das geht so weit, das die videos, die ich mit 2.6.27+2.6.30 lade, auch auf 2.6.24 so abgespielt werden. dürfte also die dateien irgendwie "ändern".
dateien, die ich mit 2.6.24 lade laufen immer flüssig.
auch geht das schreiben auf der hd mit 2.6.24 um einiges schneller.
Von kartoffel200 am Mi, 23. September 2009 um 16:36 #
Aha du bist wohl ein kleiner Experte... Videos, man die werden soooo was vom Kernel beschleunigt.... Seit der ATi Mach64 oder der RAGE hat jede verfickte Graka extra MPEG fähigkeiten. Muss also der kleine "experte" weg von Chips und Cola und sich nen Treiber basteln der die Graka mit dem nötigen Scheiß vollnöhlt. Deshalb ziehen HD Videos, auch beim richtigen Codec, bei fehlender Grakaunterstützung ordentlich CPU Leistung.
Ob der Kernel 2.6.24 oder 2.6.30 schneller ist oder nicht kann der normale Dekstopanwender eh nicht rausfinden, da der Xorg im Regelfall von Distri zu Distri neuer wird.
Von irgendwer am Di, 22. September 2009 um 16:32 #
Das hat wohl weniger mit dem Kernel zu tun als viel mehr damit, dass wahrscheinlich seine Grafikkarte schlicht von Knoppix besser unterstützt/erkannt wird. Grafikperformance macht meines Wissens zwischen den Kerneln keinen großen Unterschied. Dahingegen macht es einen riesen Unterschied, ob nun xorgs vesa-Treiber, die freien nv/radeon-Treiber oder gar die proprietären nvidia/fglrx-Treiber zum Zuge kommen. (oder bei Intel z.B. welche Treiberversion mit welchem Beschleunigermodus: xaa, exa oder gar uxa)
So merken wird man den Unterschied von 2.6.2x und folgenden wohl eher weniger. Es sei denn, es kommen unterschiedliche Scheduler, Memory Management, etc. zum Einsatz. Das ist es aber nicht, worum es hier ging.
... versuch mal den i915 mit nem 2.6.29er kernel und mit nem 2.6.31er kernel. möglichst mit aktiviertem kms .... es ist der unterschied zwischen himmel und hölle.
Von irgendwer am Do, 24. September 2009 um 13:52 #
Na das sind ja dann eben auch unterschiedliche Treiberschnittstellen. Und wenn der Grafikkartentreiber ein anderer ist (bzw. in einer anderen Konfiguration läuft), dann macht das natürlich einen fühlbaren Unterschied in der gui. Intel mit uxa und gem ist nunmal schneller als mit xaa... und in der Umstellungsphase ist vieles einfach nur ein Graus...
Es gibt einen mutmaßlichen I/O-Bug in Kernel seit etwa 2.6.15/2.6.18, der im schlimmsten Falle auch noch so "starke" Systeme mit 100% auslastet. An Xorg wird zur Zeit allerdings auch sehr viel verändert. Je nach Grafikkarte befindet sich u.U. sogar die zugehörige Kernel-Firmware mittlerweile in non-free. Welche Grafikkarte werkelt denn in Deinem Rechner?
will ein Tester mit Kernel 2.6.31 eine geringe Verbesserung bemerkt haben: "There is an improvement in desktop responsiveness with kernel 2.6.31 and the as scheduler compared to the cfq scheduler. It does not solve the problem, but it makes it more sufferable."
Das Hauptproblem ist, dass es keine stabile Kernel-2.6-Reihe von kernel.org gibt (die also jetzt noch supportet wird), die diesen Bug nicht hat. Ich persönlich setze - falls die Hardware es erlaubt - Kernel 2.4 ein, wo es nur möglich ist.
Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link.
Falls Deine Hardware geeignet sein sollte, so lasse z.B. Slackware 11.0 mit Kernel 2.4 gegen ein neuestes Linux mit Kernel 2.6 antreten und lass deinen Rechner einmal so richtig arbeiten (mitunter reichen schon große Kopieraktionen im Rahmen des Versuchs von "Multitasking"; oder kompilier einen Kernel und arbeite gleichzeitig mit einem anderen Programmen weiter; usw.). Du wirst schnell feststellen, welches System "responsiver" ist.
Kernel 2.6-Systeme verhalten sich unter annähernder Vollast, wenn denn der I/O-Bug zuschlägt, wie damals Win95 beim Formatieren einer Diskette. Siehe hierzu Kommentar 323 unter obigem Link: "The irony is that it feels like Windows 95 while a floppy was formated. You know, the whole pseudo multi tasking on top of Dos - everything was really choppy. (...) If I encode a DVD with ogmrip/mencoder h264 and 16 threads (16 threads get the highest cpu usage from my quad core which is still under 80% per core) Gnome feels like a formatting Win 95."
Von betroffener am Mi, 23. September 2009 um 08:26 #
Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link. Doch er ist GERADE auf Desktopsystemen nervig. Kopiere einfach mal ein paar Videos, ISOs, Backup,... von/zu USB-Platten und mach nebenbei was anderes, schon bist du betroffen. Mich nervt der Bug jeden Tag und kotzt mich immer mehr an. Normalerweise sind Bugs unter Linux schnell erkannt und gefixt aber hier wissen die Entwickler nicht mal wo das Problem ist.
Von Michael Lehmeier am Mi, 23. September 2009 um 09:21 #
Wenn das dieser Bug ist, in den ich häufig reinlaufe, dann kann ich bestätigen, dass er nervig ist ohne Ende.
Wenn ich versuche, ein 16 GB Backup auf eine verschlüsselte SATA-Compact-Flash Karte oder USB-Stick zu machen ist die Wahrscheinlichkeit groß, dass der Computer sich so aufhängt, dass nur noch ein Reset hilft. Nur in kleinen Häppchen mit sync dazwischen geht das gut. Das sehe ich nicht als "nicht so wichtig" an.
Dieser I/O-Bug ist tatsächlich nervig. Es aber gut zu wissen, was es eigentlich mit diesem "der Linux-Kernel ist fett und aufgebläht" auf sich hat. Immerhin weißt Du definitiv, dass Du nicht "träumst".
das wäre auch eine erklärung dafür, wieso nach all den vielen releases, für mich persönlich, noch immer 2.6.24 am "schnellsten" rennt.
gabs da nicht mal nen test drüber, das seit 2.6.24 irgendwas irrsinnige performanceverluste verursacht?
beispiel: ich betreibe mein system nur mithilfe von live cds.
knoppix mit 2.6.24 ist superflüssig. sidux mit 2.6.27 jedoch, spielt videos schon nicht mehr so flüssig ab UND die hd performance fühlt sich irgendwie langsamer an.
dasselbe gilt für 2.6.30 sidux.
bis auf weiteres, bleibe ich also auf 2.6.24
dateien, die ich mit 2.6.24 lade laufen immer flüssig.
auch geht das schreiben auf der hd mit 2.6.24 um einiges schneller.
Seit der ATi Mach64 oder der RAGE hat jede verfickte Graka extra MPEG fähigkeiten. Muss also der kleine "experte" weg von Chips und Cola und sich nen Treiber basteln der die Graka mit dem nötigen Scheiß vollnöhlt.
Deshalb ziehen HD Videos, auch beim richtigen Codec, bei fehlender Grakaunterstützung ordentlich CPU Leistung.
Ob der Kernel 2.6.24 oder 2.6.30 schneller ist oder nicht kann der normale Dekstopanwender eh nicht rausfinden, da der Xorg im Regelfall von Distri zu Distri neuer wird.
Grafikperformance macht meines Wissens zwischen den Kerneln keinen großen Unterschied. Dahingegen macht es einen riesen Unterschied, ob nun xorgs vesa-Treiber, die freien nv/radeon-Treiber oder gar die proprietären nvidia/fglrx-Treiber zum Zuge kommen.
(oder bei Intel z.B. welche Treiberversion mit welchem Beschleunigermodus: xaa, exa oder gar uxa)
So merken wird man den Unterschied von 2.6.2x und folgenden wohl eher weniger. Es sei denn, es kommen unterschiedliche Scheduler, Memory Management, etc. zum Einsatz. Das ist es aber nicht, worum es hier ging.
Intel mit uxa und gem ist nunmal schneller als mit xaa... und in der Umstellungsphase ist vieles einfach nur ein Graus...
An Xorg wird zur Zeit allerdings auch sehr viel verändert. Je nach Grafikkarte befindet sich u.U. sogar die zugehörige Kernel-Firmware mittlerweile in non-free.
Welche Grafikkarte werkelt denn in Deinem Rechner?
Laut dem letzten Posting in
http://bugzilla.kernel.org/show_bug.cgi?id=12309
will ein Tester mit Kernel 2.6.31 eine geringe Verbesserung bemerkt haben:
"There is an improvement in desktop responsiveness with kernel 2.6.31 and the as scheduler compared to the cfq scheduler. It does not solve the problem, but it makes it more sufferable."
Das Hauptproblem ist, dass es keine stabile Kernel-2.6-Reihe von kernel.org gibt (die also jetzt noch supportet wird), die diesen Bug nicht hat.
Ich persönlich setze - falls die Hardware es erlaubt - Kernel 2.4 ein, wo es nur möglich ist.
Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link.
Falls Deine Hardware geeignet sein sollte, so lasse z.B. Slackware 11.0 mit Kernel 2.4 gegen ein neuestes Linux mit Kernel 2.6 antreten und lass deinen Rechner einmal so richtig arbeiten (mitunter reichen schon große Kopieraktionen im Rahmen des Versuchs von "Multitasking"; oder kompilier einen Kernel und arbeite gleichzeitig mit einem anderen Programmen weiter; usw.). Du wirst schnell feststellen, welches System "responsiver" ist.
Kernel 2.6-Systeme verhalten sich unter annähernder Vollast, wenn denn der I/O-Bug zuschlägt, wie damals Win95 beim Formatieren einer Diskette.
Siehe hierzu Kommentar 323 unter obigem Link:
"The irony is that it feels like Windows 95 while a floppy was formated. You know, the whole pseudo multi tasking on top of Dos - everything was really choppy. (...) If I encode a DVD with ogmrip/mencoder h264 and 16 threads (16 threads get the highest cpu usage from my quad core which is still under 80% per core) Gnome feels like a formatting Win 95."
Doch er ist GERADE auf Desktopsystemen nervig. Kopiere einfach mal ein paar Videos, ISOs, Backup,... von/zu USB-Platten und mach nebenbei was anderes, schon bist du betroffen. Mich nervt der Bug jeden Tag und kotzt mich immer mehr an. Normalerweise sind Bugs unter Linux schnell erkannt und gefixt aber hier wissen die Entwickler nicht mal wo das Problem ist.
Wenn ich versuche, ein 16 GB Backup auf eine verschlüsselte SATA-Compact-Flash Karte oder USB-Stick zu machen ist die Wahrscheinlichkeit groß, dass der Computer sich so aufhängt, dass nur noch ein Reset hilft.
Nur in kleinen Häppchen mit sync dazwischen geht das gut. Das sehe ich nicht als "nicht so wichtig" an.
Es aber gut zu wissen, was es eigentlich mit diesem "der Linux-Kernel ist fett und aufgebläht" auf sich hat.
Immerhin weißt Du definitiv, dass Du nicht "träumst".
> noch so "starke" Systeme mit 100% auslastet.
Könnte man zum Stresstesten ausnutzen...