Xtreme Entwicklung - early alpha test thread

[Xman]

@x-ray
die dumpfiles zeigen im wesentlichen nur an, an welcher Stelle des Codes udn mit welchen Werten emule gecrashed ist. Damit kann nur ich was anfangen (zumindest meistens). Und natürlich werden Daten vertraulich behandelt.

@micha
der * bedeutet immer, daß der betreffende client nicht nur eines, sondern mehrere Files hat, die Du benötigst.

@all
danke für eure Unterstützung

[Hanussen]

@Xman

Habe dir zwei 24 Stunden Statistiken per E-Mail geschickt.

Was ich wegen der Gesamten Durchschnittlichen Downloadrate gemeint hatte muss nicht unbedingt ein Bug oder ein Fehler sein. Ich habe mich lediglich gefragt, wie dieser Wert errechnet wird.
Angenommen meine Statistik läuft seit 10 Tagen und davon 90% der Zeit mit einer Downloadrate von 80 kb/s. Wenn ich nun Emule nach jeder Zwangstrennung, also nach 24 Stunden, neustarte, dann nähert sich der Wert der Session-Durchschnittlichen-Downloadrate innerhalb der 24 Stunden der Marke 70 an. Die Gesamte Durchschnittliche Downloadrate fängt aber nach jedem Emule Neustart so wie ich das sehe bei Werten zwischen 0 und 30 an. Das erscheint mir unlogisch, die GDD müsste sich doch genauso bei ca. 70 kb/s einpendeln und durch kurz andauernde langsame Downloadraten (also der Übergang Volllast -> Neustart -> neue Session) nicht groß beeinflusst werden. Genauso eben wie es bei, Gesamten Upload : Download Verhältnis gehandhabt wird.
Ich hoffe es ist jetzt verständlich, wenn nicht auch egal dann lassen wir das

MfG Hanussen

[mav744]

Sorry Xman, aber ich werde mich bis nach den Feiertagen etwas aus dem genauen beobachten des emules zurückziehen. Feiertage bedeuten leider auch weniger Zeit und zudem bin ich vom Sport auch noch verletzt. Wenn irgendetwas dringendes anliegt oder eine neue Version released wird werde ich natürlich versuchen zu helfen.

Mit freundlichen Grüssen
mav744

[Xman]

@hanussen

so ganz genau kann ich es zwar nicht nachvollziehen.. aber 2 Punkte:
erstens... das hier ist der Code:

// Cumulative Max Average rates

cumDownavg = (sessionDownloadRate + thePrefs.GetConnAvgDownRate()) / 2;

cumUpavg = (sessionUploadRate + thePrefs.GetConnAvgUpRate()) / 2;

if(maxcumDownavg < cumDownavg)

{

maxcumDownavg = cumDownavg;

thePrefs.SetConnMaxAvgDownRate(maxcumDownavg);

}

zweitens: das Up/Down-Verhältnis läßt sich aufs Byte genau errechen, da klare Werte bis aufs Byte vorhanden sind. Bei der Down/uprate hingegen ist das rein mathematisch gar nicht so einfach möglich. (wann war welche up/downrate für wie lange gültig... usw. zu speichern und auszuwerten ist bei weitem zu viel Aufwand). Daher sucht das System einen möglichst realistischen Wert zu "schätzen".

[aalerich]

Wenn ich Hanussen richtig verstanden habe wird bei einem Neustart des Mulis nicht nur die Sessionrate auf Null gesetzt und neu mit ihrer Ermittlung begonnen, sondern auch die Statistik für die gesamte Rate über alle bisherigen Sitzungen. Normalerweise sollte die Statistik der Gesamtrate ja angeben, wie hoch die Downloadrate für die gesamte Laufzeit des Mulis im Schnitt war. Schon zu Beginn einer neuen Sitzung müßte dieser Wert also deutlich über Null liegen (Es sei denn natürlich, daß mit dem Muli noch nie etwas heruntergeladen wurde.) Bei ihm wird aber wohl nicht nur die Sessionrate jedesmal zurückgesetzt, sondern auch die Gesamtrate.

Naja, so habe ich das zumindest verstanden.

Mit freundlichen Grüßen
aalerich

[Hanussen]

Guten morgen allerseits. aalerich hat die Situation genau richtig erfasst.
"Normalerweise sollte die Statistik der Gesamtrate ja angeben, wie hoch die Downloadrate für die gesamte Laufzeit des Mulis im Schnitt war. Schon zu Beginn einer neuen Sitzung müßte dieser Wert also deutlich über Null liegen" <- Genau so habe ich das gemeint.
Die Gesamtrate wird zwar nach jedem Neustart nicht jedesmal auf null zurückgesetzt sondern meistens auf Werte zwischen 10-30, jenachdem wie der Download gerade lief/läuft, aber denoch kann dieser Wert ja kein realer tatsächlicher Wert sein.
Erklärung gibt daher der Post von Xman. Von dem Code habe ich eigentlich soweit alles verstanden bis auf "thePrefs.GetConnAvgDownRate". Logisch erscheint mir deine zweite Erläuterung. So etwas in der Art habe ich mir auch schon überlegt. Wenn ich es richtig verstanden habe, dann kann man den realen Wert der Gesamten Durchschnittlichen Downloadrate nicht errechnen, da sich ja der Muli nicht alle Downloadraten merken kann um daraus dann einen gesamten Durchschnitt errechnen zu können - logisch
Ich denke das "Problem" hat sich jetzt geklärt, danke für eure Erklärungen.

Mit freundlichen Grüßen
Hanussen

[aalerich]

Na gut, für mich ist der Code genauso verständlich wie Konfuzius in der Originalsprache

Mit freundlichen Grüßen
aalerich

[Hanussen]

Ich habe eigentlich auch keinerlei Ahnung vom Programmieren, aber ich finde, der Code lässt sich relativ logisch erschließen. So wie ich es verstehe beschreibt er die Berechnung der Gesamten Durchschnittlichen Downloadrate. Sie wird errechnet durch die aktuelle Session Downloadrate plus "thePrefs.GetConnAvgDownRate()" (hierbei wird wohl aus den Preferences irgend eine Durchschnittliche Connection Downloadrate gelesen) und das ganze geteilt durch zwei. Das Ganze wird bei der Gesamten Durchschnittlichen Uploadrate genauso berechnet.
Schließlich geht es noch um die Maximale Gesamte Durchschnittliche Downloadrate. Wenn der Wert der aktuellen GDD größer wird als der Wert der maximalen GDD, dann wird dieser neue größere Wert als maximale GDD eingetragen.
Also wie gesagt ich habe mit Programmieren absolut nichts am Hut, es wäre aber interessant zu hören, ob meine Erläuterungen so in etwas zutreffen.

MfG

[Xman]

@hanussen:
richtig interpretiert. Ich hab den Code hier auch darum gepostet, weil er mehr sagt, als ich mit 100 Erlkärungen ausdrücken könnte.
Die Idee zu diesem Code ist nicht auf meinem Mist gewachsen... man könnte es sicherlich besser machen... aber ich glaub der Aufwand lohnt nicht für einen doch eher unwichtigen Wert.

[Paul 2]

... aber ich glaub der Aufwand lohnt nicht für einen doch eher unwichtigen Wert

und den der Normaluser auch wahrscheinlich nie ansehen wird

[drfreak2004]

mahlzeit xman...

also 4.1 läuft sehr gut... man könnte meinen es ist ne xtreme 2.2 im neuen gewand ul/dl 1:5 !
ul sehr stabil und dl auch !

wow... !
hoffe das bleibt so....

[Xman]

um euch mal auf dem laufenden zu halten:
meine 2 Wochen Pause ist vorbei und ich bin bereits wieder fest am rumbasteln. Die nächste Version kommt also bald und wird hauptsächlich eine ganze Menge Bugfixes und Tweaks enthalten.

Auf einer der letzten Seiten deutete ich bereits an, daß ich einem emule-Bug auf der Spur bin, der wohl schon lange in emule vorhanden ist. "Lange" bezog sich darauf, daß ich diesen Bug mit allen Versionen bis runter zur 0.29 bemerkte.
Und zwar hatte ich tierische Probleme mit meinem Mod eine hohe Slotspeed zu geben. Das gleiche Problem hatte ich mit jedem Mod und Original... nur dank geglätteten Kurven und großzügiger Durchschnittsanzeige viel es dort nicht so auf. Letztendlich kam Maella auf die Ursache des Bugs. Es ist nicht emule... es ist der Netzwerkchipsatz auf etlichen Asus-Boards (ein Glück, daß Maella auch so ein Board hat, sonst wären wir nie draufgekommen). Dieser Chipsatz neigt sehr gern dazu, die zu sendenen Packetgrößen viel zu klein zu wählen. Die folge davon ist, daß der Overhead steigt (die gelbe Linie im Xtreme, welche den Wert von Windows selbst erhält.... bzw. ist der gleiche Wert den auch Tools wie DU-Meter anzeigen) und Slotspeeds >5 problematisch werden.
Ich hab nun wieder meine alte Realtek-Karte drin.. und siehe da: hohe slotspeed kein Problem... und der Overhead ist pi mal Auge um gut 2 kb gesunken.

[Xman]

also heute abend gibt es die neue Version... und ich bin einfach hellauf begeistert wie gut die neue läuft. Jetzt läuft z.b. der Upload endlich so, wie ich mir es schon immer erwünscht hab.
Das Hauptproblem vieler Leute dürfte wirklich dieser Netzwerk-Chipsatz vom Asus-Motherboard sein. Die Performace hat seit dem Wechsel der Netzwerkkarte einfach unschlagbar zugelegt. Mit den Patches des neuen Mods zusätzlich hat sich mein TCP-Overhead(nicht der, den offizieller emule anzeigt, sondern der zusätzliche, der durch das TCP/IP-Protokoll entsteht) um ca. 80% gesenkt.

Auf freudiges Testen heute Abend

[Xman]

Neue Testversion x3alpha4.2
---------------------------------
new:
- im wesentlichen nur etwas Feintuning und ein paar kleine Bugs gefixt

to test:
- nichts spezielles, also ganz allgemeiner Modtest


Download: binaries & sources


changelog alpha4.2
- reworked the maintimer (avoid doing to many actions at the same time)
- Xman Chunk Selection Patch
- some tweaks at download and upload
- small improvement on update the displayed info from partfiles
- fixed a bug in calculating AvgQR when a file was stopped
- increased the TCP-reask-time, if partstatus can be updated via UDP (@emule 0.4x)
- fixed a bug on sending modstring
- fixed a bug, with showing wrong TCP-reask-time on tooltip
- adjusted the score calculatoin.. should now work with high slotspeeds too
- fixed a bug with Xtreme Full Chunk (uploadsessions should be longer now)

[ofenheizer]

Hi Xman,

ich habe schon die 4.1 getestet, die lief schon sehr schön.
Habe soeben die 4.2 angeschmissen. Erfreulich ist der DL, der ist bei einigen Files sofort angesprungen.
Aber mit dem UL klappts überhaupt nicht. Eingestellt bei max UL sind 12kb, der "Upload Slot Speed" steht auf 2.2 und "Open more Slots if needed" ist an. Alles wie auch bei der 4.1.
Jetzt habe ich 5-6 UL-Slots, aber 4 davon sind grau und haben einen Speed von max. 0.5kb und 1-2 sind aktiv mit auch nur max 1.5kb. Ich habe einen durchschnittlichen UL von ca. 4kb.
Es ist auch nichts weiter aktiv was die Leitung beeinträchtigt, auch keine anderweitige Kommunikation über den Netzwerkadapter.

So long.
ofenheizer