eMule 0.46c Xtreme 4.6 [22.10.2005]

**Xman** · 10. June 2005, 18:28

auf dem screenshot sehe icn leider keinen Grund der zum Einbruch führt. das einzige was mir auffällt ist, daß Du sehr oft an Deine max Connections rankommst.

@all
wer den Xtreme auf italienisch haben will kann sich die Sprachdatei hier runterladen:
http://www.ackronic.net/ackws/forums...p?showforum=52

und falls jemand Lust hat eine deutsche(oder sonstige Sprache) Sprachdatei(dll) zu machen, nur zu! Es wäre allerdings wünschenswert, daß derjenige auch später für neuere Versionen diese Datei pflegt.
Der Xrtreme benutzt zum größten Teil lokalisierte Variablen, allerdings fehlt mir etwas die Zeit auch noch die passenden Sprachdateien zu erstellen und zu kompilieren.

son · 10. June 2005, 19:03

an der grenze mit meinen connections bin ich weil ich die auf 100 gesenkt habe, ändert aber wenig bis nichts am verhalten, wenn ich sie auf 400 hochsetze, dann liegen sie am anfang bei 250 und gehen so auf ca 120-150 runter. da ich ihm das jetzt abgeschnitten habe so hoch zu gehen, ists halt die ganze zeit bei 100 :o

die einbrüche gingen in wechselnden abständen weiter :/

**Xman** · 10. June 2005, 19:32

son, ich würde Dir gern helfen wenn ich könnte. Das einzige was wir wissen ist, daß es ein Problem Deines Routers ist... warum dies aber ausgerechnet in Verbindung mit dem Xtreme auftritt ist mir ein Rätsel. Von anderen Usern bekam ich die Rückmeldung, daß der Xtreme extrem routerfreundlich sei. Aber selbst wenn er total aggressiv wäre, so müßte sich spätestens beim Senken der Verbindungen das Problem erledigt haben.
Spricht denn das Verbose-Log etwas ?

Mib2003 · 10. June 2005, 19:41

Habe ihn auch mal grad im Test .

Das mit dem einbruch habe ich jetzt bemerkt ist bei mir wenn ich in die einstellungen gehe etwas verstelle (oder auch nicht verstelle)dann auf ok klicke hängt der Mod ca 3-8 Sec.

Dann habe ich fast das gleiche Bild.

Mein system ist wixp sp1 256mb speicher

Ansonsten gefällt er mir sehr gut.Nicht überladen .

Use double sendsize??Wasn das?? Wird dort der doppelte mtu Packetwert verschickt oder was hat das zu bedeuten.

**Xman** · 10. June 2005, 19:51

3-8 Sekunden ist Rekord... daß das Speichern aber zu lang dauert ist ein bekanntes Problem. Leider fällt mir hierzu aber auch keine Lösung ein, alle Routinen hierzu stammen vom offiziellen emule.

Und zu double sendsize hast Du die richtige Erklärung ja schon gegeben

Sinn davon: verschickt man sozusagen ein Doppelpacket braucht die Gegenstelle nur mit einem ACK-Packet antworten. Ist eine Idee des offiziellen emule und soll den Overhead verkleinern.. auf meinem System wird er dadurch aber größer. Selbst testen.

son · 10. June 2005, 23:28

hab jetzt mal ein wenig in die verbose logs geschaut und immer die letzten 5 min vorm einbruch rauskopiert und bei 3 verschiedenen zeiten verglichen und konnte nicht wirklich was finden. ich gebs jetzt mal vorerst auf und bleibe trotzdem bei dem mod, abgesehen von den kurzen einbrüchen funktioniert er ja wunderbar. hatte das überhaupt nur nochmal angesprochen, weil es mir so vorkam, als ob sie mit der neuen version häufiger auftreten.

einen letzten screenshot habe ich allerdings noch, um zu zeigen, dass es wirklich nichts mit den connections oder dem refresh zu tun haben kann. mich würde allerdings schon interessieren, was einen router dazu bringen kann nicht mehr zu antworten, abgesehen davon ihn mit zu vielen connections zuzumüllen :o

Frawe · 12. June 2005, 01:44

Hier eine Statistik von mir:

Code:

eMule v0.46a Xtreme 4.0b1 Statistik [Frawe]

Transfer
   Session UL:DL Ratio: 1 : 1.71
   Session UL:DL Verhältnis (ohne Freundesupload): 1 : 1.71
   Gesamte UL:DL Ratio: 1 : 1.65
   Uploads
      Session
         Hochgeladen: 2.10 GB
         Hochgeladene Daten durch Freundesuploads (Session): 0 Bytes
         Aktive uploads/nötig um Bandbreite auszunutzen: 4
         Gesamtanzahl der Uploads: 7
         Wartende Uploads: 4513
         Upload Sessions: 360
            Erfolgreiche Upload-Sessions: 346 (96.11%) (active: 7, socket: 56, completed: 253, cancelled/ended: 27, different file: 1, exception: 2, others: 0)
            Fehlgeschlagene Upload-Sessions: 14 (3.89%) (socket: 12, completed: 0, cancelled/ended: 2, different file: 0, exception: 0, others: 0)
            Durchschnittlicher Upload pro Session: 6.22 MB
            Durchschnittliche Upload-Dauer: 25:48 Minuten
         Totaler Overhead (Pakete): 69.94 MB (1.39M)
      Gesamt
   Downloads
      Session
         Heruntergeladen: 3.60 GB
         Beendete Downloads: 14
         Aktive Downloads: 22
         Gefundene Quellen: 5150
            In Warteschleife: 4321
            Voll: 382
            Keine benötigten Teile: 388
            Nachfragen: 2
            Empfange Hashset: 0
            Verbindung wird hergestellt: 7
            Verbinde über Server: 0
            Zu viele Verbindungen: 0
            Verbindung LowID zu LowID unmöglich: 0
            Problematisch: 0
            Gebannt: 0
            Andere Datei angefordert: 2141
            Unbekannt: 29
            via eD2K Server/Queue: 164
            via Kad: 351
            via Quellenaustausch: 2767
            via Passive: 1842
            eD2K: 4921 (95.6%)
            Kad: 2935 (57.0%)
            eD2K/Kad: 2845 (55.2%)
            UDP Datei-Neuanfragen: 169.04K, Fehlgeschlagen: 14.44K (8.5%)
            TCP-connections: 117.47K, failed: 16.65K (14.2%)
            Tote Quelle: 626 (544 + 82)
         Download Sessions: 1160
            Erfolgreiche Download Sessions: 952 (82.1%) (active: 22, paused: 0, no needed part: 57, timeout: 159, socket: 295, out of part: 418, exception: 0, others: 1)
            Fehlgeschlagene Download Sessions: 208 (17.9%) (paused: 0, no needed part: 8, timeout: 69, socket: 123, out of part: 5, exception: 1, others: 2)
            Durchschnittlicher Download pro Session: 3.87 MB
            Durchschnittliche Downloadzeit: 22:05 Minuten
         Durch Komprimierung gewonnen: 73.07 MB (2.0%)
         Durch Datenfehler verloren: 688 KB (0.0%)
         Teile gerettet durch I.C.H: 1
         Totaler Overhead (Pakete): 67.06 MB (1.46M)
      Gesamt
Verbindung
   Session
      Allgemein
         Erneute Serververbindungen: 0
         Aktive Verbindungen (geschätzt): 161 (Halb:7 | Komplett:51 | Andere:103)
         Durchschnittliche Verbindungen (geschätzt): 151
         Verbindungsspitze (geschätzt): 234
         Verbindungs-Limit erreicht: 0
      Upload
         Upload-Geschwindigkeit: 34.6 KB/s
         Durchschnittliche Uploadrate: 34.6 KB/s
         Max. Uploadrate: 37.5 KB/s
         Max. durchschnittliche Uploadrate: 34.6 KB/s
      Download
         Download-Geschwindigkeit: 55.6 KB/s
         Durchschnittliche Downloadrate: 59.2 KB/s
         Max. Downloadrate: 181.5 KB/s
         Max. Downloadrate Durchschnitt: 59.6 KB/s
   Gesamt
Zeit Statistiken
   Letzter Reset der Statistiken: Unbekannt
   Zeit seit letztem Reset: Unbekannt
   Session
      Programm-Laufzeit: 17:42 Stunden
      Übertragungszeit: 17:42 Stunden (100.0%)
      Dauer auf aktuellem Server: 17:42 Stunden (100.0%)
      Dauer auf Servern: 17:42 Stunden (100.0%)
   Gesamt
   Abschätzungen
Clients
   Bekannte Clients: 8274 
   Software
      eMule: 7447 (90.0%)
         v0.46a: 2817 (37.8%)
         v0.45b: 1667 (22.4%)
         v0.44b: 1283 (17.2%)
         v0.44d: 621 (8.3%)
         Weitere: 873 (11.7%)
      eD Hybrid: 305 (3.7%)
      eDonkey: 0 (0.0%)
      aMule: 42 (0.5%)
      MLdonkey: 108 (1.3%)
      Shareaza: 60 (0.7%)
      eM Compat: 285 (3.4%)
      Unbekannt: 27 (0.3%)
   Netzwerk
   Port
   Niedrige ID: 1195 (14.4%)
   Identifikation (pos : neg): 7631 (92.2%) : 37 (0.4%)
   Problematisch: 0 (0.0%)
   Gebannt: 213
   Gefiltert: 5787
   Leecher 2013
Server
   Funktionierende Server: 31
   Server mit Login-Fehlversuchen: 0
   Gelöschte Server: 19
   Gesamt: 31
   Gesamte Benutzeranzahl: 2.83M
   Gesamte Dateianzahl: 369.32M
   Rekorde
      Max. funktionierende Server: 50
      Max. Nutzer Online: 3.43M
      Max. Dateien verfügbar: 427.17M
Freigegebene Dateien
Festplattenplatz

MfG Frawe

**seppl12** · 12. June 2005, 11:04

Nach wie vor wird bei IP Wechsel NAFC wieder aktiviert!

**Xman** · 12. June 2005, 12:00

grmpf... ich schaus mir nochmal an.. danke seppl für die Info.

son · 12. June 2005, 15:02

yep ist mir auch einmal aufgefallen als ich ohne nafc getestet habe und nachm 24h discon wars dann wieder an.

**Xman** · 12. June 2005, 17:29

also bei mir läuft es... habs grad mehrmals getestet.
bei Zwangstrennung wird NAFC deaktiviert (da wir evtl den NAFC-Adapter nicht mehr kennen)... sobald wieder zu einem Server verbunden wird, wird der NAFC-Zustand vor der Trennung hergestellt. Falls ihr allerdings während ihr getrentn seid Änderungen vornehmt, (NAFC an oder aus) würden diese überschrieben werden.

**seppl12** · 13. June 2005, 07:18

Xman, es wird während der Zwangstrennung keine Veränderung vorgenommen. Ich bemerke erst morgerns im Statistikfenster, das sich NAFC wieder selbst aktiviert hat und deaktivier es anschließend wieder.

drfreak2004 · 13. June 2005, 08:38

moin xman,

du hast doch geschrieben, das zwischen der letzten alpha und der beta 1 keine unterschiede sind, oder ?! meine frage: warum läuft die alpha stabil und die beta hängt sich alle 16 bis 18 h auf ?! versteh ich net....

mfg

**Xman** · 13. June 2005, 08:45

Zufall ? Ist wirklich ein Unterschied, außer daß sie neu kompiliert wurde.
Aufhängen ist natürlich gar nicht gut.. und was heißt aufhängen 100% CPU-Last ?

@seppl
kannste das vielleicht nochmal reproduzieren und bei mir den bei der Zangstrennung entstandenen NAFC- Fehlercode mitteilen ? (steht im VerboseLog in dem moment wo die Internetverbindung aufhört)

drfreak2004 · 13. June 2005, 09:48

also einmal cpu 100% einmal freeze ohne grund... cpu 0 % aber xtreme eingefroren

Ähnliche Themen: eMule 0.46c Xtreme 4.6 [22.10.2005]