Xtreme Entwicklung - early alpha test thread

**mav744** · 2. March 2005, 18:54

@ Xman,

ich meinte nicht die Uploadkurve in der Statistik, sondern den Upload im allgemeinen, der sehr stark einsackte bis auf zeitweise 5 KB/s, also hätte ich ja in der zeit einen overhead von ca 11KB/s, das meinte ich (Hatte auch in der zeit nichts anderes im netz als das emule, und es war auch nicht für ein paar Sekunden). Mittlerweile ist der Upload nach 1h 30 min schön stabil geworden, vielleicht hat mein emule auch einfach nur nen schlechten tag, soll ja vorkommen. Zum Upload werde ich dann auch jetzt meine Klappe halten

, hatte nur gepostet was mir aufgefallen war.

Mit freundlichen Grüssen
mav744 :

**Xman** · 2. March 2005, 19:02

achso.... na es kann schon mal sein, daß der Upload für 1-2 Sekunden ganz runter geht... sollte auch theoretisch so sein.. weil:
er soll sich am Overhead orientieren.. sprich, die weiße Linie sollte stabil sein. Macht emule auf einmal sehr viele Verbindungen auf, erzeugt dies viel Overhead und darum muß der Upload runter damit die Kapazitätsgrenze nicht überschritten wird... (was sie mit der offiziellen Version leicht tut und darum viele Leute den Upload auf nur 12 und kleiner stellen, da er mit mehr nicht stabil ist)
Dieses Prinzip funktioniert übrigens im Xtreme 2.2 sehr gut (aktiviere "Übernehme Upload für Overhead + Daten"). In der alpha2.0 funktioniert das momentan leider nur sehr ungenau.

Übrigens ist am Bandwidthcontrol sehr schön zu sehen wieviel Overhead Kad schluckt... das ist echt verdammt viel.. darum hatte ich es die meiste Zeit aus.

**mav744** · 3. March 2005, 06:50

Hab nen ganz schweren Bug. Wenn ich die Inet verbindung trenne, schmiert der Xalpha 2.0 ab. Den Fehler hab ich als Bild beigefügt.Habe den Fehler auch 5 mal reproduziert, also bin ich mir sehr sicher. Bin wieder beim Xalpha 1.3.

Mit freundlichen Grüssen
mav744

EDIT:clean install natürlich gemacht, mit mitnahme der wichtigsten dateien.

**Rumpelzuck** · 3. March 2005, 18:51

Bei mir ist er nach ca. 9 Stunden Laufzeit und zwar ohne spezielle Benutzeraktion auch mit dieser Fehlermeldung abgeschmiert, ich hatte allerdings davor und dabei keine Trennung der PPPOE-DSL Verbindung.
(Win2003 Server + SP1RC2, ISA2004 Firewall, cFosSpeed 2.02, RASPPPOE DSL-Treiber von Schlabbach).

Mein Muli läuft zur Zeit mit Niedriglast, ca. 300 in der Queue und 80 Quellen. Xalpha 1.3 und jetzt wieder Eastshare 9.0 laufen stabil.

Ich habe im Prinzip bisher auch nur ein (in meinen Augen) Manko bei den xalphas 1.3 und 2.0 festgestellt. Ist ähnlich wie bei den Morphs und Eastshares, die ich sonst meist einsetze, nur noch ********

EDIT: (das war kein schlimmes Wort was hier von der Boardsoft gesternt wurde, nur ein Wortspiel-Witz)
Es werden zu viele Uploadslots aufgemacht, die dann mit 1-2 Kb/s vor sich hin dümpeln, wenn der versuchte Upload an den zur Zeit möglichen physikalischen Maximalwert stößt.

Solange mein eingestellter max.Upload deutlich (1-2 KB) unter den Möglichkeiten bleibt, klappts gut mit wenigen UL-Slots. Sobald z.B. durch starken Download oder durch Heraufsetzen des eingestellten max.Uploads mehr upgeloadet werden soll als gerade physikalisch geht, erhöht sich die Zahl der UL-Slots und auch der Slotfocus versagt.

Bei den Xalphas macht er dann bei mir bis zu 12 UL Slots auf, der Morph/Eastshare nur bis zu 8.

Bei Morph krieg ich das folgendermaßen in den Griff:
ICMP Typ 0 und 8 Pakete per cFosSpeed in dieselbe Klasse wie EMule stopfen und im Muli das USS aktivieren. So kann USS immer noch auch bei Einsatz von cFosSpeed den Betriebszustand des Muli messen und die UL-Slot Zahl regeln.
(Oder ich kompiliere mir ne eigene Version mit erhöhter UPLOAD_CLIENT_DATARATE, dann macht er auch weniger UL-Slots beim Erreichen der Lastgrenze auf.)

Bei Xalpha 1.3 hat das aber nicht gewirkt, wie misst und regelt den der Xalpha 2.0? Wie funktioniert den das Maella-Bandwithcontrol?

Ciao
Rumpelzuck

**Xman** · 3. March 2005, 20:17

die xalpha benutzen nicht mehr die UPLOAD_CLIENT_DATARATE.
Offiziell und alle anderen Mods: Bandbreite/UPLOAD_CLIENT_DATARATE= Anzahl Slots. Diese werden geöffnet und nacheinander bekommt jeder ein Datenpacket. Kann ein Slot keines aufnehmen, so nimmt halt ein anderer Slot das Packet. Bleiben am Schluß eines Zykluses noch Packete übrig, so muß evtl ein neuer Slot her (wenn Dyn-Upload eingeschalten) oder der Upload geht runter. Neuöffnen eines zusätzlichen Slots wird entweder durch die maximalzahl an Slots, oder durch den commonroutefinder (USS) begrenzt.
xalpha:
Jeder Slot besitzt seine eigene Steuerung die sagt, wann er wieder ein Packet senden muß um die gewünschte Speed zu halten. Kann die gewüschte Gesamtuploaddatenrate nicht gehalten werden->neuer Slot bis zu den definierten Maxslots. Ein Freund von USS bin ich nicht.. der Xtreme wird die von der 2.2 bewärhrten Uploadsysteme beibehalte: NAFC oder Uploadreduction at Download + Overheadintegrierung im Upload. Ich bin auch kein Freund davon, daß man den Upload bis ans Maximum stellt... es sollte immer etwas Luft bleiben... der Xtreme versucht ja bereits, dieses Mindestmaß an Luft zu reduzieren.
Nochwas zur Slotkontrolle: Im xalpha1.3, basierend auf offiziellem Code in dem der TCP/IP-Overhead nicht integriert ist, läuft das System gut. Mit Bandwidthcontrol, welches nun den kompletten Traffic zählt versagt das System. Problem: z.b. Kad macht öfter mal rießige Overhead-Spikes, sprich, es kann mal 0.5-2 Sekunden geben, in denen der Overhead 10kb und mehr ausmacht. In dem Moment hab ich ein Problem mit meiner Slotsteuerung: führe ich eine Neuberechung durch (=bei momentan möglicher Uploadrate, wieviele volle Slot können vollen Speed nehmen), so werden kurzfristig alle Slots zum Trickle. Führe ich keine Neuberechung durch, bekommen die Slots nicht ihren gewünschten Speed und die Kontrolle meint, die Slots sind problematisch, es müssen neue Slos aufgemacht werden.
Aus diesem Grund kann es sein, daß ich die gesamte Slotkontrolle nochmal umschreibe... und zwar mit Tolleranzen... zwar wird dann niemals die Möglichkeit bestehen, die exakte Slotspeed festzulegen, doch das System wird so tollerant sein, um benannte Spikes ausgleichen zu können.
Ob Neuschreiben oder Abändern wird sich zeigen... erst einmal muß das Bandwidthcontrol in den Griff gebracht werden.

Wer übrigens Abstürtze hat, sollte in den preferences.ini in der emule-Sektion "CreateCrashDump=1" einschalten... und ein generiertes dump-file an emulextreme@yahoo.de schicken. Achja.. im emule-Verzeichnis sollte sich die Datei dbghelp.dll befinden. (wurde z.b. mit Xtreme2.2 immer ausgeliefert)

drfreak2004 · 4. March 2005, 10:25

hi xman,

die funktion die wäre toll im mod ! genau die such ich !

wie man sieht von morph....

**Xman** · 4. March 2005, 10:34

@drfreak2004
klingt vernünftig, sollte einfach sein... und eine "Kopiervorlage" gibts ja auch schon

wird reinkommen.. aber erst viel später.. wenn der upload paßt.
Der Hauptbug scheint gefunden (thx Maella).. werde aber noch ein wenig rumbasteln.

drfreak2004 · 4. March 2005, 10:41

die idee ist deswegen gut weil morph/eastshare dadurch das org. der entwickler net geändert haben. unter optionen/server "lösche tote server nach x fehleversuchen" gggg find i cool !
eines hätte ich noch... da alle so von power des eastshare 9 schwärmen, hab ich den mal drauf gemacht.... ist heftig wie der nach 5 !!! min abgeht.... vielleicht wäre ja ein blick auf die veränderungen ne hilfe für deine entwicklung

( zeitersparnis )

mfg

**Xman** · 5. March 2005, 20:21

ich hab die Routine zur Uploadverteilung nochmal komplett umgeschrieben.
pros:
- das ständige hin und herspringen bedingt durch den Overhead, von Trickle zu Full-Slot entfällt
- Auch wenn man mehr Upload einstellt als überhaupt vertragen wird, werden nicht unzählige neue Slots geöffnet
contra:
- die Slotspeed ist nun sehr tolerant... sie kann bis zu 20% über der eingestellten Speed liegen, aber auch um etliches darunter.
- die Änderung der Slotspeed wirkt sich nicht mehr sofort auf die Slots aus.. z.b. wird bei Erhöhung der Speed evtl. erst mal gar nichts passieren.. allerdings wenn ein Upload beendet wird, wird die übrige Speed auf die anderen Slots verteilt.

Änderung in der Logik:
- Die Speedkontrolle eines jeden einzelnen Slots hab ich wieder verworfen (ausgenommen Trickles)
- Die Slotspeed bestimmt vielmehr wie Anzahl der Slots die geöffnet werden... auf diese Slots wird der Upload dann einfach verteilt.

Ich teste noch bis morgen.. werd hier und da bestimmt noch kleine Änderungen machen... dann gibt es eine neue Testversion.

**Xman** · 6. March 2005, 11:25

Neue Testversion x3alpha2.1
-------------------------------
new:
- Überarbeitetes Uploadslotshandling (siehe letztes Post)
- Bug in der Uploadkurve weitestgehend behoben

totest:
- Statsitiken überprüfen:
- Farbeneinstellungen, Zeiteinstellungen der Graphen, verschieben der Graphen
- alle Werte des Statistiktbaumes auf Plausibilität überprüfen
- alles überprüfen was man mit der Statistik machen kann (kopieren, zurücksetzen usw.)

- Webserver, Mobile emule zeigen richtige Werte ?
- Ist der Download ok ? (verglichen mit dem offiziellen emule)
- zu viele / zu wenig uploadslots ?
- Stabilität ?

Download: binaries & sources

Don't repost on other boards until beta-state is reached!

changelog:
alpha2.1
- reworked the uploadmanagemend: changed from a accurate slotspeed-system to a tolerant one. Reason for this was: emule overhead can change very fast, this caused the slots to permament changing its state (trickle/full).
- fixed an official cosmetic bug in statistics
- more stable uploadgraph (compared to alpha 2.0) (thx Maella)
- reworked Threadsave Bandwidthcontrol (thx Maella)

Edit: Hab vergessen in dieser Version diesen von Mav entdeckten Bug im Minimule zu fixen... ist bereits getan für die nächste Version. (thx nochmal an Mav)

**mav744** · 6. March 2005, 13:26

Hallo Xman,
die statistiken sind überprüft, sie funktionieren wie sie es sollen. Desweiteren ist auch kein Absturz beim trennen der Inetverbindung mehr zu verzeichnen. Die Cpu last liegt aber bedeutend höher als bei der X3alpha 1.3, zumindest wenn ich das muli komplett geöffnet habe. Die restlichen Punkte werde ich noch einem Langzeittest unterziehen. Dies sind die ersten Punkte die mir aufgefallen sind.

Mit freundlichen Grüssen
mav744

EDIT:Nach ca. 3 Stunden ist die Cpu last auf dem gleichen Level wie bei den Vorgängerversionen, war halt nur nen bisschen komisch.

drfreak2004 · 6. March 2005, 14:27

hi xman,

läuft alles gut bis auf folgendes :

dl/ul liefen sauber. dann passierte es ich ging auf dateien neu laden. mehrmals ..... plötzlich dl/ul beide auf 0 ! serververbindung weg aber reconnect auf anderen. nach 10 sek hat ul sich erholt aber bis jetzt kein dl mehr..... es kam noch eine hashmeldung und des wars ... er läuft noch aber 0 dl !

komisch

zusatz: emule neu gestartet nun bekomme ich die meldung" AICH Hashset konnte nicht gespeichert werden "

zusatz 2: emule rennt wieder im dl wie vorher

**Xman** · 6. March 2005, 15:23

@drfreak2004:
kann ich mir so jetzt nicht erklären, da ich an diesem Teil des Codes rein gar nichts änderte. Wäre jetzt interessant zu wissen ob der offizielle emule auch solch ein Verhalten an den Tag legt.

@mav:
Danke für den Hinweis... ich hab zwar noch keine Ahnung woran das mit der CPU-Last liegt.. aber dem werd ich mal nachgehen. Eine kleine, neue Testversion, welche die CPU-Last evtl. ein bischen drücken könnte gibt es jetzt.

**Xman** · 6. March 2005, 15:25

Neue Testversion x3alpha2.2
-------------------------------
new:
- Bugfix, bei friendslots, der dazu führte, daß zu viele Slots geöffnet werden
- ein paar Code Improvements, wann Display-Informationen im Transferfenster aktualisiert werden (CPU-Load)
- Bugfix: Minimule zeigt nun auch Uploadoverhead

totest:
- Statsitiken überprüfen:
- Farbeneinstellungen, Zeiteinstellungen der Graphen, verschieben der Graphen
- alle Werte des Statistiktbaumes auf Plausibilität überprüfen
- alles überprüfen was man mit der Statistik machen kann (kopieren, zurücksetzen usw.)
- Webserver, Mobile emule zeigen richtige Werte ?
- Ist der Download ok ? (verglichen mit dem offiziellen emule oder letzten alphas)
- zu viele / zu wenig uploadslots ?
- Stabilität ?
- im Transferfenster werden Downloadinformationen (Clients/Files) korrekt angezeigt ?

Download: binaries & sources

changelog:
alpha 2.2
- fixed a bug with friendslots
- some code inprovements, when display-informations of downloadlistctrl are updated (CPU-load)
- bugfix: minimule now shows the uploadoverhead

**mav744** · 6. March 2005, 17:00

Hallo Xman,
wie immer die leichtesten Sachen schon getestet. Also Statistik funzt, aber da wirst Du wohl von der2.1 zur 2.2 nichts geändert haben.

Zitat:

- im Transferfenster werden Downloadinformationen (Clients/Files) korrekt angezeigt ?

werden korrekt angezeigt.
Die anderen Punkte wiegesagt nach etwas längerer Zeit, also nach langzeit test (12-24 Stunden).
Was mir aufgefallen ist, seit Bandwith Control impletiert wurde, ist das Uploadlimit was ich einstelle, upload incl. overhead. Kann man das vielleicht manuell in der Pref.ini abstellen?
Die Cpu last ist wieder auf dem stand wie bei der X3Alpha 1.x
Mit freundlichen Grüssen
mav744

Ähnliche Themen: Xtreme Entwicklung - early alpha test thread