Alt.Binz forum
Alt.Binz (Other languages) => German (Deutsch) => Topic started by: mb82 on June 13, 2018, 11:52:58 am
-
Hallo,
ich möchte auf diesem Wege einmal anfragen, wenn Alt-Binz Multicore fähig wird.
Problem: Ab einem Download von ca 400.000 schaft es nicht Alt-Binz mit dem Decodierprozeß hinter her zu kommen. Hierfür wird leider nicht einmal die CPU in einem Kern ausgelastet.
Schlimmer wird es wenn ich mit 500.000 oder gar 1.000.000 downlade. Hier ist bereits der Downlad beendet, jedoch ist Alt-Binz hier noch Minuten damit beschäftigt den Decoding Prozess nach zu holen. Extrem schlimm ist die Situation, wenn die Dateien mehere (50>GB) groß sind. Hier entstehen durch den Stau auch sehr viele Decodierfehler, so daß PAR immer eingreifen muss.
Würde mich sehr über eure Hilfe freuen.
-
Hallo,
ich möchte auf diesem Wege einmal anfragen, wenn Alt-Binz Multicore fähig wird.
Problem: Ab einem Download von ca 400.000 schaft es nicht Alt-Binz mit dem Decodierprozeß hinter her zu kommen. Hierfür wird leider nicht einmal die CPU in einem Kern ausgelastet.
Schlimmer wird es wenn ich mit 500.000 oder gar 1.000.000 downlade. Hier ist bereits der Downlad beendet, jedoch ist Alt-Binz hier noch Minuten damit beschäftigt den Decoding Prozess nach zu holen. Extrem schlimm ist die Situation, wenn die Dateien mehere (50>GB) groß sind. Hier entstehen durch den Stau auch sehr viele Decodierfehler, so daß PAR immer eingreifen muss.
Würde mich sehr über eure Hilfe freuen.
Hi mb82
Ich vermute das Problem weniger bei AltBinz, als vielmehr in der Hardware oder eventuell in einer Kombination aus Hardware und Einstellungen der Software.
1. Bei den Geschwindigkeiten kann es durchaus sein, dass die Festplatte nicht hinterher kommt (bzw der Controller an dem sie angeschlossen ist,).
2. Hängt dies auch von der Grösse der einzelnen rar Dateien ab. Schau bitte mal in den Optionen unter "Download #2" im Abschnitt "Artikel Caching". Wenn du genug RAM hast, solltest du hier auf jeden Fall das Maximum von 2000MB einstellen. Dateien bis zu dieser Grösse werden dann im RAM gehalten, bis sie decodiert sind (oder die eingestellte Zeit abgelaufen ist). Sind die Dateischnipsel die du runter lädst grösser als der hier eingestellte Wert, werden entsprechend die älteren Teile der Datei auf die Festplatte geschrieben, während laufend neue Daten in den RAM geladen werden. Beim Decodieren wird dann von der Festplatte gelesen, das Decodierte darauf geschrieben und eventuell noch neu eintreffende Teile ebenfalls auf die Platte geschrieben. Hier kann schnell ein Flaschenhals entstehen.
3. Darüber hinaus kannst du mal ausprobieren, unter "Download" den Temp Ordner und den Downloadordner auf verschiedene Festplatte zu legen (Festplatten, nicht Partitionen die auf ein und derselben Festplatte liegen). Ebenfalls kannst du, wenn vorhanden, den Entpackordner ebenfalls auf eine weitere (dritte) Festplatte zu legen.
4. Die Optionen "Download während der Reparatur (und/oder dem Entpacken) könnten ebenfalls hilfreich sein.
5. Dass die PAR2 Reparatur anspringt wird wohl weniger am Decodierprozess liegen, als viel mehr daran, dass die Dateien tatsächlich lückenhaft sind, wenn du sie herunter geladen hast.
(6. Ich hatte ein ähnliches Phänomen mit einer älteren Version mehrmals gehabt, aber nicht immer, sondern nur bei grossen Parts. Da musste ich dann zwischendurch manchmal pausieren, bis sich alles etwas beruhigt hatte.)
7. Ob und wie weit sich der Decodierprozess auf mehrere Kerne verteilen lässt, oder ob dies dein Problem wirklich abstellen würde, kann ich nicht beurteilen.
8. Meist ist es auch hilfreich, wenn man weiss, welches OS genutzt wird, auf welchem Prozessor, mit wieviel RAM und mit welcher AltBinz Version, so als Mindesthinweise...
Probier das mal aus...
-
Danke für das feetback Sucker76
Versuche dieses hier so kurz wie möglich zu halten.
ZU:
1-Raid 0 4xNVME Samsung 970 Pro je 512 GB (Datendurchsatz je NVME PCI3 4x mehr als genug)
2-Rar Dateien von 100 bis 280 MB (egal welche Größe - Dekodierprozess mit gleichbleibender Geschwindigkeit)
2-2000MB JA
3-Temp Ordner auf einer weiteren NVME PCI3 4x direkt an CPU
4-Ändert nur die Warteschleife auf den momentanen Download (sonst auf allle) also nur die Anzahl,
ansonsten ist das Problem weiter vorhanden
5-Ich kann nachweisen, das durch die endlos-Warteschlange Alt-Binz nicht mehr in der Lage ist nach dem Dekodieren alle dateien als fehlerfrei zu identifizieren. (Zu Prüfen in den man in den Downloadordner Par manuel ausführt. Dort bestätigt Par das alle Dateien Fehlerfrei sind, jedoch Alt-Binz (/gelb) also Fehler erkennt.
6-Hierzu kann ich nur sagen, das all diese Probleme ab einer Downloadgeschwindigkeit von mehr als 50MB/s auftritt. Also ab den Zeitpunkt wo der Download dem Dekodierprozess davon läuft
7-Leider kann Alt-Binz nur mit einem Kern dekodieren (----SCHADE----) Sonst würde dieses Problem nicht exestieren.
8-Getestet auf WIN8 32MB RAM Ryzen 8 Kerne
8-Getestet auf WIN10 16,32,64MB mit Sockel x470 (Ryzen 2700x)
8-Getestet auf WIN10 32,64,128MB mit Sockel x399 Threatripper
Sorry für die Länge der Darstellung
-
Hi.
Ausführlich ist ja gut bei so was.
Punkt 7, ist richtig, ja, es wird nur ein Thread zum Decodieren genutzt. Deshalb schrieb ich, dass ich nicht weiss inwiefern sich das programmatisch ändern lässt.
Punkt 5, nun ja, dazu kann ich nur Vermutungen anstellen, glaube aber eben nicht, dass das eine etwas mit dem anderen zu tun hat. Vielleicht hat AltBinz schon repariert, wenn du das im Ordner von Hand prüfst?
Hast du es mal mit einem anderen Programm ausprobiert (nur um zu sehen ob es da anders läuft)?
Aber wie dem auch sei, es gibt die Möglichkeit einen Feature Request (https://www.altbinz.net/forum/requests/) abzusetzen, wenn es möglich ist setzt rdl solche Wünsche eigentlich immer gerne um.
-
6-Hierzu kann ich nur sagen, das all diese Probleme ab einer Downloadgeschwindigkeit von mehr als 50MB/s auftritt. Also ab den Zeitpunkt wo der Download dem Dekodierprozess davon läuft
P.S.: Ich weiss sicher, dass selbst ältere Versionen von AltBinz bis mindestens 200MBit/s die von dir beschriebenen Probleme NICHT haben (selbst mit nur einer Festplatte).
Vielleicht kann dir einer der Windowsnutzer weiter helfen, oder du versuchst es mal noch im englischsprachigen Teil.
-
Hallo,
hab das mal bei Google nachgesehen: 50 MB/s sind 400 Mbit/s.
Hatte mb82 ja auch am Anfang geschrieben: Ab 400.000 gehen die Probleme los.
-
Hallo,
hab das mal bei Google nachgesehen: 50 MB/s sind 400 Mbit/s.
Hatte mb82 ja auch am Anfang geschrieben: Ab 400.000 gehen die Probleme los.
;D
Da hast du natürlich Recht, hatte das als 50Mbit gelesen, mein Fehler.
Dann bleibt immer noch die Möglichkeit des Feature Request.
Vielleicht sollte sich der TE hier mit ranhängen: https://www.altbinz.net/forum/requests/using-advanced-cpu-features-like-sse2ssse3avx-to-speed-up-article-decoding/msg30471/#msg30471
-
Hi mb82,
hast Du in den Einstellungen mal testweise die Priorität des Decodierprozesses höher gestellt?
-
Ja, dieser steht auf Timecritical.... ändert leider nichts an der Decodiergeschwindigkeit.
Habe selbst alle Variationen die möglich sind versucht.
-
Hallo,
kann das leider aus verschiedenen Gründen nicht ausprobieren.
Aber ich würde folgendes versuchen:
Artikel-Caching ausschalten (weil wenn der Cache voll ist es eventuell Verwaltungsengpässe gibt),
In einer RAM-Disk den Temp-Ordner einrichten (in einem 64-bit-System mit 36 GB-Ram kann die RAM-Disk richtig fett sein)
Altbinz-LAA-Version benutzen (das 32-bit-Programm kann dann den Speicher besser nutzen und ist dadurch vermutlich schneller)
-
Hi,
Was bewirkt diese LAA Version eigentlich genau und was sind die Vor- und Nachteile?
Beste Grüße
Christian
-
Moin,
Keine Ahnung, aber Google und etwas Mut--->>>http://www.3dcenter.org/artikel/das-large-address-aware-flag,
bei diesem Fazit
Zitat Anfang
Es ist erstaunlich, dass diese einfache Methode ohne gravierende Nachteile – bei moderner Softwareentwicklung – nicht viel breitflächiger eingesetzt wird. Wir würden uns wünschen, dass mehr Entwicklerstudios darauf aufmerksam werden, gerade wenn sie noch keine 64-Bit-Versionen zur Verfügung stellen wollen.
So lange kann man oft schon durch manuelles Setzen des Flags vielleicht einen Performancevorteil ergattern, wenn das Spiel mitmacht. Viel Spaß beim Ausprobieren!
Zitat Ende
Ich verwende das LAA-Altbinz bei meinem 64-bit-Windows mit 16Gb Ram bis jetzt ohne Probleme.
Einen schönen Tag noch
-
Nochmal Moin,
Oder einfach mal hier schauen -- https://www.altbinz.net/forum/new-alt-binz-versions/alt-binz-0-45-1/ , #13.
Demnach waren wohl die alten Altbinz-Ausgaben LAA-Versionen.
Je mehr Informationen ich habe umso weniger versteht ich.
Schönen Tag noch
-
Je mehr Informationen ich habe umso weniger versteht ich.
So geht es mir auch. Wenn die alten Versionen LAA waren und dies eigentlich die bessere Lösung ist, warum dann jetzt zwei?
Oder ist es so, dass bei 32 Bit Systemen besser die nicht LAA und bei 64 Bit Systemen besser die LAA Version genutzt wird?
-
In English, so someone could translate it:
LAA flag allows 32bit applications (which alt.binz is) to use up to 3GB of memory(instead of 2GB) on both 32bit and 64bit system. However, when flag is enabled, correct pointer handling is crucial. We've already discovered one bug related to it and it was fixed. But I am not 100% sure there are not more bad pointer handling. Lately, few users had problems with Windows 10 and updates. I am not sure if it's related, so I've decided to revert to normal no-LAA state (with 2GB process limit and no risk of bad pointer handling). But then certain users requested LAA flag back, so I've released both versions.
Regarding decoding speed, I'll try to make new version all about decoding improvements. So far, based on tests, there is huge potential for major improvement in speed...
-
Thanks Rdl!
Hier die Übersetzung:
Das LAA Flag erlaubt 32bit Anwendungen (was alt.binz ist) bis zu 3GB Speicher (statt 2GB) auf 32bit und 64bit Systemen zu verwenden.
Wenn das Flag jedoch aktiviert ist, ist die korrekte Handhabung des Zeigers (Verzweigungen?) entscheidend. Wir haben bereits einen Fehler entdeckt, der damit zusammenhängt, und er wurde behoben. Aber ich bin mir nicht 100%ig sicher, dass es nicht noch mehr schlechte Zeigerbehandlung gibt.
In letzter Zeit hatten nur wenige Anwender Probleme mit Windows 10 und Updates. Ich bin mir nicht sicher, ob es damit zusammenhängt, also habe ich beschlossen, zum normalen No-LAA-Status zurückzukehren (mit 2 GB Prozesslimit und keinem Risiko einer schlechten Zeigerbehandlung). Aber dann haben einige Benutzer das LAA-Flag zurückgefordert, also habe ich beide Versionen veröffentlicht.
Was die Dekodiergeschwindigkeit angeht, werde ich versuchen, eine neue Version zu erstellen, in der es um Verbesserungen beim Dekodieren geht. Bisher gibt es, basierend auf Tests, ein enormes Potenzial für eine deutliche Verbesserung der Geschwindigkeit....
-
https://www.altbinz.net/forum/new-alt-binz-versions/alt-binz-0-46-0/ (https://www.altbinz.net/forum/new-alt-binz-versions/alt-binz-0-46-0/)
-
Thanks so much Rdl for improving your programm.
It was a right decision to stick at you.
Love your coding !!!! :-*
-
Hi, ich hätte einen kleinen Tipp/Workaround für euch!
Ich bin seit heute auch endlich in den Genuss einer 1Gbit Leitung gekommen und bin auf das selbe Problem gestoßen.
Der Decoder, der 0.46.0.1 Version, Leistet Ausgezeichnete Arbeit, aber wenn ich ohne Limit lade, dann Kommt er nicht mehr mit.
Z.B. haben sich ca. 10 250 MB große Datein gestaut, gefühlt werden die Datein 4 mal schneller geladen als dekodiert. Sobald man auf Pause drückt werden die Datein in wenigen Sekunden dekodiert - ergo, der Download-thread stört den Dekodierprozess!
Nun zum Trick der mir ein wenig geholfen hat:
Die höchste Donloadrate mit der Gbit Leitung lag bei mir bei 78 MByte/s.
Im Setup hab ich unter Connection / Maximum download speed - 102400 kb/s eingestellt.
Wenn ich nun im Limiter 80% einstelle, dann komme ich auf glatte 80 MB/s (102400 kb/s damit es glatte 10 MB schritte sind) also etwas mehr als mein erreichter Peak.
Das interessante ist jetzt, dass der Dekodierprozess sich jetzt die Wage hält und keinen Stau mehr verursacht.
Ich vermute mal, dass der Decoder dann einfach, durch das Limit, mehr CPU-Zeit bekommt und so seine Arbeit, wie gewünscht, verrichten kann.
Für mich funktioniert das bis jetzt recht gut, auch wenn ich nicht ganz an die Geschwindigkeit komme wie ohne Limit,
aber evtl. ist das auch gar nicht auf andere Setups übertragbar :/
Nach 4 h beobachten und probieren, komme ich auf 60-70 MB/s ohne dass es sich staut.
Hoffe dass euch das ein wenig weiter hilft, und sagt mir bitte, was ihr davon haltet!
Mein Setup: i7 8700k 32GB RAM davon 20GB RAM-Disk (Romex), die fürs TEMP Verzeichnis da ist,
um die SSD nicht unnötig zu belasten. Download Laufwerk 960 EVO, Unrar Laufwerk 970 EVO.
Grüße,
abismo
-
UPDATE:
Nach dem Update auf 0.47 (Neuinstallation) und einem Upgrade der Hardware (i7-9700k@5GHz), hab ich keine Flaschenhälse mehr.
Dowload Rekord bei 96 MB/s (nachts) bei Instant decoding. :o
Evtl. hatte ich vorher einen Konfigurationsfehler, der durch die Neuinstallation behoben worden ist.
Danke nochmal für die kontinuierlichen Updates :)