m.2 verkehrte einstellung / bug oder noch nicht vollständig unterstüzt?

Aktuelle Version: 12.25 (29.09.2021)
Alles zum Thema Directory Opus
Antworten
Benutzeravatar
Nobmen
Boardbetreuer
Beiträge: 1959
Registriert: 26. Jun 2004 08:48
Betriebssystem: Win 10 Home/Pro 32/64bit
DOpus Version: 12.xx + Betas
Edition: Pro
Kontaktdaten:

m.2 verkehrte einstellung / bug oder noch nicht vollständig unterstüzt?

Beitrag von Nobmen »

seit paar monaten ist ein neues system mit 3x m.2 steckkarte vorhanden (keine hdd/ssd mehr)
bis heute war es nicht möglich, monatelang verschiedenes getetest, die mögliche schreibgeschwindigkeit von 3gb/s in dopus zu erreichen.
Zwischenablagebild (2).jpg
andere dateimanager schaffen mehr in der schreibleistung (im ø 300 bis 600mb mehr)
die schreibleistung wurden von verschieden testprogrammen mit fast identischen werten bestätigt.
Zwischenablagebild (4).jpg
je größer die datei um so mehr stockt die anzeige
hier scheint der cache (copy buffer size, derzeit 512kb) dafür nicht ausreichend zu sein
oder die copy_nonbufferio_thresold (derzeit 0) passt nicht.
welche werte müssten bei den beiden vorgenommen werden um das richtig ein zu stellen.
verschiedene werte wurden schon ohne verbesserung geprüft.

aus hilfe:
Puffergröße kopieren. Einheiten können KB, MB oder GB sein. Wenn keine Einheiten angegeben sind, standardmäßig auf KB.

Dies gibt den Datenbetrag an, den OPUS beim Kopieren von Dateien sofort gelesen oder schreiben. Obwohl es nicht egal ist, scheinen einige USB-Geräte oder Netzwerke auf die Größe des Kopierpuffers zu empfindlich zu sein. Wenn Sie feststellen, dass Kopien viel langsamer oder weniger zuverlässig sind, als Sie erwarten würden, nehmen Sie die Vergrößerung oder Verringerung der Puffergröße an.

Das Bufsize-Argument des Kopierbefehls kann verwendet werden, um diese Einstellung auf einzelnen Schaltflächen, Hotkeys usw. zu überschreiben.

Dieser Puffer ist zusätzlich zu jeder Pufferung, die vom Dateisystem, der Hardware usw. bereitgestellt wird; Es ist nicht mit dem nicht gepufferten IO-Modus verbunden, der von der Einstellung COPY_NONBUFFERIO_THRESHOLD gesteuert wird.
Benutzeravatar
tbone
Berater
Beiträge: 710
Registriert: 22. Nov 2014 21:16
Betriebssystem: 7*64

Re: m.2 verkehrte einstellung / bug oder noch nicht vollständig unterstüzt?

Beitrag von tbone »

Mhh, ich finde 2gb/s nicht schlecht. o) Ich schaffe nur 250mb mit meinem SATAII-Board.. o) Dein Vorgang, ist ja eine "real life" Aktion, bei der Lesen einer Datei-X und Schreiben einer anderen Datei-Y "gleichzeitig" passiert. Wenn Du mit CrystalDiskMark das Schreiben benchmarkst, kommen die Daten aus dem RAM, nicht von einer anderen Datei die erst eingelesen werden muss, das muss also theoretisch langsamer sein, wieviel langsamer ist schwierig zu sagen.

Ich weiß nicht was andere FileManager hier an Performance bieten, ich würde mich auf die Anzeige X gb/s auch nicht verlassen, sondern die Zeiten mal vergleichen. Da sind einige Puffer in der Kette (z.B. Controller+Chip auf der M.2, Treiber, Filesystem, Windows-Cache, DO) die solche Anzeigen verfälschen können.

Ist nur eine These, ich upgrade erst, wenn AMD einen neuen Sockel bringt.
Ich bin mit der neuesten Hardware und was mit dieser normal und möglich ist längst nicht auf dem Laufenden.
Benutzeravatar
Nobmen
Boardbetreuer
Beiträge: 1959
Registriert: 26. Jun 2004 08:48
Betriebssystem: Win 10 Home/Pro 32/64bit
DOpus Version: 12.xx + Betas
Edition: Pro
Kontaktdaten:

Re: m.2 verkehrte einstellung / bug oder noch nicht vollständig unterstüzt?

Beitrag von Nobmen »

aus ram?
das programm erstellt auf dem eingestellten laufwerk (bei mir egal weil alle das gleiche produkt)
eine datei (wird nach testende automatisch gelöscht) die je nach eingestellter testgröße die geschwindigkeit ermittelt.
hier mal das testergebnis mit der 64gb datei.
datei.jpg
datei.jpg (6.43 KiB) 238 mal betrachtet
Zwischenablagebild.jpg
wenn es die 2gb/s dauerhaft geben würde wäre das ja akzeptabel,
nur liegt das meistens zwischen einem ø wert von 700mb/s bis 1400mb/s je nach dateigröße mit dopus
während andere dateimanger unter windows 10 (aktueller stand) darüber liegen?
test mit gleicher datei(en) und laufwerken vollzogen.

das thema ist aber nicht neu.
habe mittlerweile etwas nach einiger suche von 2016/2018 im gp forum dazu gefunden.
aussage dazu war, man soll mit den 2 erwähnten werten rumtesten.
Benutzeravatar
tbone
Berater
Beiträge: 710
Registriert: 22. Nov 2014 21:16
Betriebssystem: 7*64

Re: m.2 verkehrte einstellung / bug oder noch nicht vollständig unterstüzt?

Beitrag von tbone »

Ja, aus dem RAM. Die Datei wird aus dem RAM mit Dummy-Daten erst erstellt.. dann wird daraus gelesen und dann wird reingeschrieben und beide Prozesse werden nacheinander, separat gemessen. Das ist also mit einem FileCopy bei dem zwei Dateien beteiligt sind nicht direkt zu vergleichen und bringt daher eine andere Performance, vor allem wenn nur 1 Laufwerk beteiligt ist.

Wenn DO mit vielen kleineren Dateien eine andere Performance aufweist als Explorer und andere, kann es an den zusätzlichen Attributen liegen die da kopiert und abgeglichen werden, (ACL + ADS und Setzen der Timestamps bspw.). Aber zugegeben, das ist schwammig und ich will nicht ausschließen, dass es mit DO auch schneller gehen könnte. 700-1400 mb/s finde ich auch noch durchaus akzeptabel, wenn unterschiedlich große/kleine Dateien betroffen sind. Dass die Performance einbricht, wenn man Fitzel-Dateien kopiert, das war ja auch schon immer so. Viele Files öffnen/schließen, Puffer anfordern/freigeben etc. ist immer langsamer als eine riesen Datei durchzuschleifen und die Bandbreite auch ausnutzen zu können.
Benutzeravatar
Nobmen
Boardbetreuer
Beiträge: 1959
Registriert: 26. Jun 2004 08:48
Betriebssystem: Win 10 Home/Pro 32/64bit
DOpus Version: 12.xx + Betas
Edition: Pro
Kontaktdaten:

Re: m.2 verkehrte einstellung / bug oder noch nicht vollständig unterstüzt?

Beitrag von Nobmen »

infos zu dem bild der geschwindigkeit im eingangs thema für besseres erklären warum es mir derzeit zuwenig erscheint.
die erste datei war eine große datei mit 12gb = max speed angabe 2gb/s
hier müsste doch eigentlich schon ein höherer wert stehen.
dopus (steht derzeit wieder auf copy buffer 512kb) verwendet daher vermutlich die q1t1 (anzeige im testprogramm, blockgröße 512kb = 2gb/s)
und nicht die q8ti (blockgröße 1024kb = mögliche 3gb/s)
auch die letzte datei war 5gb groß.
dazwischen dateien ab min. 2gb bis zu der 12gb.
kopiert wurde mit der funktion "nur die fehlenden kopieren"
aus der gesamtanzahl waren es 45 dateien (8 minuten für 175gb)
wenn bei der ersten (max. 2gb/s) und der letzten datei (aktuell 2gb/s) angezeigt wird
und zwischendrin die erwähnten kleineren werte, läuft möglicherweise etwas beim buffern durch dopus schief.
andere tätigkeiten auf dem system (32gb ram) waren außer dem kopieren nicht aktiv.

werde aber bei den nächsten großen abgleich den copy wert auf über 1024 KB/1 MB stellen.
(die schon erhöhten werte, standard 512 KB, zeigten beim testen keinen unterschied)
ebenso versuchsweise den anderen wert von 0 auf 1 MB.

es stellt sich auch die frage warum das überhaupt eingestellt werden muss.
eine vermutung ist, das dies noch aus windows xp zeiten war, das ja ab der 12.20 version nicht mehr unterstützt wird.
option, ab winwdos 7 (Vista unterstützung unbekannt), nicht mehr nötig = entfernbar?

da andere dateimanger! so eine einstellung (die geprüften, option nicht gefunden)
nicht haben könnte das schon der grund sein warum diese schneller kopieren.
Benutzeravatar
tbone
Berater
Beiträge: 710
Registriert: 22. Nov 2014 21:16
Betriebssystem: 7*64

Re: m.2 verkehrte einstellung / bug oder noch nicht vollständig unterstüzt?

Beitrag von tbone »

Am Besten schreibt man ein Programm und probiert mal selbst aus, was unterschiedliche Puffer für Auswirkungen haben. Aber macht man das in C++ so wie DO, oder in .Net, was vermutlich viele Windows-Programme derzeit nutzen? Ein identischer Puffer kann hier in beiden Umgebungen vermutlich wieder andere Ergebnisse haben.. das wird also mit einem einzigen Testprogramm dann auch wieder nichts. o)

Um so nah wie möglich an das CrystalDiskMark heranzukommen, könntest Du auch mal eine RAM-Disk einrichten und diese beim Kopieren verwenden, vielleicht macht das irgendwo einen Unterschied.. der dann weitere Ideen bringt.

Ich habe die Puffer in DO noch nie angepasst, mein Flaschenhals ist immer das Gbit-LAN, wenn ich um die 100 mb/s liege, bin ich "zufrieden", weil technisch nicht mehr drin ist damit. Lokal kopiere/synce ich sehr selten und ich will nochmal auf das Thema "Zeit" hinweisen.. die Speed-Anzeigen können Dir sonstwas erzählen, egal wo und mit welchem Programm. Daher müsste ansich eine Stoppuhr her und dann selber ausrechnen, wieviele mb/s da jeweils tatsächlich durchgenudelt wurden.

Dass Du mit einem 0.5 mb oder einem 1 mb Puffer keinen Unterschied feststellen kannst, scheint mir fast logisch, das ist zu nah aneinander. Wenn ein "Read()" und ein "Write()" Aufruf jeweils eine Millisekunde Overhead haben (rein theoretisch), braucht der Vorgang mit 0.5 mb Puffer eine Sekunde länger bei einer 1 gb Datei im Vergleich zum 1 mb Puffer und 5 Sekunden länger bei 5 GB etc.. und dabei ist es egal mit welchem Dursatz der Transfer läuft. Eine Millisekunde als Overhead ist vermutlich viel zu lange, daher dürfte das wirklich keinen merkbaren Unterschied geben, wenn der Puffer nur doppelt/halb so groß ist. Unter Umständen gibt es einen Sweet-Spot was die Puffergröße angeht, in der das Lesen/Schreiben dann "harmonisch schwingt" und den besten Durchsatz gibt, aber sich an dieses Optimum heranzutasten, was mit jeder Software/Hardware anders ist, wäre Aufgabe einer Automatik, das versuchsweise mit der Hand zu optimieren scheint mir wenig zielführend.
Antworten