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....

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.

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

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)

Upload???
 

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

Hallo,

ich beobachte bei mir leider haargenau das gleiche wie ofenheizer es beschreibt.
Max. UL 10.5 kb/s
Upload Slot Speed 2.8 kb/s
An den Einstellungen habe ich beim umstieg auf die 4.2er nichts verändert.
Der Upload schwankt zwischen 3 und 7 kb/s, bei 4 Upload Slots.

MfG Hanussen

nach über 2h laufzeit habe ich ein durchschnittlichen UL von 5.5kb

ansonsten läuft die 4.2 sehr stabil, quellen wurden schnell gefunden und der DL ist auch bestens.

hab mal ein bildchen angehängt, wie meine UL- und DL-Kurven aussehen. die vom DL finde ich in ordnung :-)

Deine Kurve schaut genau wie das Gegenteil von meiner aus ;-)

was ich da leider nicht raussehen kann: ist die weiße Linie auch so zackig ?
Sagt das VerboseLog was ?
verwendest Du einen Router ?
Änder das Deaktivieren von Kad etwas ?
CPU-Auslastung ist aber ok ? (keine 99%)

Edit:
so wie ich das Bild sehe scheint die weiße Linie stabil.. was dafür sprechen würde, daß ich beim Annehmen eines Downloads einen Bock gebaut hab... dann müßte das VerboseLog aber gerade zu mit Messages überflutet werden... diese Message bräuchte ich.

UL läuft bei mir sehr stabil (3 Std.) UL Limit 13,6
Erfolgreiche UL 90,31

nicht wahr, die ul-kurve hat schon was besonderes:mrgreen:

also, die weisse linie ist super stabil (gerade).
ja, ein router ist im einsatz - ein linux software router.
kad ist von vorherrein deaktiviert.
cpu-last liegt um die 3%, also absolut i.o. (speicherbedarf nach fast 4h: 40mb)
so das log werde ich jetzt mal einschalten, hatte ich bishe deaktiviert, und dir dann zukommen lassen.

brauchst du sonst noch informationen? erfolgreiche dl-sessions: 85%, erfolgreiche ul-sessions: 72%

wenn die weiße Linie super stabil ist, dann ist der Upload super stabil.....
Also ist das was ich oben schrieb wohl war.... und Du sendest mit dem Mod gerade an irgendjemand eine Flut von OPCODES.
Der Fehler liegt wohl wie gesagt beim Annehmen eines Downloads... da ich hier rumexperimentiert hab und diesen Teil noch nicht vollens austesten konnte (da sehr seltene Konstellationen verarbeitet werden)
Falls das VerboseLog gerade nichts auffälliges anzeigt (vor allem: Meldungen mit "-->" beginnend), dann starte den Mod neu und sag mir ob vor dem auftreten des Bugs eine Meldung mit "-->" kam. Die wäre mir sehr wichtig, damit ich weiß welche Konstellation nun nicht läuft.

also besser kann die weisse linie nicht sein.

also ich habe jetzt mal ein weilchen mitgeloggt, es sind keine auffälligen meldung in den logs zu sehen (nur added source... , reject source...)

ich starte jetzt mal den mod neu und geb dir dann mal den log - nun muss ich erst mal ins bettchen.
mal sehen wie es nach ein paar stunden aussieht.

ich weiss ja nicht, ob es wichtig ist, aber ich bin über wlan mit meinem eigenbau-router verbunden. ich hoffe nicht, dass es an meiner nic liegt (du hattest ja probleme mit asus erwähnt)


guts nächtle,
ofenheizer

nein.. dieser Bug hat bestimmt nichts mit dem NIC zu tun.

Morgen sehen wir weiter... denke der Bug wird schnell gefixed sein

Guts nächtle

--> Meldungen aus den letzten 2 Stunden 6 mal (3 siehe Zitat)

thx Paul
genau das meine ich mit interessanten Meldungen... nur: der von Dir gepostete Fall (Konstellation) ist unproblematisch und sollte nicht das Problem von Ofenheizer sein. Der hier gezeigte Fall wurde nämlich schon im Xtreme2.2 auf die gleiche Art und Weise erfolgreich behandelt.
Kurze Erklärung zu dem was Du da siehst:
Wie ich schon öfter im Forum schrieb gibt es ein Problem im emule-Protokoll, daß ein Download/Upload zu frühzeitig beginnt, bevor alle nötigen Opcodes ausgetauscht sind. Das ist ein Fehler auf upload-Seite. Auf der Uploadseite hab ich dies im x3alpha auch schon frühzeitig gefixt, mit ein Grund warum er so wenig fehlgeschlagene Uploadsessions hat.
Jetzt ist auch noch ein fix auf Download-Seite drin. Viel passiert hier allerdings nicht, im wesentlichen spar ich mir nur das Senden eines Packetes ein.

sorry aber irgendwie laufen die ganzen mods net schlecht aber die alte 2.2 ist doch das beste !

mfg

also ich habe jetzt mal meine logs nach ungewöhnlichem durchforstet - es ist nichts vorhanden, nicht mal ein eintrag der mit "-->" beginnt

hmmm...
also irgendwas erzeugt bei Dir wahnsinnigen Overhead. Wenn keine Logeintragungen da sind, dann ist es nicht das, was ich vermute (Fehler bei der Downloadannahme). Dennoch hab ich diesen Code für die 4.3 mit einem Sicherheitscheck ausgestattet.
Durch diesen Overhead schrumpft natürlich Dein Upload.. denn beim Xtreme bezieht sich das Uploadlimit auf Overhead + Daten. Ist der Overhead zu hoch, bleibt weniger für die Daten.
Was mich nur wundert: woher kommt der Overhead ?
Was Du mal machen könntest: laß die 4.1 eine Stunde laufen (die läuft ja ohne Probleme wie Du schriebst), speichere die Statistik komplett in einer Textdatei. Dann Zwangstrennung und starte die 4.2. Laß sie auch eine Stunde laufen und speichere ebenso die Statistik (komplett).
Schick mir dann bitte beide Statistiken an emulextreme@yahoo.de

ok, werde ich so machen. brauchst du nur die statistiken oder evtl. auch die logs?

EDIT: hier mal zum vergleich die uploadkurve mit der 4.1

statistik reicht. Und danke für den Vergleichsscreenshot.

im übrigen: wie mir scheint hast Du auch den Asus-Bug. Deine gelbe Linie ist nämlich auch so weit von der weißen entfernt wie es bei mir auch einst war. Seit der neuen Netzwerkkarte hat sich der Abstand mehr als halbiert. Falls Dir also mal eine Netzwerkkarte (tut ein Teil für ~10€, sollte aber keine 3COM sein, da diese auch bei Asus verwendet wird) in die Finger gerät kannst Du gern mal ausprobieren ob es bei Dir den gleichen positiven Effekt ergibt wie bei mir.

ich bin leider per wlan (prism3-chipsatz) angebunden und nicht per kabel und das wlan ist in meinem shuttle schon integriert. da werde ich wohl nicht weiter testen.

der durchlauf mit der 4.1 ist fertig, nun läuft nach zwangstrennung die 4.2 - in ca. 45min bekommst du die statistiken.

EDIT: wenn ich mir in der 4.2 die gelbe linie so ansehe und mir aus diesem "erdbeben" eine gemittelte linie denke, ist diese dann aber nicht mehr soweit von der weißen weg wie in der 4.1

Stimmt.. das ist der kleine aber feine Tweak der 4.2. Hoffe nur, der ist nicht für Dein "Erdbeben" verantworktlich.
Wir werden sehen... evtl. schick ich Dir später noch eine PM mit Dingen die Du testen kannst.

Tests
 

also die tests habe ich durch. zur emule1.exe habe ich dir ne pm mit ul-screenshot und statistik geschickt. die war wieder fast auf dem level der 4.1.
die anderen beiden (emule2 und emule3) haben sich genauso verhalten wie in der 4.2 - also keinerlei verbesserung.

erst mal danke ofenheizer, daß Du mir geholfen hast das Problem zu lokalisieren. Ehrlich gesagt hätte ich es ohne Deine Hilfe wohl nie gefunden.

Für alle: das Problem ist, daß die 4.2 die Kontrollpackete im gegensatz zur 4.1 ohne Verzögerung schickt. Eigentlich sollte das kein Problem sein.... der Xtreme2.2 tat das z.b. immer so. Noch kann ich mir das nicht erklären. Sobald ich aber etwas genaueres weiß (oder auch nicht), werd ich dies entweder wieder ausbauen, oder als An/Abschaltbar machen.

Wintermute?
 

Hast du vor so etwas in der art wie Wintermute einzubauen?
Passt zwar auf den ersten blick nicht so rein, da es aba das dev forum ist frag ich einfach mal...

Nabend
Die 4.2 läuft seit ca.8 Stunden ohne Probleme. Ul und Dl sind auch gut.
Saubere Arbeit . Danke Xman :-)

@Edol
soweit ich weiß macht wintermute nichts anderes als ein etwas gründlichere IP-filtering. Allerdings macht das die offizielle Version inzwischen auch schon. Bleibt die Frage: welches Feature aus dem Bündel an Wintermute-Features interessiert Dich denn ?

@all
also Bug hat die 4.2 bezüglich dem seltsamen Upload, welchen 2 User berichteten keinen. Ich hab mir Ofenheizers Statistik genau zur Gemüte geführt. Wenn man genau hinsieht ging die 4.2 besser.. das heißt, sie fand mehr Quellen und werwarf weniger. Das generelle Problem liegt hier eher darin, daß der Overhead viel zu groß für die kleine Bandbreite ist. Daß die 4.1 mit diesem Problem besser zurechtkam ist dabei unbestritten. Falls mir bis morgen Abend keine Universallösung eingefallen ist, werd ich es einfach als Option integrieren, ob Kontrollpackete mit oder ohne Verzögerung gesendet werden sollen.

Edit:
und als kleines Schmakerl: reask sources after IP-change ist bereits fertig, tests bestanden, neue Version die auch Kad berücksichtigt.

das finde ich echt super - für das feature nehm' ich auch dieses eigenartige uploadverhalten in kauf :mrgreen:

PS: tests sind in arbeit und ergebnisse gehen dir heute noch zu, vielleicht hilft es dir ja dann noch beim finden der universallösung.

Konnte heute leider nicht viel testen, da ich im Abi-Stress stecke.
Ich habe jedoch versuchsweise eine andere Netzwerkkarte von Realtek anstatt meiner 3Com in Betrieb genommen. Dies hat allerdings auch keinen Erfolg gezeigt. Die neue Version erzeugt einfach haufenweise Upload-Overhead.
Übrigens meine gelbe Linie (bei Volllast ca. 13 kb/s) ist auch ziemlich weit von der weißen (UL-Maximum: 10.5 kb/s) entfernt, aber das war bei mir seit dem Implementieren dieses Graphen der Fall. Habe auch leider keine Zeit, die 4.1er auch noch mit der Realtek Netzwerkkarte zu testen, aber bei der 4.2er gab es beim Umstieg von 3Com auf Realtek keine merklichen Unterschiede.
Naja wie auch immer, ich würde eine Option zum Abschalten dieses Features auch sehr begrüßen, da die 4.2er ansonsten wieder extrem gut zu laufen schien ... (habe jetzt wieder die 4.1er am laufen, will ja auch etwas Hochladen).

hallo Xman,
da bin ich auch mal gespannt! ich benutze dazu noch den connection-checker!
gruss, cyrex2001.

@Hanussen
find ich gut, daß das prompt mal jemand ausprobierte. Nun ja... hat wohl nicht jeder so einen gravierenden Unterschied wie ich. Wie schon erwähnt ist die Frage eh, welche Netzwerkchips nun genau den Bug haben... das ist leider nur per sniffer rauszufinden.

@cyrex2001
so revolutionär ist mein code nun auch nicht ;-) Ich verhindere nur das triggern, wenn die vom server neu bekommene HighID mit der Kad-IP übereinstimmt und diese Kad-IP mehr als 5 Minuten bekannt ist. Dies verhindert, daß die sourcen neu abgefragt werden, wenn ich z.b. lange nur über Kad verbunden war und erst später den Server dazuschalte.
Welche Aufgabe hat dein connection-checker in diesem Zusammenhang ?

1. ist es nicht mein con-checker sondern der aus dem ewombat.
2. er überprüft die inet-verbindung ständig
gruss, cyrex2001.

wow ich weis zwar net warum der 4.2 geht jetzt auf einmal und rennt wie blöd .... heftig ul/dl 1:11 ?!?!?!?!

xman es ist komisch... why ?! ich habe meinen alten xtreme 2.2 ordner kopiert und dort die 4.2.exe rein... web* hinzugefügt und lang auch.... esel angemacht und nach nicht mal 1 !!! h diese leistung !

hardcore oder ?!?!?!?!

jaja cyrex, das weiß ich schon von wem er ist und was er tut...
die frage ist: was hat das ganze mit reask sources after IP-change zu tun ?

@drfreak2004
schön, daß er bei Dir so gut geht. Bei mir selbst rennt er auch extrem gut.

ich hab bei mir 3 möglichkeiten, den ip-wechsel zu bemerken, über den serverconnect, kad und con-checker! diese werden bei mir überprüft.
gruss, cyrex2001.

den IP-wechsel per Kad testen zu lassen und dann das Feature triggern zu lassen hab ich mir auch schon überlegt... wär auch nicht schwierig... doch gibt es da ein großes Problem:
Kad braucht teilweise 20 Minuten um den IP-wechsel zu bemerken. In den 20 Minuten ist ein Großteil der Quellen eh schon auf ganz normalem Weg neu abgefragt.

genau deswegen hab ich den conchecker!
gruss, cyrex2001

so mal ne kurze meldung... also 4.2 bricht nach etwas über 10 h zusammen.... ul:0.0 dl:10... wran liegt das ?!?!?!

mfg

was heißt bricht zusammen ? und upload=0, download=10... ist noch jemand drin im Upload ? Was sagt das VerboseLog ? Bischen mehr Infos mußt Du schon geben!

nenene... kann gerade dir nur schreiben... das ul/dl zusammenbrachen... nach 5 min startet er wieder durch.... nafc ?!