[FAQ] Der Sinn und der Unsinn über die SSD-Defragmentierung

KnSNaru

KnSNaru

Experte
Thread Starter
Mitglied seit
25.11.2016
Beiträge
588
Ort
Leipzig
Hallo Community,

wer unter euch streubt sich *nicht* davor, ein Halbleiterlaufwerk zu defragmentieren - Hand hoch!

Ich weiß, dass sehr viele Fragmente die Performance von einer SSD merklich beeinflussen können, dies zeigt sich überwiegend anhand von dem Device Input and Output Control - IOCTL. Es ist mit den konventionellen Mitteln über die Input/Output operations Per Second - IOPS nur bedingt aus zu machen, weil diese von verschiedenen Faktoren bedingen, dennoch resultiert der erhöhte IOCTL in die Prozessor-Auslastung.

Wer jetzt meine, es bezweckt nichts die SSD zu zu defragmentieren, weil die mechanischen Bauteile entfallen, derjenige irrt sich - er ist dem Theorem nicht mächtig!
Der IOCTL resultiert in die Input/Output Request Packets - IRPs am Advanced Programmable Interrupt Controller - APIC, eines jedes Datenpaket bedeutet einen Interrupt Request - IRQ am Local APIC und am I/O APIC, kurzum Warteschlange und Latenz.
Beispiel: Wenn ihr den Prozessor übertaktet aber vergesset die Burstrate/Baudrate mit zu übertakten dann gehen die Signallängen der Datenpakete noch weiter auseinander und es entstehenden Datenfragmente, die Datenpakete teilen sich zu mehreren Anforderungen an dem APIC auf, die Warteschlange wächst an und es entstehen Latenzen, die sich merklich auf die Performance auswirken, sei es die Maus-Reaktion oder die Verzögung am Aufrufen und Aufbauen des Windows Explorers oder des Task-Managers, unter Umständen ist das System instabil. Das ist der Grund, warum in einigen Fällen der DRAM auf Augenhöhe zum Integrated Memory Controller - IMC getaktet schneller ist, weil es einen Unterschied macht, ob die Datenpakete zu 100 MHz getaktet sind oder zu 133 MHz, denn der APIC taktet immer nur mit 100 MHz, folglich müssen die Signallängen aufgesplittet werden, aus einem Datenpaket werden zwei, eine Unterbrechungsanforderung die zweien wird und zwei Datenpakete, die zusammen gehören - das eine muss auf das andere warten. Bei dem OC-Beispiel gehen diese Signallängen noch weiter auseinander, gen 200 MHz destabilisiert sich das System.

Nachdem das jetzt geklärt ist sollte klar sein, was der IOCTL aussagt, welche Auswirkung er auf die CPU-Performance hat: Die LED-Anzeige an eurem PC-Tower trügt euch nicht - mehrere IRPs bedeuten mehrere IRQs seitens dem Datenträger-Cache.

Ich habe die Erfahrung gemacht, dass die Fragmente von einer SSD die Performance negativ beeinträchtigen, die Ursache dafür ist darüber geschildert. Oder stellt sich noch ein Kritiker quer, der meine, es bewege sich lediglich im messbaren Spektrum?
Heutige Rechner agieren so dermaßen schnell, dass selbst der Unterschied zwischen AHCI und NVMe auffällt, ob 's sich lohnt ist eine andere Thematik, aber wenn schon AHCI am Limit ist, das spürt man am Alltag, dann bewegen sich die zusätzlichen Latenzen durch den IOCTL keineswegs nur noch in dem messbaren Spektrum.

Ich habe mein System neu aufgesetzt und was anfangs, um jungfräulichen Zustand noch ultra-performant gewesen ist lässt die CPU-Auslastung um konstant 5% ausscheren und das zeigt sich spürbar in Verzögerungen, auf Webseiten in Stocken etc., und umso mehr sich die SSD erwärmt desto auffälliger sind diese Verzögerungszeiten. Allein das Analysieren der SSD per O&O Defrag 21 Professional fordert der CPU richtig viel Rechenleistung ab, der Vorgang zieht sich - mit dieser Rechenleistung - in länger dahin. Der Effekt ist darüber beschrieben und zeigt sich in meinem Fall nicht bloß in einem messbaren Spektrum: Der Task-Manager benötigt inzwischen 2 Skeunden länger, bis er das zum Start noch leere Fenster mit Inhalten gefüllt hat - das ist viel! Nach einer Defragmentierung verkürze sich diese Verzögerungszeit um in mindestens einer Sekunde, so wie zu Beginn des hier zu sehend frisch aufgesetzten Systems. Ich weiß, dass es damals ähnlich so lange Wartezeiten gegeben hatte, nachdem ich das System von einer HDD auf die SSD migriert hatte, jedoch waren die Fragmente bei weitem nicht so schlimm, dennoch gab es nach einer Defragmentierung eine spürbare Leistungssteigerung, die jedoch nicht die Boottime verkürzte. Mein aktuelles System: In dem Anhang von darunter ist praktisch ein jeder Datenblock ein Fragment.

2.jpg

O&O Defrag 21 Professional w/ 100% Power (Intel Core i7-6700K @ 30x 100 MHz)

3.jpg

O&O Defrag 21 Professional w/ 25% Power (Intel Core i7-6700K @ 30x 100 MHz): Es dauert gefühlt doppelt so lange.

1.PNG

Gesamtgrad der Fragmentierung

Ich finde diesen Artikel bis dato am besten, weil er der Wahrheit auf den Grund gegangen ist, weil er offeriert, dass die Panikmache, jene in der Gesellschaft seit langem posaunt worden ist, zu Unrecht ist:
SSD optimieren: Diese Tipps und Tricks helfen wirklich - PC Magazin

Was denkt ihr? Wie viel von der Fragmentierung spürt ihr am Alltag? Ist es während der Einrichtung von Windows auch aufgefallen, um vieles die Performance gesunken ist, nachdem ihr die SSD sukzessive befülltet, wie der CPU-Zeiger von anfangs durchschnittlich unter 5% sind gen 10% einpendelte? Ich will wissen, wir ihr darüber denkt: Fürchtet ihr der Defragmentierung von einer SSD? Mich interessiert zudem, in wie vielen zusätzlichen IRQs das NVMe endet: Sind die CPU-Auslastungen deutlich höher als wechsle man die Internetverbindung in einem großen Sprung oder halten sie sich noch im Rahmen, Toleranz +5%?

LG,
Naru!
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Danke für den Thread, sehr aufschlussreich.
Aber ein sehr dickes Fragezeichen bleibt. Dass man die Baudrate der COM ports verändern kann, war mir bekannt. Aber im zusammenhang mit OC höre ich das zum ersten mal. Was soll ich da genau Übertakten/Ändern, die Baudrate des IOCTL??? Wo soll das gehen? wie ermittele ich die korrekte Baudrate? Ist damit die CacheRatio gemeint? Fragen über Fragen.....:cool:
 
Hallo Mo3Jo3,

die Kommunikations- und Speicherschnittstellen "North Bridge Baseline, AMD/DEC HyperTransport Link, DRAM Burst, AMD Control Fabric, AMD Data Fabric, Intel Ring On-Chip Interconnect, Intel Mesh-of-Trees Interconnect (künftig eine Fusion zu High-Performance Hierarchical Ring On-Chip Interconnect), Intel/NVIDIA/VIA Direct Media Interface, Intel QuickPath Interconnect, Intel OmniPath Interconnect und Intel UltraPath Interconnect" sind verallgemeinernd alle eine Baudrate, welche die Performance von dem Prozessor bestimmt, die Speicherschnittstellen den IMC und den APIC, also die I/O/Cache-Abteilung wie den System Agent und die Kommunikationsschnittstellen die Core-Abteilung wie die System On-Chip Architecture (AMD seit AM2 - PGA-ZIF-940), die Integrated Archtecture von intel (IA; Ring On-Chip Architecture und Mesh-of-Trees Interconnect).

Der IOCTL ist erstmal nur der Interrupt von der ATA-Schnittstelle, aber er ist maßgeblich für die Latenz verantwortlich - er gibt das Tempo über die Ein- und Ausgabebefehle an, von dem Festplattencache über den ATA-Controller zum I/O-APIC, denn in so herum findet die Messung in Form von IRPs statt. Hier ist es ganz simpel, umso länger die Datenpakete in der Warteschlange stehen, desto länger dauert das Nachreichen von Daten. Desto mehr Anforderungen in der Warteschlange anstehen, desto mehr staut der Bus, das nennt man Pufferüberlauf (Heap Overflow). Es spielt also keine Rolle wie schnell der Prozessor ist, wie schnell der Chipsatz, denn simpel gesprochen ist eine jede Mautstelle ein Verkehrsaufkommen, ein Datenstau.

Ein Jeder kennt diesen Effekt: Der Prozessor behält seinen Load lange aufrecht, seien es nur ein paar Sekunden, obwohl man meine, die Berechnung ist längst abgeschlossen, aber woran liegt das? Es gibt dafür zwei Antworten: Entweder befidnet sich der Prozessor im Auto Halt, wobei es da noch nicht so schlimm ist, vielmehr im strikten Halt State, dann limitiert er sich selbst, die Datenpakete am Local APIC müssen länger auf die vor sich warten, weil der Prozessor sein Tempo drosselt, weil die Tante am Fahrkartenschalter also gemütlich mit ihrer Tochter schwatzt, oder weil die Daten zu langsam an dem Local APIC ankommen, der Bottleneck ist also woanders, irgendwo davor. In diesem Moment wartet der Prozessor auf die Antwort der erteilten Anfrage und hält seinen Load aufrecht, er ist nicht ausgelastet, er ist in der Warteposition. Diesen Effekt kann man bei HDDs am ehesten beobachten, besonders bei alten, verschlissenen und sonstwie lahmen Dingern, dann hat man diesen Effekt ständig, die LED-Anzeige am PC-Tower bleibt länger und intensiver auf Aktivität - das sind die IRQs - die Wartezeiten in den Unterbrechungsanforderungen. Es ist also egal, wie schnell der Prozessor ist, den Takt angeben tun die Einheiten von davor - die Schnittstellen, der Chipsatz und in letzter und wahrscheinlichster Konsequenz der Datenträger selbst, jener die Datenpakete fragmentiert und/oder verzögert ausgibt. Merksatz: "An dem gehaltenen Takt - das Taktverhalten - des Prozessors erkennt man den E/A-Bottleneck!"

Ergänzung
Ich überlege die ganze Zeit, wie ich Dir auf einer einfachen Weise verständlich mache, was die Signallänge zu sagen hat.
Ich versuch 's mal ... Ein Bit eine Signallänge, je nachdem wie breit das Signal ist, desto lang ist die Zeichenkette/die Informationseinheit von einem Bit. Der Prozessor hat einen Speichertakt von 2133 MHz und der Referenztakt beläuft sich auf 100 MHz, der Arbeitsspeicher taktet aber nicht mit 2133 MHz sondern mit 3200 MHz, das ergibt einen Takt von 133 MHz mal 24 Multiplikatoren. Nun taktet die Speicherschnittstelle aber nicht in den 24 Multiplikatoren des Arbeitsspeichers, das kann einzig die Ryzen-Archtektur, deren Assoziation ich hier erklärt habe, sondern die Baudrate oszilliert das Signal, die Konsequenz ist, dass aus Datenpaketen von 133 MHz aufgesplittete Fragmente von 100 MHz werden, die Multiplikatoren der Baud hängen von der Archteiktur ab, entweder 10 zu 1 oder in Oszillation zum Prozessor, je nach Architektur. So, was haben wir jetzt? Ein Datenpaket von zweimal 100 MHz Signallänge, das bedeutet, dass aus der einen Anfrage zwei entstanden sind, dass die erste Anfrage im Prozessor-Cache 0 wartet, bis die zweite, welche das Fragment ist, ohne dieses es nicht weitergeht, durch die Schranke ist und so weiter und so fort. Der OC-Experte weiß, wie er dieser entstehenden Latenz entgegenwirkt und seit Skylake ist es auf der Intel-Plattform kein Unding mehr, er erhöht den Feferenztakt, möglichst synchron zum Speichertakt, wobei es bei 166 MHz fast unmöglich erscheint, aber die 133 Mhz sind im Normalfall machbar, und will man die Taktfrequenz des Prozessor nicht maßlos anheben dann runter mit des Prozessors Multiplikatoren, die gleiche Leistung seitesn dem Hauptprozessor aber die ungedrosselte Memory- Cache und I/O-Performance wegen einem synchronen Taktsignal.

Wie ich schon sagte, so gibt es Anwendungsfälle, zumindest im produktiven Anwendungensfällen, WinRAR zum Beispiel, wo ein synchrones Taktsignal - das vermeintliche niedrigere Taktsignal - die Zeiten deutlich verkürzt, was beim Gaming aber nicht so von Bedeutung sein muss, solange der Prozessor nicht übertaktet ist, wo diese Schere immer weiter aufgeht, wenn einzig des Prozessors Multiplikatoren angehoben sind. WinRAR ist ein gutes Beispiel deswegen, weil es viele Instruktionen/Anforderungen an den Prozessor richtet, da bremsen fragmentierte Datenpakete und das kostet Zeit. Stelle man sich das bei einer üblichen Arbeit am Computer vor, denn umso größer die genannte Schere ist desto größer sind die Latenzen, die Maus schwammig, die Tastatur-Eingaben verzögert, die Texteingaben in einen Eingabeindikator wie HIER zum Beispiel verzögert, und, und, und ...

Bei der ATA-Schnittstelle in Anbindung an den Chipsatz ist es ähnlich, auch diese hat einen festen Takt, nur bringt es nichts diesen anzuheben oder anzugleichen, wenn die Daten von dem Datenträger zu langsam nachgereicht werden, dazu müsse die Bremse in ihrem Inneren ausfindig und eliminiert werden, das kann der Cache sein, am ehesten, denn mehr Interrupte erfordern mehr Cache, es stehen mehr Daten an.

Die Sache zu erklären
 
Zuletzt bearbeitet:
Danke nochmal für die ausfühliche Antwort, leider werden meine fragen nicht gänzlich beantwortet. In deinem ersten Post hast du geschrieben, dass man die Baudrate(wovon denn jetzt genau?) mit dem CPU OC anpassen soll, um eine Fragmentierung der Daten zu reduzieren.
Später hast du was zum OC des IMC geschrieben, was ich auch nicht ganz verstanden habe. Es lohnt sich nicht den IMC takt zu erhöhen, weil der APiC sowieso nur mit 100mhz taktet? Ist das richtig?

Vergib mir meine Dummheit, aber denke aber, dass der Inhalt auch für andere interessant sein kann :)
 
Zuletzt bearbeitet:
Sorry, Du hast diese Synthese etwas missverstanden! ^^

Obwohl das zum Kern des Themas nicht dazu gehört, egal ...

Ich weiß ncht, was für eine Plattform Du hast, daher weiß ich nicht, wie sich die Kommunikationsschnittstelle nennt, zu Englisch Interconnect oder kurz Intercore. In der Mainboard-Firmware (SMBIOS/UEFI) finden sich unterm OC Tweaker, Ai Tweaker, je nach Definition der OC-Rubrik, so Einträge wie Ring Bus oder North Bridge, es ist das besagte Interface.

Diese Interfaces werden meistens in Ratios/Multiplikatoren verändert, selten lässt sich das Taktsignal ändern, aber dieser Wert ist es, was angehoben gehört, damit der Intercore die Datenpakete von dem Chipsatz und dem Hauptspeicher möglichst synchron empfängt und ausgibt.
Es ist zum Beispiel so, dass wenn der Hauptprozessor die Datenpakete mit einer Breite von 100 MHz an den Hauptspeicher ausgibt dann profitiert der Arbeitsspeicher davon nicht, wenn er mit 133 MHz taktet, tatsächlich hat der Arbeitsspeicher noch Puffer, aber umgekehrt ist es tragischer, denn wenn der Arbeitsspeicher die Datenpakete in 133 MHz an den Hauptsprozessor ausgibt, dessen Baud mit 100 MHz taktet, dann erhöht sich die Anzahl an IRQs, denn wie schon zuvor beschrieben, werden die Datenpakete aufgetrennt, sodass ein jedes nur noch mit 100 MHz taktet, also wird ein Datenpaket zu zweien, 33 MHz Informationsgehalt für eine zusätzliche Anforderung und somit die doppelte Latenz.
Das ist eine verschenkte Performance, wo man doch den Arbeitsspeicher mit 200 MHz takten lassen könne, wenn er denn kann, dann bleibt es bei den zwei Datenpaketen am Local APIC aber diese enthalten volle Informationen, denn bei 133 MHz beinhaltet ein einzelnes Datenpaket ein Informatiosngehalt von 33 MHz, wo doch noch 2/3 Platz für Daten ist, deshalb machen hier die 200 MHz des Arbeitsspeichers Sinn. Die 100 MHz sind faktisch zwar auch möglich, aber dazu müsse der Arbeitsspeicher bei 3200 MHz mit Ratio von 32 werkeln, in der Voraussetzung, dass die Baud auf diese 32 Multiplikatoren oszilliert. Erkennst Du die Komplikation? Umso höher der Arbeitsspeicher taktet desto schneller muss das Interface schalten. Wir reden bisher *nur* über 3200 MHz - bei 3800 MHz geht die Schere nochw eiter auf und bei 3866 MHz wird es noch komplizierter, will man den Arbeitsspeichter auf diesen Takt bringen, weil 3866 MHz durch 100 MHz ergibt eine Ratio von 38,6 und diese gibt es nicht, der Speicher wird mit 3800 MHz takten, ob nun mit 38x 100 MHz oder mit 19x 200 MHz ist tendenziell egal, wobei die 200 MHz für das Interface schon problematischer sind und diese sowieso keinen Sinn machen, wenn der Speichercontroller nicht selbst mit annähernd 200 MHz taltet, dann hat man mit denselben Bottleneck zu tun, wobei ich in diesem Fall schon vielmehr befürchte, dass die Datenpakete nicht mehr kohärent sind, dass das System instabil werkelt bzw. es am Bootvorgang abwürgt.

Wie gesagt - Ich muss das Mainboard, den Prozessor und den Arbeitsspeicher kennen und wissen, auf was sie konfiguriert sind; - welches Taktsignal und welcher Multiplikator von welcher Komponente.
 
Zuletzt bearbeitet:
Also, erstmal zu meinem System: I5 6600k@4,5ghz, Asus Maximus Ranger 8, 2x8Gb Corsair Dominator Platinum @3200mhz. Referenztakt läuft auf 100mhz, also ein Multiplikator von 45 auf der CPU und 32 auf den Ram, korrekt?
Was ich in deinem Beispiel nicht verstehe ist, der Hauptprozessor arbeitet mit einem Referenztakt von 100mhz, wieso taktet der Arbeitsspeicher dann mit 133? Sind nicht beide am bclk gekoppelt?
 
Danke! Bitte schaue in der Rubrik "Memory" von "CPU-Z" was unter "NB Frequency" für ein MAXIMALER Wert steht! Dazu muss der Prozessor ausgelastet sein, entweder mittels AIDA64, Prime95 oder sonstiges. Daraus ergibt sich der QPI/Ring-Bus-Teiler.
Der Corsair Dominator Platinum hat womöglich ein 200-Mhz-IC verbaut, daraus ergibt sich ein RAM-Teiler von 16. Faktisch gehen auch 133 und 100 MHz, das obliegt dem VDDQ-Controller. Dieser Teiler steht im Verhältnis zum QPI, dessen Wert ich noch nicht kenne.
 
Zuletzt bearbeitet:
Hey, sorry hatte bis jetzt noch keine Zeit. Kann erst morgen Abend danach schauen.
 
Geht klar! - Ich bin mittlerweile sowieso viel zu müde und mit anderem beschäftgt! ^^
 
Seit der Samsung 840 Evo (msata format) wo die Daten Regelmäßig neu beschrieben werden müssen, da sie sonst langsamer wird. Defragmentier ich meine Festplatten immer mal wieder.

Groß geschadet hat es nie, und ich bilde mir ein das es was bringt.
 
Hallo geheim5000,

es ist das, was auch ich festgestellt habe. Es muss damit bedingt sein, dass die SSDs zur Reduzierung der Schreibzyklen die Bits in ihrem Zustand selten bis kaum refreshen. Was bei einem mangentischen Speicher auch erforderlich ist, weswegen die HDD mit der Zeit Dateisystemfehler verursacht, aber dann kann man CheckDisk mit dem Befehlssatz "chkdsk C: /f /r" fahren, infolgedessen frischt das CheckDisk die Magnetfelder auf, die Sektoren werden aufgefrischt, ohne dass die Bits direkt geändert wurden. Macht man das bei einer SSD überhaupt nicht, dann sinken infolgedessen die Signalstärken der Bits unaufhörlich ab, weil die SSD nichts bis kaum dagegen unternimmt, denn der TRIM frischt lediglich die ungenutzten Speicherzellen auf. Eine SSD jährlich zu defragmentieren schadet ihr nicht: Laut dem verlinkten Artikel gehen sogar monatliche Zyklen in Ordnung, dennoch solle man mit Bedacht herangehen und das gilt auch für den Einsatz von CheckDisk, denn summa summarum ist CheckDisk im wahrsten Sinne des Wortes genauso festplattenlastig wie es eine Defragmentierung ist, wer das also zu häufig durchführt darf sich über die in binnen kurzer Zeit rasch gesunkene Performance nicht exaltieren, denn die Unwissenheit schützt vor der Strafe nicht!
 
Wie weit jedes Datenpaket immer noch einen Interrupt Request bedeutet und dies spürbar auf die Performance geht, sei mal dahingestellt, aber das Defragmentieren von SSDs schadet ihnen nicht, Lebensdauer habe die NANDs in aller Regel weit mehr als ein Heimanwender abrufen wird bevor er sie ersetzt (für die SSDs sind ews ja nur Lese- und Schreibzugriffe) und mehr Fragmente bedeuten mehr Aufwand für die Verwaltung des Filesystems und kürzere Zugriffe auf die SSD. Ein ATA Befehl kann bis zu 2^16 LBAs adressieren, also 32MiB, aber es wird natürlich nie ein Befehl über die Grenze eines Fragmentes hinaus geben. SSDs steigen die Transferraten bei längeren Zugriffen ab und SATA SSDs brauchen meistens so 256k bis 512k pro Zugriff um überhaupt an ihr Limit zu kommen (ATTO täuscht hier mit seinen 4 Overlapping I/Os geringere Werte vor, zeigt aber gut wie die Transferraten bei längeren Zugriffen höher werden) und PCIe SSDs brauchen meist noch viel längere Zugriffe von einige MB pro Befehl. Dann gibt es auch noch einen Overhead pro Zugriffe, es müssen ja auch die Befehle selbst übermittelt werden, bei SATA 6Gb/s sind daher lesend auch nur so etwa 100.000 IOPS bei 4k pro Zugriff möglich, was eben so 400MB/s ergibt, statt über 500MB/s bei langen seq. Zugriffen.

Fragmentierung ist übrigens eine Sache des Filesystems und hat mit dem Medium auf dem sich dieses Filesystem befindet rein gar nichts zu tun. Bei HDDs macht sich eine hohe Fragmentierung massiv bei der Performance bemerkbar, weil die Köpfe dann immer wieder andere Positionen anfahren müssen, was lange dauert. Bei Enterpriseanwendungen wo es sehr viele zufällige Zugriffe parallel gibt wie etwa bei einer Datenbank, ist dies dann auch wieder egal, weil die Köpfe sowieso ständig andere Positionen anfahren müssen und auch eine größere, nicht fragmentiert gespeicherte Datei gar nicht in einem Stück gelesen werden würden. Gerade dort verwendet man ja heute zunehmend SSDs, weil deren Zugriffszeiten sehr kurz sind und die Anfragen wirklich parallel verarbeiten können, weshalb die Fragmentierung hier kaum auf die Performance geht, meist ist sie allenfalls in Benchmarks sichtbar und dort auch meist nur bei den Schreibraten.

Wenn beim Defragmentieren die Lücken des Filesystems, also die unbelegten Cluster dann auch wieder zusammengefügt werden, so verschwindet diese Effekt natürlich, weil die Benchmarks dann die Testdatei für den Test der seq. Transferraten auch wirklich in einem Stück speichern können und diese eben dann nicht fragmentiert, also auf zahlreiche kleine Lücken verteilt geschrieben werden muss. Daher kann die Defragmentierung auch bei SSDs sinnvoll sein und deren Performance verbessern. Schaden tut sie wie gesagt nicht, zumal wenn man es nicht zu oft macht, spielt der Verschleiß für Heimanwender keine Rolle, die NANDs sollte deswegen immer noch nicht verschließen sein, bevor die SSD sowieso getauscht wird. Geht sie beim Defragmentieren trotzdem kaputt, so wäre sie sehr wahrscheinlich auch so bald darauf kaputt gegangen und wer wichtige Daten aber kein Backup davon hat, verdient dann auch kein Mitleid.
 
Gruß Holt, ;)

sehr aufschlussreich Dein Kommentar - gefällt mir richtig gut! +1 ^^

Du ermutigst mich geradezu zur Defragmentierung - wobei ich sie sowieso tun wollte, sobald die Anwendungen und Konfigurationen soweit sind - jetzt ist es soweit!
Nach der Defragmentierung kann es dann mit den Games weitergehen.

Damals, nachdem ich Windows von der HDD migrierte, hatte die Defragmentierung ihren Effekt geteigt, wobei die Fragmentierung bei weitem nicht so stark gewesen ist, vielmehr lagen einige Freispeicherblöcke zwischen den belegten.
Diesmal liegt seitens der Konsolidierung kein Bedarf zur Defragmentierung vor, aber dafür sind so gut wie alle Blöcke fragmentiert und gemeint sind die wichtigsten Daten, die System-/ Treiberdateien.

Bisher weiß ich noch nicht, inwieweit der Prozessor diese Latenzen selbst verursacht - das Thema dazu wirst Du wömglich kennen -, denn so etliche Interaktionen lassen sich gezielt auf ihn eignrenzen, aber dass der Task-Manager 2 Sekunden lang aufbaut ist der Antwortzeit der Informatinen an ihm bedingt, aber ob Prozessor oder SSD ...

Dieses System ist wie gesagt neu, seit Jahren kann ich sagen, das liegt aber an einem Sstemfehler, der eine andere Ursache gehabt hatte. Als es frisch aufgesetzt gewesen ist und noch weniger Installationen vollzogen wurden war die Performance wie zu erwarten prima, doch mittlerweile verzögert einiges unangenehm die Interaktionen.

Ich denke, dass nach einer Defragmentierung diese Verzögerungszeiten halbiert werden, der Rest wird womöglich auf die Kappe des Prozessors gehen, dessen System Agent (APIC/IMC) mit den Anforderungen nicht rechtzeitig nachkommt.

LG,
Naru! :)

- - - Updated - - -

1.PNG

vor O&O Defrag 21 Professional w/ SSD Optimizer


4.PNG

nach O&O Defrag 21 Professional w/ SSD Optimizer


3.PNG

2.PNG

Brauche ich jetzt die Brille ...?
 
Also ich würde keinen mit SSD Optimizer nehmen, die versuchen beim Defragmentieren vermutlich so wenig Daten wie möglich zu bewegen und eben nicht die Lücken (freien Cluster) konsequent zu vereinen, sondern nur extrem kleine Fragmente und extrem viele Fragmente bei einzelnen Dateien zu vermeiden, genau wie es übrigens auch der Optimizer für SSD von Windows ab Win 8 macht, denn auch der Defragmentiert auch auf SSDs einzelne Dateien in solchen Fällen extremer Fragmentierung, außerdem macht er ein Offline TRIM.
 
@KnsNaru erstmal, sorry dass es was gedauert hat. Habe jetzt beim nachschauen auch erst verstanden, dass du die cacheratio meinst. Die läuft auf 4400mhz, multi manuell auf 44 gesetzt.
 
Hallo Mo3Jo3, :)

das Optimum ist ein BCLK von 133 MHz x 34 Ratios, ergibt im Endeffekt die 4.5 GHz mit einem Busgeschwindigkeit von 133 MHz, äquivalent zum Speichertakt von 133 MHz x 24 Ratios.
Ob sich das lohnt hängt von dem Anendungsfall ab, WinRAR zum Beispiel, Gaming womöglich nicht, vielleicht in seltenen Fällen, aber in den meisten Games ist die Latenz eher zweitrangig, das lohnt dann eher bei so speichercontrollerlastigen Games wie Far Cry 3, wo eine als DUNIA getaufte, echte CryENGINE auf Basis von Vektor-Renderng zum Einsatz kommt; - die Nachfolger auf Basis von DUNIA II sind davon ausgenommen.
Also fürs Gaming lohnt es nicht und 133 MHz sind recht normal in den Systemen.

Mann kann den Speicher auch auf 3000 MHz betreiben, so viele machen die 3200 MHz dann nicht mehr aus, dann taktet der DRAM synchron auf die 100 MHz, aber die Speicheranbindung und der Intercore profitieren dann eher von mehr Takt, weil das Verhältnis von 3000 zu 4400 MHz schon nicht zu vernachlässigen ist.
Das Optimum ist fast nur Theorie, in der Praxis erzielt es kaum ein System und ausgenommen von der Produktivität ist der Gewinn durch ihr einzig an einem Overclocking spürbar, wo es ein paar Takte höher gehen kann, wo ein stabilerer Betrieb herbeigeführt werden kann, also eher etwas für so Spielmatzen wie Roman "der8auer" Hartung. xD

LG,
Naru! ;)

- - - Updated - - -

Gruß Holt,

viel erhoffe ich mir dadurch nicht, weil die Verzögerungszeit von so manchen Fällen so groß ist, dass sie schon HDD-Charakter annimmt und dafür bezichtige ich zum Teil den Prozessor, der meines Erachtens Schaden davon getragen hat. ^^
 
Und die 133Mhz ist die optimale Busgeschwindigkeit, weil der Ram mit 133 mhz taktet und die Datenpakete nicht mehr aufgeteilt müssen im Referenztakt? Woher weist du dass der Speicher mit 133 läuft?
 
Eine simple Kalkulation!
Welche Taktsignale gehen, um eine Taktfrequenz von 3200 MHz zu erhalten?

Ein Taktsignal von 100 MHz x 32 ergibt eine Taktfrequenz von 3200 MHz - das Optimum! Jedoch beläuft sich die Baud auf 100 MHz x 44, also undenkbar.
Ein Taktsignal von 133 MHz x 24 ergibt eine Taktfrequenz von 3200 MHz.
Ein Taktsignal von 166 MHz x 19 ergibt eine Taktfrequenz von 3160 MHz. Was sich ein wenig abseits der Register-Spezifikation (Serial Presence Detect - SPD) bewegt. Zeigt eine solche Taktfrequenz an?
Ein Taktsignal von 200 MHz x 16 ergibt eine Taktfrequenz von 3200 MHz. Jedoch taktet ein Intel-Prozessor nicht mit einer Baud von 200 MHz, ohne dass dies den Speichertakt auf 2135 MHz senke, denn die 133 MHz x 16 sowie die 2666 MHz x 16 assimilieren mit ihm. Die Ausnahme ist, dass das IC des Arbeitsspeichers das Taktsignal von 200 MHz unterstützt, natürlich ebenso die 166 MHz, was Dein High-End-RAM durchaus zu bewältigen imstande ist. Dann belaufe sich der System Agent auf 16 Multiplikatoren: Gibt das UEFI/SMBIOS einen derartigen Value wieder?

Du musst stets abwägen, was die Komponenen beherrschen, dass sie assimilieren und wie sie korrelieren! In Deinem Fall sind nur 133 und 200 MHz möglich, die 100 MHz gehen wahrscheinlich nicht, denn dann muss der RAM-Teiler und das Mainboard die 32 Ratios unterstützten - in erster Konsequenz limitert das Speicherinterface, welches die Multiplikatoren in einem maximalen Fixvalue gestattet. Ich meine, es sind 133 MHz, weil die PC4-25600U-DIMMs überlicheweise so angesprochen werden.

Wenn der RAM mit 3300 MHz taktet dann sind die 100 MHz wahrscheinlich, denn diese ergeben sich auf den 33 Ratios, mit welcher die Baud anbinde. Theoretisch! Wie es tatsächlich ausschaut kann ich ohne die entsprechenden Values nicht sagen.
 
Zuletzt bearbeitet:
Hallo Holt,

die Defragmentierung hat den verzögerten Aufbau von dem Task-Manager um eine Sekunde verkürzt, dennoch fühlt sich die übrige Sekunde immer noch wie ungewohnt an.

Unbenannt.PNG

Ich habe alles versucht heraus zu holen; - 1.) SSD Optimizer (Online); - 2.) STEALTH (Online); - 3.) STEALTH (Offline); - 4.) SPACE (Online); - 5.) STEALTH (Online); - 6.) SSD Optimizer (Online).
Ich weiß nicht, was die übrigen Fragmente sind - womöglich gesperrte Dateien. Anstatt diese zu beseitigen kümmert sich O&O Defrag vielmehr darum, die Blöcke von innen nach außen zu befüllen, wie mir die Transparenz-Darstellung offerierte.

Die übrige Sekunde laste ich dem Prozessor an, denn das Durchhangeln durch die Ordnerstruktur offeriert schon eine abnormale Verzögerungszeit von Elementen, indessen die Cores anHALTend ausschlagen.
Ich kann es dem Online-Shop MindFactory nicht verübeln, dass er mir den Prozessor nicht reklamieren will, weil der Hersteller womöglich abermals den Händler auf seine Kosten sitzen lassen wird.

Na ja ... Zumindest habe ich den Beweis erbracht, dass die SSD mit von der Partie gewesen ist, doch zur Hälfte ist der Prozessor verantwortlich.
 
Update:
Derweil ist die durchschnittliche Prozessorauslastung auf bis zu unter 5% gesunken, im Vergleich zu am Anfang von 15% und daraufhin 10%, und die Haptik fühlt sich im Vergleich zu von davor schon etwas butterweicher an.

Unbenannt.jpg

Unbenannt 0.PNG

Zwischenzeitliches Update zur Defragmentierung


Aktuell sind 7 meiner wichtigsten Games installiert. Mit Dead Space 2 habe ich noch so mein Problem, weil zuerst wollte es meine speziell angepasste Steuerung von der "controls.rmp" nicht anwenden, bis ich gemerkt hatte, dass das Game noch ungepatcht gewesen ist, und an der ersten Speicherstation stürzte das Game ab, außerdem werden meine Spielstände nicht erkannt; alle Features meiner Collector's Edition nicht sofort abrufbar, einschließich meine geliebete Elite Advanced Suit und meine ans Maximum gepowerte RIG, Plasma Cutter etc.; "HO!! HO!! HO!!".
Mit dem Patch ist die Steuerung wieder so wie gewünscht und das Game verreckt an einer Speicherstation zwar nicht mehr, aber es speichert nicht. Zuletzt zockte ich das Game unter Windows 7, aber daran wird 's nicht liegen, weil das Kernproblem die unzureichenden Rechte in dem Benutzerverzeichnis zu sein scheinen, ergo Dokumente, Desktop etc., obwohl mir das Group Policy Object - GPO die höchstmöglichen Rechte suggeriert, was an sich nicht verkehrt sein mag, denn direkt speichern kann ich bspw. auf dem Desktop, aber indirekt, also über die Interaktion von einer Anwendung, scheint der Administrator zu meiner Benutzergruppe das Problem zu sein, auch kann ich nichts von Desktop nach Program Files verschieben, da führt nur das Kopieren zum Erfolg.
In Redstone 3 fällt mir auf, dass Microsoft den Trusted Installer von seiner Pflicht enthoben zu haben scheint, daher ich womöglich neuerdings diese Rechteprobleme habe, den praktisch alles geht an den Systemadministrator über und ist somit unerreicht für mich direkt dem Remote Procedure Call Locator - LRPC unterstellt, dafür langen die unzureichenden Berechtigungen seitens dem Distributed Component Object Model - DCOM nicht ansatzweise.

Wie ist das bei euch? Macht euch diese Änderung an der Rechteverwaltung sietens Redstone 3 auch zu schaffen?

LG,
Naru! ^^
 
Zuletzt bearbeitet:
Wenn Dateien fragmentiert sind, ist die Verwaltung des Filesystems aufwendiger und damit wird die CPU mehr belastet und auch die SSD, von der ja mehr Metadaten gelesen werden müssen. Schon von daher geht die Fragmentierung auch bei SSDs auf die Systemperformance. Was Du nun aber mit "Cores anHALTend ausschlagen" meinst und wieso die CPU reklamiert werden soll, verstehe ich nicht.
 
Gruß Holt, :)

was Du sagst ist absolut richtig!
Damit meine ich, dass die Anfragen an dem Local APIC häufig lange anstehen, also das Taktsignal lange aufrecht erhalten bleibt, bis letztendlich die Operation erfolgt. Latenz, die sich wie ein Halt auswirkt. Bei Non-Halt geht es ohne Anstellung in der Warteschlange weiter.
Der Bezug auf die CPU-Reklamation hat hiermit zu tun:
https://www.hardwareluxx.de/community/f11/intel-core-i7-6700k-vcore-gestiegen-1177889.html
Gen Ende dieses Themas stößt man dann auch auf die Verlinkung zu Dr. Windows, wo ich das aktuell zuletzt behandelte Thema um Redstone 3 behandeln ließ mit weiteren Verlinkungen zu alten Themen, der Probleme, die allesamt auf das Haupthema der hiesigen Verlinkung um die entstandenen Konsequenzen seit Redstone 2 zurückführen.

LG,
Naru! ;)

- - - Updated - - -

@Holt,

hast Du eine Wunderwaffe für mich, mit der ich dem mir unterstellten Administrator die erforderlichen Schreibrechte in den User-Folders verschaffen kann, wo nur ich als der Benutzer in dieser Benutzergruppe die Rechte erhalte?
Mich stört es total, denn Anwendungen mit administrativen Rechten - das Beispiel von MPC-BE - erhalten keine, weil der Administrator in meiner Benutzergruppe scheinbar dem Hauptbenutzer - mich - nicht gleichgesellt ist.

Unbenannt.jpg

Der Administrator in meiner Gruppe hat scheinbar Vollzugriff, aber wendet ihn nicht an.
Genau aus diesem Grund können Programme ihre Einstellungen wie Spielkonfigurationen nicht oder nur geringsfügig abrufen, zumindest diejenigen Dateien nicht ändern, die durch mich - den Benutzer - erstellt worden sind. Aber selbst wenn die betreffende Anwendung die Ordner und Dateien eigens erzeugt hat, dann geht es zwar besser, aber dennoch restriktiv.

Unbenannt 3.PNG

Meine Vermutung geht insoweit, dass das Dateisystem die Fehlerquelle ist. Gut, sehr viele Fragmente sind Ade und eine schreckliche Konsolidierung erkenne ich nicht, als dass dies zu solchen Fehlern führe.
 
Die Fragmentierung hat meines Wissens nach keinen Einfluss auf die Zugriffsrechte.
 
Es wäre mir auch neu, denn es hat eher Einfluss auf das Dateisystem, aber dass das Dateisystemfehler die Fehlerquelle ist halte ich für ausgeschlossen, weil dann hätte ich ganz andere Sorgen. ^^
Eventuell hat es damit zu tun, dass ich den Benutzernamen zu "KnSNaru" und den Computernamen zu "KnSNaru-PC" geändert habe, dieser faktisch den Namen des Benutzerordners in "knsna", womöglich ist dort das Problem, was ich habe, denn es grenzt sich stets auf die Ordner des Benutzers ein.

Eventuell helfe mir diese Prozedur doch, aber ohne zweites OS nicht machbar und anderweitige Berechtigungsprobleme und Dateisystemfehler ohne Gewähr:
https://www.drwindows.de/windows-10-desktop/135839-namen-benutzerverzeichnisses-korrigieren.html

Also die Fehlermeldung da oben klingt doch schon sehr nach einem HKEY-CURRENT/USERS-Syntax-Problem, die davon sind alle über den Administrator ausgeführen Instanzen betroffen, sei es nur das Schreiben von einer INK auf den Desktop, was grundsätzlich oder immer mit einem Fehler während dem Setup zurückgewiesen wird.
Wirklich stören tuts 's mich in Dokumente und alles darum, weil die Game-Konfigurationen sind, auch die von PCXS2; "Jaaa, ich bin seit Jahren im Besitz von Yu-Gi-Oh! - The Duelists of the Roses!", worin so gut wie gar nichts funktioniert, wegen den Schreibrechten. Dead Space 2 speichert in Dokumente die Savegames, deshalb der Savegame-Bug an einer Speicherstation.
 
Zuletzt bearbeitet:
Es steht in Anlehnung auf einen NTFS-Error! Derweil ist es obsolet!
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh