Mac Pro 6,1 SSD-Upgrade

Ich habe mich für die 8 Core CPU entschieden.

Einbau war einfacher als ich dachte, nur beim abschrauben des CPU Federblechs gab es unvorhergesehenes. Alle vier Muttern haben sich aus dem Kühlkörper geschraubt anstatt die Schrauben. Dann ging die Suche nach einem passenden Schlüssel los. Nachdem der gefunden war gabs keine weiteren Probleme.

Idle Temperaturen von CPU + GPUs liegen wie vorher bei 38 Grad.

Hier noch die Cinebench Werte:

Single -> 767
Multi -> 6882

Der Single Wert ist leicht besser als bei der 6 Core CPU, da kommt wohl der größere Cache zum tragen. Ich denke der 8 Kerner war die richtige Wahl für den geplanten Anwendungsfall. Jetzt muss nur noch die neue SSD eintrudeln…
 
Genau so hab ich das gerade eingestellt. Monitor automatisch aus nach X Minuten aber kein autom. Sleep.
Freundlicherweise hat die Soundkarte einen Ein-/Ausschalter.

Ist wohl der Preis für eine low-latency USB 3 Karte.

Werde den Support von Zoom mal anschreiben, die sind aber in der Regel wenig supportiv und dazu noch schweigsam...
Wie? Du bist schon fertig? Wann hast du den denn bestellt?
 
Hab jetzt zum ersten Mal den Thread ganz durchgelesen und bin dabei auf folgendes gestoßen:
Generell gilt:

Samsung NVME unterstützen Trim bedingt durch den Controller nicht und die Boot Zeiten werden mit der Zeit extrem lang ( 20 min. + ).

Das wusste ich vor einem Jahr nicht, als ich mir meinen MacPro6,1 (6-Core) gekauft und eine Samsung 980 NVMe mit 1 TB eingebaut habe.

Bislang ist mir in diesem einen Jahr nichts Negatives aufgefallen. Eben noch mal die Bootzeit kontrolliert:
Vom Einschaltknopf drücken über OCLP Bootpicker Auswahl bis zum Anmeldebildschirm (Sonoma) nicht ganz eine Minute.

Ist da dann bald Ungemach zu erwarten, oder wie gestaltet sich das nun mit der "bösen" Samsung?
 
@rayjoe

Das problem tritt in Zusammenhang mit dem Dateisystem APFS auf.
Hängt halt von der Nutzung ab.

Überprüfen kannst du die Zeit die Trim beim Booten braucht mit:
log show --predicate "processID == 0" | grep spaceman

Hiermit schreibst du die Ergebniss direkt in eine Datei auf deinem Desktop:
log show --predicate "processID == 0" | grep spaceman > ~/Desktop/trim.txt

Bei vielen dauert Trim dann bis zu 20 Minuten beim Booten.......
Ein löschen der NVME und neu installieren setzt das Problem wieder zurück.
 
Da bekomme ich folgende Ausgabe, die sich dann wiederholt:

Code:
 % log show --predicate "processID == 0" | grep spaceman
2023-11-06 11:37:44.794342+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_metazone_init:172: disk1 metazone for device 0 of size 2312303 blocks (encrypted: 0-1156151 unencrypted: 1156151-2312303)
2023-11-06 11:37:44.794348+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:628: disk1 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 138084352
2023-11-06 11:37:44.794353+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:628: disk1 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 43974656
2023-11-06 11:37:44.794356+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:628: disk1 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 84148224
2023-11-06 11:37:44.794360+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:628: disk1 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 41254912
2023-11-06 11:37:44.918932+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3374: disk1 scan took 0.124543 s (no trims)
2023-11-06 11:37:59.547179+0100 0x314      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3356: disk1 scan took 14.628234 s, trims took 14.477055 s
2023-11-06 11:37:59.547188+0100 0x314      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3358: disk1 138093437 blocks free in 132474 extents
2023-11-06 11:37:59.547192+0100 0x314      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3366: disk1 138093437 blocks trimmed in 132474 extents (109 us/trim, 9150 trims/s)
2023-11-06 11:37:59.547196+0100 0x314      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3369: disk1 trim distribution 1:45187 2+:31137 4+:35117 16+:8686 64+:5028 256+:7319
 
Ich habe ebenfalls den Wechsel vom Vier- auf den Achtkerner gemacht und kann nicht klagen. Ist für meine Anwendungen (viele parallel laufende VMs) der berühmte "Sweetspot" in Sachen CPU-Auswahl, vor allem im Zusammenspiel mit 64GB RAM.

Ich hoffe, dass mir der 6,1er noch lange treue Dienst leisten wird.
 
  • Gefällt mir
Reaktionen: rayjoe und NeumannPaule
Neue SSD ist angekommen, eingebaut -> läuft.

Die von mir verwendeten Komponenten:
Adapter von Sintech
Kühlkörper: be quiet MC1
SSD: WD_BLACK SN850X NVMe SSD 4 TB M.2 2280

Damit sind die Hardwarebasteleien abgeschlossen und die zeitraubende Software Installation kann los gehen.
 
Da bekomme ich folgende Ausgabe, die sich dann wiederholt:

Code:
 % log show --predicate "processID == 0" | grep spaceman
2023-11-06 11:37:44.794342+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_metazone_init:172: disk1 metazone for device 0 of size 2312303 blocks (encrypted: 0-1156151 unencrypted: 1156151-2312303)
2023-11-06 11:37:44.794348+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:628: disk1 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 138084352
2023-11-06 11:37:44.794353+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:628: disk1 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 43974656
2023-11-06 11:37:44.794356+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:628: disk1 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 84148224
2023-11-06 11:37:44.794360+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:628: disk1 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 41254912
2023-11-06 11:37:44.918932+0100 0x342      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3374: disk1 scan took 0.124543 s (no trims)
2023-11-06 11:37:59.547179+0100 0x314      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3356: disk1 scan took 14.628234 s, trims took 14.477055 s
2023-11-06 11:37:59.547188+0100 0x314      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3358: disk1 138093437 blocks free in 132474 extents
2023-11-06 11:37:59.547192+0100 0x314      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3366: disk1 138093437 blocks trimmed in 132474 extents (109 us/trim, 9150 trims/s)
2023-11-06 11:37:59.547196+0100 0x314      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3369: disk1 trim distribution 1:45187 2+:31137 4+:35117 16+:8686 64+:5028 256+:7319
trims took 14.477055 s ......
Der Wert ist aber vom 06.11.2023........

Das sieht halt bei manchen sehr übel aus, z.B. 1400+ Sekunden, bei mir

kernel: (apfs) spaceman_scan_free_blocks:3674: disk1 scan took 0.378655 s, trims took 0.240024 s
 
Überprüfen kannst du die Zeit die Trim beim Booten braucht mit:
log show --predicate "processID == 0" | grep spaceman

Hiermit schreibst du die Ergebniss direkt in eine Datei auf deinem Desktop:
log show --predicate "processID == 0" | grep spaceman > ~/Desktop/trim.txt
Danke! Interessant!

Ich hab das auch gerade mal gemacht. Auf meinem Bootvolume, einer 2TB 980 PRO, braucht TRIM demnach wohl 256 Sekunden, also etwas über vier Minuten, was sich in etwa mit der tatsächlichen Bootzeit deckt. Ich habe allerdings nicht den Eindruck, dass das, seit ich die SSD habe großartig länger geworden ist.

Ich wusste da an sich vorher, was auf mich zukommt, habe mich aber dennoch bewusst für die SAMSUNG entschieden, da es eben eine PCIe 4.0 ist und „irgendwann“ dann doch der Kauf eines 7,1 geplant ist, der das auch ausschöpfen kann.
 
Der Wert ist aber vom 06.11.2023........
Ah, ok jetzt habe ich es durchlaufen lassen, so die letzten Ausgaben von heute (zwei Starts, da ich zwischenzeitlich mal die Original M2-SSD eingesteckt hatte um dort Monterey zu aktualisieren) :

Code:
2023-12-06 07:47:10.581493+0100 0x79       Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3674: disk1 scan took 13.641118 s, trims took 13.471218 s
2023-12-06 07:47:10.581504+0100 0x79       Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3676: disk1 133530976 blocks free in 130989 extents
2023-12-06 07:47:10.581508+0100 0x79       Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3685: disk1 133530976 blocks trimmed in 130989 extents (102 us/trim, 9723 trims/s)
2023-12-06 07:47:10.581512+0100 0x79       Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3688: disk1 trim distribution 1:44052 2+:28715 4+:36924 16+:9483 64+:5283 256+:6532
2023-12-06 15:19:45.967071+0100 0x38e      Default     0x0                  0      0    kernel: (apfs) spaceman_metazone_init:196: disk1 metazone for device 0 of size 2312303 blocks (encrypted: 0-1156151 unencrypted: 1156151-2312303)
2023-12-06 15:19:45.967079+0100 0x38e      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:634: disk1 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 137723904
2023-12-06 15:19:45.967084+0100 0x38e      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:634: disk1 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 60096512
2023-12-06 15:19:45.967088+0100 0x38e      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:634: disk1 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 119996416
2023-12-06 15:19:45.967092+0100 0x38e      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:634: disk1 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 2719744
2023-12-06 15:19:46.089027+0100 0x39c      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3693: disk1 scan took 0.121891 s (no trims)
2023-12-06 15:19:46.089043+0100 0x39c      Default     0x0                  0      0    kernel: (apfs) spaceman_fxc_print_stats:496: disk1 dev 0 smfree 133451275/244139436 table 1057/1058 blocks 127617297 2237:120735:99771359 95.62% range 50570:244088866 99.97% scans 1
2023-12-06 15:19:46.089053+0100 0x39c      Default     0x0                  0      0    kernel: (apfs) spaceman_fxc_print_stats:515: disk1 dev 0 scan_stats[2]: foundmax 99771359 extents 131115 blocks 5833978 long 2236 avg 44 4.37% range 1156267:143211793 58.65%
2023-12-06 15:19:59.758464+0100 0x17d      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3674: disk1 scan took 13.669401 s, trims took 13.490020 s
2023-12-06 15:19:59.758475+0100 0x17d      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3676: disk1 133451275 blocks free in 132200 extents
2023-12-06 15:19:59.758479+0100 0x17d      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3685: disk1 133451275 blocks trimmed in 132200 extents (102 us/trim, 9799 trims/s)
2023-12-06 15:19:59.758484+0100 0x17d      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3688: disk1 trim distribution 1:44496 2+:29025 4+:37175 16+:9648 64+:5364 256+:6492
 
trims took 14.477055 s ......
Der Wert ist aber vom 06.11.2023........

Das sieht halt bei manchen sehr übel aus, z.B. 1400+ Sekunden, bei mir

kernel: (apfs) spaceman_scan_free_blocks:3674: disk1 scan took 0.378655 s, trims took 0.240024 s
Nervig, für mich wäre das aber kein Grund die SSD zu wechseln, wenn es sonst einwandfrei läuft.

Startet man die Möhre halt ein paar Minuten früher oder automatisiert...
 
Ich wusste da an sich vorher, was auf mich zukommt, habe mich aber dennoch bewusst für die SAMSUNG entschieden, da es eben eine PCIe 4.0 ist und „irgendwann“ dann doch der Kauf eines 7,1 geplant ist, der das auch ausschöpfen kann.
Mit der PCIe-Switch-Karte?
Der 7.1, falls damit nicht die ARMe Variante gemeint sein sollte, hat noch PCIe 3.0 auf den internen Steckplätzen.
 
Mit der PCIe-Switch-Karte?
Der 7.1, falls damit nicht die ARMe Variante gemeint sein sollte, hat noch PCIe 3.0 auf den internen Steckplätzen.
Naja, die Steckplätze auf der Karte sind ja 3.0. Im 5,1 zeigt System Info als „Linkspeed“ für die einzelnen Blades x4, 8 GT/s an. Und die Karte kann über den Kontroller ja jedem einzelnen Blade praktisch die volle Bandbreite der (x16) Schnittstelle zur Verfügung stellen. Also sollten 4 GB/s wohl mindestens gehen. Allerdings halt auch nur mit einer 4.0 SSD.
 
Zuletzt bearbeitet:
Aber halt nur mit einer Switch-Karte, nicht mit einem einfachen Durchschleifadapter: Die meisten M-Key SSDs nutzen ja 4 Lanes (mehr gibt M.2 nicht her), bleibt also mit einfachem Adapter auf PCIe 3-Niveau - auch wenn die SSD mehr könnte.

Wie ist das mit TRIM eigentlich bei der Switch-Karte? Sieht das Betriebssystem die SSD noch als solche?
Bei einem Hardware-RAID ist es so, dass der Laufwerkscontroller als "Laufwerk" gesehen wird, eine eigene Device-ID hat und deswegen auch einen eigenen Treiber braucht. TRIM-Befehle werden dann aber u.U. nicht weitergegeben bzw. ausgeführt.
 
Aber halt nur mit einer Switch-Karte, nicht mit einem einfachen Durchschleifadapter
Klar! Die Karte würde ich natürlich in den 7,1 übernehmen.

Wie ist das mit TRIM eigentlich bei der Switch-Karte? Sieht das Betriebssystem die SSD noch als solche?
Also TRIM findet wohl statt. Wenn ich das mit OC disable, bootet der Rechner zwar schneller, zeigt dann aber in den ersten ca. 5 Minuten nach dem Booten ein irgendwie erratisches, unresponsives Verhalten. Also hab ich das mal aktiv gelassen. Die Bootzeit ist mir (solange es keine 20 Minuten sind!) mehr oder weniger egal.

Bei einem Hardware-RAID ist es so, dass der Laufwerkscontroller als "Laufwerk" gesehen wird, eine eigene Device-ID hat und deswegen auch einen eigenen Treiber braucht. TRIM-Befehle werden dann aber u.U. nicht weitergegeben bzw. ausgeführt.
RAID ist Software, also mit SoftRAID angelegt. Eigene Treiber hat die Karte nicht.
 
Zuletzt bearbeitet:
Bin hin und hergerissen, mir noch einen 6,1er zuzulegen, so ein 8-Core wäre schon fein. Irgendwie ist aber derzeit das Secondhand und Refurbished Angebot etwas frustrierend, da werden 3,7 4-core mit 16MB RAM auch kaum unter 450 EUR angeboten und dann müsste man ja noch mal in RAM und CPU investieren ...
 
Bin hin und hergerissen, mir noch einen 6,1er zuzulegen, so ein 8-Core wäre schon fein. Irgendwie ist aber derzeit das Secondhand und Refurbished Angebot etwas frustrierend, da werden 3,7 4-core mit 16MB RAM auch kaum unter 450 EUR angeboten und dann müsste man ja noch mal in RAM und CPU investieren ...
Naja, vor ein paar Monaten waren die 6,1er noch viel teurer. Im Vergleich dazu ist es eigentlich ganz gut, einen für unter 500 € zu bekommen.
 
Zurück
Oben Unten