iMac 27" Performance Problem ? Bitte mal lesen und Teilnehmen.

alexzero schrieb:
Ist das eine "Clean Install" von OSX?

Hast du irgendwelche Dienstprogramme oder Hardwaretreiber installiert?

Hast du irgendwelche Hardware angeschlossen, die nicht dabei war?
Zum Vergrößern anklicken....

Ja Clean Install.
Keine Hardwaretreiber installiert.
Nur Wireless Keyboard und Magic Mouse angeschlossen.


Das MacBook wurde von einer 10.6 Retail DVD Installiert, und der iMac von den beigelegten Medien wo 10.6.2 drauf ist.

Im übrigen zeigt er unter Bootcamp (Windows 7 32Bit) das gleiche Phänomen mit den Hängern.
 
dansch schrieb:
Ja Clean Install.
Keine Hardwaretreiber installiert.
Nur Wireless Keyboard und Magic Mouse angeschlossen.
Zum Vergrößern anklicken....

Systemtest der Boot-DVD ausgeführt und bestanden?

Wenn das System komplett hängt, fallen mir eigentlich nur 2 Problemerichtungen ein:

1.) RAM Speicher defekt
2.) IO-System überlastet.

sofern man Software und Hardwaretreiber ausschliessen kann.
 
alexzero schrieb:
Systemtest der Boot-DVD ausgeführt und bestanden?

Wenn das System komplett hängt, fallen mir eigentlich nur 2 Problemerichtungen ein:

1.) RAM Speicher defekt
2.) IO-System überlastet.

sofern man Software und Hardwaretreiber ausschliessen kann.
Zum Vergrößern anklicken....

Jip ebenfalls alles als i.O. getestet worden.
RAM Speicher zeigt im Profiler keine Fehler.
 
dansch schrieb:
Damit hat er keine Probleme. Muss also irgendwas in Richtung IO-Last sein.
Zum Vergrößern anklicken....

Das glaube ich auch. Ich kann das 'Problem' hier übrigens neben meinem i5 auch auf meinem Hackintosh nachstellen (eigentlich fast nur, daß Safari keine Seiten mehr lädt), der ja nun einen doch ziemlich differenten Hardware-Unterbau hat: Core2Quad, anderer Mainboard-Chipsatz,...

Also denke ich, daß das eher ein Softwareproblem ist, vielleicht tritt es auch nur auf MultiCore Systemen auf (Fehler in GrandCentralDispatch oder so?)

NB: Hat Dein MacBook exakt dieselbe Software-Version wie der iMac?
 
Zuletzt bearbeitet:
StevieJobs schrieb:
Das glaube ich auch. Ich kann das 'Problem' hier übrigens neben meinem i5 auch auf meinem Hackintosh nachstellen (eigentlich fast nur, daß Safari keien Seiten mehr lädt), der ja nun einen doch ziemlich differenten Hardware-Unterbau hat: Core2Quad, anderer Mainboard-Chipsatz,...

Also denke ich, daß das eher ein Softwareproblem ist, vielleicht tritt es auch nur auf MultiCore Systemen auf (GrandCentralDispatch oder so?)

NB: Hat Dein MacBook exakt dieselbe Software-Version wie der iMac?
Zum Vergrößern anklicken....

Bis auf den Kernel ja, weiß nicht wie gravierend die unterschiede von ~1 zu ~3 sind. aber im grune isses der gleiche kernel 10.2.0
 
alexzero schrieb:
Ich glaube du hast nicht die identischen Bedingungen für deinen Test. Zufallszahlen werden bei unterschiedlichen CPU unterschiedlich in Software oder Hardware produziert. Das löschen wiederrum ist auch keine Null-Operation.

Soll heissen ich glaube so kannst du keine zuverlässige Vergleichsaussage treffen. Vieles lastet eine CPU zu 100% aus, dies ist auch der Sinn einer CPU.

Technisch gesehen lastet eh alles eine CPU immer zu 100% aus, nur über die Zeit und das Multitasking gesehen ergibt sich hier eine Verschiebung der Werte.

Ob das System dabei performant bleibt, ist Sache des Schedulers...
Zum Vergrößern anklicken....

Das Problem ist definitiv reproduzierbar.
Natürlich wäre das Verhalten bei einer SingleCore CPU nachvollziehbar, da dieser Terminalbefehl ähnlich wie 'yes > /dev/null' 100% Last erzeugt, dies aber nur einem einzelnen Core, da das ja nicht multithreaded läuft.
Damit müssten 3 echte / 7 virtuelle Cores noch frei sein und das sind sie ja auch, wie einem die Aktivitätsanzeige oder auch iStatMenus bestätigt.

Das Verschieben von Fenstern ist hier nicht spürbar langsamer aber Safari lädt eben einfach keine neuen Seiten mehr und im Finder kann man sich zwar durch Verzeichnisse klicken, wenn man ein Programm startet hüpft das Icon aber solange im Dock, bis man den Temrinalbefehl mit Ctrl-C beendet.

Ich halte es für relativ wahrscheinlich, daß das ein Bug im Scheduler bei IO-Operationen ist, da rechenintensive Sachen sonst relativ normal weiterlaufen.

Übrigens tritt der Effekt, daß Safari keine neuen Seiten mehr öffnet und Programme nicht starten interessanterweise bei dem o.g. Befehl 'yes > /dev/null' nicht auf, obwohl der auch 100% Auslastung auf einem Core erzeugt..
 
StevieJobs schrieb:
Übrigens tritt der Effekt, daß Safari keine neuen Seiten mehr öffnet und Programme nicht starten interessanterweise bei dem o.g. Befehl 'yes > /dev/null' nicht auf, obwohl der auch 100% Auslastung auf einem Core erzeugt..
Zum Vergrößern anklicken....

Wie wir schon herausgefunden haben, passiert das nur bei cat mit virtuellen Devices, ich vermute mal in Richtung /dev/urandom, die Zufallszahlengeneration ist nicht so performant. Oder das Handeling mit diesem virtuellen Device.

Die Auslastung über PI-Berechnung erzeugt des ungewünschte Verhalten ebenfalls nicht.
 
Nur als Bestätigung: mein iMac 27 i5 zeigt das gleiche Verhalten. Nicht nur Safari hängt, sondern auch Firefox. Ctrl-C im Terminal und alle Seiten sind schwubs da.

Darwin iMac27 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 23:08:29 PST 2009; root:xnu-1486.2.11~3/RELEASE_I386 i386
 
StevieJobs schrieb:
Ich halte es für relativ wahrscheinlich, daß das ein Bug im Scheduler bei IO-Operationen ist, da rechenintensive Sachen sonst relativ normal weiterlaufen.

Übrigens tritt der Effekt, daß Safari keine neuen Seiten mehr öffnet und Programme nicht starten interessanterweise bei dem o.g. Befehl 'yes > /dev/null' nicht auf, obwohl der auch 100% Auslastung auf einem Core erzeugt..
Zum Vergrößern anklicken....

Eben, genau so sehe ich das auch. Das muss nen Bug im BMM (Betriebsmittelmanager) sein.

Bin Informatiker, und kann mir da schon so meine Sachen zusammenreimen und diverse Dinge ausschließen. Und da einige andere das gleiche Verhalten bestätigen schließe ich genauso auf einen Bug.

Mal schauen was Apple dazu sagt.

Überlege ob ich nochmal eine Clean Install von der Retail DVD von Snow Leo probiere, die gleiche DVD von der ich auch das MacBook installiert habe.
Ob das überhaupt funktioniert ? Keine Ahnung, müsste aber eigentlich.
 
alexzero schrieb:
Nur hat der Scheduler nichts mit IO-Operationen zu tuen. Dies läuft über DMA-Controller.
Zum Vergrößern anklicken....

Nun ja, er scheint mir ja auch nicht bei der eigentlichen IO-Operation selbst zu hängen, sondern beim Antossen oder Abschließen derselben. Verzeichnisse durchforsten geht ja, beim Programmstart fängt ja auch die HD kurz an, zu rattern, und das hüpfende Icon erscheint im Dock - nur das eigentliche Programmfenster öffnet sich nicht.

alexzero schrieb:
Wie wir schon herausgefunden haben, passiert das nur bei cat mit virtuellen Devices, ich vermute mal in Richtung /dev/urandom, die Zufallszahlengeneration ist nicht so performant. Oder das Handeling mit diesem virtuellen Device.

Die Auslastung über PI-Berechnung erzeugt der ungewünschte Verhalten ebenfalls nicht.
Zum Vergrößern anklicken....

Ja, es wird vermutlich eigentlich ein Bug beim cat-Befehl oder der Zufallsgeneration sein, die das System lahmlegt. Denn reine CPU-Belastung reicht nicht (das wußte ich schon vorher, da ich oft neben dem Websurfen noch mit Handbr..e Videos konvertiere und da soger 100% Last auf allen vier Cores habe), reine IO-Last aber auch nicht (sieht man am 'yes > /dev/null' Beispiel, oder wenn man mal große Dateien kopiert).

Man müßte mal cat und die Zufallszahlerzeugung getrennt testen.
 
Zuletzt bearbeitet:
StevieJobs schrieb:
Nun ja, er scheint mir ja auch nicht bei der eigentlichen IO-Operation selbst zu hängen, sondern beim Antossen oder Abschließen derselben. Verzeichnisse durchforsten geht ja, beim Programmstart fängt ja auch die HD kurz an, zu rattern, und das hüpfende Icon erscheint im Dock - nur das eigentliche Programmfenster öffnet sich nicht.
Zum Vergrößern anklicken....

Gerade nochmal getestet - Versuch, eine große Datei zu kopieren:
*den Terminalbefehl vorher gestartet -> es wird lediglich das Zielicon angelegt, der Kopiervorgang startet aber nicht.
*Kopiervorgang starten, dann während des Kopierens den Terminalbefehl starten -> der Kopiervorgang läuft ordnungsgemäß durch...

Und zur Vollständigkeit:
Hier ist es erwartungsgemäß auch die:
Darwin ...iMac.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 23:08:29 PST 2009; root:xnu-1486.2.11~3/RELEASE_I386 i386
 
StevieJobs schrieb:
Man müßte mal cat und die Zufallszahlerzeugung getrennt testen.
Zum Vergrößern anklicken....

Sollte ja kein Problem sein, "cat /dev/urandom > file", dann "cat file". So ist im 2. Prozess urandom nicht betroffen.

Ich vermute es tritt nur in "cat /dev/urandom" auf. Somit würde das Problem nicht bei "cat" liegen, sondern bei urandom.
 
alexzero schrieb:
Sollte ja kein Problem sein, "cat /dev/urandom > file", dann "cat file". So ist im 2. Prozess urandom nicht betroffen.

Ich vermute es tritt nur in "cat /dev/urandom" auf. Somit würde das Problem nicht bei "cat" liegen, sondern bei urandom.
Zum Vergrößern anklicken....

Nein, so einfach ist es nicht.
Bereits bei der Aktion 'cat /dev/urandom > file' (oder auch 'cat /dev/random > file) tritt das Problem nicht mehr auf, nur wenn man die erzeugten Daten gleich ins NIL: schickt..

Also hat es wohl was mit dem Zusammenspiel des Zufallsgenerators mit dem dev/null 'Device' zu tun. Vielleicht gibt's da ja auch nur eine begrenzte Anzahl von Pipes oder so, die da dann alle volllaufen?

P.S.: Damit ist der Bug aber ja letztlich doch so abstrus, daß er in der Realität kaum vorkommen dürfte
 
Nur mal so nebenbei (falls es der Lösungsfindung hilft): Der Atom N270 zeigt das Verhalten ebenfalls nicht!
 
Zurück
Oben Unten