You need to be a member in order to leave a comment
Already have an account? Sign in here.
Sign In NowSign up for a new account in our community. It's easy!
Register a new accountHast Du mal ein Disk Bench gemacht? Zb BlackMagic Disk Speed.
Ich hatte kürzlich ein ähnliches Problem. Mein System ruckelte ab und an ohne im Task Manger erkennbaren Grund.
Ein Disk Bench zeigte bei mir nur magere 50MB/s Schreibrate.
Wie sieht das bei dir aus?
Warum ist -1 = 4294967295? Wenn -1 eingetragen ist, wird gar nicht gepatcht.
Ja, stimmt, sieht so aus, dass im OC Code im IF ein Integer und kein Unsigned benutzt wird. Der Wert, wenn er >=0 ist, wird dann beim Setzen als UINT interpretiert
4294967295 == 0xFFFFFFFF und das ist als Integer INT == -1, jedoch 4294967295 als UINT.
Ist aber auch Sinnvoll das mit -1 zu deaktivieren zu können.
Danke für den Hinweis.
Bzgl der Werte in SetApfsTrimTimeout: In der OpenCore Config Referenz steht, dass macOS einen Defaultwerte von "9,999999 sec" hat und danach den Trimvorgang stoppt. Weiterhin wird beschrieben, dass _manche_ Samsung Controller anscheinend relativ langsam seien und die nötigen Trim Commands nicht schnell genug abarbeiten und es wird die Befürchtung geäussert, wenn also der langsame Controller nicht alle Trims innerhalb der 9.999999 Sekunden schafft, immer wieder nur die kürzlich gelöschten blocks trimmt: "...trims the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks.". Somit wäre Trim in diesem Fall funktionslos und würde zu höherem Verschleiß führen (siehe Text in der OPenCore Configuration.pdf).
Mit SetApfsTrimTimeout = -1 (==4294967295) setzt man anscheinend den Timeout auf den längsmöglichen Wert. Bei meiner aktuellen 870EVO ist der Trim nach ca 1,7sec durch. Bei meiner alten 840Pro, die lange ohne Trim lief, hat das 23sec gebraucht. Mein meinem MBP2020 mit NVME ist das in 1,x sec durch.
Ich vermute dass in meinem Fall bei der Samsung 840Pro (die kam afaik 2012 auf den Markt) halt ein langsamer Controller hier die Rolle spielt und dass meine neue 870EVO hier besser ist und somit die Bootzeiten mit Timeout=-1 Timeout=4294967295 sich nicht sonderlich verlängern.
Kann ich auch bestätigen: Ich nutze die MX Keys mit Dongle#1 am Hack und mit Dongle#2 (von einer Logitech Maus) am Company Laptop und schalte mit den Switch-Tasten problemlos hin und her.
Ich hatte kürzlich ein ähnliches Phänomen: Ein Diskbench zeigte bei meiner Samsung 840Pro 256GB werte zwischen 50 und 300MB/s. Lesend lag sie bei 510MB/s.
Ich nutze diese SSD seit ca April 2020 mit Catalina und dann Big Sur ohne Trim. Vorher war sie in einem Win10 Rechner als Boot Drive aktiv. Aktuell hat sie 26TB geschrieben. Jedenfalls hab ich danach Trim aktiviert (Systemreport -> OK) und es trat eine leichte Besserung ein. Die Werte blieben länger bei ca 200MB/s, fielen aber auch wieder auf 50MBs oder so. Nach vielen Reboots und OpenCore Trim Timeout auf maximum und keiner Besserung, nahm ich an, dass die Platte halt durch ist und hab sie ausgetauscht.
Die Neue schreibt ca 460 MB/s ohne die Einbrüche.
Anschließend hab ich die alte 840Pro neu formatiert: Erst mal unter macOS mit APFS. Writespeed war schlecht wie vorher. Trim unter macOS an/aus war egal und hatte Trim erstmal unter macOS deaktiviert.
Dann hab ich die 840Pro mal unter Win10 formatiert und "winsat disk -drive x" schrieb mit schlechter Write Performance weit unter 460MB/s.
Unter Win10 hab ich auch das Samsung Magician Tool, was der Meinung ist, dass die Platte 26TB auf dem Buckel hat und "OK" sei.
Jedenfalls war die Platte mehrere Tage eingebaut und NTFS formatiert. Laut dem Samsung Tool ist bei mir ein wöchentlicher Trim Task für meine SSDs aktiv. Nach ein paar Tagen (ich nutze aktuell seit einigen Wochen tagsüber macOS und abends zum gelegentlichen Zocken Win10) wollte ich mich nochmals mit der "defekten" 840Pro befassen und hab nochmal einen Write Test gemacht und jetzt kommts: sowohl Winsat als auch das Samsung Tool schreiben dauerhauft 460MB/s auf die 840Pro.
Nach Reboot zurück in Big Sur hab ich dort die Platte gelöscht und mit macOS APFS formatiert. Auch hier: write speed 460MB/s, dauerhaft.
Da man zum Thema Trim vieles, nur nix genaues liest, hab ich Trim erst deaktiviert und nun mich entschieden, Trim dauerhaft anzulassen.
Gruß, T
Die gesuchten Einträge sind im kernel log via dmesg zu finden, nachdem ich den Bootparameter msgbuf=1048576 hinzugefügt und rebootet habe.
Probier mal AppleXcmpExtraMsrs = Yes
Hmm. "nichts im Log" bedeutet nicht zwingend dass es keine Aktivitäten gab. Ggfs landen die Logeinträge nicht im Log, weil das Logging nicht entsprechend konfiguriert ist. Daher meine Frage.
Moin,
ich bin auf der Suche nach den Logs bzgl der Trim Aktivitäten von macOS.
Zunächst will ich das an meinem MBP2020 BigSur Trim enabled ausprobieren. Theoretisch
sollte ich z.b. mit log show --last 3d --style syslog | grep "spaceman" irgendwas sehen. Leider finde ich keine Einträge.
Muss ich noch ein loglevel o.ä setzen?
Danke im voraus.
T.
nur die ssdt rein.
Hab ziemlich das gleiche System .... allerdings Aorus Pro Board.
Für meine RX 5500XT hab ich seit längerem die angehängte AML Datei in OC. Aus meiner Sicht läuft die Karte damit bei mir wunderbar.
SebiPlayz : ich hatte auch das Problem mit dem "connecten". Wobei ich aktuell nicht mehr sagen kann, ob meine Realtek Steckkarte oder die Intel Onboardkarte betroffen war.
Letztendlich bin ich auf eine Intel Steckkarte umgestiegen (die ich in Windows deaktiviert hab), für die macOS native Treiber bietet. Seither ist ruhe.
Moin,
mir ist aufgefallen, dass nach dem Update auf macOS 11.2(.0) der Mauszeiger beim Bewegen öfters kurz größer wird, obwohl ich nicht mit der Maus gewackelt habe. Beispielsweise wenn ich die Maus quer über den Bildschirm ziehe z.B. beim Surfen (und ohne Last im Hintergrund).
Habt ihr das auch festgestellt?
Mir ist dieses Accessibility Feature bekannt und wie es funktioniert. Es ist bei mir mindestens seit Catalina aktiviert. In den Settings ist "Shake mouse pointer to locate" aktiviert. Es gibt keinen Threshold oder Sensitivity. Nur an oder aus. Auffällig, unerwartet kam mir das Shake Feature bisher nicht unter.
Heute morgen hab ich das Update 11.2.1 reinlaufen lassen und es sieht so aus, dass das Problem nun weg ist.
Gruß, T
Ich hab etwas mit der Unlock Funktion in iOS/WatchOS Beta herumgespielt.
Dabei ist mir aufgefallen, dass man die Maske _über_ die Nase ziehen muss, damit die Uhr einspringt.
Allerding reicht es, auch wenn Augen und Nase bedeckt sind, damit die Uhr das iPhone entsperrt. Das ist für mich recht hiflreich, da meine Ray Ban Wayfarer wohl zu dunkel für FaceID ist, während andere Sonnenbrillen funktionieren. Also bei Sonnenbrille zwei Finger über die Nase und Unlock läuft.
Hier im Board gibts einen User der ein EFI Tool für das Unlocking programmiert hat. Vielleicht kannst Du dir das mal ansehen.
Spannendes Thema. m.E. ist jetzt die Frage, kommt das
Ich würde da so vorgehen:
1. Schauen, ob es hilft im Bios die Lüfterdrehzahl höher setzen (nur zum Test; nicht als Dauerlösung)
2. Bios Settings/Version checken (hast du bestimmt schon mehrmals)
3. falls möglich prüfen ob das Problem auch unter Windows besteht.
Ich hatte mit meiner aktuellen CPU auf meinem vorherigen Board auch ein komisches Phänomen. Eine Änderung/Verbesserung , jedoch keine Lösung, brachte AppleXcmpExtraMsrs = true (in OpenCore.cfg). Dieser Tweak sollte eigentlich in meinem Falle keine Rolle spielen, tat es aber. GGfs hilft es mit den beiden anderen Powermanagement Parameter zu spielen.
Ich verstehe das als P2P hosted Website.
Der Contentowner (ZeroNet Websiterersteller) kann nachdem der erste Besucher die Seite gespiegelt hat, offline gehen, bis er neuen Content online stellen will. Durch das P2P Konzept bleibt die Seite aber verfügbar solange eine Kopie per P2P erreichbar ist. Je mehr Besucher diese Seite hat desto mehr P2P Kopien gibt es.
Spannend wird es für diejenigen User, die das Gesamtkonzept von ZeroNet,P2P, Tor und Anonymität im Internet nicht ganz durchdringen und somit trotz Nutzung eines "dezentralen", "anonymen" Systems, dennoch identifiziert werden und ggfs für den "gehosteten" Content belangt werden.
schmalen: egal. Habe aus dem Initialpost herausgelesen, dass der "Kollege" sich mit "Deinen" Zugangsdaten auf einem Mediamarkt Gerät anmelden konnte. Und das geht ja wohl nur, wenn "der Kollege" "deine" Zugangdaten hat.
Wenn die Frage war, warum der "Kollegen" auf einem Mediamarkt Gerät im Browser Passwort Store "Deine" Zugangsdaten findet, kann das m.E. - nach ockhams Rasiermesser Ansatz - (nur) daher kommen, dass er deine Mail/Passwd in seinem Keyring hat und sich mit seiner AppleID auf dem Mediamarkt Gerät angemeldet hat und somit sein Keyring mit deinen Daten per iCloud Sync auf dem Mediamarkt Gerät gelandet sind.
Letztens hat er sich bei Mediamarkt mit meinen Daten sich dort anmelden können. Datenleck oder Apple Id für Schlüsselbund geklaut?
Ist das nicht der Sinn und Zweck von Zugangdaten, dass man sich mit Gültigen an einem weiteren Gerät anmelden kann?
Hat er sich auf dem Mediamarkt Ausstellergerät mit deinen Zugangsdaten angemeldet? Wenn ja, vielleicht hat er es da früher schon mal gemacht und es vergessen und deswegen sind die Daten hinterlegt?
ich hab das Z390 AORUS Pro, das müsste bis auf Wifi identisch mit deinem sein. Mein Mapping spiele ich per Kext ein. Im Forum hängt irgendwo mein EFI dazu. Ich hab nicht alle Ports gemappt, wg 15 Limit.
Gruß, T
