![[eMule-Web]](images/satellite/header/logo.jpg){kind=logo}
|
hmmm... so langsam glaub ich das bei meinen einstellungen was net stimmt, oder am system, oder was weiß ich was...... ihr habt beide so super zahlen, und bei mir immer max. 2:1 hab ja auch ewig den flux r6 benutzt, aber ergebnis wie immer. 2:1 oder weniger :( |
jetzt kommen wir an den punkt an dem offensichtlich wird, dass ein mod auf dem rechner so läuft und auf dem anderen so... 156:33 success failed nach 7 stunden also vielleicht sollten wir mal deine einstellungen diskutieren renegade, weil u.a. wollte ich auch darauf hinaus... wenn wir nämlich den genickbrecher finden... (und seien es verbose ausgaben) dann kann man nämlich auch mal von vernünftigem bugreport reden... also t-dsl hast du .... richtig ? ... ich glaub usul hat auch t-dsl .... da das bei ihm sauber läuft.... müssten wir jetzt die einstellungen gegeneinander rechnen, oder du testest erstmal den lovelace... und jetzt wird ausserdem interessant wieviel ram, cpu, betriebssystem du hast. |
ich hab grad den 0.27c morph v2a laufen ergebnis: success:failed nach 22:51h 256:144, was 1,77:1 macht also ich hab, wie du schon vermutet hast, t-dsl meine rechnerdaten siehst du unten. |
hmm. schonmal ohne router probiert ? wie schnell sind deine tatsächlichen maximalen down und uploadraten (du-meter ?) unter umständen mußt du die werte nach unten korrigieren, damit sie stabiler laufen... t-dsl scheitn mir keine konstante speedbremse, sondern eine variable zu haben... |
war vorher ohne router genau so du-meter zeigt andere werte als emule an. beim ul z.b. zeigt emule grad konstant 10, während du-meter ständig zw. 9 und 21 schwankt |
Ich denke das der Mule einen Schnitt rechnet ... scheint als hättest du viel kollision zwischen Datenpaketen ... Grüße...-> |
du meter kann auch average anzeigen, muß man allerdings auch einstellen. aber das gewackel vom du-meter is schon richtig prinzipiell, da is nix kaputt ;-) |
naja, mittlerweile liegt das verhältnis nach 35 stunden nur noch bei 1,5:1 |
ja nach langer zeit fällt die sache meist ab... scheint ein leak zu sein, bin aber nicht so sicher.. davon ab, sind deine werte wirklich grauenvoll hast du ein vollwertiges DSL, oder ein DSL light...vielleicht ist deine verbindung zur vermittlungsstrecke so lang, dass soviele pakete verloren gehen |
Hab momentan die neue Lovelace.9 im Test, für Werte nach 1:21h ist es wohl noch etwas früh, aber ich habe folgendes beobachtet: Momentan ist der Mod so konfiguriert, das er mit 2 Slots uploadet, welche momentan beide mit 6,2k hochladen. Gerade habe ich live gesehen, wie der eine upload beendet wurde und der nächste zum Zug kam. Der neue Upload begann natürlich mit 0,0k, aber der andere ist als ausgleich auf 10,x hochgeschnellt. Also hab ich mal zugeschaut, der neue Upload kam aber nicht auf Touren. Nach 15-30 Sekunden gab Emule anscheinend auf, und der nächste Client kam an die Reihe. Dieser Transfer klappte nun, und nach und nach hat sich die Transferrate beider Slots wieder angeglichen. Wie ich danach in der Statistik sah, war ein fehlgeschlagener Upload hinzugekommen (hatte vorher auch kurz in die Statistik geschaut) Ich was lerne ich daraus? Ich habe live gesehen, wie ein fehlgeschlagener Upload hinzukam. Dabei ist aber keine Uploadkapazität verloren gegangen, sondern die freie Kapazität bei einer nicht zustande gekommenen Übertragung wurde für eine andere benutzt. Der fehlgeschlagene Upload in der Statistik hatte also keine Uploadbandbreite vergeudet. Das muß vielleicht nicht bei jedem fehlgeschlagenen Upload so sein, bei einige aber ganz bestimmt, was die hier geführte Analyse von Failed:Success (oder umgekehrt) etwas relativiert. |
das problem ist nicht die bandbreite... der client hatte sich einen queue platz erarbeitet...genauso wie der andere... nun ist der abgearbeitet, und er muss für seinen, denselben chunk wieder anstehen... das ein ausgleich über 2 sekunden entstanden ist, bis der "kräftigere" mod dazugekommen ist... finde ich nicht ganz fair... dieser wäre nach dem chunk sowieso dran gekommen... ich weiß was du sagen willst... aber stell dir vor ... 2 uploads alufen ... nach 10 MB wird nummer 2 getrennt... nummer 1 ist bei 9 MB ... jetzt kommt ein neuer client... und statt wie in deinem fall dass der neue abfällt, bekommt der neue beim hochschnellen den vollen transfer und der erste chunk fällt ab... (schon beobachtet)... dann gehen 9 MB verloren ist erstmal nur ein beispiel... aber das prinzipielle problem hast du sehr wohl beobachtet, wenn auch von der etwas positiveren seite... aber gut, solche beobachtungen finde ich klasse. so kommen wir der sache auf den grund |
Wenn ich mich aber auf den Standpunkt stelle, das der Client, der bei mir drankommen sollte, ein Problem hatte und der Transfer deshalb nicht zustande kam (weswegen auch immer), dann hat mein Emule doch das beste aus der Situation gemacht. Er hat versucht, dem nächsten in der Queue zu geben, was ihm zusteht, hat aber dabei keine Bandbreite sinnlos reserviert, sondern sie jemand anderem zur Verfügung gestellt, und als der nächste nicht geantwortet hat (warum auch immer), kam der übernächste dran. Für mich das optimale vorgehen (in diesem speziellen Fall). |
dann würde es aber ausreichen, wenn beim client dastünde download fehlgeschlagen... der upload ist ja dann nicht von dir unterbrochen worden... also müßte man quasi unterscheiden, in selbstverursachte, und fremdverursachte .... allerdings fallen lange leitungswege, wie bei renegade ...weder unter das eine noch das andere... also wenn zwischen 2 relaisstationen das signal verloren ging... hat weder dein noch der andere mule schuld wenn ich mir aber vorstelle, der 2te slot hätte die geschwindigkeit beibehalten und der 2te client hätte eine höhere bandbreite bei dir zur verfügung gehabt, ohne sich hochkämpfen zu müssen, so denke ich mir sehr wohl, dass der ping zwischen euch kürzer gewesen wäre, und somit ein langer leitungsweg nicht zu einem fehlschlag geführt hätte.. also die probleme sind vielfältig...deswegen hatte ich damals bei badwolf auch doppelte timeoutzeit angeregt... und offensichtlich auch nach mehrwöchigen erfahrungen, hat genau das zu einer sehr großen leistungssteigerung geführt und zu weniger ausfällen ... und das sogar, ohne bandbreite zu verlieren, wie das aus deinem beispiel als umkehrschluss hervorgehen könnte. aber wichtig finde ich es, wenn wir solche situationen zusammentragen können.... ich glaube betatester haben kaum solche möglichkeiten das so zu testen... viele fehler sind unentdeckt, weil ihre ursachen nur schwer sichtbar sind |
Zitat:
in dem sinne .... :wink: |
Statusbericht Lovelace.9b Laufzeit erst 4:15h (aber die Werte sind so schön ;-) ) Succes 45, Failed 5, Verhältnis 9:1 8) Average Uploadtime 12:59min |
hier ist inzwischen ein router geschaltet.... mit dem router erhöht sich die ausfallrate statt success:failed 4:1 kommt jetzt so höchstens 3:1 heraus. das mag an verschiedenen dingen liegen, aber in erster linie muss ich wieder sagen zu kurze timeouteinstellungen in den emules, denn der weg und die kontrolle ist das was am meisten dauert.... ich werde deswegen einen der neueren badwolfs testen, mal schaun, ob das timeout-timing dort mehr hilft, als die optionen die schädlicher sein könnten |
Zitat:
|
das ist für mich kein router, sondern ein PC mit routing software ;-) der kann vielmehr verwalten, frißt aber auch mehr strom und ist mehr lauter ;-)) und blinkt weniger ich muss erst noch endgültig checken woran das liegt, ich hab hitner der DMZ auf meinem rechner ne firewall (no-standard). und möglich, daß die die kommunikation mit dem router blockiert.... muss ich aber noch verifizieren |
Einladung??? Zitat:
sollte dein Router in der Lage sein die Ports zu mappen wäre es besser / sicherer du würdest die Ports so durchschleifen anstelle die DMZ zu nutzen, denn mit deiner entmilitarisierten Zone lädst du quasi die ganzen Script-Kiddys ein zu gucken was geht. (Alle Ports erreichbar, zwar erstmal nur bis zu deiner firewall, aber auf jeden Fall ein Angriffspunkt mehr!) CU Pan Tau _________________ Be paranoid, or be hacked! |
das problem ist, dass emule SO aggressiv ist, daß der router ALLES auf supersparflamme schaltet, weil quasi die ganze zeit storming läuft. das seh ich ja auch die ganze zeit... ICMP storming auf port 1214, mein mule läuft auf anderen ports... also source exchange hin und her... aber das das udp für icmp storming ausgenutzt wird hätte auch klar sein müssen... wenn ich eben über UDP die WIEDERAUFNAHME erreiche... dann erreiche ich sie wohl schneller, wenn ich storme alle emules sollten soweiso langsames/sicheres verbinden zu servern mindestens automatisch voreingestellt haben... und die requests sollten sich nicht auf 1 request per source per file beschränken ..sondern 1 request in 10 minuten per hash / user ...egal wieviele files ich habe ich bin gern offen für weitere empfehlungen, aber mit port mapping läuft der upload bei unter 20% ...und der download bei unter 10% ist ein SMC router |
um aber kurz aufs thema auf andere weise zurückzukommen, möchte ich kurz erwähnen dass ich durch folgende dinge die failed statistic zurückschrauben konnte von 200 max. connection 200 sources per file auf je 150 ging die failed shcon leicht zurück und dann habe ich aus meinem share dateien verschoben (auch temp ordner). kontrolliert 5 dateien im temp und nicht mehr als 5 GB im share hat zu einer weiteren verbesserung geführt. |
und ich hab nochwas interessantes gefunden bei der neuen Version von enkeyDEV. l2hac lowid to highid automatic callback: A simple idea to avoid useless server load: when a lowid user enqueues a highid, it's useless the latter asks the (common) server for a callback request every 21'40". This mod makes the lowid connect to the highid automatically every time without waiting for the server callback. It works as well with most of not-modded-emule-clients: every time the not-modded highid try the connection, it finds itself already connected and make the request immediately without server callbacks. This gives: - less server load (the AVERAGE server callbacks avoided are between 4 to 8) - better lowid UL (if the lowid changes server, the highid is kept on queue and constantly updated) Does it work? Some statistics (over about 100000 tries): - L2HAC connection successful: 92% - Reask received: 85% Most of failure is due to clients with a non-standard reasktime value (21'40") Most of failure is due to clients with a non-standard reasktime value (21'40") |
Zitat:
Pan Tau |
noch ein paar werte: eMule plus v1c (Limits auf 90k, 11k) auf XP-Pro (SP1); AMD XP1800+; 256MB DDR333; ENMIC 8TTX3+; 128MB GF4 TI-4200; T-DSL 768/128; im Netzwerk über Hardwarerouter CO-SA (NoNameProduct) online seit 4T 3H erfolgreiche Uploads: 1350 fehlgeschlagene Uploads:270 durchschnittliche Uploaddauer: 18:35min Verhältnis erfolgreich / fehlgeschlagen: 5:1 Das heisst dann bei mir löppt die v1b besser im Upload und ich werd sie wohl auch wieder in Betrieb setzen auch wegen der vielen kleinen unsauberkeiten im code von v1c. Ach, und zum Thema Abstürze die plus v1b und v1c sind bei mir noch nie abgeschmiert, trotz intensiver Nutzung abseits von eMule (Spiele, surfen, Textverarbeitung, brennen). Pan Tau |
mit router dazwischen geht mein failed über den success :cry: ich hab nix verändert, ich weiss nicht was ich machen soll |
dann könnte das bei mir wohl auch am router liegen, das ich so ein schlechtes verhältnis habe |
aber ich bin gerade an den einstellungen, um da einige sachen hinzubekommen immerhin bin ich wieder bei überhalb von 4:1 success:failed nicht über DMZ gehen. ports mappen. automatic slot/datarate control AUS ! (im gegensatz ohne router: an) AMUC noch am experimentieren, aber wahrscheinlich eher AUS smart upload noch am experimentieren, aber wahrscheinlich eher EIN ganz wichtig: SOURCE EXCHANGE MAX EXCHANGE AT ONCE 100 disable for files with sources above 50 max. verbindung per second hatte ich schon immer 15 wichtig auch AUTOHARDLIMIT: EIN im advanced 2 NUR DROP NNS EIN da aber richtig start ab 50% stop bei 10% queue nach nachfrage regeln: 2000 reicht bei mir zu 80% auch sehr wcihtig unter server: MAX FILES TO SEND: 100 server connection timeout auf 20 sicheres langsames verbinden zu servern EIN und auch die prioritätssysteme müssen ein wenn amuc ein, DANN Delay >30 jau der rest musste anpassen, zum beispiel min. max. slot und datarate ...bei mir 2-6 16384 am ende spielt eigentlich keine rolle mehr wieviel du max. connection und max. sources per file eingibst... ich hatte vorher immer 200 200 ohne router, aber das is so geschwankt... jetzt steht da vom assistent für die verbindung eingerichtet 500/800 ....aber ich muss ma sagen , das is kein unterschied, die anderen werte beeinflussen schon alles automatisch. und wenn ich QSC wähle, stellt er das sowieso bissel falsch ein... also die rechnen da nicht 8 bit = 1 byte, sondern 8+2 bit = 1byte... für diese bits wo noch etliches mitgesendet wird...was auch ok ist... aber bei 25 hab ich echt noch platz nach oben. auch 115 kb/s für den down haut nicht hin, da sind es hier 132.... wobei ich den nur bei ftp loads bekomme also im moment experimentier ich noch mit dem SUC und dem AMUC aber vielleicht hilft dir das schonmal weiter. |
also mit den einstellungen habe ich jetzt seit ich gepostet habe bis zu diesem posting 110:16 ...was wie man sieht nahe 10:1 success:failed ist. ich bin nicht sicher, wie das ohne router aussieht, da am router noch wer anders ist, kann ich das jetzt auch nicht abschalten und umstecken, aber vielleicht sind die einstellungen in ähnlicher form auch ohne router nützlich. |
renegade? probierst du herum, oder wie ? :-D |
also ich will nur mal posten, ich bin vor 3 stunden mitm fahrrad losgefahren, da hatte ich so 370:70 ...seitdem hab ich nix am rechner gemacht, logischerweise... gerade jetzt steht das verhältnis 433:78 effektiv habe ich in 3 stunden 63:8 gemacht ...was 8:1 entspräche insgesamt 5,5:1 .... ich rede immernoch vom fusion flux (r6) ...also wenn man sich die einstellungen bisschen bastelt, dann wird das schon was. die laufzeit insgesamt ist 1 Tag 2 Stunden, zum server seit 8 stunden connected. |
mei .... 448:78 ...also das delay optimieren zahlt sich aus... ich hab seit 18:55 nicht einen chunk im upload verloren. |
Kurze Bilanz von 0.27c O²: Success: 61 Failed: 14 Dauer: 20:43 min Verhältnis: 4,4:1 also nicht wirklich schlecht, aber ich hab schon besseres gesehen. Aber naja, ich schätze, der Wert hängt auch von der Tagesform ab, wie so ziemlich alles bei Emule ;-) |
0.27c O² success: 273 failed: 74 dauer je chunk 11:05 (system 2-6) laufzeit 8h 30 min success:failed 3,61:1 (mit router) |
0.27c O², zweiter Lauf nach 7h Laufzeit: Success: 76 Failed: 10 Dauer: 17:33 min Verhältnis: 7,6:1 so ist das schon besser ;-) |
Ich wüsste wie man nen MEGA Upload kriegt: Man müsste nur T-online dazu bringen, das alle t-online User untereinander mit 90 kb uppen können. Wär kein Problem für t-online und die hätten den Vorteil, das WENIGER traffic verursacht wird, weil das intern läuft und t-online das nicht bezahlen muss. Dann würden auch alle Filesharer zu t-online wechseln und alle wären glücklich ... ;) Naja bei mi hat die Lovelace 7b mit Suck SEHR gute uploadwerete. Letztens war der Durchscnitt pro Verb 2:04 h bei null fehlerhaften Uploads. Leider kommt die in sachen Down-Speed nicht an die Lovelace 26 d ran. Ich bin auch für weniger slots (max 4 ) mfg |
also mit der eMule0.27c-LSD6e hatte ich mein bisher bestes ergebnis, was das verhältnis angeht, nämlich 6:1 (64:11). allerdings erreicht der ul fast nie das eingestellte max von 12 sondern bleibt immer zwischen 9 und 11. und nach einigen stunden hat sich dann auch dieser mod einfach beendet. |
emule 0.27c LSD7b Laufzeit: 10:41h success:failed 274:32 verhältnis s:f 8,5:1 MIT router average uploadtime (full chunk): 17:05 min (4.0kb/s system) dazu sei gesagt, dass ich LSD nur aufgrund von Erfahrungsberichten aus diesem Thread überhaupt downgeloadet habe und auf Basis der Aussagen im Original-Forum, daß LSD passionierter Mule Fan und Mule Programmierer sei. Im Moment kann ich das bestätigen, Features sind auch offensichtlich in den Programmcode eingebettet worden und nicht nur reinoperiert. edit: achso und der upload erreicht eigentlich durchgängig sein maximum, so wie wir es von mules vor 0.25 gewohnt sind. bei mir jedenfalls |
Welches ist nun die beste Methode um eigene Releases upzuloaden? Ich habe ein paar releases und die stehen auch auf "release". Hab DSL1500 bei arcor... also up/down = 32/187kb/s Share sonst noch 77 files... die habe ich auf "SEHR NIEDRIG" gestellt, um endlich mal die eigenen Releases durch die leitung zu jagen.... Aber keine chance.... 100 MB von den eigenen releases gingen raus...und in der selben zeit 6 GB an SEHR NIEDIRGEN Files... Das ist ja wohl Schwachsinn, oder??? Diese Eintellungen bewirken ja mal GAR nix. Klar wenn man mehrere zehntausend Anfragen an sehr niedrigen files hat... wird scheinbar das SEHR NIEDRIG sehr unbedeutend ;) Welches Mod ich nehme ist ziemlich wurscht... Das ******* Muli shared immer die Temp files mit und deswegen werden meine releases NIE rauskommen. Wie macht Ihr das??? Ich hab mir mal überlegt mit 2 emule versionen zu arbeiten. Eine für NUR Upload eine mit NUR Download. Oder wie macht Ihr das um Eure Files an den Mann zu bringen? Das Märchen von "In Share legen Upload auf max und in boards posten" ist ja nicht besonders real... Was kann man tun, um den eigenen releases wirklich hohe prio zukommen zu lassen ??? Naja also auf die NUR upload schiene möchte ich auch nicht gehen-....das ist nicht der sinn vom sharen... Ideen??? Greetz+ TheBeta =================== router smc7004 abr Sivka mod v8b1 Laufzeit 10T, 1 S U/D 1:1,47 erfolgreiche/fehlgeschlagene up 3737/1683 (wie kann man das verbessern?) Durchschnittliche upload time: 17,56min wartende upload 4963 von 5000 |
Downloadest du vielleicht Dinge die zur Zeit sehr beliebt sind wie Filme,Spiele etc. ? Wenn ja dann ist das kein Wunder und ausserdem solltest du es lieber bei einem Mule belassen. Denn es hat ja wohl kein Sinn das du 2 Mule's hast ! Falls du das machst werden bei deinem Download-eMule so oder so andere Leute downloaden oder Uploaden je nach dem, weil du da in Daten in deinem Temp Ordner hast die irgendeiner garantiert haben will ! Also solltest du alles auf Release geben, zumindest hab ich das so,weil du dann einen Upload-Bonus von 1,5 gibst, soweit ich das noch richtig in Errinerung habe... Such einfach mal auf dem Such-Button und gib dann mal was mit Release ein. Ich hoffe, dass ich dir helfen konnte. Cu Screamy |
@Screamkillerchen Wenn die Frage war, ob ich Sachen lade, die ich brauchen kann.-... dann ja ; ) Ich meine...was keine Quellen hat kann man ja kaum laden...also lädt man immer etwas was "beliebt" ist oder "beliebt genug" um es auch zu bekommen. Zitat:
Das ist ja der Sinn der Sache.... Ich will ja, dass die Upload der sowieso schon super gut verbreiten Files aufhören, damit Sie den weniger verbreiteten Files oder ganz neuen Files nicht den Upload wegnehmen. Mit einer funktionierenden Prio Regelung des Upload würde das auch gehen. Diese Multiplikatoren sind gemildet ausgedrück Quark. Wie gesagt ich kriege KEIN File release und meine Leitung is nicht dünn. Deswegen GANZ auf downloads zu verzichten is ja wohl auch gestört... Wenn es 2 mal läuft leecht der eine client und der andere lässt leechen und zwar was ICH will. Das bringt ja dann wohl auch eine bessere Verfügbarkeit. Jeder der das File will bekommt es mit einem guten Speed. Der Download client kriegt dann halt nur 1-5 kb/s download und der Upload client lädt keine files und schiebt NUR die Dateien rauf, die releast werden sollen. Ist traurig, dass man so vorgehen muss. Aber ich habe seltene Files und wenn die Prio Einstellunge absolut Müll sind und nur die super bekannten files durchlassen hat es keinen Sinn. Vorteil ist, dass auch der "kleine" Mann mal was releasen kann. Bei mir sieht es zur Zeit so aus: 258 000 Anfragen für die Top 10 Files mit den meisten Anfragen aber halt "NUR" je 1000 Anfragen für meine eigene Releases. Ergo kommen die NIE zum Zuge. Noch was...jedes mal, wenn ich ein files sauge wird die Prio zuerst auf "NORMAL" gestellt. Ich habe schon bei ALLEN Files die Prio auf SEHR niedrig und auf den releases auf RELEASE.... Aber das bringt REIN gar nix......die prio regelung funktioniert schlicht NICHT !!! Also kann man nur Releasen, wenn man einen gepatchten client zum downloaden und einen 2ten client zum Uploaden nimmt. Traurig....vielleicht werden diese "Bugs" mal behoben...sonst wird man immer nur den Main Stream Stuff bekommen. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 14:12 Uhr. |
Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.