@ Xman,:beer:
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:whistle , hatte nur gepostet was mir aufgefallen war. :wink:

Mit freundlichen Grüssen
mav744 :

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.

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.

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 ******** :mrgreen: 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

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)

hi xman,

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

wie man sieht von morph....

:beer:

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

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

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.

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)

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

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:shock:

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

zusatz 2: emule rennt wieder im dl wie vorher

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

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

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

Das mit der CPU-Last beruhigt mich, da ich bei meinem PC keine Änderungen feststellen konnte... allerdings ist ja bekanntlich jeder PC etwas anders ;-)
Das mit dem Upload incl Overhead hast Du gut beobachtet... das werd ich aber so drin lassen weil:
a) der offizielle emule macht das auch so.. nur siehst Du es nicht und außerdem ist dort im Overhead der TCP und UDP Header nicht mitkalkuliert.
b) Du hattest Dich doch immer beschwert, daß Du bei anderen emules den Upload nicht erhöhen kannst, da er sonst instabiel wird. Ich sagte Dir noch: warte aufs Bandwidthcontrol, das wird dies regeln. Und genau das macht es. Ist der Overhead zu hoch, werden weniger Datenpackete geschickt. Ist der Overhead gering, werden mehr Datenpackete geschickt. Folglich kannst Du nun den Upload von vornherein höher stellen, ohne Angst zu haben er bricht bald ein.
Um es nochmal konkret zu sagen: viele Stellen den Upload auf nur 10, weil sie wissen, daß manchmal starker Overhead entsteht und das den Muli ausbremst. Damit vergeudet man Bandbreite bei geringerem Overhead. Rechnet man den Overhead in den Upload mitein, so kann man diesen höher stellen.

Am besten ist allerdings NAFC: Hier wird der gesamte Internettraffic direkt vom Betriebssystem abgefragt. Hast Du NAFC aktiviert und Deinen Upload z.b. auf 15 eingestellt, so gibt emule genau so viel an Datenpacketen raus, bis die 15 kb gesamter Internet-Upstream erreicht sind. Vorsicht: um Mißbrauch vorzubeugen (z.b. andere Anwendungen verbraten bereits viel Upload) schaltet sich das Downloadlimit ein, wenn Dein reeller Upload unter 10 geht.

Dieses Feature ist bereits finktionstüchtig integriert. Anschalten läßt sich es in der preferences.ini, Section Xtreme, NAFCFullControl=1
Vernünftige Uploadeinstellungen in Zusammenhang mit diesem Feature sind ca. 0.5 - 1 kb unter der reell möglichen Maximaluploadkapazität. (bitte Wert selbst austesten).
Anmerkung: Nach Internettrennung muß evtl. NAFC wieder neu aktiviert werden. Wird sich in späteren Versionen aber ändern.

Habe jetzt mal NAFC aktiviert und siehe da es funzt jetzt so wie es soll (ich bekomme mehr realen Upload hin). Die stats sieht zwar schlimm aus dadurch, aber ichn habe ja auch leider immer diesen monströsen Overhead den ich einfach nicht in den Griff bekomme (Habe deine Tipps schon befolgt). Auf kurz oder lang brauche ich wohl eine Verbindung, die zumindest einen grösseren Upload bereitstellt. Das andere habe ich mir schon gedacht, nur wenn ich den Upload auf über 12 stelle, habe ich nachher 9 Slots die je mit 1-2 KB/s bedient werden. Jetzt lasse ich den X3Alpha mal so laufen, vielleicht spielt es sich dann mit der zeit wieder ein.

Mit freundlichen Grüssen
mav744

EDIT um 21 UHR:Die Quellenfindung ist langsamer als beim originalen und den Vorgängerversionen und der Download kommt bei mir nicht so in schwung wie bei den obengenannten Versionen. Die Einstellungen sind die gleichen wie bei den Vorgängerversionen. Dies ist aber nur auf meinem System, ich kann nicht beurteilen wie der X3Alpha2.2 bei anderen läuft. Ich lasse ihn aber weiterlaufen, zu testzwecken.

hi xman,

so 2.2 drauf... quellenfindung etwas langsamer aber der dl geht sofort los wie ne rakete ! spinn i nach 5 min ul 16 dl 50 ! cool... läuft super bis jetzt... das andere prob von oben tauchte nimmer auf !

Am Download / Quellenfindung wurde nichts geändert. Warum ich den Download dennoch als "to test" angegeben hab liegt daran, daß der phoenix damit probleme hat und dieser verwendet auch Maellas Bandwidthcontrol.
Wenn die Ergebnisse auch morgen noch stimmen und keine Bugs zu finden sind, dann werd ich morgen die nächsten Änderungen vornehmen..... wir sind schließlich noch ganz am Anfang.

habe die 2.2 jetzt auch seit gut 2stunden am laufen...könnte nicht sagen das die quellenfindung
langsamer als bei der 2.1 ist ...
er macht 5->8 slots auf bei eingestellten 32kb/s upload( 7kb/s pro slot) der dl kommt auch so langsam in schwung
NAFC ist aktiviert

Hallo Xman,
der X3Alpha läuft stabil, er kommt mir nur ein bisschen schwerfälliger vor als die Vorgängerversionen. Mein Download kommt auch nicht so in schwung wie bei den vorgängerern und der originalen :huh. Das Problem mit der hohen slotanzahl hat sich bei mir leider nicht erledigt, der X3Alpha öffnet immer zwischen 8-9 Slots mit je 1-2 KB/s. Ich muss dann mit dem Uploadlimit sehr stark runtergehen, was ich aber nicht möchte, um die slots zu ereichen die ich haben möchte (so 4-6 Slots a 3-4 KB/s). Ansonsten funzt alles so wie es soll. (DSL 128/768, UP Limit 14/Down ohne)

Mit freundlichen Grüssen
mav744

Der x3alpha läuft jetzt seit ca.14 Stunden stabil durch.Der Dowload ist auch O.K.Bei mir macht er
5-10 Slots auf davon dann 3-6 Volle und der rest Trickleslots bei einem Eingestellten Upload von32kb/s.

Habe jetzt doch einen Bug gefunden.Wenn ich übers Netzwerk ein file zu meinem 2 Computer
sende geht der Upload auf null.Sowas hatte ich bisher noch nie.

@daenmark:
hast Du dabei NAFC aktiviert und bist zufällig über einen Router im Netz ? Dann wäre das so zu erklären, daß NAFC den Netzwerkadapter überwacht und da dort plötzlich enorm viel Verkehr herrscht regelt es den Upload runter. In diesem Fall wäre die Aktivierung von NAFC nicht zu empfehlen.
@NAFC:
auch bei Dir stimmt was in der Uploadeinstellung nicht. Du schriebst zuletzt, der Upload sei inkonstant bei aktiviertem NAFC. Die Frage ist: was ist inkonstant ? Bei aktiviertem NAFC sollte die gelbe Linie möglichst gerade sein.. sonst die weiße.

@all
Ich überlege gerade ob ich noch eine kleine Änderung vornimm... und zwar kann ich den Upload, nach den ersten Tests zu urteilen, sehr stabilisieren, wenn ich nicht wie die offizielle Version gleichzeitig 2 Packete, sondern nur eines schick. Die offizielle Version glättet leider den Uploadgraphen so sehr, daß man gar nicht sieht, wenn es kleine Instabilitäten gibt.

@ Xman
Ja NAFC ist aktiv und ja ich gehe über Router in Netz.Werde dann mal NAFC deaktivieren.

2.2 läuft soweit ganz ok....

alle tests ohne besondere auffälligkeiten...

das einzige was halt immer noch ist da schon in der org net ganz sauber ... der langsame dl sobald der kad bei mir an ist.. deswegen deaktiviert !

kurzer Zwischenstand:
Ich denk, ich hab den Upload nun so wie ich ihn haben wollte. Absolut gerade Linie! Na ok.. sagen wir: so gerade wie im Xtreme2.2. Warum er nie sooo gerade wie in der offiziellen Version ist ? Ganz einfach:
Man kann doch das Updateintervall für den Statistikgraphen in den Einstellungen einstellen. Beim Xtreme wird bei Einstellung von z.B. 5, alle 5 Sekunden der Durchschnitt der letzten 5 Sekunden angezeigt. In der offiziellen Version wird alle 5 Sekunden der Durchschnitt der letzten 30 Sekunden angezeigt.
Wie wollt es ihr haben ? Soll ich auch mehr glätten, oder das System beibehalten ? Es ist keine Arbeit dies zu ändern, lediglich eine einzelne Variable.

Lasse es doch mal so ,dann können wir uns selbst davon überzeugen.

also ich wäre eher für die detailliertere Messung und Anzeige, von künstlich glattbügeln halte ich nichts ...

Ciao
Rumpelzuck

Lass es doch so wie es ist, das ist ja genauer. Was soll ich mit ner anzeige die einiges Schönfärbt. Habe KAD ausgeschaltet und jetzt rennt der muli wieder, hatte vorher keine probs mit Kad, aber habe mir mal eure Posts durchgelesen und es dann abgeschaltet.

Mit freundlichen Grüssen
mav744

Kurzer Zwischenstand:
Erstmal noch zur 2.1er - die lief einfach nur spitze. Die Graphen waren zwar schon recht sprunghaft aber eine solche Genauigkeit bei der Anzeige halte ich auch für sinnvoller, wenn man den Graphen glättet. Man kann viel sinnvoller die Netzwerkaktivitäten seines Rechner überwachen und analysieren. Daher finde ich auch die neue gelbe Linie mit dem Network-Adapter Durchsatz sehr sinnvoll. Ich finds gut wenn ich in Emule sehen welchen Traffic andere Downloads verursachen.

Bei der 2.2er haben sich nun ein paar Sachen, nicht sehr, aber etwas verändert. Ich habe DSL 768/128, was ich aber zumindest mein Upload laut diversen Speedtests nicht erreiche. Beim Upload gehen maximal 14 kb/s, weshalb ich 75% davon, also 10.5 als Upload Maximum in Emule eingetragen habe. Bei der 2.1er wars nun so, dass diese 10.5 kb/s im Durchschnitt von Graphen mit der weißen Linie, also eMule control + data angezeigt wurde. Networtk Adapter war etwas darüber und reiner Datendurchsatz etwas darunter. Bei der 2.2er ist es jetzt aber so, dass der Network Adapter, also der gelbe Graph, sich ständig im Bereich 10.5 kb/s aufhält. Der reale Datendurchsatz ist daher im Moment im Durchschnitt bei 7.2, jedoch weiter fallend. Bei der 2.1 waren es 8.6, bei der Alpha 1.3 sogar 9.1 kb/s. Wie ist das zu erklären?
Die erfolgreichen Upload- und Downloadsessions haben sich jedoch im Gegensatz zum 2.1er um jeweils etwas 3-6 % erhöht und liegen jetzt bei 90 bzw. 80%.
Was auch auffallend ist, sind unmögliche max. Downloadraten von 100-600 kb/s, die immer mal wieder für Sekunden in der Statistik auftauchen und von der Kapazität der Leitung her nicht zutreffen können.
Quellen findet er schnell und der Download ist auch ok (40-60 im Moment, nach 2:45 Std.), wenn er auch beim 2.1er meines Errachtens etwas schneller angefangen hat runterzuladen und auch am Anfang schon höhere Werte erzielt hat. Aber gut, das mag verschiedene Ursachen haben.

Ach ja, CPU Last: Ich wills nicht beschwören, aber ich würde behaupten, dass sie um 1-3% im Durchschnitt gestiegen ist.

Upload Slots: 4 schwarze mit 1.5-2.0 kb/s und 1-3 graue. Eingestellter Upload Slot Speed 2.8 kb/s.

Ansonsten fällt mir auf die Schnelle nichts ein.

Ich bin auch noch etwas deprimiert, da vorhin meine Festplatte zicken gemacht hat und nach einem Neustart mit ScanDisk Durchlauf fast 100 GB Daten gefehlt haben, die ich auch nicht mehr wiederherstellen konnte ;-(
Teste und lade aber trotzdem fleißig weiter, jetzt erst recht.

Gruß

die Meinung scheint wohl einstimming zu sein: also keine Glättung.
Warum der Upload zuletzt etwas zackig war: füllt man ein Faß mit großen Steinen, so wird die Oberkante des letzten Steines meistens entweder ein Stück über oder unter dem Deckelrand sein. Mit kleineren Steinen kann man "schöner" füllen... darum wird die nächste Version (heute Nacht noch), nur noch ein Packet, statt bisher ein Doppelpacket schicken. Bin dann auf eure Erfahrungen mit der nächsten Version gespannt.

@Hanussen
scheint so als hättest Du NAFC aktiviert ? mal in den preferences.ini nachsehen, ob "NAFCFullControl=0" (=aus) drinsteht.
Zu allen anderen Fragen kann ich nur sagen: von der 2.1 zur 2.2 hat sich fast gar nichts geändert. Wie im changelog beschrieben, hab ich nur einen Bug bei friendslots gefixt und das Neuzeichnen von Transferlistitems optimiert. Von daher kann ich vor allem im Bezug auf Erfolgreiche Sessions und wann Quellen gefunden werden/Upload beginnt nur sagen: das sind Dinge die hängen sehr stark vom Zufall ab. Noch sind keine Änderungen gemacht die diesen "Zufall" optimieren würden.
Kurzzeitige sprunghafte megadownloadraten sind eine krankheit schon des offiziellen emules. Wobei dies gar nicht an emule liegen muß (sondern z.b. firewall). Zumindest blockt kurzfristig ein Prozess den emule-Download-Verarbeitungsprozess und daher entstehen diese Raten.

ganz allgemein noch zu den Uploadslots:
der Upload ist nicht zu hoch und arbeitet ok, wenn keiner der Trickles über mehr als 10 Sekunden mehr als 400 - 600 Bytes bekommt.

Neue Testversion x3alpha2.3
-------------------------------
new:
- send one packet (statt zweien)
- ein paar eher nebensächliche Code-Verbesserungen, den Upload betreffend
- nach einer Zwangstrennung und evtl Verlust des NAFC-Adabters (bei WinXp, falls man über DFÜ-Netzwerk verbindet), wird NAFC nach wiedererkennung des Adabters reaktiviert

to test:
Upload
NAFC springt auch nach Zwangstrennung wieder an ?

Download: binaries&sources

changelog
alpha2.3
- reenable NAFC after adapter-change (loss of internet connection) (to be tested)
- some codeimprovemets to Xtreme Upload
- Uploadsocket: send only one package each loop (gives a smoother upload)
- sendbuffersize=8192
- increased Min-Size for FullChunks to 2.8 MB



Anbei noch ein Bildchen:
Anfangs: so sieht ein Upload aus, falls NAFC aktiviert. Während der Zwangstrennung natürlich kein Upload. Dann eine kurze Steilkurve, dies deutet auf das WinXP-DFÜ-Netzwerk hin. Hier wurde gerade der Adapter neu erkannt und sendet dabei kurz mal eben einen unendlichen Wert. Am Ende noch seht ihr wie der Upload mit ausgeschaltetem NAFC aussehen sollte.

http://xtreme.emule-web.de/alpha/Upload.JPG

Hallo Xman,
der Upload ist jetzt bei mir besser als bei der X3Alpha2.2, jetzt habe ich auch nur noch 4-6 Slots (3-4 volle slots und 2-3 Trickle Slots) die so bedient werden wie ich es wünsche. Die Einstellungen sind natürlich wie immer die gleichen. Ich habe mal zum vergleich einen Screenshot der X3alpha2.2 und der X3Alpha 2.3 vom Upload hochgeladen. Bei beiden war NAFC aktiviert.

Mit freundlichen Grüssen
mav744

EDIT NACH ZT:NAFC springt bei mir nach ZT nicht wieder an. In der Preference.ini ist es wieder deaktiviert (automatisch). Windows 2000 Prof. SP4

Ich höre gar kein Feedback mehr von euch !? Funzt die letzte Version ?

Wer mir einen gefallen tun möchte sollte folgendes tun:
nach 24 Stunden Lafzeit, die komplette Statistik (mit allen Werten, auch die unrelevaten, auf die man nie schaut) in einer Textdatei speichern... dazu noch eine Bemerkung, welche Version benutzt wurde und ob KAD verbunden war.

Dies brauchen wir für später, wenn ich mich an einige tiefergreifende Änderungen ranmache (in Versin 3.x und 4.x). Dort müssen wir dann einige Werte vergleichen um zumindest grob zu sehen, daß alles stimmt.

ok ich mach nen testlauf.... ab 10 uhr bis morgen 10 uhr

edit: wow nach 1 1/2 h guter lauf ohne kad und nafc ist an... geh über router raus.... sehr sauberer lauf !

ein mega lob der mod lässt meine cpu links liegen 1% auslastung geil !:clap

So die 2.3 läuft seit ca.23 Stunden ohne Probleme.Upload ist O.K. Er macht 4-6 volle und
1-3 Trickle Slots auf( ohne NAFC ).
@Xman
Soll ich dir meine Statistik senden ? Wenn ja,wo hin?

@daenemark:
momentan brauchst Du sie nicht senden... es wird später interessant, wenn es ans vergleichen geht. Noch hab ich ja keine neue Version die ich vergleichen kann. Also erst mal auf Platte lagern.

Ich geb euch dann bescheid, wenn ein vergleich lohnt. (kann aber noch ne Woche dauern, also nciht ungeduldig werden ;-) )

Ich habe Dir ein erstes Feedback gegeben, zu den sachen wo "to test" stand. Dies waren die Erfahrungen der ersten 12 Stunden, bzw. nach ZT. Den Rest teste ich noch. :beer:

Mit freundlichen Grüssen
mav744

@mav:
Du warst ja auch die Ausnahme ;-)

Eine Aussage von mir muss ich aber revidieren. NAFC wird bei der ZT doch nicht in der Preference.ini zurückgesetzt. Ich habe den Wert von 0 auf 1 vor dem Starten des X3Alpha 2.3 gesetzt und gespeichert. Dann schaltet es sich auch nach der ZT nicht mehr ab. Wenn ich den Wert aber im laufenden Muli Betrieb verändere, dann stellt er sich bei der ZT wieder auf den Ursprungswert (20 mal reproduziert :shock: ).
Sorry, my vault :bang

Mit freundlichen Grüssen
mav744