eMule 0.45b - StulleMule Alpha-Test

aalerich · 10. April 2005, 19:53

Selbst auf die Gefahr hin, mich wieder einmal unbeliebt zu machen; ich finde diese Statistik ziemlich verheerend.

Zitat:

Zitat von MonoManiac

Session UL

L Ratio: 1 : 4.39
Upload-Geschwindigkeit: 6.76 KB/s
Durchschnittliche Uploadrate: 8.02 KB/s

Aktive uploads/nötig um Bandbreite auszunutzen: 1

Fehlgeschlagene Upload-Sessions: 49 (24.87%)

Totaler Overhead (Pakete): 125.35 MB (2.35M) bei: Upload Sessions: 197 und Hochgeladen: 672.07 MB

(zum Vergleich mal meine aktuellen Daten: Totaler Overhead (Pakete): 57.57 MB (1.21M) bei Upload Sessions: 854 und Hochgeladen: 5,15 Gigabyte) Find' ich wirklich heftig...
Und das Ratio hast Du offensichtlich auch komplett entfernt...

Zitat:

Zitat von MonoManiac

Totaler Overhead (Pakete): 131.32 MB (2.55M) bei: Download Sessions: 4842 und Heruntergeladen: 2.88 GB

(zum Vergleich: Totaler Overhead (Pakete): 52,00 MB (1,18M) bei: Download Sessions: 1879 und Heruntergeladen: 5,08 GB)
Kad habe ich die ganze Zeit an...
Auch die fehlgeschlagenen Downloads finde ich viel, weiß aber nicht, inwieweit das mit WC zusammenhängt (Habe mich mit allem, was damit zu tun hat, also auch den Statistiken, noch nie befaßt.).
Das alles bei:

Zitat:

Zitat von MonoManiac

Programm-Laufzeit: 23:50 Stunden

Zitat:

Zitat von MonoManiac

Bekannte Clients: 6444
Leechers: 2326

Ich bin ja nun gewiß nicht zimperlich, aber das ist definitiv fern jeder Realität.

Zitat:

Zitat von MonoManiac

Anzahl freigegebener Dateien: 344

@ MonoManiac:
Das sind viel zu viele! Nimm mal 300 davon raus! Daher kommt nämlich ein kleiner Teil Deines viel zu hohen Overheads.

Fazit: "wirkl. gut" kann ich das nicht finden. Irgendwo ist da der Wurm drin. Die hohe Zahl freigegebener Dateien hat ja nichts mit dem ebenfalls mörderischen Download-Overhead zu tun. Und dann noch die blinde Bannwut und das entfernte Ratio... Sei mir nicht böse Stulle, aber netzwerkfreundlich ist Dein Mod noch nicht...

Mit freundlichen Grüßen
aalerich

daenemark · 10. April 2005, 20:35

Da Stimme ich aalerich zu.Auch bei Trexpower2005 liegt der Upload unter 10kb und er kommt auf eine Ratio von 1:3,76.
Ob das alles so gut ist ???

**mav744** · 10. April 2005, 20:48

Nur mal so zum Vergleich ne Stats von mir

Code:

eMule v0.45b [StulleMule alpha v0.5] Statistik [***]

Transfer
   Session UL:DL Ratio: 1 : 1.82
   Session UL:DL Verhältnis (ohne Freundesupload): 1 : 1.82
   Gesamte UL:DL Ratio: 1 : 1.91
   Uploads
      Session
         Hochgeladen: 557.08 MB
         Hochgeladene Daten durch Freundesuploads (Session): 0 Bytes
         Aktive uploads/nötig um Bandbreite auszunutzen: 6
         Gesamtanzahl der Uploads: 5
         Wartende Uploads: 2146
         Upload Sessions: 118
         Totaler Overhead (Pakete): 35.19 MB (650.73K)
      Gesamt
         Hochgeladen: 2.18 GB
         Upload Sessions: 3086
         Totaler Overhead (Pakete): 168.73 MB (3.13M)
   Downloads
      Session
         Heruntergeladen: 0.99 GB
         Beendete Downloads: 1
         Aktive Downloads: 5
         Gefundene Quellen: 4438
         Download Sessions: 334
         Durch Komprimierung gewonnen: 34.47 MB (3.4%)
         Durch Datenfehler verloren: 0 Bytes (0.0%)
         Teile gerettet durch I.C.H: 0
         Totaler Overhead (Pakete): 29.61 MB (678.41K)
      Gesamt
         Heruntergeladen: 4.16 GB
         Beendete Downloads: 4
         Download Sessions: 1586
         Durch Komprimierung gewonnen: 150.42 MB (3.5%)
         Durch Datenfehler verloren: 9.28 MB (0.2%)
         Teile gerettet durch I.C.H: 1
         Totaler Overhead (Pakete): 144.25 MB (3.22M)
Verbindung
   Session
      Allgemein
         Erneute Serververbindungen: 1
         Aktive Verbindungen (geschätzt): 222 (Halb:12 | Komplett:144 | Andere:66)
         Durchschnittliche Verbindungen (geschätzt): 178
         Verbindungsspitze (geschätzt): 1003
         Verbindungs-Limit erreicht: 9 : 10.04.2005 08:45:24
      Upload
         Upload-Geschwindigkeit: 11.48 KB/s
         Durchschnittliche Uploadrate: 11.58 KB/s
         Max. Uploadrate: 17.61 KB/s
         Max. durchschnittliche Uploadrate: 12.13 KB/s
      Download
         Download-Geschwindigkeit: 12.22 KB/s
         Durchschnittliche Downloadrate: 21.06 KB/s
         Max. Downloadrate: 71.04 KB/s
         Max. Downloadrate Durchschnitt: 21.40 KB/s
   Gesamt
      Allgemein
         Erneute Serververbindungen: 6
         Durchschnittliche Verbindungen (geschätzt): 193
         Verbindungsspitze (geschätzt): 1003
         Verbindungs-Limit erreicht: 35
      Upload
         Durchschnittliche Uploadrate: 10.18 KB/s
         Max. Uploadrate: 17.87 KB/s
         Max. durchschnittliche Uploadrate: 10.48 KB/s
      Download
         Durchschnittliche Downloadrate: 17.77 KB/s
         Max. Downloadrate: 74.26 KB/s
         Max. Downloadrate Durchschnitt: 17.93 KB/s
Zeit Statistiken
   Letzter Reset der Statistiken: Unbekannt
   Zeit seit letztem Reset: Unbekannt
   Session
      Programm-Laufzeit: 13:41 Stunden
      Übertragungszeit: 13:40 Stunden (100.0%)
      Dauer auf aktuellem Server: 1:40 Stunden (12.3%)
      Dauer auf Servern: 13:40 Stunden (99.9%)
   Gesamt
      Programm-Laufzeit: 2 Tage 13:50 Stunden
      Übertragungszeit: 2 Tage 13:47 Stunden (99.9%)
      Dauer auf Servern: 2 Tage 13:41 Stunden (99.7%)
   Abschätzungen
Clients
Server
Freigegebene Dateien
   Anzahl freigegebener Dateien: 29
   Durchschnittliche Dateigröße: 670.84 MB
   Größte freigegebene Datei: 810.11 MB
   Gesamtgröße freigegebener Dateien: 19.00 GB
   Rekorde
Festplattenplatz

Also bei Trexpower2005 lag es definitiv an den vielen Quellen, was er aber auf meinen Rat hin abgestellt hat. Ich frage mich allerdings auch und Stulle habe ich auch schon gefragt, wie man so eine Ratio hinbekommt

. Alles was Höher als 1:1 ist, ist ein Geschenk. Ich habe im Schnitt mitlerweile 1:1,xx und bin zufrieden. Nachdem ich jetzt meinen Upload in den Griff bekommen habe, liegt dieser im Schnitt so bei 11-12 KB/s,nachts auch höher.

Mit freundlichen Grüssen
mav744

**Stulle** · 10. April 2005, 21:06

Also gegen den Vorwurf ich hätte keine Ratio mehr drin muß ich mich auf schärfste wehren! Wenn ich euch genau das Changelog durchlest seht ihr wie die Ratio Bedingungen sind!
Ich habe nichts, aber auch garnichts entfernt! Im gegensatz habe ich die Bedingungen für PS on partfile und friendslot verhärtet (gilt für ganze session) und noch den Punkt friend-boost für die gesamte session hinzugefügt. Weiter habe ich das Limit für den Durchschnitt auf generell 8 gesenkt und auf 10, so man min 12 kbps UL geben will. Unter 10 kbps is die ratio auch aktiv. Aber wie ich ja eingansg sagte wird dies schon aus meinem Changelog ersichtlich!
Ihr glaubt mir nicht¿ Seht euch die sourcen an!
Was den Overhead betrifft... Wie ihr wiederum meinem Changelog entnehmen könnt habe ich NICHTS verändert was einen direkten Einfluss auf den Rest des Netzwerkes hat.
Leecher-Ban... Wenn jemand den Sivka-Ban auf maximal konfiguriert kann es unter umständen zu Ban-Orgien kommen. die werden dann da mit einfließen. ABER bei mir ist das nicht so!
Hier mal zum Vergleich meine Sessionstats. Derzeit läuft der Muli zwar nicht so gut wie er sonst zT läuft, aber er läuft trotzdem tadellos! Zu beachten ist das ich ca. 2h den esel auf 9 kbps UL max stellen mußte. Nun max 14, min 11 und USC!

Code:

eMule v0.45b [StulleMule alpha v0.6] Statistics [Stulle]

Transfer
   Session UL:DL Ratio: 1 : 1.58
   Session UL:DL Ratio (Friends UL excluded): 1 : 1.58
   Cumulative UL:DL Ratio: 1 : 1.84
   Uploads
      Session
         Uploaded Data: 195.73 MB
         Uploaded Data to Friend Slots (Session): 0 Bytes
         Active Uploads/Needed to fill Bandwidth: 4
         Total Uploads: 3
         Waiting Uploads: 4988
         Upload Sessions: 238
            Total successful upload sessions: 135 (56.72%)
            Total failed upload sessions: 103 (43.28%)
            Average Uploaded Per Session: 1.42 MB
            Average upload time: 9:39 Minutes
         Total Overhead (Packets): 39.40 MB (670.98K)
            File Request Overhead (Packets): 8.34 MB (242.23K)
            Source Exchange Overhead (Packets): 2.71 MB (2.10K)
            Server Overhead (Packets): 384.19 KB (12.80K)
            Kad Overhead (Packets): 17.16 MB (283.16K)
      Cumulative
   Downloads
      Session
         Downloaded Data: 309.09 MB
         Completed Downloads: 0
         Active Downloads (chunks): 2
         Found Sources: 4198
         Download Sessions: 127
            Successful Download Sessions: 86 (67.7%)
            Failed Download Sessions: 41 (32.3%)
            Average Downloaded Per Session: 3.59 MB
            Average Download Time: 6:53 Minutes
            Successful WC-DL/WC-Requests: 202/1193 (16.9%)
            Failed WC-DL/WC-Requests: 991/1193 (83.1%)
         Gained Due To Compression: 10.43 MB (3.4%)
         Lost Due To Corruption: 0 Bytes (0.0%)
         Parts Saved Due To I.C.H: 0
         Total Overhead (Packets): 35.98 MB (590.59K)
            File Request Overhead (Packets): 7.28 MB (231.90K)
            Source Exchange Overhead (Packets): 1.09 MB (1.95K)
            Server Overhead (Packets): 63.48 KB (926)
            Kad Overhead (Packets): 18.15 MB (224.80K)
      Cumulative
Connection
   Session
      General
         Reconnects: 1
         Active Connections (estimate): 186 (Half:1 | Compl:42 | Other:143)
         Average Connections (estimate): 201
         Peak Connections (estimate): 403
         Max Connection Limit Reached: 95 : 10.04.2005 16:20:32
      Upload
         Upload-Speed: 11.21 KB/s
         Average Uploadrate: 8.76 KB/s
         Max Upload Rate: 21.41 KB/s
         Max Average Upload Rate: 8.76 KB/s
      Download
         Download-Speed: 5.12 KB/s
         Average Downloadrate: 13.83 KB/s
         max. Downloadrate: 56.22 KB/s
         Max Downloadrate Average: 13.84 KB/s
   Cumulative
Time Statistics
   Statistics last reset: 09.01.2005 23:21:55
   Time Since Last Reset: 90 days 21:42 Hours
   Session
      Runtime: 6:21 Hours
      Transfer Time: 6:21 Hours (100.0%)
      Current Server Duration: 19:58 Minutes (5.2%)
      Total Server Duration: 6:21 Hours (100.0%)
   Cumulative
   Projected Averages
Clients
   Known Clients: 6669 
   Client Software
   Network
   Port
   Low ID: 1191 (17.9%)
   Secure Ident (OK : Failed ): 6367 (99.8%) : 12 (0.2%)
   Problematic: 0 (0.0%)
   Banned: 314
   Filtered: 182
   Leechers: 385
   EastShare: 6 (0.1%)
   New HideOS : 9
Servers
Shared Files
Disk Space

In anbetracht dessen, dass ich wirkl. IMMER betone etwas gegen leecher usw. zu haben und in anbetracht dessen, dass ich in meinem Thread zu meinen Änderungen betreffs der Ratio bereits argumentiert habe warum die Änderungen, finde ich es eine ziemliche Frechheit von euch mir das zu unterstellen. Ich weiß nicht, ob du, daenmark, dort mitgelesen hast, aber du, aalerich, du hast dort mitdiskutiert und solltest meine Einstellungen dazu kennen! Und das man JEDEN Client böse einstellen kann... das kommt sogar von dir!

Mit äußerst verärgerten Grüßen
Stulle

EDIT: 0.6 hat nur eine graphische Änderung bisher und das 2. feature funktioniert noch nicht, hat aber auch keinen einfluss.

EDIT 2: Wie man siehst hat MonoManiac einen Schnitt von über 8! Hat er also den Muli auf 12 konfiguriert und verringert anderweitig seine Bandbreite ist es ihm gestattet eine unbegrenzte Ratio zu haben! Das ist aber NICHT aber auch GARNICHT meine Schuld! Sucht bitte nicht erst die Schuld bei mir, sondern erst bei anderen. Bei so etwas kann ich wirkl. extrem abgehen, da sowas wirkl. mehr als kontraproduktiv ist!

EDIT 3: (und noch einer *aufreg*) aalerich, bevor du tönst ich würde verbotenes tun, schau dir deine geliebte Vorlost Mod an! Ich werd hier nur eins dazu sagen "manual kick/ ban"! Erst lesen (das changelog), dann denken, dann posten! selbiges gilt auch für daenmark!

An die Mods: Es tut mir leid das ich mich so aufrege, aber das mußte einfach mal raus. Hab gerad SOOOOOO n Hals!

**Xman** · 10. April 2005, 23:36

eine kleine Anmerkung zur Anzahl der Leecher in der Statistik:
Diese Zahl ist nicht ganz ernt zu nehmen aus folgendem Grund:
ein Client wird als Leecher erkannt, die Statistik wird um 1 erhöht, und seine IP landet auf der Ban-Liste. Nach einer gewissen Zeit werden IPs von der Ban-Liste entfernt. Trifft man nun erneut auf diesen Client so wird die Statistik wieder um 1 erhöht.

Auf diesen "Bug" machte ich Morph heute aufmerksam. Allerdings wird er und werden wohl ich diese "Falschberechnung" nicht ändern aus dem einfachen Grund: um eine wirklich korrekte Zahl zu bekommen bräuchte man eine eigene Liste und Extra-Coding-Aufwand (+Speicher * CPU). Dies lohnt sich für einen simplen Statistikwert einfach nicht.

aalerich · 11. April 2005, 03:16

@ Xman:

Danke für die Erläuterung! Das wußte ich nicht und das relativiert die Sache natürlich erheblich. Bei einer Laufzeit von fast 24 Stunden und einer (vermuteten) Bannzeit von 2 Stunden kann man also die Zahl der tatsächlich gebannten bei vielleicht einem Zehntel der "erkannten Leecher" ansetzen. Das ist dann schon ein realistisches Maß und beruhigend.

@ Stulle:

Wir sind hier im Development-Bereich! Und Dein Mod heißt "Alpha-Test! Hier geht es um die Entwicklung und Fehlersuche, um das Testen von Funktionen, ihrer Wirkungen und ihrer Auswirkungen.

Zum Ratio: Ich bin kein Freund der Absenkung auf ein Minimum von 8. Und ich habe aus den Anmerkungen derer, die sich zu dem Thema ebenfalls geäußert haben herausgelesen, daß ich damit nicht allein stehe. Konkret gesagt haben sich, soweit ich mich erinnere, alle mehr oder weniger deutlich dagegen ausgesprochen. Diese Statistik nun zeigt, was die Auswirkungen dieser Absenkung sind. Pathfinder formuliert es immer so schön treffend; das Ratio soll die Leute dazu zwingen, ihre Mulis sauber einzustellen. MonoManiac ist sicher kein Leecher oder jemand, der rücksichtslos saugen oder gar Schaden anrichten will. Seine 344 freigegebenen Dateien sind gut gemeint. Nur richtet er damit ungewollt Schaden an; er erzeugt unverhältnismäßig viel Overhead. Durch die Senkung des Ratios merkt er das aber nicht...

Zum Overhead: Da muß irgendwo ein Bug sein. Auch Deine Statistik besagt:

Zitat:

Uploads
Session
Uploaded Data: 195.73 MB
Total Overhead (Packets): 39.40 MB (670.98K)

Downloads
Session
Downloaded Data: 309.09 MB
Total Overhead (Packets): 35.98 MB (590.59K)

Das ist mörderisch! Im Upload sind das 1 mb Overhead für 5 mb Datenupload und im Download immerhin noch 1 mb Overhead für 10 mb Datendownload. Vielleicht ist das ja auch nur ein Fehler in der Statistik, ich weiß es nicht. Aber da mußt Du Dich unbedingt dahinterklemmen! Wenn diese Werte stimmen kannst Du den Mod unmöglich so rausgeben. Meine Vergleichswerte stammen übrigens auch nicht vom vorlost

...
Und bei mav744 sieht das auch schon ganz anders aus:

Zitat:

Uploads
Session
Hochgeladen: 557.08 MB
Totaler Overhead (Pakete): 35.19 MB (650.73K)

Downloads
Session
Downloaded Data: 309.09 MB
Totaler Overhead (Pakete): 29.61 MB (678.41K)

Bis zu ca. 10% Overhead kann man ja noch als relativ normal ansehen, so jedenfalls meine Erfahrung über verschiedene Mods. Aber 20%... Was allerdings sein kann: Ich weiß, daß mav744 seine Warteschlange auf 2000 begrenzt und bei Dir steht "Waiting Uploads: 4988". Deine Warteschlange ist also mehr als doppelt so groß. Wenn der Warteschlangenoverhead beim Uploadoverhead mit einberechnet wird wäre das eine Erklärung. Allerdings hat MonoManiac seine Queue auch auf 2000 begrenzt ("Wartende Uploads: 2001"), und trotzdem hat er diesen extremen Overhead... Das spräche wieder dagegen, daß das die Ursache des Overheads ist. Vielleicht liegt das dann aber auch an den einfachen Anfragen für seine 344 Dateien.

Es geht hier ja nicht um Leechervorwürfe. Irgendwas funktioniert halt scheinbar noch nicht so, wie es soll. Mit Leechen hat das nichts zu tun. Wenn ich mir aber mal eine Bemerkung in diese Richtung (konkret zur Begrenzung der Warteschlange) erlauben darf: Zu Leuten mit voller Queue lade ich nicht hoch. Ich finde eine volle Queue extrem unfair. "Queue full" bedeutet, daß jemand beliebig viel zu einem anderen hochladen kann, es nützt ihm nichts. Ein Nutzer kann ein ganzes Gigabyte bei einem anderen gut haben, seine Kredite sind wertlos. Er kommt gar nicht erst in die Warteschlange hinein. Er bekommt keine Chance, seine Kredite jemals einzulösen. Zu solchen Nutzern lade ich nur hoch, wenn die Situation der jeweils angeforderten Datei es sinnvoll erscheinen läßt. Und da diese Nutzer als Uploader unbrauchbar sind ist das extrem selten...

Mit freundlichen Grüßen
aalerich

**mav744** · 11. April 2005, 05:40

Zitat:

Zitat von aalerich

Ich finde eine volle Queue extrem unfair. "Queue full" bedeutet, daß jemand beliebig viel zu einem anderen hochladen kann, es nützt ihm nichts. Ein Nutzer kann ein ganzes Gigabyte bei einem anderen gut haben, seine Kredite sind wertlos. Er kommt gar nicht erst in die Warteschlange hinein. Er bekommt keine Chance, seine Kredite jemals einzulösen. Zu solchen Nutzern lade ich nur hoch, wenn die Situation der jeweils angeforderten Datei es sinnvoll erscheinen läßt. Und da diese Nutzer als Uploader unbrauchbar sind ist das extrem selten...

Hmm, irgendwann wird doch jede Warteschlange "Voll" ob 2000 oder 10000. Ich dachte immer das dafür, im Morph und in den MoDs die auf in aufbauen (bei anderen bin ich mir nicht so sicher), trotzdem Leute in die Warteschlange kommen die genug Credits haben. Korrigiert mich bitte falls ich etwas falsches sage. Ich habe extra jetzt noch einmal geschaut, meine Warteschlange ist ja auf 2000 begrenzt, das ist ein offenes Geheimniss, aber im moment habe ich 2485 in der selbigen. Dieser überschuss kommt von den Leuten, die Credits bei mir haben, wenn ich alles richtig verstanden habe. Im Grunde ist es auch egal, wie hoch man seine Warteschlange einstellt, da die Anfragen trotzdem kommen und man trotzdem ein Paket schicken muss "Hallo, ich bin voll". Also ist der Overhead der gleiche. Es gibt jetzt 2 Möglichkeiten: Trexpower 2005 hatte definitiv zu viele Quellen, daher der hohe Overhead. Punkt Falsche Einstellung des Hardlimits. Bei MonoManiac liegt es an den zu viel freigegeben Dateien und ich weiss wovon ich spreche. Xman und Du aalerich, müsten noch wissen das mein Overhead auch mal astronomisch war und es lag auch an zu vielen freigegebenen Dateien. Manchmal ist halt weniger doch mehr, was ich selber ja auch feststellen musste. Falls ich etwas falsch erklärt habe, korrigiert mich bitte.
Und das doofe ist, je höher der durchschnittliche down, desto höher der Overhead, hatte das Problem ja auch schon mal beim MaxMoD, da saugte er wie verrückt und mein Upload war für den Ar.... Worauf dann mit einer grossen Portion Ironie von Xman die aussage gekommen ist, das ich ein Leecher wäre. Postwendend hat er aber eine Erklärung gepostet.

Mit freundlichen Grüssen
mav744

**Stulle** · 11. April 2005, 06:06

Zitat:

Zitat von aalerich

Wir sind hier im Development-Bereich! Und Dein Mod heißt "Alpha-Test! Hier geht es um die Entwicklung und Fehlersuche, um das Testen von Funktionen, ihrer Wirkungen und ihrer Auswirkungen.

sehr richtig. wir sind hier um fehler aufzudecken, dev fragen durch zusprechen und uns gedanken über die Entwicklung zu machen, aber leecher Vorwürfe lass ich gewiss nicht auf mir sitzen!

Zitat:

Zitat von aalerich

Und das Ratio hast Du offensichtlich auch komplett entfernt...

Das da war bestimmt nicht die gute fee!

Wie uns sicher allen bewußt ist, kann man Stats manipulieren. Ich kann meinen Muli 23h falsch laufen lassen, ihn dann einstellen und dann die stats kopieren!

Ich selbst habe schon IMMER meine Queue auf 10k gesetzt. Warum¿ Weil ich jedem die selbe Chance geben will. Und meine Queue war auch noch nie voll. Hinzu kommen 424 freigegebene Datein. Die Zahl wird sogar noch steigen! Warum¿ Weil ich die Mods die ich lade Powershare und weil ich annähernd 300 Dateien share die zusammenhängen!

Mein Overhead ist momentan bei 16% des UL.

Was ich nicht wirkl. verstehe sind 2 Sachen:
1.: Wieso suchst du als erfahrener Nutzer zuerst die Schuld bei mir¿ Ich denke du kennst meine Position zu leechern und zur Ratio. Wäre ich Dev des Morph teams, wäre diese ganze Diskussion garnicht erst aufgekommen! Aber ich bin ja nur Anfänger und Anfänger machen alles falsch, vor allem wenn se an Overhead beeinflussenden Sachen (bis auf Reask Timer for File Src und das senkt) garnicht rum bauen... weisst du was¿ Auf solche "experten Meinungen" kann ich getrost verzichten!
2.: Warum springt daenmark auf diesen fahrenden Zug auf¿ Ich weiß es nicht! Hab ich dir was getan¿ Hab ich mein Changelog in der falschen Sprache veröffentlicht und soll ne deutsche Übersetzung EXTRA für dich bringen¿ Bin ich es nicht wert, erst das Changelog zu lesen und dann zu hetzen¿

Mit verstimmten Grüßen
Stulle

EDIT: Willkommen im Mittelalter. Heute verbrennen wir Hexen! Seht dorthinten, da steht auch schon die erste Gruppe Hexen... sie nennen sich "eMule Developers"... aber in wirklichkeit sind es hundsgemeine, keine session-ratio nutzenden Hexen! Darum müßen sie sterben. Klingt komisch, ist auch so, macht aber nix!
Das dazu! Und, lieber aalerich, was du machst ist kein file-sharing. Aus irgendwelchen impulsen heraus meinst du drüber bestimmen zu können wer gut ist und wer nicht¿ Sicher nicht, das einzige was du tust, das ist dir eben dies anzumaßen!

In diesem Sinne, Stulle

**Pathfinder** · 11. April 2005, 07:05

Jetzt krieg dich mal wieder ein, Stulle! Du weißt doch, dass aalerich seine Meinung immer mit reichlich spitzer Zunge zu Papier bringt. Du kannst das jetzt nicht verallgemeinern und von Hexenjagd sprechen.

Es muss ja wohl erlaubt sein zu hinterfragen ob deine Änderungen an der Ratio auch in allen Fällen richtig greifen. Bei den hier geposteten Stats stellt man eben ganz klar fest, mit einem unveränderten Morph-MOD wäre das nicht möglich gewesen. Deine Absichten sind uns bekannt, niemand unterstellt dir ein Leecher zu sein oder einen coden zu wollen. Allerdings muss man sich fragen ob die Absenkung des Durchschnittsuploads ab dem die Ratio greift nicht eben genau die hier gezeigten Fehlkonfigurationen auf User-Seite provoziert. daenemark, ob er nun das Changelog gelesen hat oder nicht ist egal, bringt sein Bauchgefühl zum Ausdruck, er fragt sich wie jemand mit < 10 kB/s Upload eine solche Ratio verdient hat. Kein Grund ihn so anzugehen wie du das tust.

Was den Overhead betrifft, aalerich teilt dir seine Beobachtungen als erfahrener User mit, er ist kritisch und hat ein scharfes Auge. Du hast zwei Möglichkeiten, verstecke dich beleidigt hinter deinem Stolz oder nutze diese Beobachtungen und überprüfe deine Arbeit. Letzteres hilft dir am Ende einen MOD zu präsentieren der fehlerfrei arbeitet. Und genau dabei wollen wir dir hier helfen.

MonoManiac · 11. April 2005, 07:43

Zu meine (und Stulle) verteidigung:

1. Ich bin kein Leecher

, und Stulle-MOD ist auch kein leecher mod

!
2. Meine Mule läuft 24/7, und die meiste zeit habe Ich DL/UL=1:1, 2:1.
1:4 ist nur eine Ausnahme (Ich war eben an der Reihe...

)
3. Wusste gar nicht das 344 freigegebenen files schädlich für netzwerk sind. Wenn es so ist - OK, ist leicht zu korrigieren

.
4. Kritik angenommen. Habe UL erhöht von 12 auf 13, und queue von 2500 auf 3500. Mal schaun...

Für weitere Ideen und Vorschläge bin ich offen.

P.S.
Von 1:4.39 ist nicht viele übrig geblieben.. 1:2.8 ->Tendenz fallend...

**Xman** · 11. April 2005, 07:57

und mal wieder eine Anmerkung:
das was mav da oben schreibt stimmt natürlich voll und ganz.... mit einer kleinen Erweiterung: auch die offizielle Version erlaubt Dir in die volle Queue zu kommen, wenn Du überdurchschnittlich viele Credits hast.

Edit: Nick richtig geschrieben

**Pathfinder** · 11. April 2005, 08:00

Zitat:

Zitat von MonoManiac

1. Ich bin kein Leecher!

Hat das irgendwer behauptet?

Zitat:

Zitat von aalerich

MonoManiac ist sicher kein Leecher oder jemand, der rücksichtslos saugen oder gar Schaden anrichten will.

Wir wollen, dass du was lernst aus den Kritikpunkten die sich aus deiner Statistik ableiten ließen. Das scheint gelungen zu sein, kein Grund rumzubrüllen (-> Fettschrift).

MonoManiac · 11. April 2005, 08:06

Zitat:

Zitat von Pathfinder

Hat das irgendwer behauptet?Wir wollen, dass du was lernst aus den Kritikpunkten die sich aus deiner Statistik ableiten ließen. Das scheint gelungen zu sein, kein Grund rumzubrüllen (-> Fettschrift).

Ich wollte nur klarstellen. Und fettschrift war versehen.

**mav744** · 11. April 2005, 08:06

Zitat:

Zitat von MonoManiac

3. Wusste gar nicht das 344 freigegebenen files schädlich für netzwerk sind. Wenn es so ist - OK, ist leicht zu korrigieren .

Das ist nicht direkt schädlich, aber dein upload wird durch den hohen Overhead ausgebremst. Dein effektiver Upload ist also weniger und du beisst dich ins eigen Fleisch (sprich Ratiobegrenzung). Tausche zB. jede Woche mal die Dateien aus, die Du hochladen möchtest, so ereichst Du eine gute Verteilung und du kannst deine Dateien trotzdem sharen. Und dein Upload geht auch höher (also effektiv). Ich hatte das gleiche Problem wie du, und habe mit dem Weg eine Lösung gefunden. Es kommt auch auf die Grösse der Dateien an, da wenn eine Datei kleiner bzw. gleich einem Chunk ist werden hierfür wohl weniger Anfragen vorliegen, als wie für grössere Dateien. Damit meine ich datei a ist ca. 6 MB gross, wenn diese hochgeladen wird fragt der gleiche Client nach fertigstellung nicht mehr an. Datei b ist 700 MB gross, ein chunk wird hochgeladen und der gleiche client fragt aber noch nach anderen Chunks. Das soll bedeuten, das bei grossen Dateien prinzipiell mehr anfragen zusammen kommen als bei kleinen.

Mit freundlichen Grüssen
mav744

Edit:@Xman: Du tippst zu schnell, du schreibst meinen Nick öfter falsch

MonoManiac · 11. April 2005, 08:11

@mav744
Ich habe immer gedacht, je mehr desto besser. Wieviel soll ich dann noch sharen ? Wieviel habt ihr ?

Ähnliche Themen: eMule 0.45b - StulleMule Alpha-Test