• Herzlich willkommen im "neuen" DSLR-Forum!

    Wir hoffen, dass Euch das neue Design und die neuen Features gefallen und Ihr Euch schnell zurechtfindet.
    Wir werden wohl alle etwas Zeit brauchen, um uns in die neue Umgebung einzuleben. Auch für uns ist das alles neu.

    Euer DSLR-Forum-Team

  • In eigener Sache!

    Liebe Mitglieder, liebe Besucher und Gäste
    ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
    Bitte hier weiterlesen ...

  • DSLR-Forum Fotowettbewerb neu erfunden!
    Nach wochenlanger intensiver Arbeit an der Erneuerung des Formates unseres internen Fotowettbewerbes ist es Frosty als Moderator
    und au lait als Programmierer gelungen, unseren Wettbewerb auf ein völlig neues Level zu heben!
    Lest hier alle Infos zum DSLR-Forum Fotowettbewerb 2.0
    Einen voll funktionsfähigen Demowettbewerb kannst du dir hier ansehen.
  • Neuer Partner: AkkuShop.de
    Akkus, Ladegeräte und mehr (nicht nur) für Digitalkameras und Drohnen
  • Neuer Gutscheincode unseres Partners Schutzfolien24:
    DSLR-Forum2024
    Dauerhaft 10% Rabatt auf alle Displayschutzfolien der Eigenmarken "Upscreen", "Brotec", "Savvies".
    Der Code ist für alle Geräteklassen gültig.
  • Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs März 2024.
    Thema: "Arbeitsmittel"

    Nur noch bis zum 31.03.2024 23:59!
    Jeder darf abstimmen!
    Zur Abstimmung und Bewertung hier lang
  • Frohe Ostern!

    Wir wünschen allen DSLR-Forum Nutzern, ihren Familien und Freunden sowie unseren Sponsoren und Partnern und deren Familien und Freunden ein frohes Osterfest.

    Euer DSLR-Forum Team!
WERBUNG

Mehr Performance für LR 5.6?

fl_dutch

Themenersteller
Ich bin mit der Performance meines System unter Lightroom 5.6 nicht ganz zufrieden.

Folgende Punkte sehe ich als Problem:
a) Geschwindigkeit der Live-Vorschau bei Änderungen im Entwicklungsmodus (Helligkeit, Sättigung, Temperatur etc) bei RAW Dateien aus der 5D Mark III
b) Geschwindigkeit beim Rendern von RAW nach JPG beim Export.

RAW Cache: 100 GB auf SSD (Anbindung nur mit Sata 2.0)
Katalog: auf SSD (Anbindung nur mit Sata 2.0) (Größe aktuell ca. 1.8 GB)

RAW Dateien liegen auf einem QNAP NAS (TS-870) mit aktuell 4x 2 TB (RAID 5, eine Platte Hot Standby, Platten WD Red), Switch ist ein HP 1810-24G v2, Anbindung QNAP: 4x Gbit, Anbindung PC: 2x Gbit (Intel Pro Dual Nic), jeweils per Trunking.

PC-System: Intel Core i7-3770 Quadcore, 3.4 Ghz, 16 GB, Radeon R7 260x, SSD 120 GB (Corsair Force GT, an Sata 3) für System, SSD 120 GB (Corsair Force 3 an Sata 2) für LR Cache und Katalog.

Mögliche Flaschenhälse:
  • Anbindung NAS - der aktuelle Trunkingmodus bringt nicht den gewünschten Effekt, es sind aber sehr gute 120 MByte/s in der Übertragung möglich.
  • Prozessor bringt zu wenig Leistung beim Rendern
  • Grafikprozessor zu wenig Leistung fürs Rendern (?)
  • Anbindung Cache SSD mit Sata 2

Mögliche Lösungen:
  • NAS und PC umstellen auf 10 Gbit oder Trunking optimieren (hat das von euch schon wer hinbekommen mit Trunking?)*
  • NAS mit SSD nachrüsten für Caching
  • Neues Board, Prozessor (aktueller Core i7 6-core oder 8-core)*
  • Aktuellen Prozessor übertakten, sollte bis 3.8 Ghz stabil laufen wie ich im Netz gesehen habe
  • SSD für Cache an Sata 3 und schnellere SSD
  • SSD für Cache als PCIe Version, bspw. Mushkin Scorpion Deluxe 240 GB (mit 2150 MB/s Übertragungsrate lesen, 1950 MB/s schreibend*
  • schnellere Grafikkarte (habe bis dato aber nur Infos zu PS gefunden, rechnet Lightroom überhaupt auf der GPU?)

Favorisiert sind die mit dem * am Ende - wie sind eure Meinungen und Erfahrungen zu dem Thema?
 
Naja - ich bin nicht "ganz" zufrieden.

Wenn ich beim parallelen Rendern von 2x 600 Bildern (volle Auflösung, reduzierte Auflösung) 20-30% Zeit einsparen könnte, wäre das schon klasse (das dauert nämlich mal gerne 1-2 Stunden)!

Gleiches gilt für Punkt a - wenn es da gefühlt schneller ginge, wäre das von Vorteil, gerade wenn ich wirklich mal schnell durch die Dateien durchgehe, braucht es manchmal doch lange, bis die Vorschau/Änderung da ist.

Vielleicht ist es auch eher ein Luxusproblem :).

Noch zu erwähnen: die Bearbeitung der Fotos erfolgt per Logitech G13 Tastatur mit Paddy for Lightroom als Addon (dh. ich habe entsprechend Shortcuts auf den Tasten für einzelnen Schritte in der RAW Entwicklung), was entsprechen schnell ist: Tastendruck, Wert rauf/runter, Tastendruck, Wert ändern, nächstes Bild etc...

Das hätte ich halt gerne noch flüssiger, deswegen auch die Idee mit der PCIe SSD von Mushkin.
 
2x600 ist eine Menge. Darf man fragen warum so viele?
 
RAW Dateien liegen auf einem QNAP NAS (TS-870) mit aktuell 4x 2 TB (RAID 5, eine Platte Hot Standby, Platten WD Red), Switch ist ein HP 1810-24G v2, Anbindung QNAP: 4x Gbit, Anbindung PC: 2x Gbit (Intel Pro Dual Nic), jeweils per Trunking.

Mögliche Flaschenhälse:
  • Anbindung NAS - der aktuelle Trunkingmodus bringt nicht den gewünschten Effekt, es sind aber sehr gute 120 MByte/s in der Übertragung möglich.
Dann stimmt etwas mit deinem Trunk nicht.

  • Grafikprozessor zu wenig Leistung fürs Rendern (?)
Für Lightroom ist die Grafikkarte nicht relevant.

Mögliche Lösungen:
  • schnellere Grafikkarte (habe bis dato aber nur Infos zu PS gefunden, rechnet Lightroom überhaupt auf der GPU?)
Nein.

Wenn ich beim parallelen Rendern von 2x 600 Bildern (volle Auflösung, reduzierte Auflösung) 20-30% Zeit einsparen könnte, wäre das schon klasse (das dauert nämlich mal gerne 1-2 Stunden)!
Mehrere Vorgänge parallel anstoßen.
 
Mehrere Vorgänge parallel anstoßen.
Mag helfen. Ich würde erst mal ganz profan (PC Wissen scheint beim TO ja verhanden zu sein) analysieren, wo die Performance hängen bleibt:

- CPU Auslastung
- Lesen der Originale
- Schreiben der entwickelten Bilder
- u.U. die beiden letzteren Punkt synchron, das irgendwen überfordert (egal ob die Anbindung des NAS oder das NAS selber).

Selbst lokal (SSD->SSD) brauche ich nur beim Zielformat von TIFF unkomprimiert nach TIFF(LZW-Komprimiert) zu wechseln, um massive Performanceeinbussen zu erhalten (egal, ob Bibble Pro, LR oder NX-D).

Ähnliches kann ich lokal beobachten (und hören :D), wenn ich von HDD->HDD (auf die selbe HDD) kleinere RAWs rendere.

Wobie das ganze natürlich nichts mit der Bearbeitung zu tun hat. Das lässt sich allenfalls durch eine schnellere CPU oder eine kleiner Monitorauflösung beschleunigen. Oder vieleicht noch durch die Umstellung des Workflows, falls neben den genannten Punkte auch noch die Objektivkorrektur und/oder das Entrauschen genutzt wird.
 
Danke für eure Feedbacks!

@sou: Thema Trunks: Die sind so schon "richtig" konfiguriert. Hier liegt der Knackpunkt in der Methode des Trunks: aktuell ist 802.3ad am Qnap und am Switch konfiguriert. Das bedeutet es gibt zwar 4 Gbit/s, aber die volle Bandbreite gibt es nur, wenn mehrere NICs/Rechner darauf zugreifen (zumindest ist das bei der aktuellen QNAP Implementierung der Fall). Das ist natürlich bei einer Verbindung von einem Rechner schlecht - es gibt Threads im QNAP-Forum, dass das ein QNAP Implementierungsproblem sein könnte. Es gibt viele verschiedene Möglichkeiten, das Trunking zu konfigurieren, hab mich da aktuell noch net rangetraut. Die NIC (Intel PRO/1000 PT) ist ebenso als 802.3ad Trunk konfiguriert, hier scheint es mit den 2 Gbit/s zu funktionieren.

Alternativ werd ich es mal mit nem statischen Trunk probieren - falls da jemand Erfahrungen damit hat, bin ich für Empfehlungen dankbar.

Graka: jip, hatte ich auch im Kopf, aber man weiss ja nie, hätte ja sein können, das mit da was entgangen ist. Wäre cool, wenn Adobe das mit LR6 implementieren würde. (Auch wenn mich da Treiberprobleme mit ATI Treibern schon den letzten Nerv gekostet haben.)

Parallele Prozesse: jip, mache ich ja bereits. Das bringt schon ein wenig, könnte aber noch besser. Das Rendern ist ganz klar ein CPU Problem!

Auflösung: 1. NEC PA271, 2560x1440 (Displayport), 2. NEC P221w, 1050x1680 (DVI), LR läuft nur auf dem großen Monitor, da LR mit Paddy nicht auf 2 Monitoren läuft. Verkleinern der Auflösung kommt nicht in Frage, eher steht ein Umstieg auf 4k+ an, sobald NEC da in der PA-Serie was ordentliches verfügbar auf 27/30 Zoll.

@GymfanDE: Analyse ist ne gute Idee. Tips für Analysetools? Benchmarking wäre ja nicht der richtige Ansatzpunkt.

Fürs Rendern ist der Flaschenhals klar die CPU, ohne Frage. Komprimierung bspw. muss gerechnet werden.

Kleinere Auflösung kommt nicht in Frage.

Workflowänderung werde ich mal probieren. Ich fürchte aber, dass es hinterher mehr Arbeit wäre, bspw. Rauschfilter/Objektivkorrektur nochmal anzuwenden, als dass es eine Zeitersparung bringen würde.


Schon mal wer ne schnelle PCIe SSD für den Cache genutzt? Bspw. OCZ Revodrive.
 
Auflösung: 1. NEC PA271, 2560x1440 (Displayport), 2. NEC P221w, 1050x1680 (DVI), LR läuft nur auf dem großen Monitor, da LR mit Paddy nicht auf 2 Monitoren läuft. Verkleinern der Auflösung kommt nicht in Frage, eher steht ein Umstieg auf 4k+ an, sobald NEC da in der PA-Serie was ordentliches verfügbar auf 27/30 Zoll.

Mach mal testweise folgendes: nur einen Monitor anschließen und die Auflösung auf 1024x768 reduzieren. Wetten, LR geht ab wie eine Rakete?

Analyse ist ne gute Idee. Tips für Analysetools? Benchmarking wäre ja nicht der richtige Ansatzpunkt.
Task-Manager, Ressourcenmonitor, Sysinternal Tools etc.

Kleinere Auflösung kommt nicht in Frage.
Schon klar, probier es aber trotzdem mal aus.
 
@sou: ich kann die Auflösung auch auf 800x600 oder auf Briefmarkengröße reduzieren, das ist aber leider eine Lösung, die mich nicht weiterbringt - sondern weist auf ein Problem in der Programmierung von Lightroom hin :). Das es was bringen würde glaube ich gerne - hast du da vielleicht nen Link zu dem Thema?

Am Ende wird die Entscheidung (in der aufgefühten Reihenfolge) hier wahrscheinlich so aussehen:
1) Trunk optimieren (weil nur zeitintensiv aber davon ab ohne weitere monetäre Ausgaben)
2) PCIe SSD kaufen (weil meine aktuelle Force 3 SSD in die Jahre gekommen ist und bereits schonmal getauscht wurde)
3) Board, Speicher, Prozessor upgraden (erst später, weil dann die vielleicht ein neuer Prozessor mehr bringt als "nur" 30% Leistungszuwachs).

Analyse auf aktuelle Engpässe vorausgesetzt.
 
Wird das Ganze denn schneller, wenn Du es lokal machst, dann wüsste man schonmal , ob es lohnt, am NAS zu schrauben oder obs eher ein CPU Thema ist.

Und wie sieht die CPU Auslastung aus, wenn Du renderst ? ( Task Manager )

Das Problem dürfte aber hauptsächlich sein, daß z.B. das Rendern der Vorschauen nicht parallelisiert werden kann und so im Grunde Datenmenge und CPU über die Dauer entscheiden, und weniger der Ablageort der Daten.
 
Zuletzt bearbeitet:
Mal paar adhoc Werte:
Beim "Blättern" von Bild zu Bild ist die Transferrate im Netzwerk max. bei 40 MB/s, dh klar unterhalb der 120 MB/s die die Verbindung zum NAS so hergibt - einzig allein die Latenz zum Laden des RAWs dürfte da merkbarer Faktor sein. Da traue ich aber der Anzeige im Task Manager nicht allzuviel zu.

Geschrieben wird dabei gar nicht (warum auch, die Änderungen stehen ja nicht in der RAW-Datei) aufs NAS.

Bei wildem Schiebgeregel gibt es also auch keinen NAS Zugriff - dh. ohne weitere Empirie: das NAS als Flaschenhals dürfte fast ausscheiden (bis auf die Latenz). Am Trunking muss also nicht zwangsweise optimiert werden.

Da es scheinbar beim Transfer auch der Cache Dateien eher um Latenz als um Speed geht, dürfte muss ich auch meine Idee einer PCIe SSD hinterfragen - wobei Cache & Katalog in Ram-Disk ja schon angeblich Bombe laufen soll. Ergo nächstes Analyseziel die Festplattenbelastung, die Lightroom verursacht. Dann begebe ich mich mal auf die Suche nach nem geeigneten Tool.
 
Am Trunking muss also nicht zwangsweise optimiert werden.

Richtig. Das wäre zwar rein technisch gesehen interessant, ändert aber an der Lightroom Thematik nichts. Deswegen bin ich auch nicht weiter darauf eingegangen.

Ergo nächstes Analyseziel die Festplattenbelastung, die Lightroom verursacht. Dann begebe ich mich mal auf die Suche nach nem geeigneten Tool.
Wie gesagt, Ressourcenmonitor. Oder noch spezieller die Sysinternal Tools.
 
Fürs Rendern ist der Flaschenhals klar die CPU, ohne Frage. Komprimierung bspw. muss gerechnet werden.
Die Frage ist halt,. ob man die Komprimierung benötigt (falls das Ergebnis TIFFs und keine fertigen JPGs sind). Das ist aber natürlich auch die Frage, wo die Bilder landen (SSD oder gar aus dem NAS, von dem zeitgleich das nächste Raw gelesen wird).

Schon mal wer ne schnelle PCIe SSD für den Cache genutzt? Bspw. OCZ Revodrive.
Mir reicht eine (bzw. mittlerweile zwei) SSDs im PC. Diese haben meinen regelmäßigen Flaschenhals (den oben erwähnten, hörbaren Zeitverlust der Festplatte) behoben. Der Rest ist bei mir ein reines Softwareproblem, und da wäre durch vernünftige Programmierug (egal, ob bei LR/NX-D oder in meiner eigenen Batch-Engine) viel mehr heraus zu holen wie mit einer neuen CPU.

@sou: ich kann die Auflösung auch auf 800x600 oder auf Briefmarkengröße reduzieren, das ist aber leider eine Lösung, die mich nicht weiterbringt
Doch, denn sie zeigt Dir, ob Du das Problem mit LR 5.6 überhaupt irgendwie lösen kannst (außer mit einer Stickstoffkühlung und 5-6 GHz als CPU-Takt).

- sondern weist auf ein Problem in der Programmierung von Lightroom hin :)
Nein, eher das Gegenteil ist der Fall. Bei der 100%-Vorschau (u.U. auch bei anderen, habe ich aber nie getestet) wird nur exakt das gerendert, was auch angezeigt werden muss. Je kleiner die Anzeige, um so schneller ist LR damit fertig (im Gegensatz zu NX-D). Jetzt kannst Du Dich allenfalls noch darübner beschweren, daß LR allgemein lahm ist, das bringt aber nciht, so lange Du bei LR bleiben willst. BibblePro wäre auf der gleichen HW mit den gleichen RAWs ca. doppelt so schnell, die Entwickler dort haben halt die richtigen Priortäten gesetzt, bis sie von Corel erst geschluckt und dann gefeuert wurden.

. Das es was bringen würde glaube ich gerne - hast du da vielleicht nen Link zu dem Thema?
Eine kurze Beobachtung des Verhaltens von LR beim Verschieben der 100%-Ansicht zeigt das schon ohne eine technische Erklärung von Adobe. Insb. wenn man das Verhalten mit dem anderer Konverter vergleicht, die in der Anzeige noch viel langsamer sind.

Ergo nächstes Analyseziel die Festplattenbelastung, die Lightroom verursacht. Dann begebe ich mich mal auf die Suche nach nem geeigneten Tool.
Immer noch der Task Manager, zur Not Perfmon (wenn Du Dich dort einarbeiten willst, oder die schon erwähnten Sysinternals/MS Tools (ProcessExplorer und ProcessMonitor)
 
Ich habe dann grade nochmal den AS SSD Benchmark drüberhopsen lassen und die Werte der beiden Corsair SSDs in der Foto-Workstation mit denen einer Samsung 840 Pro 240 GB in meinem "Alltagsrechner" (der ist vom Board her auch etwas neuer) verglichen - weia, mit so gravierenden Unterschieden hatte ich nu nicht gerechnet!

Die Zugriffszeiten der Corsair SSDs liegen zwischen 0.17-0.33s, bei der Samsung sind es 0.02-0.09s - das sind Welten und erklärt schonmal ein wenig. Dazu kommen halt die um diverse Faktoren höheren Lese und vor allem Schreib-Werte der Samsung SSD (Force 3 vs Samsung 840 Pro: 78MB/s vs 483MB/s beim Sequenztest (Faktor 6!)).

Also lieber erstmal schauen, ob eine preiswerte Samsung 840 EVO (ähnliche Benchmark Werte wie die 840 Pro) ein wenig Abhilfe bringen wird (mit zusätzlich etwas Kabel-Jonglage, da die Cache SSD ja eigentlich an Sata 2 hängt, der 2. Sata 3 Port ist durch eine normale Platte besetzt, die nicht zwangsweise Sata 3 benötigt). Die Zugriffszeiten der 840er sind auf jeden Fall besser als die der Mushkin PCIe Karte, die noch mit den alten Sandforce Chips arbeitet (die in diversen PC Foren nicht gut weg kommen).

Analye: paar kleinere Tools installiert, systemeigenen Kram probiert. Problem dabei: man sieht es nicht, wenn man keine Vergleichswerte hat :). Ergo ist Benchmarking doch Pflicht - wodurch ich auch auf obiges gekommen bin... Der Taskmanager ist nur eine Pi-Mal Daumen Ansicht, die auch vom Zeitintervall der Datenerfassung nicht wirklich ausreichend ist - ist aber zur ersten Orientierung sicherlich eine nette Sache. Der Process Manager ist klasse und wird nochmal getestet.

Die Previews für den Cache werden bei mir auf 2880 Pixel gerendert, hat also nichts mit der Bildschirmauflösung am Hut, das Rendering dürfte also auch bei Briefmarkenauflösung die CPU-Last hochtreiben. Ich werdes es morgen trotzdem nochmal probieren :).

An Lightroom geht (leider) kein Weg vorbei (viel probiert vorher) - BibblePro wird ja scheinbar nicht weiterentwickelt (Stand 2010). Und ich möchte halt nicht im Entwicklungsmenü mit der Maus rumklicken müssen, sondern dafür meine Logitech G13 nutzen (seperate Tastatur mit 23 frei belegbaren Tasten auf 3 Ebenen und nem Mini-Joystick).

Danke schonmal für den Input hier. Ich glaube andere Leute würde die Performance des Systems gar net stören - es ist auch wirklich eher marginal.
 
... daß es für die Samsung EVO 840 ein Firmware-Update gab, das die Performance verbessert hat, hat Du mitbekommen?
 
Folgende Punkte sehe ich als Problem:
a) Geschwindigkeit der Live-Vorschau bei Änderungen im Entwicklungsmodus (Helligkeit, Sättigung, Temperatur etc) bei RAW Dateien aus der 5D Mark III
hier fällt mir auf die Schnelle folgendes ein: beim Importieren von RAWs in den LR-Katalog bringt es bekanntlichermassen ja einiges an Geschwindigkeit, wenn man gleich 1:1 Vorschauen rendern lässt - allerdings nur dann wenn diese in den Katalogeinstellungen von der Grösse her grösser eingestellt sind als die native Monitorauflösung! Ich hatte das bei mir falsch und diesen Hinweis irgendwo in einem Forum gelesen, und das Umstellen hat wirklich merklich was gebracht! Das könnte vielleicht auch Dein Problem sein...

@sou: Thema Trunks: Die sind so schon "richtig" konfiguriert. Hier liegt der Knackpunkt in der Methode des Trunks: aktuell ist 802.3ad am Qnap und am Switch konfiguriert. Das bedeutet es gibt zwar 4 Gbit/s, aber die volle Bandbreite gibt es nur, wenn mehrere NICs/Rechner darauf zugreifen (zumindest ist das bei der aktuellen QNAP Implementierung der Fall). Das ist natürlich bei einer Verbindung von einem Rechner schlecht - es gibt Threads im QNAP-Forum, dass das ein QNAP Implementierungsproblem sein könnte. Es gibt viele verschiedene Möglichkeiten, das Trunking zu konfigurieren, hab mich da aktuell noch net rangetraut. Die NIC (Intel PRO/1000 PT) ist ebenso als 802.3ad Trunk konfiguriert, hier scheint es mit den 2 Gbit/s zu funktionieren.

Alternativ werd ich es mal mit nem statischen Trunk probieren - falls da jemand Erfahrungen damit hat, bin ich für Empfehlungen dankbar.
hier hast Du das Problem schon richtig erkannt, und es liegt kein Konfigurationsfehler Deinerseits vor: ein Trunk bringt nur was für die Lastverteilung von mehreren IP-Sessions, und macht niemals eine einzige Session schneller, egal ob Du "Cisco Fast Etherchannel" od. LACP (802.3ad), od. statische Trunks konfigurierst. D.h. wenn Du 2GBit zwischen Deinem Rechner und der QNAP-Box nutzen willst, dann wird Dir das z.B. in "einem Kopiervorgang" nicht gelingen - anders aber wenn Du z.B. ein LUN über ein ein getrenntes VLAN (einem anderen IP-Netz) über iSCSI connectest, und gleichzeitig z.B. über CIFS kopierst, dann wirst Du die 2GBit nutzen können. Das einzige was hilft eine einzige IP-Verbindung zu beschleunigen ist 10GBit Ethernet, ab das ist halt noch etwas teuer ;)

lG Gerald
 
hier fällt mir auf die Schnelle folgendes ein: beim Importieren von RAWs in den LR-Katalog bringt es bekanntlichermassen ja einiges an Geschwindigkeit, wenn man gleich 1:1 Vorschauen rendern lässt - allerdings nur dann wenn diese in den Katalogeinstellungen von der Grösse her grösser eingestellt sind als die native Monitorauflösung!

1:1 ist 1:1. Der Punkt in den Katalogeinstellungen bezieht sich auf die Standardvorschaugröße.
 
WERBUNG
Zurück
Oben Unten