Problem mit Trim-Timeout bei Samsung SSD seit 14.5 gelöst?

    Ist Euch auch schon aufgefallen, dass seit MacOS 14.5 das Problem mit den langen Boot-Zeiten bei Samsung SSDs verschwunden ist? Mein Zweitsystem mit einer 970 EVO, welches früher über eine Minute zum Booten brauchte, bootet jetzt richtig flott, obwohl ich NVMeFix.kext entfernt und ApfsTrimTimeout = -1 gesetzt habe.


    Könnt Ihr diese Beobachtung auch bei anderen SSDs von Samsung bestätigen?


    Edit: Bitte bei Antworten immer Mainboard, CPU und wie die SSD an das System angebunden ist (CPU, PCH oder TB) nennen. Danke!

    Einmal editiert, zuletzt von Mieze ()

    Meine Evo 970 pro hat derzeit ein Windows drauf. Dafür steht aber auch eine sata ssd zur Verfügung. Den Test werde ich demnächst mal machen. Im Moment kann ich aber kein Statement abgeben.
    Aber Danke für den Hinweis 👍

    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

    Meine Möhren

    Kann ich leider nicht bestätigen hier bei mir.

    In Benutzung ist eine Samsung SSD 970 PRO 512GB, Opencore in der Version 1.0.2 und macOS Version ist 15.0.0.

    Nach umstellen von ApfsTrimTimeout von 0 auf -1 dauerte der Bootvorgang wieder ewig.

    Laptop

    ab macOS 12.0 kann kein TRIM-Timout mehr angebenen werden. Der Wert 0 deaktiviert TRIM. Der Wert -1 oder etwas anderes als 0 wird deshalb m.E. ignoriert.

    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

    Meine Möhren

    Im Manual von OpenCore 1.0.1 steht zu SetApfsTrimTimeout:

    Zitat

    Note: The failsafe value -1 indicates that this patch will not be applied, such that apfs.kext will remain untouched.

    Ja, danach gehts weiter:

    Note: The failsafe value -1 indicates that this patch will not be applied, such that apfs.kext will remain

    untouched.

    Note 2 : On macOS 12.0 and above, it is no longer possible to specify trim timeout. However, trim can be disabled

    by setting 0.

    Note 3 : Trim operations are only affected at booting phase when the startup volume is mounted. Either specifying

    timeout, or completely disabling trim with 0, will not affect normal macOS running.

    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

    Meine Möhren

    Ich bin der Sache mal etwas genauer auf den Grund gegangen und habe die apfs.kext von Ventura (13.6.6) und Sonoma (14.7) verglichen. Beide haben die Versionsnummer 11.4 und sind fast gleich groß (5309 Bytes gegen 5310 Bytes), so dass sich am Treiber mit hoher Wahrscheinlichkeit nichts geändert hat. Das würde drauf hindeuten, dass andere Ursachen für das Problem verantwortlich sind.


    Also, was habe ich sonst noch geändert?


    Bis vor einem Monat wurde die 970 EVO mit einem MSI MPG Z490 Gaming Plus (mit Core i7-10700) genutzt und steckte in einem M.2-Slot, der am PCH angebunden ist. Dort gab es das Problem mit den langen Bootzeiten.


    Im August habe ich sie dann in ein anderes System eingebaut, welches mit einem Gigabyte Z490 Gaming X und Core i9-11900KF ausgestattet ist. Dieses Board besitzt einen als "reserved" gekennzeichneten M.2-Slot, der direkt an der CPU hängt, und nur mit Prozessoren der 11. Generation genutzt werden kann. In diesem Slot habe ich die 970 EVO installiert und seitdem waren die langen Bootzeiten Geschichte.


    Sollte also evtl. nicht der Treiber, sondern die Anbindung an das System für die Trim-Probleme verantwortlich sein, welche zu langen Bootzeiten führen? Wie sieht es mit SSDs von Samsung aus, die in externen Thunderbolt-Gehäusen installiert sind? Dauert das Booten von diesen Laufwerken ebenfalls so lange?


    Früher vor einigen Jahren steckte die 970 EVO in dem Gigabyte Z490 Gaming X mit Core i7-10700 und war über den PCH angebunden. Damals hatte ich ebenfalls lange Bootzeiten, was auch der Grund war, sie durch eine andere SSD zu ersetzen. :think:

    Ich muss gestehen, dass ich am KBL-Desktop nie Probleme mit der Evo 980 Pro hatte. Also 980 nicht 970 wie ich erst schrieb. Ich hatte diese dann durch eine 2TB CRUCICAL ersetzt, siehe Meine Möhren in der Signatur. Also aus Platzgründen. Ich hatte seit Mojave immer mit Migrationsassistent die Accounts übernommen und die haben sich dadurch massiv aufgebläht. Da war 1 TB bald zu klein.
    jetzt habe ich noch eine PCIe Steckkarte mit 1x M.2 Nvme und 1x NGFF und da ist die EVO 980 wieder im Rennen. Werde heute Abend mal versuchen.

    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

    Meine Möhren

    Man muss wirklich aufpassen und genau drauf achten um was es geht. Erinnerung reicht nicht.
    Es ist eine Samsung 980 pro NVMe PCIe 1TB


    EDIT: Sonoma 14.7 (23H124) läuft jetzt nach Clean-Install und Datenmigration von Time-Machine auf der 980 Pro. Die NVMe steckt in einem ICY BOX IB-PCI215M2-HSL PCI Express x4 Adapter und hat durchaus passable Werte die dem M.2 (32Gbps.) vom Board des KBL-Desktop nicht nachstehen. Die Firmeware hatte ich 2023 schon aktualisiert, neuere ist nicht verfügbar.


    Der Bootvorghang läuft zügig ohne jeden Hänger, gefühlt schneller als die Crucical CT2000P5P. Mieze



    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

    Meine Möhren

    4 Mal editiert, zuletzt von Arkturus ()

    Mit Samsung-NVMe's, die in externen USB-C-Gehäusen stecken, hab ich so wenig Probleme wie mit SSDs: Trim wird im Verbose kurz angemerkt, geht aber nach vier, fünf Zeilen weiter. Also ohne Probleme, kurzer Trim. Und der X299er, über dessen interne Samsung 970 Evo Plus NVMe ich hier schreibe, hat zumindest mit Catalina und Ventura eigentlich garkeine Probleme.

    Der Original-MacPro6,1 hatte die Boot-Zeiten mit ner Samsung allerdings ins Gigantische verlängert. Aber mit Festplatten ist die Tonne ja sowieso ne Diva: lange meinte die Kiste, es fehle irgendwas am Speicher, um neue Firmware zu laden. Das hat sie mit der X-ten Update-Platte auf ne Crucial MX500 endlich abgelegt.

    Ich hab halt die vielen Samsung fast überall raus geworfen, obwohl ich sonst nie ernsthafte Schwierigkeiten mit ihnen hatte.

    Nur die weitergegebene Z-Box Mi553 läuft noch auf einer Samsung 970Evo als Systemplatte mit Ventura. Die größeren Daten liegen dort aber auch von Anfang an auf einer 2-GB-SSD. Wirklich schnell startet die kleine Kiste nicht, aber ich hatte da auch nie große Probleme mit der NVMe. Und eigentlich ist es meine letzte verbliebene Samsung im Dauer-Start-Betrieb.

    Meine Rechner


    :hackintosh:

    Horsti Könntest Du mir bitte kurz mitteilen, um welches Mainboard und welche CPU es sich handelt, an das die 970 Pro angeschlossen ist?

    Wie ist die 970 Pro an das System angebunden (PCH, CPU oder TB)?

    Beim System handelt es sich um jenes in meinem Avatar.

    Bei der SSD um diese.

    Laptop

    die CPU vom Horsti kann nur PCIe 2.0 und das ist nicht der Renner.

    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

    Meine Möhren

    Da hast du wohl Recht Arkturus aber das war hier ja nicht die Frage.

    Laptop

    Hast du mal gecheckt ob es für die 970 pro neuere Firmware gibt?

    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

    Meine Möhren

    Ich habe jetzt die 980 Pro aus meinem Server herausgeholt und in mein Hauptsystem (Gigabyte Z790 D + 12700KF) eingebaut, Sonoma 14.6.1 installiert und mit dem Migrationsassistenten meine Daten wiederhergestellt. Die 980 Pro hängt jetzt direkt an der CPU und der Rechner bootet flott mit ApfsTrimTimeout = -1.


    Hier noch mal eine Zusammenfassung der getesteten Konfigurationen (jeweils mit ApfsTrimTimeout = -1):

    1. Gigabyte Z490 Gaming X + Core i9-11900KF + 970 Evo im M.2-Slot an der CPU (macOS 14.5 / 14.6 / 14.6.1 / 14.7) -> OK!
    2. Gigabyte Z790 D + Core i7-12700KF + 980 Pro im M.2-Slot an der CPU (macOS 14.6.1) -> OK!
    3. MSI MPG Z490 Gaming Plus + Core i7-10700 + 970 Evo im M.2-Slot am PCH (macOS 14.5) -> nicht OK!

    Offensichtlich tritt das Problem nur auf, wenn die NVMe am PCH hängt. MacGrummel hatte ja schon berichtet, dass es mit externen Samsung SSDs keine Probleme gibt, während die internen gemischte Resultate zeigten.

    Bei der Frage, was könnte diese Konfigurationen unterscheiden, so dass dieses Problem auftritt oder nicht fällt meine Vermutung spontan auf Power Management, genauer genommen auf ASPM. Sollte die TRIM-Problematik bei Samsung NVMes also evtl. mit ASPM zusammenhängen, da die Konfigurationen sich in diesem Fall definitiv unterscheiden? Was denkt ihr?

    Das Problem trat bei neu aufgesetzten Systemen aber sowieso nie auf, sondern erst, wenn sie das x-te Mal getrimmt werden sollten. Ich hab grad die originale HighSierra-Samsung NVMe von meinem X99 wieder ausgegraben (die Kiste mit den alten Intel- und Broadcom-WLAN-Karten und zu kleinen oder zu alten System-Platten) , ich bau die grad mal zum Testen ein. Jetzt, wo der Dicke endlich wieder mit Sequoia läuft..

    Meine Rechner


    :hackintosh:

    MacGrummel Ein neues Betriebssystem auf einer NVMe installieren und dann die Daten aus Time Machine zurückzuspielen habe ich in der Vergangenheit regelmäßig immer mal wieder machen müssen, jedesmal wenn Apple mir mit einem verkackten MacOS-Update das System lahm gelegt hat, weil das der einzige Weg ist, zur alten Version zurückzukommen. Wenn dadurch die ewigen Bootzeiten beseitigt worden wären, dann wäre mir das definitiv aufgefallen. Ist es aber nicht, also muss sich irgend etwas geändert haben. Das MSI MPG Z490 Gaming Plus habe ich im vergangenen November so aufgesetzt, als ich das Board bekommen habe, aber das Booten hat von Anfang an ewig gedauert. Außerdem habe ich neue Versionen immer erst mal in einem neuen Volume zum Testen installiert. Da gab es auch keinen Unterschied bei den Bootzeiten zum Hauptsystem.

    Ich hab fleißig weiter getestet, diesmal mit dem ganz kleinen Rechner, der Z-Box: in der Z-Box steckt von Anfang an eine Samsung 970er NVMe als Startplatte drin.

    Die läuft seit etwa 4, 5 Wochen wieder mal mit OC und seit gestern mit Sequoia 15.1 b5, vorher lange mit Clover von der anderen EFI-Platte aus. Ohne Probleme. Ich erinnere mich, dass sie die ersten Male mit Ventura und OC in Essen sehr langsam gestartet war mit einer Wartezeit beim Trim. Aber das hatte griven dort noch mit dem bekannten Griff in die Trickkiste beschleunigt, indem er SetAPFSTrimTimeout auf 0 gestellt hat, der NVMeFix.kext war vorher auch schon aktiviert. Aber eigentlich braucht ein System beim ersten Start ja immer etwas länger, bis es sich sortiert hat.

    An welchem Teil des Rechners diese NVMe eigentlich angeschlossen ist, lässt sich durch den extrem modularen Aufbau des Rechners leider kaum feststellen, eigentlich gibt es sogar noch einen zweiten M.2-Anschluss mit halber Länge..

    Meine Rechner


    :hackintosh: