[eMule-Web] - eMule 0.45b Xtreme 3.0 final [03.05.2005]

[eMule-Web] (http://www.emule-web.de/board/)

- Xtreme MOD (http://www.emule-web.de/board/xtreme-mod/)

- - eMule 0.45b Xtreme 3.0 final [03.05.2005] (http://www.emule-web.de/board/9442-emule-0-45b-xtreme-3-a.html)

eMule 0.45b Xtreme 3.0 final [03.05.2005]

Xtreme 3.0
--------------------------------------------------------------------

http://xtreme.emule-web.de/pics/xtreme_logo.gif

Main Features:

- Maella Bandwidthcontrol
- big parts of uploadmanagement is rewritten
- removed zz-downloadmanager, replaced with Xtreme-Downloadmanager
- improved Xtreme-Creditsystem
- Powerrelease with dynamic Hide OS
- hundrets of code improvements

based on emule 0.45b
compiled with:
libpng 1.2.7
zlib 1.2.1
crypto 52.1
CxImage version 5.99a

Code:

changelog Xtreme 3.0 (final)

- fixed two sorting bugs

- disabled new Xtreme-Splashscreen on Win9x (crashed on that OS)

- removed many Verbose-Messages which are only usefull on beta-state

- changed: use more UDP - less TCP (need now less connections)

- changed: the real slotspeed should now be closer to the wanted

- patch: don't answer wrong filereaskpings, (remote client using incorrect protocol)

Code:

changelog Xtreme3.0 beta2

- changed few default settings

- avoid "silly window syndrome" on limited download (= receive always n*MAXFRAGSIZE)

- added an option to statistics where you can choose if you want accurate or smooth graph

- tweaked few slot-opening conditions

- few internal bugfixes

Code:

changelog Xtreme 3.0 beta1

- rewritten most parts of Uploadbandwidthtrottler

- Threadsave Bandwidthcontrol (thx Maella)

- Maella -Accurate measure of bandwidth: eDonkey data + control, network adapter-

- NAFC - Network adapter Feedback Control - (Maella)

- Include ACK to Overhead (TAG: //XMan Include ACK)

- automatic NAFC-Adapter-Selection (only works if you are connected to server) (TAG: Xman new Adapter Selection)

- possible bugfix of official code InsertIntoUploadlist

- 80% score for non SI-clients

- accept only clients which asked the last 30 minutes

- clients wich timeout on US_CONNECTING get a second changed on reconnect (TAG: //Xman uploading problem client)

- increased queue-purgetime to 80 minutes

- min 11 upload for unlimited download!

- friend-uploads get an slot on connect under same conditions as LowIDs

- MTU-configuration (Maella/Xman)

- changed uploading-sendbuffersize to 6000 

- don't accept uploads if no internetconnection

- Xtreme Full Chunk (TAG: //Xman full chunk)

+ full block system: upload doesn't stop befor a complete block (180kb) isn't transfered (other than in official)

+ lower CPU 

+ FullChunkMode: min 2,5 MB will transfered, after that, emule looks at the chunkboarder. uploads ends if either a chunk at the downloader is completed, or 9.30MB are completed

+ anticipate if a new slot is needed: if a slot is near the end , new slot is opend if needed

- Allow Bandwidth Settings in <1KB Incremements- (Maella)

- New bandwidth control (downloading) (Maella/Xman)

- Support for tag ET_MOD_VERSION 0x55 (Maella/Slugfiller/Xman)

- improved sockethandling / Exceptionhandling in Listensocket 

- dynamic IP-filters (clients wich cause an exception are filtered 12 houers)

- option to not open more slots (recommend setting: open more slots if needed)

- fixed an official bug in emsocket (don't try to send until socket is ready for sending)

- adjusted the score calculatoin.. should now also work with high slotspeeds

- added an option to preferences->Xtreme to use doublesendsize

remark: you can try to use this, if you have choosen a high slotspeed(>5), this can help to increase the datarate, given to each client

but this option let your uploadgraph show a little "unstable".. this is a technical reaction

- closed two backdoors (TAG: //Xman close Backdoor v2)

- spread reasks (Maella/Xman)

- reworked statistics (few parts taken from TPT)

- codeimprovement to the quelistupdating (TAG: //Xman faster Updating of Queuelist)

- added //Xman Xtreme Downloadmanager (many changes!)

+ includeds all features of Xtreme2.2

+ manual/automatic dropping (without refinding same sources right after that)

+ manual A4AF Handling (without the risk to get banned)

+ manual stoping of single downloading source

- Maella -Unnecessary Protocol Overload- (modiefied by Xman) (this feature is used by Xtreme Downloadmanager)

- Maella -Extended clean-up II- (modiefied by Xman) (this feature is used by Xtreme Downloadmanager)

- show time until next UDP-reask/TCP-reask in downloadlistctrl-Client-Info-Tip

- retry connection attempt before adding to deadsource-list

- some timeout improvemets (didn't touched the peercache-sockets)

- reworked the maintimer (avoid doing too many actions at the same time)

- winsock2 (ewombat)

- Reask sources after IP change- v2 (Maella/Xman) (TAG: //Xman -Reask sources after IP change- v2)

+ new version take care of kad. If the IP(HighID) received from server was already detected by Kad for more than 5 minutes, reask sources doesn't trigger. This prevents a fail-trigger, if you are only connected to kad and decide later to also connect to a server

- reconnect Kad on IP-change (TAG: //Xman reconnect Kad on IP-change)

- askfordownload priority first ask the sources which are most urgent (TAG: //Xman askfordownload priority )

- Maella Smart Low ID check

- accepting download from non ONQUEUE-clients if emule is connected

- allow queue overflow with minimumcontingent (TAG: //Xman allow queue overflow with minimumcontingent)

- SLS + some improvements (Xman, Maella, enkeyDEV(Ottavio84)

- see own credits (VQB)

- Xtreme Credit System

- see sourcecount found per categorie in transferwindow (TAG: //Xman see all sources)

- changed format of data (bytes/kb/Mb...)

- see how many clients are waiting for each file at sharedfilelist (TAG: //Xman see on uploadqueue)

- changed auto-upload-prios. (>100->Low, >20->nowmal, <=20 High)

- shared-files-AvailPartFrequency is initialized with 0 (better to see which chunks are missing)

- Show AVGQR instead of remaining-time

- bugfix of official emule, which shows wrong source-count in statistics if a file was stopped

- Xman Chunk Selection Patch

- fixed a official bug in banning clients

- fixed: memory exception when sources of a server where added

- PowerRelease (TAG: //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)

- cleaned up Preferences->Tweaks, removed USS

- added an option to Log Dropping messages

- color LowID-clients in downloadlistctrl

- some codeimprovements in drawing of chunkbars (Maella/Xman)

- IP to country (Eastshare/ morph)

- friendhandling from all windows (TAG: //Xman friendhandling)

- Preferences Fix (tHeWiZaRdOfDoS)

- added Xtreme Icons

- Fixed UTF-8 strings on web searchs (Monki)

- always enabled createcrashdump during the alpha/beta-test

- Anti-Leecher-Log (TAG: //Xman Anti-Leecher-Log)

- Anti-Leecher with codes of Morph, ewombat and IONIX (TAG: //Xman Anti-Leecher)

- Mighty Knife: Static server handling (morph)

- show requested files (sivka/Xman)

- Fix For Incorrect Corruption Stats (netfinity)

- searchCatch (SLUGFILLER)

- option to change process prio (parts of code from TPT) (TAG: //Xman process prio)

- many other improvements

remark:
- this mod has no USS (use nafc instead!)
- this mod doesn't allow unlimited uploadspeed
- the adjustable slotspeed is not an accurate speed, but a tolerant(can go 25% over the settings). Xtreme Mod decide itself how much slots are needed to best fit your slotspeed
- the uploadlimit is applied to overhead + data
- if you use NAFC, the uploadlimit is applied to whole networktraffic (also other applications) and downloadlimit is automatically adjusted
- the overhead includes TCP/IP + UDP-Header + blockpackage-header + ACK-packets
- because the uploadlimit is applied to data + whole overhead, you have to set your upload to min 11kbs to get unlimited download, but please set it to about 90% of your uploadcapacity

Download: http://www.xtreme-mod.net

Achtung:
- dieser Mod besitzt kein UploadSpeedSence (stattdessen kann NAFC benutzt werden)
- unlimitierter Upload wird nicht unterstützt
- die eingestellte Slotspeed ist keine genaue Vorgabe. Sie kann 25% mehr betragen, aber auch weniger, wenn die Clients keine hohe Speed abnehmen.
- Das eingestellte Uploadlimit gilt für Daten + Overhead
- Bei Verwendung von NAFC gilt das Uploadlimit für den kompletten Internetverkehr(alle Anwendungen werden berücksichtigt). Mit NAFC wird das Downloadlimit automatisch geregelt
- Im Overhead wird zusätzlich noch miteingerechnet: TCP/IP + UDP-Header + blockpackage-header + ACK-packets
- da das Uploadlimit den gesamten Overhead beinhaltet ist das Uploadlimit auf mindestens 11 kbs zu stellen um unlimitierten Download zu bekommen. Empfohlener Upload: 90% der Kapazität.

An dieser Stelle noch ein Dankeschön an meine alpha-Tester.
thanks to emule-web.de for supporting me and for the nice logo.
special thanks to ikabot (phoenix mod) not only for his friendship but also for his mod. It answered me many questions and helped me with unicode-related problems
Most of all, I thank to Maella. He was aleays present when I had a question... and I had a lot! Thank you for your great code and all your efforts you did for emule.

Das Prinzip des Xtreme-Uploads
Wie jeder weiß, heißt wird es grundsätzlich empfohlen das Uploadlimit des emules auf ca. 80% der Leitungskapazität zu setzen. So manche Leute setzen es sogar noch sehr viel weiter herunter, damit es den Download nicht stört. So mancher Leechermod wirbt sogar damit, daß der angeprießene Mod 0 Upload ermöglicht, da dies wesentlich besseren Download ermöglicht.

Was ist dran an der Aussage: Upload bremst Download und warum wird oft empfohlen den Upload auf nur 80% der Kapazität zu setzen ?
Die offizielle emule-Version unterscheidet nur zwischen Upload(Datenupload: Bild-Item1) und Overhead(Bild Item2). Als Overhead rechnet die offizielle Version hierbei nur die Größe eines Kontrollpacketes. Was hierbei nicht berücksichtigt wird ist, daß das Betriebssystem an jedes versandte Packet noch einen Kopf anhängt (TCP-Header, UDP-Header). Bei kleinen Packeten kann es sein, daß so ein Header größer als das eigentliche Packet ist. Gerade bei vielen gleichzeitigen Verbindungen werden sehr viele Kontrollpackete verschickt, was den zusätzlichen TCP/UDP-Header-Overhead vergrößert. Der im unteren Bild markierte Bereich 3, also die Fläche zwischen rosa Linie und weißer Linie soll diesen Overhead veranschaulichen.

Zusätzlich zum gerade eben besprochenen Overhead muß für jedes empfangene Packet ein Bestätigungspacket gesendet werden (ACK-Packet). Auch diese Packete zählt die offizielle Version nicht. Bereich 4 im Bild soll veranschaulichen wieviel zusätzlicher Overhead durch diese ACK-Packete entsteht bei hohem Download. Ist man am Uploadkapazitätslimit so können ACK-Packete nicht mehr schnell genug gesendet werden und sowohl Download als auch Upload können einbrechen.

Um solche Probleme zu minimieren wird empfohlen den Upload auf nur 80% der Kapazität zu setzen.

Bereich 5 soll noch einen zusätzlichen Overhead veranschaulichen, nämlich den des Netzwerkadapters. Tatsächlich fließen nämlich noch etliche Bytes Upload mehr über die Leitung als zunächst beschrieben. Zu bisherigem Overhead können sich nämlich noch "Retransmissions"(fehlerhaft übertragene Packete die durch windows neu übertragen werden), Ping-Signalen auf die man antworten muß, aber auch der Upload von anderen Programmen (z.b. Browser) hinzugesellen.
http://xtreme.emule-web.de/docs/up1.GIF

Der Xtreme Mod arbeitet anders.

Er versucht den entstehenden Overhead inklusiv TCP/UDP-Header und ACK-Packeten soweit wie nur irgendwie möglich abzuschätzen. Das im Xtreme eingestellte Uploadlimit umfaßt somit Daten, Kontroll-Packete und die dazugehörigen Header, und die ACK-Packete. Bild Bereich 2 veranschaulicht die Gesamtsumme des Overheads. Der DatenUpload selbst (Bild Bereich 1) wird heruntergeregelt damit die weiße Linie möglichst stabil gehalten werden kann. Durch das System kann das Uploadlimit wesentlich höher eingestellt werden, die Bandbreite effektiver genutzt werden und auch der Download wird niemals durch den Upload ausgebremst. Der Netzwerkverkehr (Bild Bereich 3)) bleibt unberücksichtigt.

http://xtreme.emule-web.de/docs/up2.GIF

Was ist NAFC ?

Das "Network adapter Feedback Control" richtet den emule-Upload nach dem am Netzwerkadapter gemessenem Gesamtupload aller Anwendungen aus. Das in emule eingestellte Uploadlimit berücksichtigt somit nicht nur emule-Daten, sondern alle Upload-Packete aller Anwendungen (Webbrowser, Onlinegames, FTP-Upload usw.).

Ist beispielsweise der Upload auf 15 kbs eingestellt und eine Internettelefonie verbraucht 5 kbs Upload, so sendet emule nur noch 10 kbs an Daten. Durch dieses Verfahren wird eine geringere Pingzahl gewährleistet und die Uploadkapazität am optimalsten ausgenutzt. Bei Verwendung von NAFC läßt sich das Uploadlimit ganz dicht unterhalb der Uploadkapazität einstellen. Das dritte Bild veranschaulicht nochmal wie die Summe aus Upload Daten (1) + Overhead + restlicher Netzwerkverkehr (3) den bei NAFC eingestellten Wert ergibt.

Um Mißbrauch des Features vorzubeugen, schaut emule nach ob die gemessenen Daten emule-Daten sind oder Daten anderer Anwendungen. Sind die gesendeten emule-Daten (Nutzdaten + Overhead) kleiner als 11 kbs, so schaltet sich dynamisch ein Downloadlimit ein.

NAFC funktioniert nicht wenn man ein Heimnetzwerk verwendet und gemeinsam mit anderen Rechnern per Router ins Internet geht.
http://xtreme.emule-web.de/docs/up3.GIF

Kleine Anmerkung am Rande:

Die Bilder sind keine Screenshots sondern wurden durch Paint erstellt. Sie sollen nur das Prinzip veranschaulichen aber keine reellen Werte wiederspiegeln. Durch Latenzzeiten, Windows-Einstellungen und die Netzwerkkarte können die Graphen mehr oder weniger gezackt aussehen.

Normale Screenshots können so aussehen:
(NAFC ausgeschalten)
http://xtreme.emule-web.de/docs/up5.GIF
Erklärung zu den Spitzenwerten bei Kreis 1 und Kreis 2:

Bei 1 dürfte es sich um typischen Browserverkehr handeln... es wurde also eine Webseite geladen.
Kreis 2 zeigt eine typische, kurzzeitige Auslastung von emule an. Dies kann mehrere Gründe haben:
- ein anderer Prozess stahl emule die benötigte Rechenzeit
- Der CD/DVD-Brenner blockierte den IO-Bus (kommt häufig vor beim schreiben des Lead-In)
- Ein anderes Programm (z.b. der Explorer) tätigte gerade einen Schreib-/Lese-Vorgang auf der Festplatte, während emule auch gleichzeitig Daten der Platte lesen/schreiben wollte.

Gratz zum release, werd mich gleich mal durch's Changelog lesen. Hoffe du bekommst gute Resonanz!

MFG Stulle

Werde ihn mir auch mal anschauen, die Aplhas sahen ja ganz gut aus.

Mit freundlichen Grüssen
mav744

für die alpha-Tester möchte ich nur kurz anmerken:
die beta hat keine großen Änderungen mehr.. lediglich ein paar marginale Bugfixes und den splashscreen.

Ich bin's nochmal. Hab n paar Sachen, die ich bemerkt hab oder wo ich fragen hab:

Zitat:

- accept only clients which asked the last 30 minutes

Wo akzeptieren¿ In der UL queue¿ Wenn ja, warum¿ Versteh das feature nicht ganz und hab meine Bedenken wie es mit Timer for ReAsk File Src zusammenarbeitet.

Zitat:

- New bandwidth control (downloading) (Maella/Xman)

Wo ist der Unterschied zu NAFC¿ Arbeitet es nur mit NAFC¿ Kannst du mir dazu bitte n paar Ausführungen zukommen lassen¿

Zitat:

- dynamic IP-filters (clients wich cause an exception are filtered 12 houers)

Rechtschreibfehler... hours.

Außerdem habe ich überlegt NAFC in meine Mod zu implementieren... 2 Dinge, wärst du grundsätzlich bereit mir etwas zur Hand zu gehen wenn ich Fragen hab¿ Und hättest du überhaupt Zeit dafür¿ Weiterhin würde mich interessieren ob es etwas spezielles zu beachten gibt.

MFG Stulle

1. ja, die Uploadqueue ist gemeint. Ganz einfacher Patch der schon im Xtreme 2.0 enthalten war. Clients, welche seit mehr als 30 Minuten kein Lebenszeichen mehr von sich gaben bekommen keinen Uploadslot (weil sie höchstwahrscheinlich offline sind). Keine Angst.. sie werden nicht aus der Warteschleife rausgeschmissen sondern verbleiben dort min 80 Minuten... melden sie sich wieder bekommen sie auch wieder Upload.
2. "bandwidthcontrol" meint hier, daß der Download -die Kontrolle darüber - auf andere Art und Weise funktioniert als im offiziellen emule. Kommt aber nur bei limitiertem Download zum Einsatz.
3. NAFC zu implementieren dürfte Dir wohl nicht so einfach gelingen... entweder Du schreibst es in großen Teilen um... oder Du nimmst den meinigen Code... das würde dann aber bedeuten, daß Du das gesamte Bandwidthcontrol übernehmen mußt welches hunderte und mehr Codeänderungen bedeutet. Da bist Du einfacher dran, wenn Du meinen Mod als Basis nimmst und allen Morph-Eastshare-Code dort einbaust.

xman

dumme Frage; ist am Ende das "!" zuviel?

Zitat:

23.04.2005 19:24:55: Failed to download and install selected language dll from http://langmirror2.emule-project.org/lang/045159/de_DE.dll!

Ich bekomme leider keinen konstanten Upload hin.
Es schwankt immer zwischen 8 - 12. Meistens bleibt es dann eine Zeit lang bei 10 stehen.
Das limit steht bei mir auf 12.
Slot Speed ist 2,8.

@Paul2
schaut so aus... eigentlich sollte er gar keine deutsche Sprachdatei runterladen, da die im Packet enthalten ist. Tat er aber bei mir auch... vielleicht hab ich ne falsche Version erwischt... der Download von emule-project klappte bei mir dann aber wunderbar.

@Ragnarök
beachte, daß die weiße Linie konstant sein muß (zumindest einigermaßen).

Edit: Nachtrag:
Ich hab wirklich die falsche Sprachdatei reingepackt... macht aber nix... emule lädt automatisch die richtige vom Server.

hab dasselbe problem wie ragnarök.

average datarate over seconf: bei 11 oder 12
UL grenze bei 13kb/s

dümpelt immer bei 8-9 rum

eMule v0.45b Xtreme 3.0b1 Statistik [Hopie]

Upload
Upload-Geschwindigkeit: 9.7 KB/s
Durchschnittliche Uploadrate: 9.9 KB/s
Max. Uploadrate: 12.2 KB/s
Max. durchschnittliche Uploadrate: 10.3 KB/s

NAFC an
open more: off

bei aktiviertem NAFC muß die gelbe Linie konstant sein.

die gelbe liegt so bei eingestellten 13kb/s, aber muss/sollte unten in der leiste nicht auch 13kb/s stehen?

steht meist nur 8 9 oder 10kb/s

Auf den MOD hab ich ewig gewartet. THANX und Gracias X-Man und Aplha-Tester8-)

@Hopie
ist vielleicht verwirrend... und vielleicht sollte ich es in zukünftigen Versionen ändern... in der Statusleiste steht der reine Datenupload... das Uploadlimit bezieht sich aber auf den kompletten Overhead (bei NAFC: den kompletten Internetverkehr)
Übrigens: openmore slots sollte an sein, damit werden neue Slots geöffnet, falls die bisherigen den Speed nicht nehmen können. Bei Slotspeed von 2.8 sollte es kein Problem sein, aber sicher ist sicher.

joa.. wäre besser wenn du es ändern könntest :)

hatte vorhin mal open more slots aktiviert, aber dann hatte ich 7 slots offen mit ca. 1,5kb/s
slot speed war bei 4

nach 2,5h laufzeit.. schaut gut aus

Zitat:

eMule v0.45b Xtreme 3.0b1 Statistik [Hopie]

Transfer
Session UL:DL Ratio: 1 : 2.24
Session UL:DL Verhältnis (ohne Freundesupload): 1 : 2.24
Gesamte UL:DL Ratio: 1 : 2.24
Uploads
Session
Hochgeladen: 89.26 MB
Hochgeladene Daten durch Freundesuploads (Session): 0 Bytes
Aktive uploads/nötig um Bandbreite auszunutzen: 2
Gesamtanzahl der Uploads: 4
Wartende Uploads: 2535
Upload Sessions: 23
Erfolgreiche Upload-Sessions: 18 (78.26%) (active: 4, socket: 5, completed: 9, cancelled/ended: 0, different file: 0, exception: 0, others: 0)
Fehlgeschlagene Upload-Sessions: 5 (21.74%) (socket: 3, completed: 0, cancelled/ended: 2, different file: 0, exception: 0, others: 0)
Durchschnittlicher Upload pro Session: 4.96 MB
Durchschnittliche Upload-Dauer: 56:34 Minuten
Totaler Overhead (Pakete): 6.67 MB (135.98K)
Gesamt
Downloads
Session
Heruntergeladen: 199.92 MB
Beendete Downloads: 0
Aktive Downloads: 13
Gefundene Quellen: 4021
Download Sessions: 112
Erfolgreiche Download Sessions: 73 (65.2%) (active: 13, paused: 0, no needed part: 4, timeout: 16, socket: 21, out of part: 18, exception: 0, others: 1)
Fehlgeschlagene Download Sessions: 39 (34.8%) (paused: 0, no needed part: 2, timeout: 6, socket: 29, out of part: 0, exception: 1, others: 1)
Durchschnittlicher Download pro Session: 2.74 MB
Durchschnittliche Downloadzeit: 16:06 Minuten
Durch Komprimierung gewonnen: 4.73 MB (2.4%)
Durch Datenfehler verloren: 0 Bytes (0.0%)
Teile gerettet durch I.C.H: 0
Totaler Overhead (Pakete): 6.61 MB (138.15K)
Gesamt
Verbindung
Session
Allgemein
Erneute Serververbindungen: 0
Aktive Verbindungen (geschätzt): 121 (Halb:8 | Komplett:44 | Andere:69)
Durchschnittliche Verbindungen (geschätzt): 130
Verbindungsspitze (geschätzt): 282
Verbindungs-Limit erreicht: 0
Upload
Upload-Geschwindigkeit: 10.1 KB/s
Durchschnittliche Uploadrate: 9.7 KB/s
Max. Uploadrate: 12.2 KB/s
Max. durchschnittliche Uploadrate: 10.3 KB/s
Download
Download-Geschwindigkeit: 28.6 KB/s
Durchschnittliche Downloadrate: 21.7 KB/s
Max. Downloadrate: 51.4 KB/s
Max. Downloadrate Durchschnitt: 21.7 KB/s
Gesamt
Zeit Statistiken
Letzter Reset der Statistiken: 23.04.2005 18:23:07
Zeit seit letztem Reset: 2:31 Stunden
Session
Programm-Laufzeit: 2:37 Stunden
Übertragungszeit: 2:37 Stunden (99.9%)
Dauer auf aktuellem Server: 2:37 Stunden (99.9%)
Dauer auf Servern: 2:37 Stunden (99.9%)
Gesamt
Programm-Laufzeit: 2:37 Stunden
Übertragungszeit: 2:37 Stunden (99.9%)
Dauer auf Servern: 2:37 Stunden (99.9%)
Abschätzungen
Clients
Server
Freigegebene Dateien
Festplattenplatz

Ich habe NAFC aktiviert.
Es ist ein kleines Bischen konstanter geworden.
Aber ich komm trotzdem nicht an 12 kb/s.
Es bleibt immer zwischen 10 - 10,9

@Ragnarök
es ist genau so wie es sein soll. Der Graph könnte zwar etwas weniger gezackt sein... das hängt aber mit vielen Faktoren zusammen: Firewall, Netzwerkkarte, Netzwerkeinstellungen usw.
Wie gesagt.. es ist so wie es sein soll.. Deine weiße Linie ist auf der 12.
Tipp: Du kannst Deinen Upload ruhig auf 14 erhöhen.. evtl. sogar noch höher.

Hier mal ein screenshot wie der Upload aussehen darf:
links mit NAFC.. rechts ohne:
http://xtreme.emule-web.de/alpha/Upload.JPG

Wobei das noch ein screenshot von einer älteren Version ist, deren Code noch nicht optimiert war.

OK ... ich habe meinen Upload jetzt auf 13,5 gestellt und es bleibt bei + - 12 kb/s.
Nur finde ich das bischen störend. Beim offiziellen eMule war das ein absolut gerader Strich und das fand ich auch gut so. Aber egal. Läuft bis jetzt super. :beer:

http://img172.echo.cx/img172/7302/unbenannt32mn.th.jpg

Der zackige Graph zeigt dir eigentl. nur ein realistischeres Bild! Wenn du die average zeit für den graphen beim offiziellen auf 5 sec senkst, dann sieht die welt auch ganz anders aus!

MFG Stulle

ich werd wahrscheinlich noch eine Option einbauen, ob man lieber einen "smooth" graph oder einen accurate graph sehen will. Ist keine große Sache.

Wenn du es tust wäre ich für eine wählbare Sekundenzahl. Da du ja aber eher auf wenig Einstellungen und mehr Effekt Wert legst, Schalter.

MFG Stulle

PS: Schau mal plz in der Coder's Corner vorbei. Thx

Ich fände es schön wenn der Speed für Downloads und Uploads mit 2 Stellen hinterm Komma angezeigt wird. Vielleicht sogar Wahlweise.

@Verrückter Esel
die zweite Nachkommastelle würde nur 0 Informationsgehalt darstellen, da hier keine Genauigkeit mehr besteht.

@all
Ich hab auf der zweiten Seite dieses Thread mal ein bischen was zur Funktionsweise des Uploads erklärt.

Programm-Laufzeit: 13:50 Stunden, läuft stabil und gleimäßig ohne groß zackige Ausschläge.

PHP-Code:

    eMule v0.45b Xtreme 3.0b1 Statistik [***]
 
Transfer
Session UL:DL Ratio: 1 : 2.51
Session UL:DL Verhältnis (ohne Freundesupload): 1 : 2.76
Gesamte UL:DL Ratio: 1 : 1.54
Uploads
Session
Hochgeladen: 514.74 MB
Hochgeladene Daten durch Freundesuploads (Session): 45.95 MB
Aktive uploads/nötig um Bandbreite auszunutzen: 3
Gesamtanzahl der Uploads: 4
Wartende Uploads: 4061
Upload Sessions: 71
Erfolgreiche Upload-Sessions: 68 (95.77%)
Fehlgeschlagene Upload-Sessions: 3 (4.23%)
Durchschnittlicher Upload pro Session: 7.57 MB
Durchschnittliche Upload-Dauer: 54:11 Minuten
Totaler Overhead (Pakete): 21.17 MB (458.07K)
Overhead durch Dateianfragen (Pakete): 8.59 MB (330.25K)
Overhead durch Quellenaustausch (Pakete): 2.89 MB (1.81K)
Overhead durch Server (Pakete): 41 KB (973)
Kad Overhead (Pakete): 74 KB (2.17K)
Gesamt
Downloads
Session
Heruntergeladen: 1.26 GB
Beendete Downloads: 0
Aktive Downloads: 7
Gefundene Quellen: 2973
In Warteschleife: 2546
Voll: 290
Keine benötigten Teile: 108
Nachfragen: 0
Empfange Hashset: 0
Verbindung wird hergestellt: 13
Verbinde über Server: 0
Zu viele Verbindungen: 0
Verbindung LowID zu LowID unmöglich: 0
Problematisch: 0
Gebannt: 0
Andere Datei angefordert: 358
Unbekannt: 9
via eD2K Server/Queue: 189
via Kad: 3
via Quellenaustausch: 1375
via Passive: 847
eD2K: 2947 (99.1%)
Kad: 1684 (56.6%)
eD2K/Kad: 1669 (56.1%)
UDP Datei-Neuanfragen: 56.19K, Fehlgeschlagen: 5.22K (9.3%)
Tote Quelle: 666 (615 + 51)
Download Sessions: 360
Erfolgreiche Download Sessions: 250 (69.4%)
Fehlgeschlagene Download Sessions: 110 (30.6%)
Durchschnittlicher Download pro Session: 5.17 MB
Durchschnittliche Downloadzeit: 22:02 Minuten
Durch Komprimierung gewonnen: 59.15 MB (4.6%)
Durch Datenfehler verloren: 360 KB (0.0%)
Teile gerettet durch I.C.H: 0
Totaler Overhead (Pakete): 21.65 MB (501.85K)
Gesamt
Verbindung
Session
Allgemein
Erneute Serververbindungen: 0
Aktive Verbindungen (geschätzt): 91 (Halb:3 | Komplett:41 | Andere:47)
Durchschnittliche Verbindungen (geschätzt): 90
Verbindungsspitze (geschätzt): 226
Verbindungs-Limit erreicht: 0
Upload
Upload-Geschwindigkeit: 10.6 KB/s
Durchschnittliche Uploadrate: 10.6 KB/s
Max. Uploadrate: 12.8 KB/s
Max. durchschnittliche Uploadrate: 10.9 KB/s
Download
Download-Geschwindigkeit: 26.4 KB/s
Durchschnittliche Downloadrate: 26.6 KB/s
Max. Downloadrate: 130.0 KB/s
Max. Downloadrate Durchschnitt: 39.6 KB/s
Gesamt
Zeit Statistiken
Letzter Reset der Statistiken: 23.04.2005 21:47:03
Zeit seit letztem Reset: 1 Tage 10:05 Stunden
Session
Programm-Laufzeit: 13:50 Stunden
Übertragungszeit: 13:49 Stunden (99.9%)
Dauer auf aktuellem Server: 13:49 Stunden (99.9%)
Dauer auf Servern: 13:49 Stunden (99.9%)
Gesamt
Abschätzungen
Clients
Bekannte Clients: 6390 
Client-Software
Netzwerk
Port
Niedrige ID: 907 (14.2%)
Identifikation (pos : neg): 6081 (95.2%) : 21 (0.3%)
Problematisch: 0 (0.0%)
Gebannt: 114
Gefiltert: 422
Leecher 824
Server
Freigegebene Dateien
Festplattenplatz

Hi Xman,

erst einmal ein grosses Kompliment für diese Beta.
So grossartig ist schon lange kein Mod mehr bei mir gelaufen. Nicht einmal der Morph 6.7 kommt da mit.
Ich war nun mal 2 Tage nicht zu Hause und da dachte ich mir, dass ich Deine Version mal einem Langzeittest unterziehe.
Fazit: Einfach nur Klasse :mrblue:. Sehr stabil. Extrem wenig CPU-Last und nach nunmehr 2,5 Tagen Programm-Laufzeit ca. 65MB Speicherauslastung.

Folgend nun mal meine Statistik. Und natürlich noch ein paar Eckdaten zu meiner Konfiguration.
- CleanInstall gemacht
- System ist XP Prof.
- DSL 1000 mit Tiscali-Flat
- HardLimit: 180 / Max. Verbindungen: 500
- Upload Limit: 12kB / SlotSpeed: 2.4kB
- Max. Verbindung pro 5sek: 40 / Max. halboffene Verbindungen: 25
- 31 aktive Downloads / 36 shared

Code:

eMule v0.45b Xtreme 3.0b1 Statistik [[GSB] ofenheizer]

  

  Transfer

     Session UL/DL Ratio: 1 : 3.74

     Session UL/DL Verhältnis (ohne Freundesupload): 1 : 3.74

     Gesamte UL/DL Ratio: 1 : 3.74

     Uploads

            Session

                   Hochgeladen: 1.86 GB

                   Hochgeladene Daten durch Freundesuploads (Session): 0 Bytes

                   Aktive uploads/nötig um Bandbreite auszunutzen: 4

                   Gesamtanzahl der Uploads: 6

                   Wartende Uploads: 2003

                   Upload Sessions: 853

                  Erfolgreiche Upload-Sessions: 773 (90.62%) (active: 6, socket: 180, completed: 567, cancelled/ended: 19, different file: 0, exception: 1, others: 0)

                  Fehlgeschlagene Upload-Sessions: 80 (9.38%) (socket: 61, completed: 0, cancelled/ended: 3, different file: 0, exception: 16, others: 0)

                          Durchschnittlicher Upload pro Session: 2.46 MB

                          Durchschnittliche Upload-Dauer: 25:34 Minuten

                   Totaler Overhead (Pakete): 219.95 MB (3.10M)

            Gesamt

     Downloads

            Session

                   Heruntergeladen: 6.95 GB

                   Beendete Downloads: 7

                   Aktive Downloads: 4

                   Gefundene Quellen: 3273

                          In Warteschleife: 2902

                          Voll: 210

                          Keine benötigten Teile: 122

                          Nachfragen: 0

                          Empfange Hashset: 12

                          Verbindung wird hergestellt: 9

                          Verbinde über Server: 2

                          Zu viele Verbindungen: 0

                          Verbindung LowID zu LowID unmöglich: 0

                          Problematisch: 0

                          Gebannt: 0

                          Andere Datei angefordert: 732

                          Unbekannt: 12

                          via eD2K Server/Queue: 78

                          via Kad: 4

                          via Quellenaustausch: 957

                          via Passive: 2234

                          eD2K: 3234 (98.8%)

                          Kad: 2004 (61.2%)

                          eD2K/Kad: 1989 (60.8%)

                         UDP Datei-Neuanfragen: 284.57K, Fehlgeschlagen: 41.77K (14.7%)

                          Tote Quelle: 1.08K (1.00K + 82)

                   Download Sessions: 2281

                  Erfolgreiche Download Sessions: 1902 (83.4%) (active: 4, paused: 0, no needed part: 38, timeout: 316, socket: 585, out of part: 959, exception: 0, others: 0)

                  Fehlgeschlagene Download Sessions: 379 (16.6%) (paused: 0, no needed part: 0, timeout: 240, socket: 113, out of part: 25, exception: 1, others: 0)

                          Durchschnittlicher Download pro Session: 3.74 MB

                          Durchschnittliche Downloadzeit: 21:37 Minuten

                   Durch Komprimierung gewonnen: 108.08 MB (1.5%)

                   Durch Datenfehler verloren: 11.83 MB (0.2%)

                   Teile gerettet durch I.C.H: 4

                   Totaler Overhead (Pakete): 154.66 MB (3.35M)

            Gesamt

  Verbindung

     Session

            Allgemein

                   Erneute Serververbindungen: 6

                   Aktive Verbindungen (geschätzt): 113 (Halb:0 | Komplett:29 | Andere:84)

                   Durchschnittliche Verbindungen (geschätzt): 114

                   Verbindungsspitze (geschätzt): 375

                   Verbindungs-Limit erreicht: 0

            Upload

                   Upload-Geschwindigkeit: 8.7 KB/s

                   Durchschnittliche Uploadrate: 9.0 KB/s

                   Max. Uploadrate: 11.4 KB/s

                   Max. durchschnittliche Uploadrate: 9.3 KB/s

            Download

                   Download-Geschwindigkeit: 8.4 KB/s

                   Durchschnittliche Downloadrate: 33.6 KB/s

                   Max. Downloadrate: 105.7 KB/s

                   Max. Downloadrate Durchschnitt: 36.0 KB/s

     Gesamt

  Zeit Statistiken

     Letzter Reset der Statistiken: Unbekannt

     Zeit seit letztem Reset: Unbekannt

     Session

            Programm-Laufzeit: 2 Tage 12:13 Stunden

            Übertragungszeit: 2 Tage 12:13 Stunden (100.0%)

            Dauer auf aktuellem Server: 2:13 Stunden (3.7%)

            Dauer auf Servern: 2 Tage 12:12 Stunden (100.0%)

     Gesamt

     Abschätzungen

  Clients

     Bekannte Clients: 4318 

     Client-Software

     Netzwerk

     Port

     Niedrige ID: 425 (9.8%)

     Identifikation (pos : neg): 4017 (93.0%) : 19 (0.4%)

     Problematisch: 0 (0.0%)

     Gebannt: 114

     Gefiltert: 16116

     Leecher 3253

  Server

  Freigegebene Dateien

  Festplattenplatz

Hallo

Ich habe ein kleines Problem und ich glaube, dass es mit dem Xtreme Mod zutun hat.
Wenn ich Miranda laufen habe und dann eMule starte, dann verliere ich schon nach wenigen Minuten die Verbindung von mehreren Miranda-Protokollen. Eine Wiederverbindung war nicht möglich. Ich dachte, dass das Zufall ist und hab es einfach gelassen. Doch sobald ich eMule ausgemacht habe, hatte ich sofort wieder eine Verbindung mit Miranda.

Kann das sein?

Edit :

Ok ... jetzt bin ich mir sicher. Es ist 3 Mal hintereinander passiert.

passiert Dir das mit dem standard emule auch ?

Nein, ist mir noch nie passiert.

stelle mal die höhere Prozess-Piorität auf normal in den xtreme-Einstellungen

Zitat:

Zitat von Paul 2

stelle mal die höhere Prozess-Piorität auf normal in den xtreme-Einstellungen

Nope ... selbes Problem.

Um jetzt 100 % sicher zu sein, werde ich den offiziellen Esel installieren und nochmal schauen. Aber wie gesagt ... das ist mir dem offiziellen noch nie passiert.

@Xman

ich habe einen bug entdeckt. ist zwar eher optischer natur und beeinträchtigt keinerlei funktionalität, aber ich will ihn trotzdem kundtun.
folgendes szenario:
ich bin über einen router mit dem internet verbunden. die verbindung geht per wlan.
die wlan-karte im pc hat die eigenart manchmal die verbindung zum router zu unterbrechen. dieses problem konnte ich bisher nicht einkreisen, ist aber so. manchmal mehrmals am tag für sekunden, manchmal, wie jetzt geschehen nach 7 tagen, für längere zeit.
heute war die unterbrechung für längere zeit - also hab ich die netzwerkkarte deaktiviert und sofort wieder aktiviert und prompt war die verbindung zum router wieder hergestellt.
dein mod hat auch sofort, wie es sich gehört, seine arbeit wieder aufgenommen - also alle quellen wieder abgefragt.
nun zum fehler:
in der statistikanzeige fehlen seitdem die graphen für "network adapter" im download und upload.

wie gesagt, nur ein schönheitsfehler.

ich hoffe, ich konnte dir den fehler ausreichend beschreiben, wenn nicht, dann melde dich ruhig nochmal bei mir.
dieses verhalten kann ich einfach reproduzieren.

greetz
ofenheizer

ist nicht nur ein Schönheitsfehler... auch NAFC würde dann nicht mehr funktionieren.
Es ist schwer dieses Verhalten zu beseitigen (Bug ist es keiner)... der Netzwerkadapter fiel aus... tja... ich könnte nun alle x Millisekunden abfragen ob denn nicht schon wieder ein Neuer verfügbar ist. Allerdings verbraucht das zu viel Ressourcen und betrifft auch nur diese spezielle von Dir geschilderte Ausnahme. Darum werd ich diesbezüglich den Code auch nicht ändern.
Was Du machen kannst, nachdem der Adapter ausfiel (im Verbose-Log sollte hierzu übrigens ein Warnhinweis stehen)... ist einfach nochmal zu irgendeinem Server connecten. Nach jedem Serverconnect startet die NAFC-Adapter-Auswahl neu.

stimmt, wenn nafc ausfällt, ist das kein schönheitsfehler.
betrifft dann wahrscheinlich wirklich nur mich :yes:.
der muli hat sich doch nachdem adapterausfall automatisch wieder mit einem server verbunden, weil ja die verbindung komplett unterbrochen war. ich habe zwar nicht genau ins verbose gesehen, aber es stand keine meldung bezüglich nafc drin (nach dem neuverbinden) - und der muli lief danach auch genauso gut weiter.

macht sich denn der ausfall von nafc noch anders bemerkbar, ausser dass die graphen fehlen?

da die beta jez wieder superrund läuft, werde ich morgen mal mit absicht den adapter aus- und wieder einschalten und die ganze sache mal mitloggen.

Zitat:

macht sich denn der ausfall von nafc noch anders bemerkbar, ausser dass die graphen fehlen?

wenn Du in den Einstellungen kein NAFC aktiviert hast, macht es sich gar nicht bemerkbar.. .falls aktiviert, er hat aber einen falschen NAFC-Adapter gefunden hättest Du ein Problem, falls er keinen fand gilt die Standard-Uploadeinstellung.

ofenheizer

Kann es sein, dass Du den TIMER im Router "nicht" deaktiviert hast ? Bei meinem Router (Sitecom) muss ich das auch expliziet machen.

Januar

Hier mal eine Statistik von mir

Code:

 eMule v0.45b Xtreme 3.0b1 Statistik [[MK.L]daenemark on Xtreme 3.0beta1]

Transfer

   Session UL:DL Ratio: 1 : 1.27

   Session UL:DL Verhältnis (ohne Freundesupload): 1 : 1.27

   Gesamte UL:DL Ratio: 1 : 1.26

   Uploads

      Session

         Hochgeladen: 7.41 GB

         Hochgeladene Daten durch Freundesuploads (Session): 0 Bytes

         Aktive uploads/nötig um Bandbreite auszunutzen: 6

         Gesamtanzahl der Uploads: 7

         Wartende Uploads: 3132

         Upload Sessions: 1276

            Erfolgreiche Upload-Sessions: 1223 (95.85%) (active: 7, socket: 187, completed: 970, cancelled/ended: 59, different file: 0, exception: 0, others: 0)

            Fehlgeschlagene Upload-Sessions: 53 (4.15%) (socket: 40, completed: 0, cancelled/ended: 11, different file: 0, exception: 1, others: 1)

            Durchschnittlicher Upload pro Session: 6.20 MB

            Durchschnittliche Upload-Dauer: 24:35 Minuten

         Totaler Overhead (Pakete): 237.06 MB (4.91M)

      Gesamt

   Downloads

      Session

         Heruntergeladen: 9.44 GB

         Beendete Downloads: 13

         Aktive Downloads: 18

         Gefundene Quellen: 3725

         Download Sessions: 2680

            Erfolgreiche Download Sessions: 2142 (79.9%) (active: 18, paused: 0, no needed part: 94, timeout: 402, socket: 700, out of part: 926, exception: 0, others: 2)

            Fehlgeschlagene Download Sessions: 538 (20.1%) (paused: 0, no needed part: 4, timeout: 244, socket: 282, out of part: 8, exception: 0, others: 0)

            Durchschnittlicher Download pro Session: 4.51 MB

            Durchschnittliche Downloadzeit: 27:01 Minuten

         Durch Komprimierung gewonnen: 431.23 MB (4.5%)

         Durch Datenfehler verloren: 2.60 MB (0.0%)

         Teile gerettet durch I.C.H: 3

         Totaler Overhead (Pakete): 209.45 MB (5.05M)

      Gesamt

Verbindung

   Session

      Allgemein

         Erneute Serververbindungen: 2

         Aktive Verbindungen (geschätzt): 138 (Halb:1 | Komplett:33 | Andere:104)

         Durchschnittliche Verbindungen (geschätzt): 134

         Verbindungsspitze (geschätzt): 401

         Verbindungs-Limit erreicht: 4 : 24.04.2005 10:04:15

      Upload

         Upload-Geschwindigkeit: 28.3 KB/s

         Durchschnittliche Uploadrate: 28.4 KB/s

         Max. Uploadrate: 31.5 KB/s

         Max. durchschnittliche Uploadrate: 28.5 KB/s

      Download

         Download-Geschwindigkeit: 48.8 KB/s

         Durchschnittliche Downloadrate: 36.2 KB/s

         Max. Downloadrate: 178.9 KB/s

         Max. Downloadrate Durchschnitt: 37.1 KB/s

   Gesamt

Zeit Statistiken

   Letzter Reset der Statistiken: 14.03.2005 11:30:08

   Zeit seit letztem Reset: 44 Tage 1:11 Stunden

   Session

      Programm-Laufzeit: 3 Tage 3:51 Stunden

      Übertragungszeit: 3 Tage 3:50 Stunden (100.0%)

      Dauer auf aktuellem Server: 0 Sekunden (0.0%)

      Dauer auf Servern: 56:15 Minuten (1.2%)

   Gesamt

   Abschätzungen

Clients

   Bekannte Clients: 6687 

   Client-Software

   Netzwerk

   Port

   Niedrige ID: 841 (12.6%)

   Identifikation (pos : neg): 6379 (95.4%) : 45 (0.7%)

   Problematisch: 0 (0.0%)

   Gebannt: 194

   Gefiltert: 6913

   Leecher 5631

@daenmark:
viel Spaß beim brennen der 9.44 GB :mrgreen:

läuft bei Dir ja noch besser als bei mir.

@Xman
Danke werde ich haben.Der Mod ist dir aber auch wieder gelungen.
Bin sehr zufrieden.Bei mir läuft die besser,ist ja toll und das trotz Router,alle 12 Stunden ZT und nur
mit KAD.
Du hast jetzt bei der beta eine ipfilter.dat dabei getan.Ich hole die mir immer bei Open Media
,da wird die jede Woche erneuert.

jup...ist ein echt klasse mod :)
hab ich schon bei den ersten alphas gemerkt,das da was tolles kommt ;)