Kaffeine auf zweiten Bildschirm = 100% CPU
Hi Ich habe hier ein AMD Athlon 2400+ mit einer dualscreen graka (Matrox G400) und einer einzelnen Graka (auch Matrox) Mein Problem ist, dass zwar zB xine auf allen bildschirmen normal läuft, jedoch kaffeine nur auf dem primären Bildschirm vernünftig läuft. Auf den beiden anderen Screens geht X auf ca 75% CPU hoch und kaffeine benutzt den Rest - dies hat den Effekt dass das Bild etwa jede Sekunde etwas ruckelt was ziemlich unschön ist.... Gibts dafür eine Lösung? Ich möchte eigentlich bei kaffeine bleiben da ich noch nicht rausgefunden habe wie ich xine per fernbedienung via irkick steuern könnte..... Das ist das Ende meiner xorg.conf: Section "Device" BoardName "G400 DH" BusID "1:0:0" Driver "mga" Identifier "Device[0]" Option "usevnc" "no" Screen 0 VendorName "Matrox" EndSection Section "Device" BoardName "G400 DH" BusID "1:0:0" Driver "mga" Identifier "Device[1]" Screen 1 VendorName "Matrox" EndSection Section "Device" BoardName "MGA 1064SG" BusID "0:12:0" Driver "mga" Identifier "Device[2]" Option "NoHal" Option "VideoOverlay" "on" Screen 0 VendorName "Matrox" EndSection Section "ServerLayout" Identifier "Layout[all]" InputDevice "Keyboard[0]" "CoreKeyboard" InputDevice "Mouse[1]" "CorePointer" Option "Clone" "off" Option "Xinerama" "off" Screen "Screen[0]" Screen "Screen[1]" RightOf "Screen[0]" Screen "Screen[2]" LeftOf "Screen[0]" EndSection Section "DRI" Group "video" Mode 0666 EndSection Danke ! Matti
Hallo, ich würde gerne auf einem Dual-Xeon System mit 4GB SuSE 10.0 installieren. Das System unterstützt grundsätzlich eine spätere Umrüstung auf Dual-Xeon-Dual-Core (also 4 logische CPUs!? Oder 8? Zählt man das Hyperthreading noch dazu?). Meine Frage ist nun, ob es grundsätzliche sinnvoll ist SuSE 10.0 Prof. dafür einzusetzen, oder ob man mit SLES 9.0 in Bezug auf die Hardware besser fährt. Zu bedenken gilt noch, dass ich derzeit auch selbstgeschriebene Software (gcc compiliert) nutze. Gibt es eine CPU Beschränkung bei der Prof. Version? Wenn ja, ist diese nur von einer entsprechenden Kompilierung des Kernels abhängig? Die bereits angesprochene selbstgeschriebene Software läuft bisher auf einem P4 mit Hyperthreading problemlos. Muss ich bei der späteren Ausführung auf einem Multiprozessorsystem mit Problemen rechnen? (Die Lastverteilung erreiche ich übrigens einfach über mehrfache Ausführung der Software, also mehrere Prongramminstanzen und nicht über Threads. Das geht glücklicherweise, weil mehrere voneinander völlig unabhängige Aufgaben parallel zu erledigen sind.) Ich gehe davon aus, dass die Prof. Version kein EM64T unterstützt. Da eine spätere Erweiterung des RAM voraussichtlich nicht vorgesehen ist, nehme ich an, dass ich auch kein EM64T brauche? Angenommen ich würde doch ein EM64T fähiges Betriebsystem (SLES9.0?) einsetzen - was macht das System zu einem EM64T-System? Sind hier grundsätzlich alle Pakete dafür compiliert bzw. ggf. bei eigener Software neu zu kompilieren, oder ist das rein eine Sache des Kernels? Sofern ersteres gilt, lässt sich grundsätzlich alles was sich unter x86 kompilieren lässt ohne irgendwelche Fixes auch für EM64T kompilieren? Bzw. ist das überhaupt nötig? Laufen für x86 compilierte Binaries auch unter EM64T? Schöne Grüße, Danke Robert
Guten morgen Am Donnerstag, 30. März 2006 01:58 schrieb Robert:
Meine Frage ist nun, ob es grundsätzliche sinnvoll ist SuSE 10.0 Prof. dafür einzusetzen, oder ob man mit SLES 9.0 in Bezug auf die Hardware besser fährt. Zu bedenken gilt noch, dass ich derzeit auch selbstgeschriebene Software (gcc compiliert) nutze. Ich denke, hier mmußt du slbst herausfinden, ob deine Software mit dem neuem GCC tut.
Gibt es eine CPU Beschränkung bei der Prof. Version? Wenn ja, ist diese nur von einer entsprechenden Kompilierung des Kernels abhängig? Afaik reicht ein SMP-Kernel, den du vermutlich eh hast. So einen Blödsinn wie CPU-Begrenzung gibt nur bei Microsoft, um die Kunden zu teuren Server Versionen zu zwingen. Bei Linux gibt es zwar auch eine, aber die wird für dich irrelevant sein.
Die bereits angesprochene selbstgeschriebene Software läuft bisher auf einem P4 mit Hyperthreading problemlos. Muss ich bei der späteren Ausführung auf einem Multiprozessorsystem mit Problemen rechnen? (Die Lastverteilung erreiche ich übrigens einfach über mehrfache Ausführung der Software, also mehrere Prongramminstanzen und nicht über Threads. Das geht glücklicherweise, weil mehrere voneinander völlig unabhängige Aufgaben parallel zu erledigen sind.) Wenn du das so löst bestimmt.
Ich gehe davon aus, dass die Prof. Version kein EM64T unterstützt. Da eine spätere Erweiterung des RAM voraussichtlich nicht vorgesehen ist, nehme ich an, dass ich auch kein EM64T brauche? Das hängt vom Kernel ab. Google sagt mir und dir, dass es gehn sollte.
Ich hab den Eindruck, du denkst zu sehr wie ein Microsoft Nutzer. Schau ob der verwendet Kernal kann, was du willst. Ich hab noch keine Distribution gesehen, die versucht künstliche Grenzen in den Kernel etc. einzubauen, damit die Server Pakete gekauft werden. Würde auch nicht viel Sinn machen. Bis dann, Tilo
Robert wrote:
[...] ich würde gerne auf einem Dual-Xeon System mit 4GB SuSE 10.0 installieren. Das System unterstützt grundsätzlich eine spätere Umrüstung auf Dual-Xeon-Dual-Core (also 4 logische CPUs!? Oder 8? Zählt man das Hyperthreading noch dazu?).
Es wuerde mich wundern, wenn Dual-Core CPUs vom Kernel des SLES 9 unterstuetzt werden. Generell ist die Unterstuetzung dafuer noch nicht so lange im Vanilla-Kernel. Dual-CPU Systeme (SMP) hingegen werden schon lange unterstuetzt.
Meine Frage ist nun, ob es grundsätzliche sinnvoll ist SuSE 10.0 Prof. dafür einzusetzen, oder ob man mit SLES 9.0 in Bezug auf die Hardware besser fährt.
Ich denke, mit SuSE 10 wuerdest Du hardwaretechnisch besser fahren. Die Professional Variante (genauer IIRC die 10.1) dient ja auch als Grundlage fuer den naechsten SLES 10. Die SLES zeichnen sich insbesondere durch den Support und die laenger zur Verfuegung stehenen Bugfixes/Updates aus. Der Support fuer SuSE 10 wird eben in ca. 2 Jahren (ab dem Erscheinungstermin gerechnet) auslaufen.
Zu bedenken gilt noch, dass ich derzeit auch selbstgeschriebene Software (gcc compiliert) nutze.
SuSE 10 kommt mit GCC 4 daher. Du musst eben schauen, dass Deine selbstgeschriebenen Programme damit compilieren und auch korrekt laufen.
Gibt es eine CPU Beschränkung bei der Prof. Version?
Die gibt es tatsaechlich, hat aber nichts mit der Professional Version zu tun, sondern mit dem Linux-Kernel selbst. Das Limit liegt aber weit jenseits von dem, was fuer Dich vermutlich relevant und bezahlbar ist ;-)
[...] Die bereits angesprochene selbstgeschriebene Software läuft bisher auf einem P4 mit Hyperthreading problemlos. Muss ich bei der späteren Ausführung auf einem Multiprozessorsystem mit Problemen rechnen?
Bei jeder Aenderung des OS (glibc, etc.) und des Compilers musst Du Dein Programm checken, ob es auch noch 100% funktioniert. Wir haben dafuer z.B. eine ganze Testsuite, die abgearbeitet werden muss. Tritt irgendwo ein Fehler auf, so wird erst dann ein generelles Upgrade aller Maschinen und ggf. des Clusters gemacht, wenn das Problem auf der Testmaschine zur Zufriedenheit geloest werden konnte.
[...] Ich gehe davon aus, dass die Prof. Version kein EM64T unterstützt. Da eine spätere Erweiterung des RAM voraussichtlich nicht vorgesehen ist, nehme ich an, dass ich auch kein EM64T brauche?
Du kannst auf EMT64 Systemen die 64-bit Variante von SUSE Linux installieren. Warum sollte das nicht gehen? Ob Dir 64-bit generell Vorteile bringt, kann ich nicht sagen, das haengt wohl vor allem davon ab, wie viel Speicher Dein Programm braucht. Auf 64-bit Systemen kannst ein Prozess eben mehr Speicher allokieren als auf einem 32-bit System, da ist in der Praxis noch unterhalb von 2GB Schluss.
[...] Sofern ersteres gilt, lässt sich grundsätzlich alles was sich unter x86 kompilieren lässt ohne irgendwelche Fixes auch für EM64T kompilieren? Bzw. ist das überhaupt nötig?
Die Frage heisst wohl eher, ob alle Software, die bisher ohne Probleme unter 32-bit Systemen compiliert und eingesetzt werden konnte, auch auf 64-bit Systemen compiliert und funktioniert. Die Antwort haengt von mehreren Dingen ab, unter anderem davon, wie sauber die Software geschrieben ist. Cheers, Th.
Hi Am Donnerstag, den 30.03.2006, 01:18 +0200 schrieb Matthias Keller:
Hi
Ich habe hier ein AMD Athlon 2400+ mit einer dualscreen graka (Matrox G400) und einer einzelnen Graka (auch Matrox)
Mein Problem ist, dass zwar zB xine auf allen bildschirmen normal läuft, jedoch kaffeine nur auf dem primären Bildschirm vernünftig läuft. Auf den beiden anderen Screens geht X auf ca 75% CPU hoch und kaffeine benutzt den Rest - dies hat den Effekt dass das Bild etwa jede Sekunde etwas ruckelt was ziemlich unschön ist....
Wenn ich mich recht erinnere, unterstützt die G400 Overlay nur am primären Anschluß. Möglicherweise hängt das damit zusammen? Wenn Kaffeine das overlay softwaremäßig emuliert (Unter Windows bleibt das Videofenster auf dem zweiten Bildschirm einfach schwarz), wäre das eine Erklärung für die Systemlast. Gruß -- Dr. Reiner Pietrzak <suse@crasswerk.de> Abonnierte SuSE Mailinglisten
Dr. Reiner Pietrzak wrote:
Hi
Am Donnerstag, den 30.03.2006, 01:18 +0200 schrieb Matthias Keller:
Hi
Ich habe hier ein AMD Athlon 2400+ mit einer dualscreen graka (Matrox G400) und einer einzelnen Graka (auch Matrox)
Mein Problem ist, dass zwar zB xine auf allen bildschirmen normal läuft, jedoch kaffeine nur auf dem primären Bildschirm vernünftig läuft. Auf den beiden anderen Screens geht X auf ca 75% CPU hoch und kaffeine benutzt den Rest - dies hat den Effekt dass das Bild etwa jede Sekunde etwas ruckelt was ziemlich unschön ist....
Wenn ich mich recht erinnere, unterstützt die G400 Overlay nur am primären Anschluß. Möglicherweise hängt das damit zusammen?
Wenn Kaffeine das overlay softwaremäßig emuliert (Unter Windows bleibt das Videofenster auf dem zweiten Bildschirm einfach schwarz), wäre das eine Erklärung für die Systemlast.
Das mit dem Overlay hab ich mir auch schon überlegt und beim 2nd Head der G400 kann ich das ja noch verstehen - aber warum habe ich den genau gleichen Effekt auf der zweiten graka welche eine single head ist? Da müsste es doch eignetlich gehen - oder ist dies wiederum eine limitation im kernel/kde/... dass nur die primäre Graka alles kann und bei weiteren vieles emuliert werden muss oder so? Also ich habe sowohl auf dem zweiten Head der G400 wie auch auf der anderen Graka die 100% Systemlast... Wenn du aber denkst es könnte mit der Graka zusammenhängen kann ich auch mal eine ander einbauen zum sehen ob sich was ändert - irgendwo liegt glaub noch ne andere PCI-Karte rum... Grüsse Matti
Hi Am Donnerstag, den 30.03.2006, 10:48 +0200 schrieb Matthias Keller:
...
Wenn Kaffeine das overlay softwaremäßig emuliert (Unter Windows bleibt das Videofenster auf dem zweiten Bildschirm einfach schwarz), wäre das eine Erklärung für die Systemlast.
Das mit dem Overlay hab ich mir auch schon überlegt und beim 2nd Head der G400 kann ich das ja noch verstehen - aber warum habe ich den genau gleichen Effekt auf der zweiten graka welche eine single head ist? Da müsste es doch eignetlich gehen - oder ist dies wiederum eine limitation im kernel/kde/... dass nur die primäre Graka alles kann und bei weiteren vieles emuliert werden muss oder so?
Also ich habe sowohl auf dem zweiten Head der G400 wie auch auf der anderen Graka die 100% Systemlast... Wenn du aber denkst es könnte mit der Graka zusammenhängen kann ich auch mal eine ander einbauen zum sehen ob sich was ändert - irgendwo liegt glaub noch ne andere PCI-Karte rum...
Außer Datenratenproblemen des PCI-Busses im Vergleich zu AGP fällt mir da nichts ein. Gruß -- Dr. Reiner Pietrzak <suse@crasswerk.de> Abonnierte SuSE Mailinglisten
participants (5)
-
Dr. Reiner Pietrzak
-
Matthias Keller
-
Robert
-
Thomas Hertweck
-
Tilo Lutz