Xtreme Entwicklung - early alpha test thread

[Xman]

thx... danke für die Info.. ist auch interessant zu lesen, wie oft diese auftauchte und daß es jeweils der gleiche client war.
vielleicht sollte ich noch hinzufügen: wenn eine solche Message auftaucht... klappt der Upload immer ? (darum gab ich oben an, auch die Folgemessages anzugeben)

Edit
PS: die Anzahl der Messages ist entscheidend davon abhängig, wie oft die clients swappen. Hab ihr vieles Files einer Serie ist die Wahrscheinlichkeit höher. Auch durch unterschiedliche Uploadprioritäten werden die Wahrscheinlichkeiten höher.

[mav744]

Testbericht

Hallo Xman,

- Punkt 1 Stabilität: Der X3Alpha 3.0 lief 14 Stunden Stabil, dann habe ich die 3.1 angeworfen. Die X3Alpha 3.1 läuft jetzt seit 4.30 Stunden stabil, der test läuft weiter.

- Punkt 2 Open more slots if needed: Habe ich bei mir abgeschaltet, da bei mir 8-9 Slots aufgemacht wurden. Stelle ich das Uploadlimit so ein das nur 3-5 Slots geöffnet werden, gebe ich weniger "effektiven" Upload durch meinn Overhead. Stelle ich den Upload so ein, zB. das maximum meiner Leitung, dann kann ich mehr "effektiven" Upload geben, da der Overhead+Upload bis an die grenze meiner Leitung geht. Ich habe meinen Overhead jetzt mal 2 Tage mit dem DUMeter beobachtet und habe festgestellt das ich einen durchscnittlichen Overhead von ca. 6-8 KB/s habe. (Berechnung: Effektiver Upload laut DUMeter - Effektiver Upload laut eMule = Overhead zb. 16 - 9 = 7,0)

X3Alpha3.0 Meldungen mit --> im Log sind nicht vorhanden, habe 44 abgespeicherte Verboselogs durchgearbeitet . Das einzige waren A4AF Aktionen und Nicknames. In der 3.1 bis zum jetzigen Zeitpunkt das gleiche.

Überprüfe Werte der Spalte on Queue
Ich habe mir mal die Mühe gemacht für ca. 15 Files die Clients zu zählen, sowohl bei kleinen (ca.10-15 Clients) als auch bei grösseren (ca. 50 Clients). Die Abweichung beträgt ca. 10-15 für die 15 Files (Zählfehler vorbehalten).

Mit freundlichen Grüssen
mav744

[Paul 2]

x3alpha3.1

14.03.2005 11:30:26: -->Adding client, but last packet was: 146, 81.47.***.*** 'http://emule-project.***' (eMule v0.45a,OnQueue/Connecting)
14.03.2005 11:30:28: ...
14.03.2005 11:30:36: ...
14.03.2005 11:30:48: ...
14.03.2005 11:30:48: Removing client from upload list: Timeout: State:2 Client: 81.47.***.*** 'http://emule-project.***' (eMule v0.45a,OnQueue/Connecting) Transferred: 21 Sek SessionUp: 0 Bytes QueueSessionPayload: 0 Bytes


14.03.2005 14:13:19: -->Adding client, but last packet was: 146, 81.47.***5.*** 'http://emule-project.***' (eMule v0.45a,NoNeededParts/Connecting)
.
. der zeite Eintrag hierzu erfolgt erst sehr viel später
.
14.03.2005 14:34:45: Removing client from upload list: Completed transfer Client: 81.47.***.*** 'http://emule-project.***' (eMule v0.45a,NoNeededParts/Uploading) Transferred: 21:25 Mins SessionUp: 2.88 MB QueueSessionPayload: 2.89 MB


14.03.2005 15:49:23: -->sending ACCEPTUPLOADREQ a second time: 220.120.**.** '[KOR]www.P***a.com v2.79' (eMule v0.30,None/Uploading)
14.03.2005 15:49:23: Removing client from upload list: Remote client canceled transfer. Client: 220.120.**.** '[KOR]www.P***a.com v2.79' (eMule v0.30,None/Uploading) Transferred: 3 Sek SessionUp: 0 Bytes QueueSessionPayload: 0 Bytes

und in der Stat, habe nur max 16
eMule v0.45b alpha3.1 Statistik [***]
Upload
Upload-Geschwindigkeit: 10.8 KB/s
Durchschnittliche Uploadrate: 9.8 KB/s
Max. Uploadrate: 24.2 KB/s
Max. durchschnittliche Uploadrate: 9.9 KB/s

[daenemark]

Zitat von Xman

achso... nun weiß ich wie Du gemacht hast.. also alle zusammengezählt und mit der Gesamtzahl der Warteschleife verglichen... hmmm.. der Wert sollte eigentlich auch übereinstimmen. Waren hier die 50 Unterschied ? Und falls ja... wo waren 50 weniger?

Ja genau so habe ich es gemacht.Und da waren bei OnQueue die 50 weniger.
-> solche meldungen hatte noch nicht.

[Xman]

So, danke Jungs für eure Tests...
ich hab gestern auch nichts anderes getan als zu schauen, prüfen, testen...
Ergebnis:
- See OnQuploadqueue funktioniert wies soll. daenmark brachte mich auf die Idee, daß ich doch alle OnQueue addieren könnte und mit der Wartelistenzahl vergleichen... diese Zahl sollte immer übereinstimmen: aber vorsicht: addiert man zu langsam können sich die Werte währenddessen schon wieder stark verändert haben. (@daenmark: schätze daher kamen die Abweichungen)
- Es kann zwar immer noch passieren, daß ein "Trickle" in der Uplodliste um eine Stelle "fehlplatziert" ist.... allerdings ist er mit meinem Patch in der internen Liste auf der richtigen Position... und nur darauf kommt es an.
- Protokoll-Fehler beim Upload: Bin mir nicht ganz schlüssig was da evtl. vorsich gehen kann. Bei meinem Testlauf hatte ich genau einen Client dessen Upload fehlschlug wegen falscher Packetreihenfolge. Andererseits bin ich zum Entschluß gekommen, daß der Patch des Xtreme2.2 auch nicht schaden dürfte. Werd ihn also heute mal einbauen.

Bis zur nächsten Version könnt ihr also eure Zählungen einstellen. Danke nochmal.

[drfreak2004]

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]

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]

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:

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]

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]

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]

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

[Xman]

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 )
- 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]

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]

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:

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:

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

Version lief stabil.

Gruß,
X-Ray

[Paul 2]

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)

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