eMule 0.44d eNOS OD BETA HoTFiX 18h% [19.01.2005]

[Bombada]

eMule v0.44d eNOS OD Beta15 v10d Statistik [[xxxxxxxx]]

Transfer
   Session UL:DL Ratio: 1 : 4,03
   Session UL:DL Verhältnis (ohne Freundesupload): 1 : 4,03
   gesamte UL:DL Ratio: 1 : 1,16
   Uploads
      Session
         Hochgeladen: 774,63 MB
         hochgeladene Daten durch Freundesuploads (Session): 0 Bytes
         Aktive uploads/nötig um Bandbreite auszunutzen: 6
         Gesamtanzahl der Uploads: 6
         Wartende Uploads: 500
         Upload Sessions: 346
            erfolgreiche Upload-Sessions: 272 (78,61%)
            fehlgeschlagene Upload-Sessions: 74 (21,39%)
            durchschnittlicher Upload pro Session: 2,85 MB
            durchschnittliche Upload-Dauer: 28:48 Minuten
         Totaler Overhead (Pakete): 25,03 MB (608,00K)
      Gesamt
   Downloads
      Session
         Heruntergeladen: 3,05 GB
         beendete Downloads: 9
         Aktive Downloads: 16
         Gefundene Quellen: 818
         Download Sessions: 1397
            erfolgreiche Download Sessions: 869 (62,2%)
            fehlgeschlagene Download Sessions: 528 (37,8%)
            durchschnittlicher Download pro Session: 3,59 MB
            durchschnittliche Downloadzeit: 18:42 Minuten
         durch Komprimierung gewonnen: 43,32 MB (1,4%)
         durch Datenfehler verloren: 9,28 MB (0,3%)
         Teile gerettet durch I.C.H: 1
         Totaler Overhead (Pakete): 36,49 MB (756,85K)
      Gesamt
Verbindung
Zeit Statistiken
   letzter Reset der Statistiken: Unbekannt
   Zeit seit letztem Reset: Unbekannt
   Session
      Programm-Laufzeit: 13:38 Stunden
      Übertragungszeit: 13:36 Stunden (99,8%)
      Dauer auf aktuellem Server: 13:36 Stunden (99,8%)
      Dauer auf Servern: 13:36 Stunden (99,8%)
   Gesamt
   Abschätzungen
Clients
Server
freigegebene Dateien
Festplattenplatz

Ich habe es mal mit Seltenen dateien getestet, pro datei nur max. 10 quellen.
Zu erst mit einen UL-Rate von 13kB/s, nach 6 stunden hatte ich ein DL-rate von 60kB/s.
Session ULL Ratio: 1 : 5,00
Max UL auf 25 kB/s eingestellt und rennt immer noch, nach 13 Stunden lauftzeit mußt ich schon sagen, geniales MOD.

edit:
Ich hatte nur 800 quellen, bei 100 dateien mußt ich noch dazu sagen.
Hier kann man sehen das meine sachen selten waren, normaler weise
könnte man mit 2 dateien mehr quellen als 1000 quellen kriegen.

[oma wetterwax]

gibt es bei diesem mod irgendwelche ul-kontrollen (slot-focus ...) ?

oma

<edit 15.12.2004>
Der RAM-Verbrauch hielt sich bei mir in Grenzen,
allerdings fehlen die UL-Einstellungen zur besseren Verteilung (auch kein Powershare gefunden).
Darüber hinaus ist mir aufgefallen, dass in der Statistik die durchschnittlichen UL- und DL-Raten einschließlich Overhead gezeigt werden, was doch zu leicht "verschobenen" Werten führt.
</edit>

[Bombada]

eNOS OD Beta15 10d verwendet bei mir zuviel RAMM!!!!!!!!!
Rund 250 MB. Es läuft schon seid 2 tage und 19 stunden.

Ratio liegt bei 1:2,5



Upload slot oder Focus einstellungen habe ich nicht gesehen.

[kinetixzz]

Der enos läuft echt super den genannten Bug kann ich bestätigen aber Up und Down ist gut

[Pathfinder]

Update auf eNOS OD BetaFix 13f%

[Fatalio]

Mh...kenn die vorige Version zwar net...aber die 13f läuft gut....

[Pathfinder]

Update auf eMule 0.44d eNOS OD BETA HoTFiX 18h%

[Stulle]

Zitat von Pathfinder

ADDED : Waiting queue Overflow From EF-mod/Sivka [FASTT]
-> Allow Waiting Queue Overflow
-> Friends
-> Valid Sources
-> Release
-> Reward Uploaders
-> Remote Queue Rank

Dachte Push-Friends is verboten¿ Push Valid Sources find ich persönlich nicht gut. Remote Queue Rank versteh ich nich was damit gemeint is...

MFG Stulle

[Pathfinder]

Es handelt sich dabei nicht um ein Push-Feature, sondern um einen "Überlauf" der Queue, d.h. u.a.Freunde können in eine ansonsten volle Warteschlage eintreten. Das Feature wurde von Sivka entwickelt und ist legitim. Besonders praktisch beim Releasen, denn jemand der eine Datei auf Release-Priorität anfragt wird mit dieser Funktion auch nie eine volle Queue vorfinden.

[aalerich]

Hallo Pathfinder, hallo Stulle,

ehrlich gesagt stimme ich Stulle zu. Auch wenn das kein Pushen ist finde ich es zweifelhaft.

Zu "Remote Queue Rank" habe ich auf die Schnelle nur im Changelog des ZX v2.9 etwas gefunden (stand vor der selben Frage wie Stulle), nämlich das hier:

- Added: Waiting Queue Overflow (for Remote Queue Rank < XXX) [ZX] (Idea by eMulefan83)

Wenn ich das richtig verstehe heißt das, daß jemand, bei dem man selbst gut in der Warteschlange platziert ist, die eigene Warteschlange betreten kann, auch wenn sie eigentlich voll ist.
"Valid Sources" geht in die gleiche Richtung, wer etwas für mich hat, der bekommt auch. Wer hingegen nichts für mich hat, der soll sich sein Zeug gefälligst woanders holen.

Gestern erst gefunden:

Zitat von Ornis+ vom 22. Oktober 2003

Nehmen wir das "Overflowing". Es erlaubt bestimmten Usern u.U. immer die Warteschlange zu betreten, während alle anderen abgewiesen werden. Der Haken daran wird um so deutlicher, desto kleiner man die Queue einstellt (hier ist also auch ein verringern der minimalen Queue negativ förderlich). Und dass zB Freunde immer in die Queue dürfen und andere nicht ist der Punkt des Anstosses.
Wenn Gleichberechtigung angestrebt ist, muss man sich auch über diesen Fall Gedanken machen.

Zitat von Ornis+ vom 22. Oktober 2003

Wenn aufgrund der Clients selber (Freund oder nicht Freund, hohe QR oder nicht,...) der Queuebeitritt entschieden wird, ist das nicht tragbar. Wenn die Entscheidung auf anderen Dingen beruht, dass zB Clients mit Anfragen für schlecht verbreitete Files zB bevorzugt in die Queue kommen) ist dies jedoch denkbar.

Allerdings weiß ich nicht, ob diese Meinung inzwischen geändert wurde.

Mit verunsicherten Grüßen
aalerich

[Pathfinder]

Die Erweiterungen von eMulefan83 des alten Sivka-Features gehen eindeutig in die Richtung eigener Vorteil, da gebe ich dir Recht. Ursprünglich war der Overflow auf Freunde, Release-Files und Valid Sources i.A. beschränkt.
Die Erweiterungen werfen Bedenken auf, da im Falle einer kleinen Queue hier User benachteiligt werden die nichts für einen selbst anbieten. Dieses Feature findet sich neben dem ZX auch in eMulefan's eigenem MOD und wurde auf eMule-Project.net afaik bisher nie gegenüber den MODdern direkt beanstandet.

Allerdings würde ich trennen zwischen dieser passiven Art der Bevorzugung und einem Push, der sich ja durch ein aktives Bevorzugen in der Queue, also ein Besserstellen in Form einer schnelleren Verringerung des QR gegenüber anderen auszeichnet. Daher würde ich das Feature als bedenklich aber noch tolerierbar einstufen. Ein Verbot würde neben dem eNOS ja auch noch die anderen angesprochenen MODs betreffen, solange die MODder nicht durch die DEVs dazu aufgefordert werden dieses Feature aus ihren MODs zu entfernen halte ich das für übertrieben.

Ich würde es begrüßen in den betroffenen MODs als Ausgleich eine erhöhte minimale Queuesize vorzufinden um die Ausnutzbarkeit des Features zu verringern.

[Stulle]

Hoppla, hab ich dieses feature also langezeit falsch verstanden. davon abgesehen stimme ich dem gesagten zu

MFG Stulle

[aalerich]

Also gewissermaßen als Fazit: Es ist nicht schön, aber solange die DEVs es nicht als so schlimm betrachten, daß sie eingreifen...
Ich stimme Dir, Pathfinder, in jedem Falle zu, wenn es nicht explizit und offiziell als schädlich bezeichnet wird sollte man den Nutzern überlassen, sich dafür oder dagegen zu entscheiden.

Mit freundlichen Grüßen
aalerich

[Xman]

ich mußte dieses Feature damals raustun, weil ich von Ornis "abgemahnt" wurde. Seltsam, daß er da bei Anderen toleranter ist. Nun ja, man kann es sehen wie man es will.... ich persönlich bin inzwischen auch eher ein gegener davon jemand aufgrund von Querankings in die Queue zulassen.

[aalerich]

Hallo Xman,

Das zweite Ornis+-Zitat beginnt im Original auch mit "@Xman:"... Ich habe es aber weggelassen, weil es in der Sache nicht wichtig ist.

Mit freundlichen Grüßen
aalerich