eMule MODs - Allgemein Alles zu den eMule-MODs, die unsere Anforderungen für 'saubere' MODs erfüllen. |
19. July 2003, 23:09
|
#136 | Advanced Member
Registriert seit: 30.06.2003
Beiträge: 109
|
hab immer das gleiche problem wenn ich bei ner datei alle nicht benötigten quellen kicken will stürzt er ab das prob hab ich aber erst seit der 62.zumindest is die 63 bisher von alleine noch nicht abgestürzt wie die 62 naja bleibt wohl wieder nur die 61bb
__________________ |
| |
19. July 2003, 23:15
|
#137 | MODder
Registriert seit: 28.03.2003
Beiträge: 5.800
| böser_oachebär,
benutzt Du auch die aktuelle Version (vom 17.7.03). Lies Dich mal hier durch, der Bug wurde sozusagen gefixed.
__________________ |
| |
20. July 2003, 06:02
|
#138 | Gesperrt
Registriert seit: 14.01.2003
Beiträge: 1.015
| @ Kosh,
Das sagt Usul dazu: Zitat: Zitat:
MxM. hat folgendes geschrieben::
ich werde jetzt meinen upload auf 16 beschränken.... tests in der vergangenheit haben bewiesen dass tatsächlich fast alle mules auf 16 max bei 4x4 optiminiert sind.... und lieber 150:20 -> 15:2 oder meinetwegen 7,5 : 1 ...bei 16 kb/s upload .... als 1600:1600 also 1:1 bei zurzeit 25kb/s upload
bei 16 wären das 2 verschwendete und 14 glückliche kb/s....bei meinen 25 wären es 12 glückliche und 13 failed kb/s ....
|
Ich habe das schon mal in dem Spezialthread erklärt, wo es nur um das Thema fehlgeschlagene Uploads geht, ich bin mir nicht 100%ig sicher, ob es stimmt (vielleicht kann das darkwolf mal bestätigen oder wiederlegen), aber ich glaube es:
Ich glaube, so kann man nicht rechnen!
Begründung: Du gehst davon aus, das ein fehlgeschlagener Upload verschwendete Uploadbandbreite ist. Das ist meiner Meinung nach nicht so. Ein Wert bei den fehlgeschlagenen Uploads könnte doch auch so zusammenkommen (und das sind bestimmt die meisten): Es wird versucht, zwischen zwei Clients eine Verbindung aufzubauen, damit der eine dem andern einen Uploadslot gibt, dieser Verbindungsversuch schlägt fehl -> Wert für fehlgeschlagene Uploads wird um eins erhöht. ABER: Es wurde keine Upload verschwendet (außer etwas Overhead für den versuchten Verbindungsaufbau), da die anderen Uploadslots den Upload voll weiterführen. Im Maximalfall wird der Upload nicht voll ausgelastet, aber nur so lange, wie der Timeout für den Verbindungsaufbau läuft, dann bekommt der nächste eine Chance.
Meine Frage an darkwolf und alle anderen Modder: Ist das so? Wenn ja, dann wären die fehlgeschlagenen Uploads nicht soooo schlimm.
Außerdem wäre es für die Analyse des Problem interessant, ob man die Uploadstatistik so hinbiegen könnte, das man die Gründe für die Fehlschläge nach eigenen und fremden Fehler trennen kann (diletantisches Beispiel: "Konnte kein Socket für Verbindung erstellen" -> eigener Fehler, "Der andere antwortet nicht" -> fremder Fehler). Natürlich ist der eWombat aufgrund seines schlanken Designs eigentlich für solche ausgefeilten Statistiken der falsche, hat halt alles Vor- und Nachteile
Außerdem kommt ja noch hinzu, das an den fehlgeschlagenen Uploads noch nicht mal der eigene Muli schuld sein muß, sondern eventuell nur die anderen. Ich gebe zu, das das Verhältnis fehlgeschlagen/erfolgreiche Uploads auch bei mir rel. schlecht ist (erfolgr./fehlgeschl. 2:1 bis 3:1), vielleicht gibts es dafür eine logische Erklärung (eWombat zählt die fehlgeschlagenen anders als andere Mods zum Beispiel), vielleicht hat eWombat auch ein Problem hier. Auf jeden Fall scheint mit der "neuen" 0.063 sich das Verhältnis gebessert zu haben, muß ich mal beobachten. Außerdem hab ich noch ne andere Idee, an was es liegen könnte, muß ich heute mal testen.
| mfg
Odinasgardson |
| |
20. July 2003, 07:51
|
#139 | Advanced Member
Registriert seit: 30.06.2003
Beiträge: 109
|
__________________ |
| |
20. July 2003, 09:12
|
#140 | Gesperrt
Registriert seit: 14.01.2003
Beiträge: 1.015
| @ böser_oachebär, Das ist die selbe,wie auch darkwolf sie auf seiner Page hatt.Biste dir sicher das du sie nachdem ich den Link geändert habe auch gezogen hast.?
Um ganz sicher zu gehen würd ich sie einfach nochmal ziehen.
mfg
Odinasgardson |
| |
20. July 2003, 11:37
|
#141 | Board Methusalem
Registriert seit: 01.06.2003
Beiträge: 2.177
| mit neuangelegter Clients.met
Ratio: 1 : 1.57 (1 : 1.57)
Heruntergeladen (Session (Total)): 1.85 GB (1.85 GB)
Hochgeladen (Session (Total)): 1.18 GB (1.18 GB)
Average(5-min) DL-Rate: 16.73Kbs (31.42Kbs) UL-Rate 10.68Kbs (11.01Kbs)
aktive Verbindungen (geschätzt): 77 - Zu viele Verbindungen: 0 UL-Sessions successful: 358 - failed: 62 - Avg. time: 19:09 mins
DL-Sessions successful: 525 - failed: 133 - Avg. time: 25:11 mins
Wartende Uploads: 795
Gefundene Quellen: 1411
SUI successful: 2387 - failed: 9
Detected 79 leechers, 5 credit thieveries, 0 friendshare-mod leechers
Programm-Laufzeit: 1 T 8 h
Also so schlecht ist das Verhältnis nun auch nicht. (Bei mir) |
| |
20. July 2003, 11:38
|
#142 | Advanced Member
Registriert seit: 30.06.2003
Beiträge: 109
| hab sie gestern von dem arcor account gezogen weil der download von der atrac hp ned gefunzt hat. weiß nicht wann der link geändert wurde
__________________ |
| |
20. July 2003, 13:08
|
#143 | Board Methusalem
Registriert seit: 01.06.2003
Beiträge: 2.177
| 845 Clients in meiner Warteschlange.
Detected 84 leechers, 5 credit thieveries, 0 friendshare-mod leechers
Programm-Laufzeit: 1 T 9 h
Wenn ich mir diese Zahlen anschaue, kann ich es kaum glauben, das ca. 10 %
Mistkerle unterwegs sind.
Oder besteht die Möglichkeit, das der Wombat sich bei den Leechers irgendwie
verrechnet. Doppelerkennung oder sowas. Keine Ahnung
Die Frage ist also : sind diese Zahlen (84/5) korrekt ?
Im Moment sehe ich in bekannte Clients 3 User mit
identischen Hash. Allerdings ist nur einer davon erkannt (gebannt)
Die anderen Beiden stehen in meiner Warteschlange und warten auf UL.
Jetzt wäre vielleicht eine manuelle Bannfunktion, bedingt durch
identischem Hash, von Vorteil. |
| |
20. July 2003, 13:45
|
#144 | Newbie
Registriert seit: 24.06.2003
Beiträge: 19
| Mit neu angefangener Clients usw. (komplett Neu)
Ratio: 2,94 : 1 (4,49 : 1)
Heruntergeladen (Session (Total)): 196,21 MB (248,35 MB)
Hochgeladen (Session (Total)): 576,87 MB (1,09 GB)
Average(5-min) DL-Rate: 11,78Kbs (24,18Kbs) UL-Rate 34,63Kbs (37,94Kbs)
œ
aktive Verbindungen (geschätzt): 136 - Zu viele Verbindungen: 0
UL-Sessions successful: 146 - failed: 39 - Avg. time: 35:17 mins (habe 20 UL Slots offen-Probe)
DL-Sessions successful: 54 - failed: 15 - Avg. time: 22:42 mins
Wartende Uploads: 3003
Gefundene Quellen: 3986
SUI successful: 3743 - failed: 2
Detected 108 leechers, 2 credit thieveries, 0 friendshare-mod leechers
Programm-Laufzeit: 4:44 h
Mem used: 114,79 mb free: 1933,08 mb
Mal kurz eine andere Frage,wenn ich eine andere Version benutzen will. Muß ich doch um die clients.met vom ewombat zu bekommmen die ClientCredits.exe ausführen und exportieren auswählen,richtig?
dann die cryptkey.dat mitnehmen. Aber wo steht die preference.dat die soll man doch auch mitnehmen,oder nicht?
Ansonsten war es das,oder?
MFG
Knightmover |
| |
20. July 2003, 14:42
|
#145 | Gesperrt
Registriert seit: 14.01.2003
Beiträge: 1.015
| böser_oachebär, da zieh ihn dir halt nochmal ich weiß es auch nicht genau.
Sind jetzt auf jedenfall beide Identisch.
mfg
Odinasgardson |
| |
20. July 2003, 15:48
|
#146 | MODder
Registriert seit: 02.05.2003
Beiträge: 331
| Hi
@bloomy, die Leecher werden korrekt gezählt (allerdings auch die, die keinen upload wollen und nur in der downloadqueue stehen). Es dauert immer einige Zeit, bis die HashDiebe erkannt werden und dann kann man sie auch aus der Queue kicken (Wenn sie der ACT zuerst erkennt, fliegen sie von allein raus)...
@knightmover, mit dem exportieren liegst du ganz richtig.
Die preferences.dat ist beim eWombat als /config/eWombat.dat zu finden. Einfach in dein anderes Mod Verzeichniss kopieren und unbennenen (siehe install*.rtf)
Ich habe die geschichte mit den fehlerhaften sessions mal per Protokoll verfolgt, die meisten kommen definitiv zustande, weil keine Verbindung zu dem client aufgebaut werden kann (auf TcpIp-Ebene Timeout on Connection-request 95%). Die wenigsten kommen zustande, weil der client nicht richtig antwortet oder ein 0 Up/Downloader ist (5%). Bei einer Laufzeit von 16 Stunden habe ich gerade einen gefunden bei dem kein Socket aufgebaut werden konnte.
Wenn natürlich DSl-Zwangstrennung ist oder die Internetverbindung aus sonst irgendeinen Grund zusammenbricht gehen die fehlerhaften sessions schlagartig in die höhe
cu
darkwolf |
| |
20. July 2003, 16:46
|
#147 | V.I.P.
Registriert seit: 07.12.2002
Beiträge: 3.033
| Zitat:
Zitat von darkwolf Ich habe die geschichte mit den fehlerhaften sessions mal per Protokoll verfolgt, die meisten kommen definitiv zustande, weil keine Verbindung zu dem client aufgebaut werden kann (auf TcpIp-Ebene Timeout on Connection-request 95%). Die wenigsten kommen zustande, weil der client nicht richtig antwortet oder ein 0 Up/Downloader ist (5%). Bei einer Laufzeit von 16 Stunden habe ich gerade einen gefunden bei dem kein Socket aufgebaut werden konnte. | Damit ist das Thema hoffentlich mal einigermaßen geklärt. Danke für die Klarstellung und die Mühe. |
| |
20. July 2003, 17:24
|
#148 | Advanced Member
Registriert seit: 13.02.2003
Beiträge: 191
| ich habe bei mir die connections per 5 sec reduziert. auf 40.
jetzt ist cpu last besser
__________________ Es gibt nichts besseres als Hubraum. Außer noch mehr Hubraum. |
| |
20. July 2003, 17:40
|
#149 | Senior Member
Registriert seit: 07.01.2003
Beiträge: 477
| cobrajet,
habe ich nur auf 30 und funtzt sehr gut !!
__________________ cu .. de DQA321 .. nur ICH halt |
| |
20. July 2003, 17:49
|
#150 | Board Methusalem
Registriert seit: 01.06.2003
Beiträge: 2.177
| Ich hab sogar nur 20 und läuft und läuft und ..... |
| |
Forumregeln
| Es ist Ihnen nicht erlaubt, neue Themen zu verfassen. Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten. Es ist Ihnen nicht erlaubt, Anhänge hochzuladen. Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten. HTML-Code ist aus. | | | Alle Zeitangaben in WEZ +1. Es ist jetzt 21:26 Uhr.
|