Derzeit habe ich ein kleines Problem.
Seit dem ich mit Ligthroom 5.x und Photoshop CS 6 die Bilder aus meiner D800 bearbeite "kackt" mein MacbookPro i7, 2,5Ghz angeschlossen an einen externen Monitor mit seinen 8GB Ram regelmässig nach einiger Zeit nahezu ab. Deshalb bin ich am überlegen ob es womöglich Sinn machen würde meinen alten MacPro 3Ghz von anfang 2008 nochmals zu reaktivieren (diente in letzter Zeit mehr als Backuprechner) und aufzurüsten. Festplattenkapazität hätte ich dabei genügend aber es fehlt definiv an RAM, da hat er im Augenblick nur magere 6 GB zu bieten.
Käme ich gerade in Verbindung mit den oben genannten Programmen und meinen Kameras dann wieder besser zurecht, wäre flüssiges Arbeiten selbst mit diesem schon etwas älteren Modell wieder möglich ? Rein von der Rechenleistung wäre der i7 dem alten MacPro ja grundsätzlich überlegen, aber das nützt wenig wenn der Flaschenhals der Arbeitspeicher ist.
Oder wäre es sinnvoller generell auf neue Hardware zu setzen zb.einen iMac in Maximalaustattung und gar den neuen MacPro ? Bei diesen beiden Lösungen müsste ich aber nochmindesens in ein zusätzliches externes Festplattengehäuse investieren wo ich zumindest zwei meiner internen HD aus dem alten MacPro unterbringen könnte.

Solchen internen Tests traue wieder ICH nicht. Der Footprint von Memtest+ ist dabei nun auch nicht so dramatisch, dass ein nennenswerter Speicherbereich ungetestet bleibt.

Aber nichtsdestotrotz Macs sind halt einfach kompliziierter als klassische PC. Früher auf PC konnte man auch prima mit c't-Ramtest 5.1 testen. Da blieb kein Speicherbereich unberücksichtigt, da dieser Test vollständig im RAM der Grafikkarte residierte und er so den gesamten Hauptspeicher testen konnte.

Was konkret? Die Module mal zu tauschen, wenn man mit einem Speichertest-Programm rumwerkelt, das selbst in eben jenem Speicher residieren muß? Oder dass AHT/AD nix taugen?

Was soll man denn bitte bei RAM testen außer es mit Mustern vollzuschreiben und zu gucken, ob das, was man eben reingeschrieben hat, auch wieder auszulesen ist?

Das gilt aber nur und ausschließlich, wenn man ein separates Linux- oder DOS-basiertes Installationsmedium mit dem Zeugs drauf hat. Unter OS X und selbst im Single-User-Modus laufend ist das blanke Augenwischerei (hier trotz Single-User-Modus 1,5 GByte nicht im Zugriff: ). Und ganz ehrlich: Bevor ich da mit externem Medium hantiere, um memtest aufzurufen, drück ich lieber "d" und laß das laufen, was Apple auch intern nimmt.

Pardon? Wozu der Link? Da geht's um DDR3-RAM und nicht historischen DDR2 oder überseh ich was?

Nenn's wie Du es willst, mir ist das inzwischen eh zu blöd. Soll sich doch jeder seinen RAMsch kaufen, wo er will

Abermals: Sollte hier irgendjemand eine Bezugsquelle für Arbeitsspeicher kennen, die a) nur Major-Original-Riegel und weder OEM-Zeugs noch No-Name-RAMsch anbietet, b) frei von Fälschungen ist und c) problemlose Abwicklung bietet, dann her damit. So lange bleib ich halt bei dem einzigen mir bekannten RAM-Anbieter, bei dem das gesichert ist: Crucial.

Also Apples Hardware Test ist auch nicht immer 1A.
Erfahrung!
Meinen Mac Pro (RAM noch auf der Riserkarte) hatte ich mit dem Apple Hardware Test getestet. Ergebnis, alles OK????
Ich brachte den Mac zur Reparatur. Ergenbnis Logiboard hatte ein Defekt, daher funktionierte die Riserkarte nicht mehr korrekt.
Das 2x
Mac Pro 2010
Grafikkarte, machte öfter Probleme. OK, ausgetauscht. Eingesetzt und nach einiger Zeit wieder die gleichen Probleme. AHT hat nichts gefunden, auch der Support ist hier ratlos gewesen.
Ich bestellte mir dann eine (PC) EVGA Geforce GTX 660. Eingesetzt UND woooow sie lüpp. Ab 10.8.2 sind die Treiber dafür bereits enthalten. Bislang keine Probleme mehr!!!!! ATI bzw. AMD ist eine Marke. Aber wie ich schon geschrieben habe, sind diese auch nicht ohne Fehler.

RAM-Testen ist ein schlechter Ersatz für ECC Logs. Wir testen immer wieder die Systeme unter Last, und trotzdem treten dabei nicht die RAM Fehler auf, die im Regelbetrieb auftreten. Ein RAM Test identifiziert ein eindeutig kaputtes Modul, aber es rutschen viele Module durch die trotzdem fehlerhaft sind. Wenn man seine Lebenszeit mit so einem Schrott nicht verschwenden will, dann muß man ECC RAMs nutzen und die Logs auswerten.
Ganz so schlimm ist Kingston auch wieder nicht. Wenn man "Server Grade" Memory von Kingston kauft (Server Grade gibt's natürlich nur als ECC Module.), sind immer Chips eines definierten Markenanbieters aus einer definiertem Die Revision verbaut. Zu gut deutsch man bekommt entweder Hynix oder Elpida Chips, in der gleichen Qualität wie von diesen Anbietern selbst, und man kann nachvollziehen aus welcher Charge die Chips stammen. Kingston liefert auch Spezialmodule als Ersatz für Spezialmodule von HP u.a. die deutlich günstiger sind, weil der Supportaufschlag nicht dabei ist. Standardmodule von Hynix, Elpida, … laufen in einer Reihe von Systemen nämlich nicht, weil HP u.a. spezielle Temperatursensoren auf den Module verbaut, die nicht auf Standardmodulen nicht vorhanden sind. Steckt man ein statt des HP Moduls ein Hynix Module piept das System nur und verweigert den Start.

Diese Unsitte mit dem Spezialmodulen findet man bei allen großen Serveranbietern. Man muß dann unbedingt die Originalmodule nutzen, oder im SoHo Umfeld etwa auf Kingston Module zurückgreifen. Für einen einfachen Xeon E3 Server im Standgehäuse lohnen sich die Originalmodule nur selten.
Bei Crucial klickst Du Dich durch die Auswahlmenüs und bekommst die kompatiblen Module für Dein System angezeigt. Kingston handhabt das genauso. Bei Hynix, Elpida, Samsung … ist es schwieriger, da Apple leider keine Kompatibilitätsliste heraus gibt, und diese Anbieter das ebenfalls nicht tun. Da kann man sich nur erkundigen welche Module Apple direkt am Werk verbaut hat.

Und was hat das jetzt alles mit dem 2008er Mac Pro zu tun?

Beim Aufrüsten geht es auch um die Frage welche RAM Module man kaufen sollte, oder etwa nicht?

Beides klar. Nur: Wer kann ECC-RAM am Mac einsetzen (MacPro-User) und wer kann ECC-Logs auslesen? Ich wüsste nicht, wie ich das am MacPro anstellen sollte...

Und selbst der simple "Funktionieren die Riegel überhaupt?"-Test per AHT/AD wird von so gut wie niemand bei RAM-Neuerwerb durchgeführt. Bei paar unserer Kunden krieg ich ab und an mit, dass die Denke vorherrscht "wenn man die Kiste schon mal anlangt, dann gscheid" und neben RAM-Aufrüstung dann gleich noch neue System-Version eingespielt und sonstwelches "Tuning" gemacht. Und wenn die Kiste anschl. instabil läuft, steht die neue OS X Version im Verdacht und nicht naheliegenderweise das "Fundament" AKA RAM.

Andere Sparte, die da bedient wird. Das auf Endkunden abzielende HyperX und ValueRAM muß ja auch nicht schlecht sein. Ich hab in der Vergangenheit nach paar Preisvergleichen aber von Kingston Abstand genommen, weil ich "Major Original" normalerweise günstiger bekommen habe. Und für die hier im Thread erwähnten 8 ollen DL380 kosteten auch die Kingston-Module so horrend viel, dass ein Neuaufsetzen auf aktueller Hardware wirtschaftlicher erschien.

Wie's bei Kingston bzgl. Automatisierung steht, weiß ich nicht. Crucial bietet auch eine kleine Mac-App zum Download, die nix weiter macht, als einen XML-Systemprofiler-Report anzufertigen und per POST nach http://www.crucial.com/eu/systemscanner/macresults.aspx zu schubsen, von wo aus man dann das für den eigenen Mac passende RAM angezeigt bekommt. Wir prüfen grad, das für einen Kunden zentral aus Apple Remote Desktop heraus nutzen zu können.

Normalerweise stellt diese Funktion IPMI oder das OS zur Verfügung. Die Hardware springt in eine dann in spezielle Software Routine, wenn ein ECC Fehler auftritt. Der Vorteil ist, daß 100% des Nutzungszeitraums vom Speichertest abdeckt wird, und nicht nur ein spezieller Test. Leider ist das so, daß bis auf den MacPro keinerlei Mac die notwendige Hardware besitzt. Und der MacPro von Apple nicht mit der passenden Software versorgt wird. Es läßt sich theoretisch relativ einfach ein Kernel Erweiterung schreiben.

Mit anderen Worten: Schöne Scheize

Wer das Glück hat, einen Mac zu haben, der ECC verkraftet, kann sich darüber freuen, dass 1-Bit-Fehler automatisch korrigiert werden. Und das war's auch schon am Mac.

Wo anderswo wenigstens nicht korrigierbare 2-Bit-Fehler wenigstens noch gelogged werden und der Admin im Monitoring ein "krank werdendes Modul" identifizieren und austauschen kann am Mac Fehlanzeige.

Netterweise (für Apple) nimmt der typische Mac-User die (in der Realität gar nicht mal so selten auftretende) Problematik noch nicht mal wahr und vermutet die Ursache für Datenkorrumption oder auftretende Systeminstabilitäten immer erstmal sonstwo. Und auch Admins, denen das eigentlich klar sein sollte, verdrängen das meist. Wer von den "alten Hasen" erinnert sich nicht noch daran, dass viele G4s damals beim Umstieg von MacOS 9 auf OS X auf einmal "kaputten Speicher" hatten? Derweil war nur die für ein Unix typische andere Speichernutzung bzw. -alloziierung Schuld daran, dass vormals schon malades RAM (das unter MacOS 9 Dank ineffizientester Speicherverwaltung ever ggf. nie oder nur in Ausnahmefällen genutzt wurde) endlich auffiel.

Ja, das Problem ist mir noch gut bekannt. Ich habe noch defekte DIMMs herumliegen, sowohl aus einem UMAX S900 wie auch einem G3 b/w.

Ob der Fragestellern nun klüger ist? Auf jeden Fall ein paar interessante Postings zum Thema Ram.

Umax S900, hehe, war eigentlich ein guter Rechner.

Das mit dem No-Name-RAM halte ich praktisch für recht unerheblich. Seit Mitte der 80er sind mir dazu keine Fälle bekannt - bis auf ca. drei Fälle (von vielen hundert), in denen der Speicher gar nicht erst funktionierte. Im MP 4,1 aus 2009 beteibe ich selbst seit Jahren drei 8GB ECC-Module (und ne SSD).

Aus den Beiträgen gibt es ja schon viele super Hinweise - eine Idee aus den Anmerkung von Thomas Kaiser "ging jedoch etwas unter":

Sinnvoller als den 2008er MP aufzurüsten könnte es sein diesen zu verkaufen und einen 2009/2010er gebaucht zu kaufen.
- Der Aufpreis sollte durch die günstigeren RAM-Preise der Folgemodelle gemildert werden. Dafür ist dann zusätzlich etwas mehr Power vorhanden (bei weniger Energieverbrauch)… - ODER ?




- - - 8< - - - schnipp - schnapp - - - >8 - -

@ Thomas Kaiser:

Ich will hier keine(!) "doofe Anmache" schreiben. Jedoch im Eigeninteresse möchte ich mal Folgendes loswerden, weil es mir immer weniger Spaß macht die Beiträge zu lesen bzw. mittlerweile überscrolle ich diese oft:

Deine Beiträge empfinde ich (leider) recht lang und oft mit "enge Sicht" geschrieben. Kannst du dich bitte etwas kürzer fassen (also nicht immer die ganze Welt erklären). Gern und auch mal mit einem "nicht Recht haben müssen"?

Nachfolgend ein konkretes Beispiel aus diesem Trend: (16.04.14 08:59 - Andere gingen ebenso):

- - - - -
Grüße & Bitte, nimm diesen Hinweis sportlich - als feedback (falls du magst/ kannst).

Mit anderen Worten: Dir sind keine Speicherfehler aufgefallen. Wären Dir welche aufgefallen, dann ist es fraglich, ob Deine Erfahrungen (oder wahlweise auch meine oder die von irgendeiner anderen Einzelperson) irgendeine statistische Relevanz haben. Zum Glück gibt es Firmen/Institutionen, denen sowas auffällt (und das bei weitaus besserer Hardware als Desktop- oder Notebook-Rechner von Apple) und die dazu Untersuchungen vorlegen, bspw. Google: . Da das wieder mal viel zu viel Text ist, die Quintessenz, die sich wohlgemerkt auf ECC-bestückte Systeme bezieht (d.h. bei Rechnern ohne ECC isses ggf. noch schlimmer):

Ich wollte vom Fragesteller ursprünglich eigentlich nur wissen, wieviel er jetzt für "historischen" Speicher abdrücken will, da ich grad selbst bzgl. einer Serveraufrüstung über entsprechend horrende Preise für altes DDR2-RAM gestolpert bin. Aber der Fragesteller kann offensichtlich nur Fragen stellen jedoch keine beantworten.

Noch sinnvoller könnte es auch sein, anstatt der fixen Idee "zu wenig RAM" anzuhängen, mal zu gucken, was im Workflow wirklich lahmt. Das war wenigstens meine Intention hinter den "nervigen" Nachfragen/Feststellungen (und ja, ist leider so: Mittels iStat Menus kriegt man nie und nimmer raus, ob man für eine Aufgabenstellung zu wenig RAM hat bzw. wo sich der konkrete Flaschenhals befindet -- warum hab ich im Thread schon versucht, zu erklären. Da aber komplexere Zusammenhänge nicht in einem Satz darstellbar sind und längere Textmengen offensichtlich überfordern...)

Letzteres find ich deutlich interessanter, Dank gfhfkgfhfk auch wieder was dazugelernt

Abwarten, - grundsätzlich sehe ich nach wie vor den RAM, im Augenblick 6GB im MacPro als Hauptverantwortlich an. Der MacPro kam seinerzeit mit OSX 10.6 (Tiger) auf den Markt, bei Photoshop war ich damals bestenfalls bei CS3 und Lightroom gab es noch nicht. Meine DSLR hatte damals gerade mal 6Mpix, hier reichte seinerzeit die (Grund-)Ausstattung des Rechners noch problemlos. Im laufe der Jahre kamen dann weiter interne HDs und eine bis dato magere 2GB RAM Aufrüstung auf insgesamt 6GB RAM hinzu.
Nun der MacPro ist inzwischen bekanntermaßen 6 Jahre alt, in dieser Zeit hat sich einiges getan in Sachen OS und bei den Programmen. Es ist nun mal so das beides, OSX und die Apps immer komplexer werden und somit höhere Ansprüche an die Hardware stellen. Am Beispiel RAM, reicht dieser nicht mehr aus werden Daten auf die HD ausgelagert, andere wiederum angefprdert und währenddessen knickt der Rechner weil die CPU auf Daten warten muss ein. Nicht genutzten RAM freizugeben wie z.b. mit einem Programm wie "Memory Clean" funktioniert wenn dann immer nur kurzeitig. Zudem kommt, damit ich von beiden Rechnern, also dem MacPro sowie denn schon erwähnten i7 MBP auf meine Daten zugreifen kann liegen diese derzeit auf einer externen HD und sind mit Firewire mit den Rechnern verbunden was die Sache auch nicht schneller macht

Es geht mir nicht darum den oder die Rechner wie es unser Spezialist genannt hat "zur Rakete" zu machen sondern jene Momente zu minimieren wo man nicht weiß ob die Kisten bei einer Aktion nun friedlich entschlafen sind oder das OS mit dem Programm nur mal eben einen Saufen gegangen ist. Gerade bei der Bearbeitung von RAW Dateien aus dem 36 Mpix Monster Nikon D800 stoßen beide Maschinen nun eindeutig an ihre Grenzen. Der einzige Unterschied, beim i7 dauert es etwas länger bis dieser Zustand der Lethargie erreicht ist da er doch noch über 2GB RAM mehr verfügt.

Es ist also also keine Frage das ich etwas mache sondern nur was ich mache. Den Kauf eines neuen MacPro schließe ich hier aber zunächst mal aus weil (im Moment) zu teuer. Also bleiben mein i7 MacBook Pro, 2,5Ghz oder eben mein MacPro 2008 die beide zum Zweck der Bildbearbeitung an einen EIZO Colorgraphics angeschlossen sind. Die Aufrüstung beim MBP ist aber auf 16GB (8GB im Augenblick) begrenzt, der MacPro ließe sich hingegen noch bis auf 32 GB RAM ausrüsten, aber dies kostet wie richtig angemerkt wurde mehr.

Das funktioniert mit so einer App (die eh nix weiter macht, als purge aufzurufen) schon grundsätzlich nie. Für jemand, der sich nicht damit auseinandersetzen will, wie die RAM-Verwaltung eines unixoiden Betriebsystems wie OS X funktioniert, sieht nach Aufruf von so einem Quatsch zwar die Welt besser aus, weil irgendwelche RAM-Werte bei free und inactive hübscher sind. Der Effekt ist nur leider kontraproduktiv (siehe ) und auf der Basis wird es einem auch beim besten Willen nicht gelingen, das zu identifizieren, was den Lightroom-Workflow lahmen läßt.

Da Du aber keinen Bock auf Hilfe hast und ich nicht andauernd die Welt erklären soll: Viel Spaß damit, unsinnig Geld zum Fenster rauszuwerfen (auf Basis der dürftigen Infos, die man Dir bislang entlocken konnte, dürfte ein Aufrüsten des MBP auf 16 GB + SSD + Anpassung Raw-Cache-Settings + strukturierter Workflow bei gleichem Etat ein Vielfaches bringen. AHT/AD-Check nicht vergessen)

ich hänge mich da mal kurz rein, wie und wo in PS oder LR mache ich denn dieses "Anpassung Raw-Cache-Settings".
Das würde mich schon interessieren . . .. .

Wie schon geschrieben: In Bridge. Der Cache ist per default häßlich klein (ich glaub in aktuellen Versionen 1 GByte) und zeigt auf das Systemlaufwerk, d.h. wenn das keine SSD ist aber eine im Zugriff bzw. Mac sein sollte: Dorthin zeigen lassen und groß dimensionieren.

Wenn man zu wenig RAM haben sollte (das bemißt sich immer nur daran, was für Workflow man fährt), was man durch Blick auf "pageouts" und durch sonst gar nichts rausfindet (im Terminal mittels "top" oder in der Aktivitätsanzeige oder am Präzistesten abermals im Terminal per "vm_stat 10"), dann hilft logischerweise mehr RAM, alternativ flottes Paging (findet per default unterhalb /var/vm statt, auch das kann man umbiegen bzw. an dem Pfad eine SSD einhängen) oder alternativ ein anderer Workflow. Es hat seinen Grund, warum es mittlerweile fette Bücher zu Lightroom gibt, die sich kapitelweise mit Peformance-Tuning, Arbeitsfluß, Vorbereitungen und Randbedingungen auseinandersetzen

Stichwort Workflow: Wenn ich den Cache für meinen Workflow passend bemesse und vorab richtig Previews rechnen lasse (Import neuer Bilder unbeaufsichtigt), dann hab ich in der "kreativen Phase" einen weitestgehend ruhigen Mac vor mir, auf den ich nicht warten muß. Und der finale Export soll dann ruhig wieder die Kiste stressen aber nicht mich, weil das abermals unbeaufsichtigt vonstatten gehen kann.

ich verwende Bridge nicht, sondern die Frage zielte auf LR und PS, da du ja Sachkompetent scheinst kannst du ja hier ganz kurz sagen wo und wie ich etwas einstellen muss um dieses "Problem" zu lösen.

In Bridge, wie oft denn noch?!

Bridge starten Menü Einstellungen Cache-Gedöns einstellen Bridge beenden. Gilt fortan für alles Adobe-Zeugs, das an Camera Raw andockt.

aaaha, das werde ich dann einmal beobachten auf meinen Rechnern ob die Leistung durch eine Optimale Einstellung noch besser wird, wie viel % vom Ram ist optimal?

Das hat null komma nix mit dem RAM zu tun sondern mit Deinem "typischen Workflow" (ohne ein Verständnis für "Workflow" ist alles Herumoptimieren rund um Lightroom eh sinnlos).

Der Cache sollte ausreichend bemessen sein, dass typische Jobs reinpassen (wenn Du also regelmäßig mit 300-500 Bildern in einem Schub daherkommst, dann sollten die Previews da reinpassen, denn andernfalls passiert dann mitten in der "kreativen Phase", wenn man Bildeinstellungen vornimmt oder Filter/Korrekturen anbringt, dass LR Previews neu berechnet und andere schon gerechnete Previews aus dem Cache rausschmeißt, auf die man ggf. kurze Zeit später eh wieder zugreifen will).

Nach unserer Erfahrung profitiert der "Camera Raw Cache" in erster Linie von hohem Durchsatz und weniger von blitzschnellen wahlfreien Zugriffen. SSDs bieten im Regelfall beides (man macht also nix verkehrt, wenn man auf SSD setzt) aber ein schnelles externes TB-RAID oder ein internes in 'nem ollen MacPro tun's für den Zweck auch, Hauptsache hoher Durchsatz. Die eigentlichen LR-Katalogdateien sind anders als Cache-Verzeichnisse aber echte Datenbank-Dateien (kann man mittels sqlite3 auch direkt befummeln). Die profitieren in jedem Fall von ordentlich IOPS, sprich sind auf einer schnellen SSD ideal aufgehoben (wie auch "das System" selbst -- für das Systemlaufwerk sind hohe Durchsatzraten nebensächlich, das profitiert in erster Linie von schnellen wahlfreien Zugriffen SSD ist die Technologie der Wahl, selbst eine lahme SSD über eine arschlahme Anbindung wie USB2 bringt mehr als eine vermeintlich schnelle HD mit zigfach höheren Dauertransferraten, siehe bspw. )

Der Rest ist Organisation/Workflow: Richtige Preview-/Cache-Settings einstellen, Importieren (dabei dafür sorgen, dass 1:1-Previews vor der kreativen Phase generiert werden sonst bremst man sich später nur unnötig aus), dann interaktiv ohne lästige Verzögerungen den Kram bearbeiten und am Ende wieder unbeaufsichtigt alles exportieren lassen.

Und die Settings müssen eben immer zum Workflow passen (wir haben bspw. Kunden, die 360°-Shootings anfertigen, d.h. pro Bild gibt's 24 Aufnahmen, die am Ende zu 3D verrechnet werden. Hier wäre es schwachsinnig, von allen 24 Shots vorab Previews rechnen zu lassen, denn der Workflow ist der, dass der Operator nur 1 Shot in Camera Raw richtig einstellt und speichert und dann eine unserer Lösungen alle 24 RAWs samt Settings ferngesteuert an einem separaten Mac "entwickelt").

Noch ein Wort zu "RAID" mit HDs. Wenn man sich anschaut, wie Festplatten funktionieren, dann stellt man fest, dass diese maximale Transferraten nur auf den äußeren Spuren bringen, d.h. wenn ich ein RAID-0 oder besser RAID-10 für Cache-Zwecke einrichten will, dann zwack ich mir idealerweise von möglichst schnellen HDs je die ersten 20% oder 30% der Kapazität als eigene Partition ab und lasse aus diesen Partitionen, die allesamt in der schnellsten Medienzone residieren, ein RAID bauen.

Dann kriegt man auch nur mit 4 halbwegs aktuellen HDs als RAID-0 spielend über 500 MByte/sek konstante Transferrate über das komplette RAID (nicht zu schaffen, wenn man die kompletten Platten als RAID zusammenfaßt, weil die auf den inneren Spuren normalerweise nur die Hälfte des Durchsatzes schaffen wie auf den äußeren).