[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   eMule MODs - Allgemein (http://www.emule-web.de/board/emule-mods-allgemein/)
-   -   eMule 0.44d eNOS OD BETA HoTFiX 18h% [19.01.2005] (http://www.emule-web.de/board/8652-emule-0-44d-enos-od.html)

Bombada 13. December 2004 00:29

Code:

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 UL:DL 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 14. December 2004 09:09

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 15. December 2004 05:42

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 19. December 2004 17:40

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

Pathfinder 25. December 2004 01:23

Update auf eNOS OD BetaFix 13f%

Fatalio 30. December 2004 02:34

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

Pathfinder 19. January 2005 20:40

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

Stulle 19. January 2005 21:10

Zitat:

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 19. January 2005 21:14

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 19. January 2005 22:18

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:
Zitat:

- 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:

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:

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 19. January 2005 22:41

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 19. January 2005 22:55

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

MFG Stulle

aalerich 19. January 2005 23:01

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 20. January 2005 17:51

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 20. January 2005 22:16

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


Alle Zeitangaben in WEZ +1. Es ist jetzt 12:14 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, 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