Xman,

sehr gute, ergänzende Argumentation.

Ein Problem, bei dem ich bei Vorlost auf Granit gestossen bin. Der Mod der beim Coder erstellt wird, kann für einen Leitungsweg von 420 m zum nächsten Knotenpunkt erstellt worden sein, während ich vielleicht auf 700m oder auf 40m bin. dass sich zusätzlich auch noch der knotenstandpunkt für die wege zu den noch wieder anderswo befindlichen zielen ganz andere zeiten ergeben mögen... auch meinetwegen durch die wahl des servers beeinflußt.... könnte man wettmachen, indem man zumindest die timeouts so optimiert, das sich der average verbessert... was dann zumindest den weg zum ersten knotenpunkt...die erste meile erstmal gut einfindet.

Ich habe nur auf Lovelace in Verbindung mit Release Features hingewiesen (Wenn Clients Release-Files haben wollen, kommen sie immer in die Queue (so eine Art kontrollierte Infinite Queue), außerdem einstellbare Priorität der Release-Files). Was deine Ban-Liste damit zu tun hat verstehe ich nicht ganz. Erstens läßt sich darüber trefflich streiten, sie hat nämlich auch einen gewissen Referenzwert, wenn man mal ein paar Leecher testen will, zweitens, selbst wenn Lovelace ein Leecher sein SOLLTE, kann sich darin trotzdem interessanter und wertvoller Code verbergen, und drittens ist das Offtopic und ich will nicht, das jetzt dieser Thread wieder in eine abwegige Diskussion hinausläuft. Hier gehts im eWombat und fertig. Das ging an ALLE!

Hier mal ein Zitat von dir:Also erstmal ist 16k upload bei dir noch weit vom theoret. Uploadlimit entfernt (wie hoch ist das eigentlich? 25k oder 32k? ist aber eigentlich egal, 16k ist weit davon weg, ich arbeite hier mit 13k bei 16k max.), zweitens würde mich mal interessieren, wie hoch dein Uploadschnitt war, als du 25k Upload eingestellt hattest, und wie hoch bei 16k. In diesem Beispiel hast du doch so gerechnet, wie ich nicht glaube, das man rechnen kann, du hast die Sessions in Prozente umgesetzt und diese auf die Uploadwerte gerechnet. Was hast du den für Uploadwerte gemessen?

eieiei... jetzt willst du es genau wissen... ich frag mich gerade, ob du absichtlich nach diesem gescuht hast... offensichtlich ja.


hat dich schön irritiert mein mix aus 3 antworten was ?

ok, was hab ich getestet.


1. T-DSL in meiner damaligen Zweitwohnung mit 16k up
2. QSC in meiner immernoch aktuellen Wohnung mit 32 theor. und praktischen irgendwo bei 38k up.

experimentiert habe ich bei QSC mit Zahlen, die dem Faktor 4 entsprehcen und diversen Systemen wie AUBWC, X-Slots und auch ohne diese Features.

die success:failed werte haben, wenn auch nicht überdimensional die Tendenz aufgewiesen, dass sie bei einem Faktor von 4 besser waren.

Am schlechtesten waren sie bei Primzahlen. So meine Erfahrung bei QSC.

11 , 13, 17 laufen ganz schlecht, wenn ich mit x-slots ohne aubwc arbeite.
mit aubwc sieht die sache wieder anders aus.

damals wollte ich unbedingt wissen, warum es soviele failed sachen gibt, das sind nur die ergebnisse daruas, die letzendlich schlüssig waren und sich regelmässig wiederholt haben, was natürlich objektiv auch zufall sein kann. mein fazit war, das die erten wombats und die letzten fusion der 26er bei 16 und bei 24 am besten liefen. auf qsc.
16 war für t-dsl wiederum zu nah am leitungslimit... hier bin ich dann am besten mit 4x3 also 12 gefahren.



jetzt habe ich diese erfahrungen also bisschen gemixt... und der letzte satz gibt eigentlich so ein konflumerat aus allem wieder.

das beste verhältnis auf meiner QSC Leitung mit einem Wombat (0060)
150:20 runterdividiert auf die theorie von mir, dass emule sowieso auf 4x4 compiled wird (aber eben nur offline BERECHNET WIRD...festplatten sollen enorme übertragungsgeschwindigkeiten mit erstaunlich wenig packet loss besitzen) also dividiert auf 16
im vergleich zu dem verhältnis meiner 0063 und den realen werten die sie gerade ereicht hatte und hier habe ich natürlich die failed werte auf meinen average berechnet.

zu deiner frage... bei 32 max hat der average immer zwischen 29 und 30 gelegen. je nach mod. bei vorlost ist der average unter 27 gefallen, allerdings war er mit abstand am schlechtesten... der nächstschlechteste lag knapp unter 29.

aktuell habe ich das angepaßt je nach browser und messaging verhalten von mir switche ich von 25 k auf 32 k. bis vor kurzem musste ich ebenfalls rücksicht auf eine WG nehmen. teilweise habe ich diese regel auch mit nightshift automatisiert.

Also um es mal auf den Punkt zu bringen: Wenn du 32k mit dem aktuellen eWombat freigibst, dann hast du einen Average Upload von sagen wir 27-30k, wenn du 25k freigibst, vielleicht 20-22k (ist jetzt von mir geraten). Gleichzeitig hast du aber **********e Statistikwerte, UploadsessionsSuccess/Failed im Verhältnis 2:1 oder schlechter. Du willst jetzt deinen Upload auf 16k drosseln, damit die Statistikwerte für die Uploadsessions besser werden, habe ich das richtig verstanden? So hast du es oben wiedergegeben. Stell dir mal vor, das würde jeder machen!! Nochmal zum mitmeiseln: Wenn du schlechte Statistikwerte bei den Uploadsessions hast, verschwendest du praktisch KEINEN Upload, es kommt halt nur nicht der an die Reihe, der mit Uploaden dran ist, sondern der zweite, dritte oder vierte. Praktisch geht aber dein Uploaddurchschnitt von 20-22k auf unter 16k herunter, also so 13-15k, schätze ich mal. Und das alles nur, damit deine Uploadsessionstatistik besser ist?

vor allem weil ich mir wirklich nicht vorstellen kann, daß diese Statistik bei 16 besser als bei 24 ist. Die wird erst schlechter wenn nach oben zu wenig Platz ist.

Ich habs selbst wirklich in aller Ausführlichkeit getestet. Bei mir verschlechtert sich erst was ab 25,5. Und genau dies ist auch die Marke, wo cfos (falls benutzt) bei mir das TrafficShaping einsetzt.

Hi,

Um die Sache kurz zu machen die 0.064er wird mit optimierten TCPIP-Routinen arbeiten, vorallem was die Anzahl und Verarbeitung der Verbindungen betrifft.

Jetzt habe ich aber auch mal durch Zufall einen Bug im eWombat gefunden :oops:

Wenn man im Downloadfenster auf einen Client doppelklickt oder die Details dazu aufruft, der den Status 'waiting for 1st connection' hat, verabschiedet sich der eWombat.
Also: Bitte keinen doppelklick auf Clients mit 'waiting for 1st connection', macht auch wenig sinn, da noch keine Daten für diese Clients da sind..
Dieser Bug wird in der 0.064er behoben...

cu
darkwolf

zum zeitpunkt der 16 war zusätzlich noch ein router und ein aktiv freundlcihes WG Netzwerk mit angeschlossen.


richtig aber ist, dass ich den upload auf 25k drossele, weil die failed werte um 30% zurückgehen.

deinem satz "stell dir mal vor das würde jeder machen" kann ich nicht ganz folgen.

du gehst von deinem beispiel aus:


32k upload 4 slots meinetwegen

a)1 slot 12
b)1 slot 20
c)1 slot 0

tüdeltüü... 1 Minute später wird slot c ausgewechselt und ich hab einen failed mehr.

an dieser stelle würde ich dir recht geben, dass es rein um die zahl gehen würde.

da die sache aber eher so aussieht

a) 4
b) 6
c) 4
d) 4
e) 8
f) 4
g) 2

und hier auch leute vor beendigung der chunk größe aber im bereich von massiver traffic verschwendung verloren geht, weit nachdem der kontakt hergestellt wurde, und ich genau diesen effekt drosseln konnte, indem ich den up beschränkt habe

statt bei 32 ein verhältnis von 10:12
bei 25 eines von 10:8

habe ich meine effektivität entweder um 30% gesteigert, oder andersherum würde ich meine effektivität um 50% verschlechtern, würde ich sie abändern zu 32


leider funktionieren ätere mods recht schnell nichtmehr, sonst würde ich immernoch auf einem 24er Plus oxygen badwolf rumhängen bei dem ich leitungne prinzipiell auskosten konnte.

wann ich wo welche leitung benutze und wieviel ich da zur verfügung habe und wieviel ich dafür benutze dateien über ein sharing programm laufen zu lassen, solltest du übrigens dringend meine sache sein lassen,

ob ich meine musik via FTP anbiete, ob ich nebenbei einen mp3 stream mit einem mix-set laufen lasse, ob ich das parrallel mache... oder ob andere user bei großem upload nicht doch auch auf die RIAA oder ähnliche Vereine aufpassen sollten, solltest du ihnen überlassen.

ich hab rechtlich kein problem, und ich hab auch kein problem mich zu erklären was gewisse dinge angeht.... aber wieviel leitung ich wann wo für was gebe und warum, sollte meine sache sein... und wenn mein engagement wegen schlechter sessionwerte verändert wird, so ist das auch meine sache... ich bin lange genug wegen schöner werte auf vollem level gefahren... 24 stunden lang... mit dem rechner neben mir rauschend während ich schlief... ca 340 GB upload sprechen eine sprache.

ende der durchsage.

MxM.,
wir sprachen ja auch nicht von drosselung von 32 auf 25 (was ja zu empfehlen ist), sondern von drosselung auf 16 (was nicht zu empfehlen ist).

*offtopic on*
MxM, ich glaub du hast ein problem und dass ist, du hast ein bisschen mehr upload, als viele user hier im board! du sagst, dass du hauptsächlich deine musik share's! und nun willst du dein werke einschränken, dies ist doch unglaubwürdig!
ist nur meine meinung!
*offtopic off*
cyrex2001
ps: ich hoffe dies bleibt ein ewombat-thread!

http://www.streamerp2p.com
trefferquote sendung: 100%

einschränkung 16K gilt für einen standortwechsel eines rechners.




und das thema ist SUCCESS:FAILED

wenn success:failed = 100% dann emule 32kb/s + 16kb/s

aber ich sags gern nochmal... ich lass hier nciht meine privaten hosen runter, damit ihr zu 100% versteht wie und was ich wo arbeite. bestimmte sachen muss man ja nicht jedesmal in eine glaubwürdigkeitskrise katapultieren indem man die komplette umgebung erfragt um sie zu verstehen. manches mal reicht es ja auch aus, indem man eine aussage akzeptiert und mit ihr weiterrechnet.


dieses prinzip ist sogar mathematisch fundiert und nennt sich mengenlehre.

sehr sehr richtig, deswegen gibts aber schon seit urzeiten threads für leute mit soclhen leitungen... diese leitungen gibts schon länger als emule selbst... und deswegen pranger ich immer wieder an, dass emule offensichtlich auch nur auf 16K systemen erstellt, geprüft und getestet wird... weil es am ende offensichtlich auch nur dort so funktioniert.

also setze ich mich seit eh und je dafür ein, dass man eben diese unterschiede erkennt und vielleicht einen flaschenhals beseitigt der offensichtlich zu dieser form von skalierbarkeit von uploaderfolg gegenüberleitungsgröße resultiert.

blacklotus hat an dieser stelle eine ziemlich geniale idee eingebaut, leider nur private zwecke... dass die gegenstelle überprüft wird, ob sie dementsprechend in der lage ist mit dem speed beim empfang mitzugehen. den dicken leitungen kommt es zugute, wenn die gegenseite gecancelt wird, wenn sie nciht darüber verfügt....

kann man jetzt argumentieren, dass dann ja die kleinen nix davon haben wie modem und ISDN...allerdings werden die ganz sicher viel eher zu 100% von T-DSL'ern erreicht und abgedeckt...

aber das ist wie gesagt leider nur für privatzwecke, und auch nicht für mich zugängig

der thread achillesferse war jedenfalls bereits ein schritt in die richtung, weil ich dachte dinge aufdecken zu können die damit in zusammenhang stehen, da ich dieses und andere phänomene (stichwort bei cpu last rennt der esel) beobachtet habe und geklärt wissen wollte.

ich denke, dass ich in dem thread meines favorisierten emules sehr wohl auch was dazu sagen und beitragen kann, auch wenn 80% der user mangels deckungsgleicher möglichkeiten dazu nix sagen können und das auch nicht nachstellen können.

das man solche sachen jedesmal tot diskutiert ist jedenfalls nicht in meinem interesse... in der vergangenheit gabs nur schwierigkeiten, mangels erklärungen und wegen überschuß von mißverständnissen.

an manchen stellen hört aber öffentlichkeit auf. und der druck auf P2P gemeinschaften wächst ungemein. gerade leute die viel uploaden sind im kreuzfeuer.


und inwiefern wir hier überhaupt so richtig weit offtopic sind frag ich mich auch... schlussendlich benutzt sowohl usul als auch ich gerade wombat es geht um die m.E. krass hohe failed:statistik und der sache gehen wir mit einem workaround von argumenten auf den grund....

wem das jetzt nicht paßt und wer jetzt hier gern nur AUBWC vom hersteller erklärt haben möchte, weil einzig dies und die meldung eines neuen wombats in diesen thread gehören, der sollte das dann gleich sagen, ich finde einen extra thread für solche sachen schwachsinn, wenn sie schlussendlich hier speziell auf das problem des wombats laufen und eben nciht meinetwegen auf das eines anderen emules einer anderen versionsnummer.

Hi,

Ich bin ja dabei die Sache mit den failed upload sessions zu analysieren (langzeit).
Ich habe erstmal verucht herauszufinden woran es liegen kann um dann in die statistik zu dem failed wert noch einen 'critical' wert anzugeben (critical ist im den fall meine persönliche Meinung und basiert auf Fehlern die vom eWombat verursacht worden sind).Desweiteren geht es bei den failed upload sessions nur um diejenigen die mit 0 upload enden (so wird auch im org. eMule gezählt).
Folgendes ist aber Fakt:
- die failed sessions verbraten nur minimale Upload-Bandbreite (für einen neuen Upload-Slot wird 1Kb/s freigehalten und die anderen Slots brauchen halt ein bisschen bis sie sich einpendeln falls der neue Slot seine Bandbreite nicht ausnützt)
- Die ganze geschichte ist irgendwie von der Tagesform abhängig :wink: (an machen tagen läufts gut an anderen schlecht)
- Irgendwie ist es auch davon abängig zu welchen Server man connected ist
- Meistens sind es (seit ich da log mitlaufen habe) immer dieselben IP-Ranges die Probleme haben (80.x.x.x, 200.x.x.x, 217.x.x.x)
- Bis auf die genaueren Timer des eWombats gibt es im Verbindungsaufbau keinen unterschied zu den meisten anderen Mods (ich benutze immer noch den code vom eMule0.28b)
- Das ganze ist auch definitiv stark von den einstellungen und von der Hardware (Router) abhängig. (Könnte sich jemand mit ISDN für den nächsten Betatest zur verfügung stellen)
- Man kann die Timeout Zeiten für den Verbindungsaufbau und für die Übertragung beim eWombat unter TCPIP-Settings ändern.

wegen der Releasefunktionalität habe ich mir folgendes ausgedacht:
Das ganze ist nur aktivierbar wenn eXtended Upload aktiviert ist.
x Slots ist einstellbar von 1 - min. Slots-1
y ist einstellbar von 1-1000.
Releasefiles werden dann auf x Slots um den faktor y gegenüber normalen files bevorzugt. Wenn niemand ein releasefile haben will läuft alles ganz normal.
Clients die ein releasefile haben wollen kommen immer in die queue falls aktiviert.

Das ist doch der Trugschluß, den ich meine. Wenn die failed-Werte um 30% zurückgehen, hast du deswegen nicht mehr geuploadet. Wenn du den Upload senkst, hast du weniger Failed UND weniger Upload, wenn du den Upload oben lässt, hast du mehr Upload und mehr Failed, die Failed machen das mehr an Upload aber NICHT kaputt.
Der Satz ist wie folgt gemeint: Wenn jeder seinen Upload so massiv senken würde wie du, damit seine Statistikwerte besser werden, wäre Emule viel langsamer vom Download her. Oder ist das jetzt auch falsch?

Wieso ist ein Upload Verschwendung, wenn der Upload vor der Chunkgröße beendet wird? Gehst du davon aus, das Emule das dann wegwirft? Das ist doch nicht so, der Rest vom Chunk wird einfach später geladen, du verschwendest NICHTS, wenn der Upload noch der Hälfte der Zeit abbricht.

Ich verstehe dein Verständigungsproblem echt nicht. Bei 32k hast du selber gesagt, hast 27-30k Uploaddurchschnitt, bei 25k sinds vielleicht 22-24k. Rechnen wir mal mit den unteren Grenzen, da nichts weggeworfen wird, war an Upload rausging, sind doch 27k upload weniger als 22k upload, oder steh ich jetzt total auf dem Schlauch? Das schlechtere Verhältnis steht NICHT für verschwendeten Upload, wie oft den noch? Wenn 27k rausgehen, gehen 27k raus, bei 22k halt 22k, das hat doch nichts mit dem Verhältnis zu tun.

Das einzige, was du veränderst, ist die Effektivität der UploadSessions, nicht des Uploads, du setzt das immer wieder gleich.

Natürlich ist es deine Sache. Wenn du anderen aber (in meinen Augen) falsche Tipps gehst und andere dann auch ihren Upload um 25% oder so drosseln, ist es nicht mehr nur deine Sache. Nur darum gehts.

Witzig, das du damit anfängst. Hab mich auch mal mit ihr darüber unterhalten. Erstens mal ist das wirklich ihr privates Forschungsprojekt, keine Ahnung, ob sie will, das davon was in die Öffentlichkeit getragen wird, ich werd sie bei Gelegenheit mal fragen. Zweitens ist es gut, das es privat ist, weil es in dieser beschriebenen Form wohl nicht öffentlich bestand haben würde. Wieso hast du bei Lovelace, wo ich diesen Namen in den Mund nahm, mit deiner Ban-Liste gewunken, bei dieser Variante, die Clients einfach kickt, wenn deren Leitung nicht gewissen Anforderungen genügt, aber kein Problem damit, das toll zu finden? Ist das Ziel dann eine Zwei-Klassen-Gesellschaft, die reichen Emules (mit den dicken Leitungen) geben nur den reichen, die armen Emules (mit den dünnen Leitungen) geben nur den armen? Ich sage nicht, das dieser Code nicht gut ist, das er zur Selektierung der Uploads benutzt wird, ist es jedenfalls nicht. Ok wäre es, wenn man es für die Einstellung der Uploadmenge nehmen würde, so ist es aber wohl NOCH nicht implementiert.

usul,

Thema Lovelace wollte ich davor warnen blind jedweden Code zu übernehmen, da eben Modder auch und gerade hier in diesem Thread mitlesen und es ging um Übernahme von Code aus dem Lovelace. Ich habe hier Angst davor, dass gerade das thema Push & Kick verharmlost wird.

Thema Blacklotus, mir ist nicht bekannt, dass sie Ideen patentiert hat... warum soll man Ideen die eventuell gut sind für sich behalten... Zweitens ist sie selbst von dieser Slotstrategie abekommen... und mir geht es eigentlich auch und gerade beim Wombat um das auseinandersetzen mit solchen Sachen, da AUBWC noch nicht in dem Maß (oder nichtmehr ? ) funktioniert wie ich mir das wünschen würde, die Funktionsweise bei rein eingeschalteten x-slots und dann zugeschaltetem AUBWC ist so stark unterschiedlich mit wenig Auswirkungen auf die success:failed Werte, daß ich gern Vorschläge und Ideen einbringe, die so noch nicht umgesetzt sind, daß man dann darüber diskutieren kann. ausserdem wenn lovelace ungestraft push & kick einbaut, warum soll ich dann nciht über 1 slot strategie REDEN. andere mods werden aus dem project verbannt für weit unwichtigere sachen als eine manuelle möglichkeit leute zu kicken.


Thema success:failed muß ich hier jetzt eindeutig zugeben, dass erst seit der Definition weiter oben von darkwolf klar ist, daß ein failed-Wert ein nicht zustande gekommener upload ist, der also 100%ig keinen einzigen Byte übertragen hat. Vorher gab es nicht wirklich eine Bestätigung für diese für mich bis dahin Vermutung. Tatsächlich bin ich auch bei meinen ganzen Berechnungen davon ausgegangen, dass failed Werte auch abgebrochene Uploads darstellen, bei denen Bytes verlorengehen. Die Ursachen der sich wiederholenden Chunks die immer wieder hin und herladen habe ich teilweise damit in Verbindung gebracht.

Insofern erschließt sich mir erst jetzt eine andere Sichtweise. Aus dem reinen Datenstrom heraus kann ich ja nicht einsehen, welcher Datenstrom wohin geht und ob der erfolgreich ist. Das FullChunUpload nur der Versuch ist der Chunk komplett hochzuladen, er aber nicht als nicht erfolgreich gilt, wenn er vorher abbricht, ist mir schon klar... wie gesagt kenne ich aber das problem von sogenannten fertiggestellt Bytes und übertragene Bytes

insofern betrachte ich die bezeichnung failed upload als falsch, da der upload ja dann nicht fehlschlägt, lediglich der Versuch eine Verbindung herzustellen schlägt fehl. Vermutlich gehen meine Überlegungen alle sämtlich auf diesen Formfehler zurück. Möglich auch, dass dies aus Übersetzungen aus dem Deutschen ins Englische oder umgekehrt zustande gekommen ist, wobei der Schreiber quasi eine andere Überlegung dabei hatte.

Genauso wie failed upload, sollte man also auch SUCCESS neu definieren.
zusätzlich zum failed upload braucht es meines Erachtens nach einen Wert der ausgibt bei wievielen Clients ein Upload sich wiederholt... also tatsächlich fehlschlägt, schade, dass dies dann offensichtlich nicht in den eigentlichen Wert eingeht. success sollte dann aber auch erst gegeben werden, [b] wenn der chunk fertig gesendet wurde[B] und nicht schon beim reinen zustandekommen der verbindung. Ob der Wert +1 vorher oder nachher addiert wird, sollte für die Performance keine Rolle spielen, könnte aber in der Definition und Verständlichkeit Unpäßlichkeiten beim Verständnis ausräumen.




bezüglich der 2 Klassengesellschaft möchte ich dir widersprechen. ziel ist keine 2 klassengesellschaft sondern eigentlich nur besser funktionierender upload. und meine ideen bleiben vorschläge keine verpflichtungen. ich vermisse bei dir manchmal eine aufgeschlossenheit gegenüber offenen diskussionen. ungelegte eier bleiben ungelegte eier. und solange ich ncith selber daran rumbastele bleibt es auch so. und jede diskussion mit verschiedenen standpunkten verhärtet sich an manchen punkten. hier aber über ein immernoch ungelegtes ei. die grundlage ist also ideologischer streit, nicht sachbezogen. die intensität könnte von daher etwas rausgenommen werden... und wir sollten mehr auf möglichkeiten und varianten und deren mögliche auswüchse eingehen.

meine idee von der schnelleren verteilung durch 1 slot strategie sollte dir bekannt sein. ebenso bin ich der meinung dass wenn ich viele kleine verbindungen habe die oft abbrechen, dass ich einen verlust an bandbreite auf zeitraum gesehen habe...weil er einfach ungenutzt ist... sofern ich sichergestellt habe, dass ich EIN ziel habe, welches genügend bandbreite hat, habe ich weniger overhead und weniger unnötigen verkehr auf der leitung. in meiner idee hier in diesem thread ist übrigens sehr wohl eingerechnet, dass es massiv anschlüsse gibt, die einen kleinen upload und einen großen download haben. also schnell empfangen könnten von großen sendern, und an kleinere wie ISDN und Modem durchreichen könnten. Auch bin ich bei dieser Überlegung davon ausgegangen dass der anteil dieser nutzer 80% ist. Wenn der Anteil dieser Mittelsmänner unter 50% läge, da gebe ich dir recht, könnte es nicht funktionieren... schnelle geben nur an schnelle und langsame nur an langsame. Dass die Idee hinkt ist auch mir offensichtlich...aber mehr als solche Überlegungen einbringen, um eventuell mehr success ,also dann hier anders als bisher formuliert: mehr rechtmässig erkämpfte slotplätze durch wartelistepunkte und credits, sowie kürzere Zeiten zum Zustandekommen eines P2P Vorganges vorhanden sind, um damit eine höhere Auslastung der Leitung durch weniger Overhead, weniger freigehaltene Leitungsreserven zu erreichen und zusätzlich den rechtmässigen Queuerankings gerecht zu werden, die durch einen fail in einem Unverhältnis stehen werden

das ist jetzt eine neuformulierung des sachverhaltes, falls ich falsch damit liege, dass nach einem failed:upload derjenige der den fail bekommt neu die warteliste durchstreifen muss, möge man mich bitte auch hier aufklären. ich denke aber nicht, dass es sinnvoll wäre an dieser praxis etwas zu ändern, da sonst einfach ein byte mit einem failure verursacht werden müsste um einen download schneller zu erreichen...bzw. so eine unsachgemäße fortsetzung eines scheinbar abgebrochenen downloads zu erstreiten. ich hoffe also dass dies auch gar nicht so ist.


nebenbei habe ich durch abschalten der spread connection funktion die success:failed gerade auf ein verhältnis 2:1 verbessert

bei den downloads liegt mein verhältnis kaum mehr unter 15:1