Xtreme Entwicklung - early alpha test thread

[Stulle]

Joa, sonst könntest nicht mehr so gut leechen, was¿ *OMFG*

MFG Stulle

[Xman]

da ich kein Powershare für partfiles hab und auch keine multiple friendslots brauch ich kein ratio das irgendetwas anders berücksichtigt als dies der offizielle emule tut.

Den min Upload auf 11 heraufzusetzen ist eine logische Konsequenz, da der gesamte Overhead im Uploadlimit berücksichtigt wird (im offiziellen emule ist das ebenso, allerdings wird hier nur weniger als die hälfte des Overheads erfaßt).

Falls jemand Einwände gegen das Heraufsetzen des min Uploadlimits hat oder irgendwelche Nachteile sieht so möge er sich melden

[Stulle]

Also ich find es sicher nicht schlecht, war nur ne Idee, weil ich eigentl. von der Funktionsweise die session based-ratios besser finde, da sie bis zu dem Punkt wo das Limit erreicht ist keine Limitierung mit sich bringt.
Aber hey, du bist der Boss! Und vor allem weiß du wesentl. besser was du tust als ich!

MFG Stulle

[Paul 2]

Den min Upload auf 11 heraufzusetzen finde ich ok.

der Upload läuft super, hatte noch nie so wenig fehlgeschlagene UL, lag sonst immer bei 4-6 %, beim original Muli ca. bei 15 %.
Laufzeit 30 Std.

eMule v0.45b alpha4.5 Statistik [***]

Upload Sessions: 141
Erfolgreiche Upload-Sessions: 138 (97.87%)
Fehlgeschlagene Upload-Sessions: 3 (2.13%)
Durchschnittlicher Upload pro Session: 6.72 MB
Durchschnittliche Upload-Dauer: 56:38 Minuten
Totaler Overhead (Pakete): 66.79 MB (1.36M)
Overhead durch Dateianfragen (Pakete): 29.49 MB (975.20K)
Overhead durch Quellenaustausch (Pakete): 9.44 MB (4.05K)
Overhead durch Server (Pakete): 102 KB (4.64K)
Kad Overhead (Pakete): 0 Bytes (0)

[evil]

lieber xman .. ich wäre dir wirklich sehr verbunden wenn du die kompletten src files endlich online stellen würdest ... (anstatt die unkompletten .. um es mal so zu sagen)




Die src Files sind nicht komplett vorhanden .. aber sie sind vorhanden ..
nur warum nicht komplett ..? Um eine abwendung deinerseits zu vermeiden ..

Ich würde denen Code nun gerne mal als Basis benutzen ...
Am allerhellsten würde natürlich die Final vor meiner Nase leuchten ...

[Rumpelzuck]

Hi Xman,

ich habe jetzt auch für ca. 3 Tage deine Alpha45 laufen lassen und nun ein paar Rückmeldungen über meine Beobachtungen dabei, auch speziell im Vergleich zum Morph Mod, den ich sonst meist einsetze.

Alpha45 Muli läuft stabil, keine Abstürze oder Prozessorvolllastphasen trotz teilweise provozierender Rumklickerei in den Mulifenstern , weniger Prozessorzeit- und Speicherverbrauch als bei Morph 6.7.

Upload läuft stabil und hält sich weitestgehend an die Slotspeedeinstellung, solange man nicht zu dicht an die aktuell für den Muli nutzbare Uploadbandbreite stößt. Während ich bei 0-Down noch so 25,8 Upload einstellen konnte, ohne dass die Regelung versagte, mußte ich bei stärkerem Download das Uploadlimit doch was runterdrehen, sonst versagte die Regelung von Slotspeed und die Uploadlinien wurden sehr zackig.
Bei ca. 50-Down auf 25 Uploadlimit und bis auf 24,5 UpLimit bei noch mehr Download, dann blieb auch der Upload gleichmäßig.
Mir ist aufgefallen, dass in meiner 24 Stunden Dfü-Netzwerkstatistik die gesendete Datenmenge in den letzten 3 Tagen immer (egal ob mit max. Uploadeinstellung oder auf 25 begrenzt) ca. 50-100 MB geringer als an den Morph Tagen war, das ist doch ein spürbarer Teil meines täglichen Uploads. Auch die Uploadwerte in den Mulistatistiken waren etwas kleiner als beim Morph.
Halte ich mal bei den nächsten Mulisessions mit anderen Mods genauer im Auge, ich bin halt ein Uploadfan, alles muss raus.

Download lief ebenfalls sehr gut für meine Verhältnisse, bei meinen geringen Quellenzahlen kann ich da aber nicht mit Rekorden dienen, obwohl rein subjektiv der Download vielleicht noch etwas besser als beim Morph war. Gefundene Quellenanzahl war jedenfalls vergleichbar zum Morph. Auch Download von einer mir schon länger bekannten problematischen (aber leider einzigen vollständigen) Quelle klappte.

Aufgefallen ist mir die etwas mangelhafte Funktion beim "Download in alphabetischer Reihenfolge" innerhalb der Mulikategorien. Keine Ahnung ob das hoffentlich nur vom offiziellen Muli geerbt ist und nicht doch vom Xman-Downloadmanager stammt?
Das tats jedenfalls nicht so toll, selbst vollständige Quellen für die alphabetisch erste Datei wurden oft bei weiter hinten liegenden Dateien als Quelle einsortiert. Auch die praktischen Ergebnisse waren mies, die ersten beiden Dateien wurden nicht fertig, aber welche mittendrin (gemäß alphabetischer Sortierung). Die Quellen waren im Prinzip für alle Dateien ähnlich, 2 vollständige für alle Dateien und ca. 30 Quellen insgesamt mit unterschiedlichem Stand je nach Datei. Alle Dateien wurden mit Prio Auto (Hoch) geladen.

Im Morph verwende ich für die gleichen Dateien erst die Sortierung nach Alphabet, dann die Zuordnung der "Linear Priority" Werte für einzelne Dateien und die Download Methode "gestapelte Sourcen" , dann klappt die Quellenzuordnung ganz gut und auch das praktische Ergebnis überzeugt.

Insgesamt gefällt mir dein Mod sehr gut, er ist auch gut für Anfänger geeignet oder Leute, die einfach nur downloaden wollen ohne sich groß mit speziellen Details beschäftigen zu wollen.

Ciao
Rumpelzuck

[Xman]

mensch.. das ist so viel... bevor ich jetzt weiterlese fang ich mal mit antworten an

mein Mod untersützt gar kein "download in alphabetischer Reihenfolge". Die Quellen werden immer gleichmäßig(hohe Prioritäten bevorzugt) verteilt. Ich hab das Feature noch gar nie benutzt... muß sogar gestehen: noch gar nicht gefunden. Wo stellt man das denn ein ? Das muß ich nämlich noch entfernen.

Zu Deinem Upload:
Ich bin mir noch nicht sicher, ob ich die ACK-Packete richtig zähle. Leider konnte ich das noch nicht zu genau testen, da es dafür einen hohen Download braucht, was wiederum Zeit benötigt. Doch mein Mod läuft dank des vielen testens meist nicht länger als ein paar Stunden. Es sollte aber zumindest genauer funktionieren als Uploadreduction.
Möglicherweise sind es aber gar nicht die ACK-Packete die zu wenig gezählt werden. Es gibt ein anderes Problem welches schwieriger in Griff zu bekommen ist: nehmen die Clients brav das gewünschte ab, so ist bei mir die gelbe Linie nur sehr wenig über der weißen. Ist aber ein oder mehrere problematische Clients dabei erzeugen diese zusätzlichen Overhead - die gelbe Linie wird zackig und ist wesentlich weiter von der Weißen entfernt. Hintergrund dafür ist, daß sich der interne Socketbuffer füllt und erst später recht viel auf einmal versendet, und das dann mit zusätzlichem Overhead. Das Problem dabei ist... sobald ich ein Packet in den Socketbuffer gestellt hab gilt er für emule als versendet und ich hab keine Kontrolle mehr darüber. Windows übernimmt dann die Kontrolle darüber und entscheidet wie und wann gesendet wird. Ich hab probiert den Socketbuffer zu verkleinern was den benannten Effekt verminderte. Allerdings geht das auf Kosten des Datendurchsatzes zu einzelnen Clients. Mit anderen Worten: eine höhere Slotspeed wird erschwert.
Zu empfehlen ist eh eher eine kleine Slotspeed (nicht höher als 4kbs)... daher auch mein default-wert von 2.8
Generell besteht das Problem, daß emule nur auf OSI-Schicht 7 (Anwendungsschicht) arbeitet.. auf das Darunterliegende besteht kein Einfluß. So weißt Du in emule auch nicht, wieviele Retransmissions vorgenommen mußten, da die Packete fehlerhaft empfangen wurden.
Bezüglich diesen 100MB welche Dir in Deiner DFÜ-Netzwerkstatistik fehlten kann ich Dir nur sagen: Du weißt nicht ob das Uploaddaten oder Overhead waren. Du weißt nicht mal ob TCP oder UDP, ob Retransmissions, ACK-Packete oder sonst irgendwas. Als Tipp: der offizielle emule hat noch einen deftigen Bug im zz-Downloadmanager bezüglich UDP-Filereaskpings... UDP-Packete zur Datei-neuanfrage sollten frühstens nach 28 Minuten emule-Laufzeit stattfinden. Schaust Du in die Statistik vom offiziellen emule wirst Du bereits nach einigen Minuten sehen, daß er UDP-Neuanfragen startet.
Noch ein Tipp: der offizielle emule arbeitet mit doublesendsize. Das bedeutet, daß immer zwei Packete auf einmal versendet werden. Das soll eigentlich rein theoretisch den Overhead vermindern, da so nur ein ACK-Packet zurückgesendet werden muß. Tatsächlich vergrößert es bei mir allerdings den Overhead (gelbe Linie). Allerdings kannst Du damit eine höhere Slotspeed geben. Probier es selbst was bei Dir am besten funktioniert, doublesendsize oder einfache.

Auch wenn ich momentan mit dem Upload des Xtremes wirklich zufrieden bin, es wird immer etwas zu verbessern geben.


Edit:
ok, hab den Code und die Einstellungen für Download in alphabetical Order gefunden. Da das mal ein Code ist der modular aufgebaut ist, sollte er sich eigentlich ohne weiteres in den Xtreme-Downloadmanager integrieren lassen. Das darfst du dann in der nächsten Version testetn


Edit 2:
Ich hab heute mal mit >180 kbs runtergeladen (danke an den Tipp @Paul2).. die ACk-Packete wurden hier definitiv richtig gezählt.
Den Downloadmanager hab ich auch in manchen Teilen umgeschrieben... war doch mehr Aufwand als zunächst gedacht.. sollte nun aber auch mit linearer Prio funktionieren.

[daenemark]

eMule v0.45b alpha4.5 Statistik [[MK.L]daenemark on x3alpha 4.5]

Transfer
   Session UL:DL Ratio: 1 : 1.28
   Session UL:DL Verhältnis (ohne Freundesupload): 1 : 1.28
   Gesamte UL:DL Ratio: 1 : 1.24
   Uploads
      Session
         Hochgeladen: 9.84 GB
         Hochgeladene Daten durch Freundesuploads (Session): 0 Bytes
         Aktive uploads/nötig um Bandbreite auszunutzen: 6
         Gesamtanzahl der Uploads: 8
         Wartende Uploads: 3468
         Upload Sessions: 1623
            Erfolgreiche Upload-Sessions: 1558 (96.00%) (active: 8, socket: 210, completed: 1252, cancelled/ended: 86, different file: 0, exception: 2, others: 0)
            Fehlgeschlagene Upload-Sessions: 65 (4.00%) (socket: 36, completed: 0, cancelled/ended: 28, different file: 0, exception: 1, others: 0)
            Durchschnittlicher Upload pro Session: 6.46 MB
            Durchschnittliche Upload-Dauer: 23:45 Minuten
         Totaler Overhead (Pakete): 313.55 MB (6.52M)
      Gesamt
   Downloads
      Session
         Heruntergeladen: 12.58 GB
         Beendete Downloads: 25
         Aktive Downloads: 15
         Gefundene Quellen: 3853
         Download Sessions: 3127
            Erfolgreiche Download Sessions: 2543 (81.3%) (active: 15, paused: 0, no needed part: 156, timeout: 504, socket: 784, out of part: 1078, exception: 0, others: 6)
            Fehlgeschlagene Download Sessions: 584 (18.7%) (paused: 0, no needed part: 13, timeout: 192, socket: 363, out of part: 12, exception: 1, others: 3)
            Durchschnittlicher Download pro Session: 5.07 MB
            Durchschnittliche Downloadzeit: 29:07 Minuten
         Durch Komprimierung gewonnen: 672.31 MB (5.2%)
         Durch Datenfehler verloren: 18.38 MB (0.1%)
         Teile gerettet durch I.C.H: 2
         Totaler Overhead (Pakete): 276.42 MB (6.70M)
      Gesamt
Verbindung
   Session
      Allgemein
         Erneute Serververbindungen: 3
         Aktive Verbindungen (geschätzt): 140 (Halb:5 | Komplett:58 | Andere:77)
         Durchschnittliche Verbindungen (geschätzt): 172
         Verbindungsspitze (geschätzt): 401
         Verbindungs-Limit erreicht: 15 : 15.04.2005 18:00:46
      Upload
         Upload-Geschwindigkeit: 29.0 KB/s
         Durchschnittliche Uploadrate: 28.5 KB/s
         Max. Uploadrate: 32.2 KB/s
         Max. durchschnittliche Uploadrate: 28.5 KB/s
      Download
         Download-Geschwindigkeit: 46.9 KB/s
         Durchschnittliche Downloadrate: 36.4 KB/s
         Max. Downloadrate: 234.0 KB/s
         Max. Downloadrate Durchschnitt: 46.3 KB/s
   Gesamt
Zeit Statistiken
   Letzter Reset der Statistiken: 14.03.2005 11:30:08
   Zeit seit letztem Reset: 36 Tage 9:55 Stunden
   Session
      Programm-Laufzeit: 4 Tage 4:35 Stunden
      Übertragungszeit: 4 Tage 4:35 Stunden (100.0%)
      Dauer auf aktuellem Server: 0 Sekunden (0.0%)
      Dauer auf Servern: 1:10 Stunden (1.2%)
   Gesamt
   Abschätzungen
Clients
   Bekannte Clients: 7877 
   Client-Software
   Netzwerk
   Port
   Niedrige ID: 936 (11.9%)
   Identifikation (pos : neg): 7609 (96.6%) : 51 (0.6%)
   Problematisch: 0 (0.0%)
   Gebannt: 194
   Gefiltert: 7774
   Leecher 7508

Bin sehr Zufrieden.Gute Arbeit Xman.

[edit by Pathfinder: Statistiken bitte auf's Wesentliche kürzen oder Code-Tags verwenden!]

[Xman]

-------------------------------------------
Kapitel 5
- Optimierungen der GUI -
-------------------------------------------
new:
- neben zahlreichen Optimierungen der GUI (z.b. IP to country) gibt es auch noch ein paar extra Features:
- Powerrelease:
+ nur für komplette Dateien möglich
+ stark erhöhte Release Priorität: wenn weniger als 100MB oder das 1,5 fache der Filegröße geshared wurde, dann sehr sehr hohe Priorität, ansondern sehr hohe
+ für Powerreleasedateien gilt ein dynamisches HideOvershares. Es startet mit hideos=1. Sobald 2/3 aller chunks versteckt sind wird der Wert für HideOS automatisch erhöht
- Xtreme Downloadmanager sollte nun auch mit download in alphabetischer Reihenfolge zurechtkommen
- 11kb min Upload für unbegrenzten Download
- weitere Änderungen im englischen changelog... und auch mit dem Auge sofort sichbar

to test:
- funktioniert das mit dem swappen richtig ? regeln sind:
+ Dateien mit hoher Downloadprio werden am meisten für A4AF-sourcen bevorzugt
+ bei Dateien mit gleicher Prio sollte einigermaßen gleichmäßig verteilt werden, es sei denn:
+ download in alphabetischer Reihenfolge ist eingestellt, dann gehts nach Alphabet
- ansonsten ist alles zu testen... findet den letzten Bug!

Anmerkung:
sollte alles so funktionieren wie gewünscht wird dies die letzte alpha sein, bevor der große, allgemeine, internationale beta-Test erfolgt. Da inzwischen hunderte Dateien geändert sind, noch nicht alles sauber dokumentiert ist und es viel Arbeit macht den Quellcode zusammenzustellen, hab ich die sourcen für diese Version weggelassen. Wie gesagt, findet ihr keine größeren Fehler gibt es in ein paar Tagen die beta, selbstverständlich mit (wie früher auch) großen source-packet.


Download: binaries


changelog alpha5.0
- //Xman PowerRelease
+ only avaiable for complete files:
+ increased release-prio: if transfered <100MB or < 1.5 of filesize, very very high Prio, otherwise very high prio
+ dynamic hide overshares: start with hideos=1, after 2/3 of the chunks are hidden, hideos will be increased
+ (some parts of code from slugfiller)
- added Xtreme Icons
- MoNKi: -Fixed UTF-8 strings on web searchs
- Preferences Fix (tHeWiZaRdOfDoS)
- color LowID-clients in downloadlistctrl
- min 11 upload for unlimited download!
- // Mighty Knife: Static server handling (morph)
- // - show requested files (sivka/Xman)
- //Xman friendhandling from all windows
- some rewriting of xtreme-downloadmanager to be compatible with categorie-handling of 0.45b
- some codeimprovements in drawing of chunkbars
- Fix For Incorrect Corruption Stats (netfinity)
- fixed a bug in anti-leecher-log
- //Xman process prio (parts of code from TPT)
- IP to country (Eastshare/ morph)
- // SLUGFILLER: searchCatch

[drfreak2004]

mal schauen, ob ich emule mal wieder laufen lasse; wenn ja nehme ich natürlich deinen. würde gerne weiter testen aber ich bin gerade an einer systemumstellung auf debian 3.1 ....

naja viel erfolg

[Xman]

@drfreak2004
ich hoff Du hast bemerkt, daß ich Dein Feature-Request berücksichtigt hab

[evil]

wann rutscht dir endlich mal die final ausm sack ...
manche leute habens nicht so mit dem warten ..... (ICH zB)

Und .... Für dich gilt übrignes auch die GNU General Public License ...
Wenn du die bin online stellst, müssen die vollständigen brauchbaren Sources
dabei sein ... Sei es nun eine Testversion, eine Beta oder gar eine Final ....


Jetzt hab ich ihn

greetz,
evil

[Stulle]

lol, was soll das denn wieder¿ es ist reine freundlichkeit das xman überhaupt in diesem Stadium (pre-beta / alpha) Versionen zur Verfügung stellt! Hast du ein Problem damit, dass er nicht die sourcen released, niemand wird gezwungen diese Mod alpha zu nutzen, nicht mal du! Und davon abgesehen EastShare ist so gesehen eine etabblierte Mod (im Morph n eigenes Pref-Fenster) und hat zB für die Version 9.1 auch keine sourcen released weil es nur ne Test-Version ist. Und das war auch nicht das erste Mal (soweit ich weiß).

MFG Stulle

[evil]

dazu kann ich nur immer wieder "GNU General Public License" sagen .. ^^

Das mit dem Sack war als "Weihnachtsman Geschenkesack" gemeint ...
also wer das als beleidigung auffasst ...

ok stulle .. ich habe zawr respekt .. aber als analforscher werd ich mich
desswegen nicht eintragen ... für alle gelten dieselben regeln ..

und wenn Xman so nett ist und seine pre aplha/beta zur verfügung stellt,
steht er hiermit auch unter der GNU General Public License ....

diese besagt (wie gesagt), dass man die modifizierte source
anderen benutzern frei zugänglich machen muss ...

und wenn der Xman hier die programmdatei veröffentlicht, wird er wohl sicherlich
auch keine probleme haben, dasselbe mit dem quellcode zu machen ...

ich verstehs beim besten willen nicht!
Ich finde seine Ideen erste Sahne ... Nun .. warum muss ich auf die Srces warten ..?
Vielleicht gefällt mir der XTreme ja jetzt schon ....
Außerdem - einmal stellt er eine nicht komplette src online .. und dann wieder gar keine ..


das ist schon ziemlich verwirrend .. finde ich ..
"KEINE SRCes VOR DER FINAL"
(obwohl er mit der programmdatei allein viel mehr schaden anrichtet)
Die src selber wird niemandem weh tun ... außer die beißt .. da kann ich dann auch nix für

[Stulle]

*kopfschüttel*
ich glaub irgendwas geht hier zieml. verkehrt. soll ich nun mav auch die src zu meiner 1.0 pre mitschicken¿ wenn du n problem mit xman seiner politik hast, ignorier den mod, schnapp dir ne andere src, bau "ban gnu verletzer" ein, adde die xtreme alphas! typischer korintenausscheider...
meine meinung!

MFG Stulle

PS: gl beim weiteren coden, xman, bin schon gespannt!