[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   eMule MOD - Development (http://www.emule-web.de/board/emule-mod-development/)
-   -   Xtreme Entwicklung - early alpha test thread (http://www.emule-web.de/board/9050-xtreme-entwicklung-early-alpha-test.html)

drfreak2004 15. March 2005 11:51

Hi Xman,

heute kurz vor zwölf brach der 3.1 zusammen. ul war schlagartig null ! nafc an. ich dachte mir erst nix dabei.... als dann auch plötzlich der dl weg war... würde ich stutzig ... verbindung zum server war da... also dachte ich reconnect und gut ist... doch dies klappte net. mod neu gestartet aber ich kam nicht mehr auf nen server oder ne kad verbindung. dachte ich ok irgendwie zuviel power aus dem netz gesaugt und auf der blacklist gelandet. modem resetet. nix gebracht. dachte des kann net sein. deinen xtreme 2.2 drauf ... sofort high id und durchstart.... ne idee was ich da habe ???

Xman 15. March 2005 12:11

na was sagte denn das Debug-Log so ? Und sagte die Windows-Ereignisanzeige was ?
Wenn Du den Mod neustartest, sollte eigentlich alles wieder zurückgesetzt sein, falls es ein Bug in meinem Code ist. Glaub aber jetzt erst mal nicht daran, daß es ein Fehler meinerseits sein könnte.

Xman 15. March 2005 14:26

ok.. das ist ein "offizieller Bug".. den auch schon andere bemerkt haben. Ich denke mal, das "Unheil" ist einzig und allein darauf zurückzuführen:
Zitat:

15.03.2005 11:44:42: Hashe Datei: "D:\123.gif"
15.03.2005 11:44:42: Duplicate shared files: "D:\1.gif" and "D:\123.gif"
15.03.2005 11:44:42: Failed to load known2.met file - A sharing violation occurred while accessing F:\x3alpha3.1\config\known2.met.
versteh ich net warum ?!
15.03.2005 11:44:42: AICH Hashset konnte nicht gespeichert werden! -> hab ich dir schon mal geschrieben
15.03.2005 11:44:42: 52 Server gefunden in server.met
wobei mich 2 Sachen wundern:
1.) Wieso verbindet er schon, bevor er Creddit-File und Server geladen hat ? Macht er das bei Dir immer so ? (auch die offizielle Version ?)
2.) Was hat es mit dem "123.gif" auf sich ? Warum muß er das kopieren ?

Was evtl dran schuld sein könnte ist, daß ein Virenscanner gerade Zugriff auf die Dateien hatte. Am besten das temp, das emule und das config-Verzeichnis nicht scannen lassen.

Ansonsten meine Empfehlung: probier den Fehler nochmal mit dem offiziellen emule nachzuvollziehen und poste es dann im emule-Allgemein-Forum.

drfreak2004 15. March 2005 14:34

die datei 123 und 1 sind tweety ver*****e bilder :-) aber das andere hatte ich auch damals bei der 44 org... jetzt weist warum ich froh bin das es den guten alten xtreme gibt.... also die verzeichnise werden gescannt aberr muss sein hängt mit auf meiner firmenleitung ( hat noch nie probs geben deswegen ).

und ja er verbindet sich schon immer so !

Xman 15. March 2005 16:55

laß ihn am besten noch automatisch connecten, sondern warte kurz bis alles geladen wurde und connecte manuell.
Es bringt nicht viel wenn Du temp-Ordner scannst. (solang Du die Vorschau-Option nicht nutzt).. wichtig ist lediglich der incoming-Ordner.

drfreak2004 15. March 2005 20:51

genau die vorschau nutz ich ;-) habe das log von 45b angefügt bei allgemein.
mfg

Xman 16. March 2005 19:01


Neue Testversion x3alpha3.2
---------------------------------

new:
- einige Änderungen um die Anzahl fehlgeschlagener Uploadsessions zu senken (ähnlich wie im Xtreme 2.2)
- Aktualisiere Warteliste in Echtzeit verbraucht nun fast keine CPU mehr. (wesentlich cleverer Code :wink: )
- Xman Creditsystem (wie im Xtreme 2.2)
- Auto-Upload-prios geändert. Abhängig wieviele clients in der Warteliste anstehen (>100->Low, >20->nowmal, <=20 High)
- etliche kleinere und größere Codeverbesserungen

to test:
- fehlgeschlagene Uploadsessions deutlich weniger ?
- alles was mit Upload zu tun hat, denn dieses Kapitel sollte nun abgeschlossen sein
- wie immer: Stabilität


Download: binaries & sources


changelog
alpha 3.2
- some codeinprovemets in otherfunctions,uploadclient, uploadqueue
- // WiZaRd memory exception fix
- Sort Order changed: do not sort downloading clients by speed
- 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 //Xman uploading problem client
- //Xman faster Updating of Queuelist
- increased queue-purgetime to 80 minutes
- knwonfile: removed GetQueuedCount, AddUploadingClient, RemoveUploadingClient. "see on uploadqueu" does this job now. (lower memory/CPU)
- changed auto-upload-prios. (>100->Low, >20->nowmal, <=20 High)
- see own credits (VQB)
- Xman Credit System

drfreak2004 16. March 2005 19:13

hi weist was komisch ist... hab die known2.met und known.met, und sämtliche AC*.dat files gelöscht. teste dies gerade.... wenn diese dateien gelöscht werden läuft es auf einmal au bei der org. mal schauen wie lange.....

X-Ray 16. March 2005 21:59

Hi Xman,

bei mir läuft jetzt auch die 3.2 und kann hoffentlich etwas positives zum Thema "fehlgeschlagene Uploadsessions" sagen. Denn bei der 3.1 zeigte mir die Statistik nach ca. 30 Stunden folgendes:
Zitat:

Erfolgreiche Upload-Sessions: 97 (16.61%)
Fehlgeschlagene Upload-Sessions: 487 (83.39%)
Durchschnittlicher Upload pro Session: 4.44 MB
Durchschnittliche Upload-Dauer: 59:04 Minuten
Die Downloadstatistik verhielt sich (zum Glück) umgekehrt: Erfolgreich 87%.

Die Verbose-Datei brachte folgende "-->" Einträge:
Zitat:

15.03.2005 22:05:29: -->Adding client, but last packet was: 146, ---ip--- 'UserA' (eMule v0.45b,OnQueue/Connecting)
16.03.2005 07:23:57: -->sending ACCEPTUPLOADREQ a second time: ---ip--- 'URL' (eMule v0.45b,OnQueue/Uploading)
16.03.2005 10:10:35: -->Adding client, but last packet was: 146, ---ip--- 'UserA' (eMule v0.45b,OnQueue/Connecting)
16.03.2005 12:19:35: -->sending ACCEPTUPLOADREQ a second time: ---ip--- 'URL' (eMule v0.44d,None/Uploading)
16.03.2005 12:36:40: -->sending ACCEPTUPLOADREQ a second time: ---ip--- 'UserB' (eMule v0.42g,OnQueue/Uploading)
Direkt nachfolgende Einträge waren "normal" und waren den Fehlern nicht zuzuordnen.
Eine Deutung des LOGs überlasse ich dem großen Meister :mrblue:

Version lief stabil.

Gruß,
X-Ray

Paul 2 17. March 2005 00:16

hi Xman

die 3.2alpha läuft bei mir stabil, was mir bei der UL Statistik auffiel war das die fehlgeschlagenen UL
mit der Zeit weniger wurden. Es waren mal 5 jetzt nur noch 3. auch die letzte Zahl scheint nicht so zu sein wie du dir das vorgestellt hast (others: 4294967290)
Zitat:

eMule v0.45b alpha3.2 Statistik [Laufzeit 4:45]

Upload Sessions: 55
Erfolgreiche Upload-Sessions: 52 (94.55%) (active: 7, socket: 22, completed: 19, cancelled/ended: 1, different file: 0, exception: 0, others: 3)
Fehlgeschlagene Upload-Sessions: 3 (5.45%) (active: 7, socket: 9, completed: 0, cancelled/ended: 0, different file: 0, exception: 0, others: 4294967290)
Durchschnittlicher Upload pro Session: 3.22 MB
Durchschnittliche Upload-Dauer: 39:39 Minuten

Xman 17. March 2005 00:58

hmm tja.. da scheint wohl ein kleiner Berechungswurm drin zu sein. ;-)
Ok, danke für die Info.. ich weiß wo ich zu suchen habe..
wegen der Zahl die sich veringert: einfach erklärt... ist wie schon beim Xtreme2.2... schlägt der Upload fehl, da der Socket nicht connecten konnte, so bekommt der Client eine zweite Chance, wenn er selbst zu Dir connected. Klappt dies, so wird das bei "fehlgeschlagen" wieder abgezogen.

@all:
ein kurzer Zwischenstand wie es weitergehen wird:
so ca. 30% der Arbeit sind nun getan. Noch ein paar Bugfixes und Verbesserungen, dann kommt ein ziemlich aufwendiges und kompliziertes Thema dran: Downloadoptimierung. Gerade wenn ich den Xtreme Downloadmanager einbau, wird es interesant werden die Statistiken der Vorversionen mit der dann aktuellen Version zu vergleichen. Ich hoffe, daß ich das soweit bis nächsten Dienstag hinbekomme, denn danach mach ich erstmal 2 Wochen Moding-Pause.
Anschließend gibt es noch 4 größere Themen:
- GUI überarbeiten
- Anti-Leecher-System
- etliche Codeverbesserungen
- Zusatzfeatures (z.b. Reask-Sources after IP-change)

daenemark 17. March 2005 08:07

So die 3.2 läuft jetzt seit ca.11 Stunden ohne Probleme.

Erfolgreiche Upload-Sessions: 187 (94.92%) (active: 6, socket: 23, completed: 138, cancelled/ended: 12, different file: 0, exception: 0, others: 8)
Fehlgeschlagene Upload-Sessions: 10 (5.08%) (active: 6, socket: 21, completed: 0, cancelled/ended: 5, different file: 0, exception: 0, others: 4294967280)

Und das sieht ja auch klasse aus.Freue mich schon auf deine nächste Test-Version.
Danke für deine Arbeit an dem Muli.:clap

Paul 2 17. March 2005 10:36

Zitat:

wegen der Zahl die sich veringert: einfach erklärt... ist wie schon beim Xtreme2.2...
einleuchtend, hatte soweit gar nicht gedacht
die UL Optimierung ist dir sehr gut gelungen, Danke
Programm-Laufzeit: 14:53 Stunden
Zitat:

Upload Sessions: 143
Erfolgreiche Upload-Sessions: 136 (95.10%) (active: 5, socket: 32, completed: 79, cancelled/ended: 13, different file: 0, exception: 0, others: 7)
Fehlgeschlagene Upload-Sessions: 7 (4.90%) (active: 5, socket: 21, completed: 0, cancelled/ended: 0, different file: 0, exception: 0, others: 4294967282)

Xman 17. March 2005 15:47

Neue Testversion x3alpha3.3
---------------------------------

new:
- ein paar Bugs gefixed
- vollständige Files werden im shared-files-fenster mit der Farbe rot initialisiert, um besser erkennen zu können welcher chunk anfragenden Clients fehlt


Download: binaries & sources


changelog alpha 3.3
- fixed some small bugs
- readded AddUploadingClient, RemoveUploadingClient (last version was a bad idea)
- shared-files-AvailPartFrequency is initialized with 0



Als nächstes geht es dann an die Downloadoptimierung. Hierbei werde ich wieder Maellas Code einbauen. Allerdings macht gerade dieser Code im Phoenix-Mod Probleme. Aus diesem Grund such ich für irgendwann die nächsten Tage jemand mit dem ich testen kann... und zwar sollte dieser jemand in der Lage sein mir einen konstanten Upload von min 40kbs z.b. mit per Slotfokus-Mod zu geben. Wer diese Kapazität zur Verfügung hat möge sich bitte per PM melden.

daenemark 18. March 2005 10:00

Moin,
die 3.3 läuft seit ca.15 Stunden ohne Probleme.
eMule v0.45b alpha3.3 Statistik [[MK.L]daenemark on x3alpha 3.3]

Upload Sessions: 263
Erfolgreiche Upload-Sessions: 253 (96.20%) (active: 6, socket: 41, completed: 193, cancelled/ended: 13, different file: 0, exception: 0, others: 0)
Fehlgeschlagene Upload-Sessions: 10 (3.80%) (socket: 9, completed: 0, cancelled/ended: 1, different file: 0, exception: 0, others: 0)

und das sieht ja auch gut aus.
Schönen Tag noch.

Paul 2 18. March 2005 12:57

Xman

wenn die Zeile Max. Uploadrate: in der Statistik keine annähernt realistische Werte anzeigt, sollte man sie vielleicht ganz weg lassen (habe 128/16 Leitung)
Zitat:

eMule v0.45b alpha3.3 Statistik [***]

Upload
Upload-Geschwindigkeit: 10.9 KB/s
Durchschnittliche Uploadrate: 10.2 KB/s
Max. Uploadrate: 31.9 KB/s
Max. durchschnittliche Uploadrate: 10.2 KB/s

Xman 18. March 2005 13:29

oder man sollte mal schauen, ob es da nicht was zu optimieren gibt !? ;-)

Den Downloadteil hab ich nun umgeschrieben und er scheint gut zu funktionieren. Ich teste noch etwas... und falls keine Probleme auftauchen gibt es heut noch die 4.0

Xman 18. March 2005 15:56

-------------------------------------------
Kapitel 4
- Optimierungen der Downloadroutinen -
-------------------------------------------
new:
- komplett anderer Code wann und wie die hertuntergeladenen Bytes eingelesen werden
- Patch um Peaks in der Statistik (maxUpload und maxDownload) zu vermeiden
to test:
- Downloadrate ok ?
- Stabilität ? (dieser Code sorgte dafür, daß der Xtreme2.0 instabil lief)
- bitte Probieren: ein paar Dateien auf Auto-Downloadpriorität und die Downloadrate limitieren (z.b. 96kb... hautpsache nicht 0)
- fehlgeschlagene/erfolgreiche Downloadsessions mit Statistiken früherer Versionen / offizieller Version vergleichen

Download: binaries & sources

changelog alpha4.0
- adapted Maella Bandwidthcontrol to regulate the download
- Patch by Phoenix for AutoDownloadpriorities
- reworked some parts by Xman
- patch to avoid peaks in statistics for maxUpload/Downloadrate

Anmerkung:
der nächste Schritt ist nun das entfernen von zz-Downloadmanager, den ich durch meinen eigenen ersetzen werde. Dies wird eine aufwendigere Geschichte und wird ein bischen Zeit in Anspruch nehmen

Paul 2 18. March 2005 19:50

alpha4.0

nach 3 Std stabiler lauf
UL 0 % fehlgeschlagen
fehlgeschlagene DL bisher 37 bis 40 % in der 3er Version, jetzt momentan 32 % bei Version 4
DL wird bei ca 90 ausgebremst, geht mit der 3er Version mit den Testdateien auf 117 bis 120 (im Org. auch)
Max. Downloadrate: wird als Obergrenze wohl das: Kapazität Download genommen wenn die Werte sehr hoch steigen

mav744 18. March 2005 20:14

X3Alpha 4.0 (Laufzeit 2.30 h)

Fehlgeschlagene Upload-Sessions: 9 (8.18%) (socket: 8, completed: 0, cancelled/ended: 0, different file: 0, exception: 1, others: 0)

Fehlgeschlagene Download Sessions: 15 (24.6%) (paused: 0, no needed part: 0, timeout: 1, socket: 14, out of part: 0, exception: 0, others: 0)

zum Vergleich X3Alpha 3.3
Fehlgeschlagene Upload-Sessions: 13 (9.70%)
Fehlgeschlagene Download Sessions: 79 (32.6%)

Bis jetzt läuft der X3Alpha4.0 stabil, auch wenn ich den Eindruck habe das er nicht so saugt wie der originale bzw. den X3Alpha Vorgängerversionen, aber viele Files sind mitlerweile auch schon fertiggestellt, wo grosse Downloadraten waren. Von den Files her lahmt der Vergleich also, desweiteren warte ich auf aussagekräftige Ergebnisse bei mir ersteinmal bis morgen früh. Ich hatte eigentlich immer bisher das Problem das jeder Muli so 1-3 h zum warmwerden brauchte, darum warte ich schon sehnsüchtig auf Reask Source after IP Change von Dir Xman, aus den bekannten Gründen ;)

Mit freundlichen Grüssen
mav744

masterai 18. March 2005 20:49

Hallo Xman

habe mich entschlossen deine alpha4.0 zu Testen.Kann mir noch kein Urteil bilden ,da diese Version erst
eine Stunde bei mir läuft. Die Warteliste hat die 5000 erreicht ,daß ist schneller als meine andere Version (eMule-0.45b-RT15a) die braucht dafür etwa 2 Stunde.
Eine Frage hab ich noch wird es einen Slotfokus geben um die min. u. max. Slots einzustellen?

Hochachtungsvoll masterai

mav744 18. March 2005 21:38

Hallo Xman,
aalerich und ich haben gerade etwas beobachtet, was wir dir gerne zeigen möchten. Es ist also eine Art "Live Bericht" von aalerich.

[21:13:09] aalerich: Wenn Du nachher nochmal reinschaust: Dein Download schwankt extrem. Innerhalb weniger Sekunden springst bzw. fällst Du um fast 10 kb/s. Eben bist Du innerhalb von 9 Sekunden von knapp 30 kb/s auf 0 Byte/s gefallen. Nachdem ich diesen letzten Satz geschrieben hatte warst Du schon wieder bei 12 kb/s.
[21:15:45] aalerich: Die Sprünge werden von keinen "Ruhephasen" unterbrochen; es geht pausenlos rauf und runter. Kein Verharren bei einem Tempo, auch nicht für kurze Zeit.
[21:18:50] *** Connected
[21:20:54] *** Verbindung getrennt
[21:22:30] *** Connected
[21:22:30] aalerich: Eben hast Du ziemlich genau 60 Sekunden("von Hand" mitgezählt) überhaupt nichts abgenommen, erstaunlich, daß Du nicht rausgeflogen bist. Dann bist Du exakt 8 Sekunden lang gleichmäßig schneller geworden und hast dann bei 17,8 kb/s einen Zwischenstopp eingelegt.
[21:23:29] mav744: ich teste gerade den neuen X3alpha4.0 vielleicht liegt es daran
[21:24:15] aalerich: Ja, ich weiß. Darum schreibe ich das ja auch. Ist für Xman sicherlich interessant.
[21:24:40] mav744: hmm wie drücke ich das nur am besten aus
[21:24:56] aalerich: Was denn?
[21:25:11] mav744: was du gerade beobachtest
[21:26:27] aalerich: Ich würde das einfach so posten, wie ich es geschrieben habe. Einfach dazuschreiben, daß das eine Art "Live-Bericht" war...Er versteht dann mit Sicherheit, wo das Problem liegt.
[21:27:37] aalerich: Jetzt bist Du doch rausgeflogen. Leider habe ich nicht gesehen, was dem Rauswurf konkret vorausging.

Kannst du Dir vielleicht vorstellen woran das liegt?

Mit freundlichen Grüssen
mav744 THX aalerich

Xman 18. March 2005 22:42

@masterai
nein gibt es nicht.. der Mod benutzt ein anderes System um die Anzahl der Slots zu regulieren

@mav:
danke.. interessante Beobachtung.. konnte sie allerdings bei meinen Tests nicht teilen. Evtl. liegt es daran, daß Du (wie Du weißt) enorm viel Overhead hast und Deine Leitung am Anschlag ist.
@aalerich:
Du hast also genügend Bandbreite zur Verfügung um auch mal "nen saftigen Upload rüberwachsen zu lassen" ? Schrieb ja schon auf der letzten Seite, ich such jemand bei dem ich mal testen könnte. Schreib mir ne PM, falls Du gewillt bist, mir mal einen Friendslot zu leihen ;-)

mav744 18. March 2005 22:56

@Xman

Ich möchte dir ja nicht wiedersprechen, aber so ein phänomen hatte ich bei der originalen und den Vorgängerversionen nicht, ansonsten hätte mich aalerich bestimmt darauf hingewiesen.Der Overhead ist zwar extrem hoch, aber sowas ist mit noch nicht aufgefallen. Das ganze ist aber noch mit vorsicht zu geniessen, da bei aalerich wohl etwas mit dem Speicher nicht stimmt und er morgen einen neuen einbaut und wir das dann nochmal testen.

Mit freundlichen Grüssen
mav744

aalerich 18. March 2005 23:04

Für die Öffentlichkeit :mrgreen: : Ich kriege erst morgen (Sonnabend früh) neuen Speicher (Versandhandel halt). Im Moment ist das also alles von meiner Seite aus noch mit Vorsicht zu genießen; ich weiß, daß mein Speicher kaputt ist, aber nicht genau, welche Auswirkungen das hat. Theoretisch ist wohl jede denkbare Fehlfunktion möglich. Morgen abend sind wir schlauer :-)

Mit freundlichen Grüßen
aalerich

Xman 19. March 2005 09:14

@mav
als du bei aalerich "getimeoutet" bist... hast Du bei Downloadlimit einen Wert oder 0 stehen gehabt ? Falls 0, probier doch mal dort was einzutragen und vergleiche ob dies zu besseren Ergebnissen führt. (am besten wir schnappen uns heute Abend nochmal den aalerich ;-) )

mav744 19. March 2005 09:39

@Xman
ja ich hatte eine 0 bei downloadlimit stehen, aber mehr als 85 KB/s gibt meine leitung sowieso nicht her laut DUMeter. Das Problem ist halt nur das wir uns wirklich aalerich schnappen müssen ;-) , da er sehr gezielt so hohe Uploadraten geben kann, auch über einen längeren Zeitraum. Wenn ich andere beobachte, dann springt der down zwar auch, ich habe bei solchen Uploadraten, von seiten anderer Clients, aber nicht so lange Zeit zu beobachten, da der Chunk dann ja auch schnell fertig wird. Ich setzte mein download limit jetzt mal auf 96 KB/s und werde weiter beobachten. Wenn aalerich dann heute abend Zeit hat, könnten wir es nocheinmal testen. (am besten einmal mit Downlimit und einmal mit keinem Downlimit, sprich einer 0).

Mit freundlichen Grüssen
mav744

daenemark 19. March 2005 10:16

Moin,
die 4.0 läuft jetzt seit ca.14 Stunden ohne Probleme.Alle DL`s stehen auf Auto.
eMule v0.45b alpha4.0 Statistik [[MK.L]daenemark on x3alpha 4.0]

Upload Sessions: 257
Erfolgreiche Upload-Sessions: 252 (98.05%) (active: 5, socket: 26, completed: 205, cancelled/ended: 16, different file: 0, exception: 0, others: 0)
Fehlgeschlagene Upload-Sessions: 5 (1.95%) (socket: 4, completed: 0, cancelled/ended: 1, different file: 0, exception: 0, others: 0)

Download Sessions: 394
Erfolgreiche Download Sessions: 273 (69.3%) (active: 9, paused: 0, no needed part: 14, timeout: 54, socket: 92, out of part: 102, exception: 0, others: 2)
Fehlgeschlagene Download Sessions: 121 (30.7%) (paused: 0, no needed part: 2, timeout: 24, socket: 95, out of part: 0, exception: 0, others: 0)
Die Fehlgeschlagenen Download Seesions lagen am Anfang bei 46%.
Ansonsten läuft er sehr stabil wenig CPU-Last.

masterai 19. March 2005 12:34

Zwischenbilanz an Xman
 
[QUOTE]eMule v0.45b alpha4.0 Statistik [emuleRE]

Transfer
Session UL:DL Ratio: 1 : 1.62
Session UL:DL Verhältnis (ohne Freundesupload): 1 : 1.91
Gesamte UL:DL Ratio: 1 : 1.62
Uploads
Session
Hochgeladen: 1.36 GB
Hochgeladene Daten durch Freundesuploads (Session): 212.62 MB
Aktive uploads/nötig um Bandbreite auszunutzen: 3
Gesamtanzahl der Uploads: 5
Wartende Uploads: 6246
Upload Sessions: 202
Totaler Overhead (Pakete): 59.98 MB (1.38M)
Gesamt
Downloads
Session
Heruntergeladen: 2.21 GB
Beendete Downloads: 2
Aktive Downloads: 26
Gefundene Quellen: 7721
Download Sessions: 833
Durch Komprimierung gewonnen: 142.54 MB (6.3%)
Durch Datenfehler verloren: 0 Bytes (0.0%)
Teile gerettet durch I.C.H: 0
Totaler Overhead (Pakete): 51.73 MB (1.39M)
Upload
Upload-Geschwindigkeit: 16.5 KB/s
Durchschnittliche Uploadrate: 17.3 KB/s
Max. Uploadrate: 24.8 KB/s
Max. durchschnittliche Uploadrate: 17.4 KB/s
Download
Download-Geschwindigkeit: 64.1 KB/s
Durchschnittliche Downloadrate: 28.0 KB/s
Max. Downloadrate: 136.2 KB/s
Max. Downloadrate Durchschnitt: 28.0 KB/s

Programm-Laufzeit: 22:55 Stunden
Übertragungszeit: 22:55 Stunden (100.0%

Gruß masterai

Hanussen 19. March 2005 12:35

Ersteinmal muss ich dir, Xman, großen Respekt aussprechen für deine Arbeit. Wirklich klasse!
Ich breche im Moment mit jedem deiner Updates meine eigenen Rekorde.
Die X3alpha 4.0 schöpft nun das volle Potential meiner Leitung (UL: max 14, DL: max 90 kb/s) aus.

Programm-Laufzeit: 19:38 Stunden

Erfolgreiche Upload-Sessions: 122 (90.37%)
Fehlgeschlagene Upload-Sessions: 13 (9.63%)

Erfolgreiche Download Sessions: 1381 (77.6%)
Fehlgeschlagene Download Sessions: 399 (22.4%)

Upload
Upload-Geschwindigkeit: 9.0 KB/s
Durchschnittliche Uploadrate: 8.8 KB/s
Max. Uploadrate: 10.0 KB/s
Max. durchschnittliche Uploadrate: 8.8 KB/s
Download
Download-Geschwindigkeit: 85.1 KB/s
Durchschnittliche Downloadrate: 69.5 KB/s
Max. Downloadrate: 92.0 KB/s
Max. Downloadrate Durchschnitt: 69.5 KB/s


Stabilität ist 1a!
Was wirklich erstaunlich ist, der Download-Overhead ist von utopischen 10-15 kb/s auf ca. 3 kb/s im Schnitt gesunken!!!
Download läuft die letzten 10 Stunden oder so mit einem Durchschnitt von etwa 80-85 kb/s (insgesamt eben knapp 70 bisher).
Das ganze resultiert in einer UL:DL Ratio von knapp 1:8 !!! Mehr Upload kann ich leider nicht geben, da meine Leitung wie gesagt nur ca. 13,5 - 14 kb/s zulässt und der Network-Adapter Graph bewegt sich im Durschnitt schon bei 13. Vielleicht komme ich aber von 8,8 ja noch auf 9 kb/s, ich bin auch gerade dabei das UL-Limit schrittweise um 0,1 zu erhöhen ... sehr viel mehr wird aber wohl nicht gehen.


Zum Vergleich:
x3alpha 3.1:
Fehlgeschlagene Upload-Sessions: 26 (15.66%)
Fehlgeschlagene Download Sessions: 410 (25.9%)

x3alpha 3.3:
Fehlgeschlagene Download Sessions: ca. 31%. Nach 1 1/2 Tagen


Ach genau: Hast du irgendetwas beim Quellen suchen/entfernen verändert?
Ich habe meine laufenden Downloads von 35 auf 60 und das HardLimit von 250 auf 300 erhöht und bekomme trotzdem weniger Quellen (ca. 4400) also vorher (ca. 5200).
Es mag wohl sein, dass ich vorher höher verfügbare Files drin hatte, aber ein so großer Unterschied?

MfG Hanussen

Xman 19. March 2005 12:39

wenn Du mir sagst was eine "Freundslotautomatik" ist !?

@Hanussen
danke für Deine Info... freut mich wenn er bei Dir gut läuft.
Bei den fehlgeschlagenen Downloadsessions kann man nicht zu viel machen...
ich bat euch darauf zu achten, um evtl. Probleme ausfindig zu machen, falls mit der Version 4.0 absolut atypische Werte (z.b. >50%) auftreten.
Oft enstehen aber viele dieser failed Downloadsessions durch 0-Upload-Mods, Mods mit Problemen beim Upload.. aber auch durch eine Protokollschwachstelle. Beim letzten Punkt hab ich noch einen möglichen Fix auf Lager, den ich aber erst austesten muß (wird noch dauern). Ansonsten wird es in absehbarer Zeit auch wieder den Patch des Xtreme2.2 geben, der Clients, welche ständig failed Downloadsessions produzieren filtert.

Xman 19. March 2005 12:50

@masterai
ja und wie genau läuft es da ?
Welche Prioritäten passen nicht ? Upload oder Downloadprioritäten ?

Xman 19. March 2005 13:06

das ist ja schlimmer wie friendboost .. und der ist (aus gutem Grund) verboten

aalerich 19. March 2005 15:27

Da masterai ständig Beiträge löscht kann ich nicht genau nachvollziehen, worum es geht. Der automatische Friendslot ist meines Wissens nach aber ein ZZ-Feature. Wenn ich eine HighID in die Freundesliste aufnehme bekommt der Klient sofort einen Uploadslot als Freundupload. Notfalls wird sogar jemand anderer hinausgeworfen.

EDIT: Und wieder mal Unfug geschrieben :bang
Bitte Pathfinders Korrektur nicht überlesen!

Mit freundlichen Grüßen
aalerich

P.S.: Es scheint, daß nicht mein Speicher, sondern das Mainboard kaputt ist. Der Zuse soll froh sein, daß er schon tot ist! Wenn ich den in die Finger kriegen würde... Nur Streß mit den Dingern...

MaxUpload 19. March 2005 16:39

Warum heißt es dann eigentlich nicht Zuse Linux so als Homage wäre das ja angebracht :-) .

@masterai : Ohne dich in irgend einer Weise einschränken oder dich in die Schublade Newbie runter kritisieren zu wollen,aber mit deinem momentanen Auftreten hier bin ich mir ziemlich sicher,daß du sehr bald mit einem Moderator oder Admin anecken wirst. Ich kenne dieses Feauture nicht näher,aber was man hier so ließt solltest du lieber die Finger davon lassen oder zumindest keine Werbung dafür machen! :evil:
Das man auch mit "ehrlichen" Mods sehr gute Ergebnisse erzielen kann steht für mich außer Frage. Ich habe einen DL kaum unter 85kb/s...gebe dabei mindestens 10kb/s und kann außer Online Gamen alles nebenbei machen. Der Xtreme läuft mit Sicherheit genauso gut wahrscheinlich sogar noch besser....*kann ich nicht beurteilen da ich leider schon lange nicht mehr zum testen gekommen bin* :sb .
Was du hier beschreibst kannst du genauso gut mit Powershare erreichen und was wirklich sauer aufstößt ist das kicken von Uploads um diese sogenannte Friendslotautomatik zu realisieren. Die Folgen sind Aufgrund der Komplexibilität des P2P-Networks einfach nicht absehbar. Woher willst du denn wissen,daß du nicht in Folge einer Kettenreaktion viel mehr Quellen zur Verfügng gehabt hättest ohne den User zu kicken????

@Xman ich hoffe ich komme sehr bald zum Testen, aber die Quellen Begrenzung hat so viele positive Nebeneffekte,daß mir ein baldiges ausgereiftes Release sehr am Herzen liegt. Dannach werde ich mich dann wieder intensiver hier in diesem Thread äußern.

MfG Max

daenemark 19. March 2005 18:02

Die 4.0 läuft jetzt seit fast 23 Stunden der pload ist Super.
eMule v0.45b alpha4.0 Statistik [[MK.L]daenemark on x3alpha 4.0]

Download Sessions: 680
Erfolgreiche Download Sessions: 449 (66.0%) (active: 9, paused: 0, no needed part: 27, timeout: 86, socket: 155, out of part: 169, exception: 0, others: 3)
Fehlgeschlagene Download Sessions: 231 (34.0%) (paused: 0, no needed part: 2, timeout: 39, socket: 185, out of part: 5, exception: 0, others: 0)
Aber ich habe jetzt mehr Fehlgeschlagene DL`s.Sonst waren es max 28% und im schnitt so um die
20% -> 25%.

masterai 19. March 2005 18:04

Siehe Seite 23 Geändert von masterai (Heute um 17:58 Uhr).

Werde diese Version weiter laufen lassen.

MFg masterai

Xman 19. March 2005 19:20

@daenmark:
es wäre sehr hilfreich zu wissen, ob Du mit oder ohne Downloadbeschränkung gearbeitet hast. Versuch doch einfach mal dies zu ändern (von mit auf ohne oder von ohne auf mit) und kontrolliere ob sich dadurch etwas verbessert.

daenemark 19. March 2005 21:02

@Xman
die Werte sind mit dl beschränkung.Werde jetzt mal ohne dl beschränkung laufen lassen.Allerdings bin ich noch nie an mein Limit gekommen ( 345 KB/s )

Pathfinder 20. March 2005 00:22

Zitat:

Zitat von aalerich
Da masterai ständig Beiträge löscht kann ich nicht genau nachvollziehen, worum es geht. Der automatische Friendslot ist meines Wissens nach aber ein ZZ-Feature. Wenn ich eine HighID in die Freundesliste aufnehme bekommt der Klient sofort einen Uploadslot als Freundupload. Notfalls wird sogar jemand anderer hinausgeworfen.

Es handelt sich nicht um ein ZZ-Feature, meines Wissens nach ist es eine Entwicklung von so8so, dem MODder des RT-MODs.
Die Beschreibung von masterai war auch nicht ganz zutreffend. Der FriendSlot funktioniert genauso wie in der offiziellen Version, er wird allerdings automatisch aufgebaut, wenn ein Friend in der Queue auftaucht. Dabei gelten aber alle Beschränkungen der offiziellen Version, daher wurde das Feature auf eMule-Project.net nicht beanstandet. Sollte es mittlerweile verändert worden sein (die aktuellsten Versionen habe ich nicht getestet), so lasst es mich wissen, dann wird der RT-MOD bei uns nicht mehr stattfinden.
Eine Bemerkung am Rande, auch im ZZ-System wird niemand aus dem Upload gekickt beim Aufbau eines FriendSlots. Der FS wird zwar direkt vergeben und bekommt Slot 1 mit höchster Priorität (erlaubt ist das bekanntermaßen dank der strengen Ratio), der vorherige Inhaber von Slot 1 wird aber auf 2 heruntergestuft und kann seinen Chunk beenden.
Zitat:

Zitat von so8so in RT-MOD Feature Description
Use Friend Slot Automatically
Automatically gives a friend slot if there is a friend in upload queue.
** Order by Wait time.
** Only upload one part every time.
** Upload priority : Credit1 > Friend > Release

@masterai,
wenn du nicht zu dem stehst was du hier schreibst, dann lass es gleich bleiben. Wenn du deine Beiträge hinterher löschst verfälschst du den Diskussionsverlauf. Solltest du an dieser Praxis festhalten wird das Konsequenzen haben.


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:44 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102