Hallo,
bevor ich beginne, möchte ich die beiden naheliegendsten fragen, die einem beim lesen des topititels einfallen, vorweg beantworten:

1. Ja, ich meine das ernst!
2. Nein, ich bin nicht auf drogen und heute auch nicht zu lange in der sonne gewesen!

Nun zur sache:
Ich hatte gestern eine ausführliche diskussion unter freunden über SUQWT (wen dieses thema interessiert, kann ja mal in diesen thread reinschauen - hier spielt das keine rolle mehr).
Es wurde deutlich, dass sich diejenigen, die emule nur temporär nutzen, sehr benachteiligt fühlen. Obwohl ich als "dauernutzer" natürlich anfänglich dagegengehalten habe, mußte ich am ende doch zugestehen, dass das wartelistensystem mit seinen relativ langen startphasen die beiden gruppen (dauernutzer<->temporärnutzer) doch sehr ungleich behandelt.
Nun, so ist nun mal ein wartelistensystem - aber es geht auch anders:

Wie wäre es, wenn emule einen freiwerdenden uploadslot unter den wartenden verlosen würde?

Das hört sich jetzt abwegig an. ich weiss...

Was ist mit wartezeit?
Was ist mit credits?
Was ist mit Upload-prios?

Wartezeit:
Das ist einfach - je länger du da bist, an desto mehr verlosungen nimmst du teil .
[EDIT] Für die bewertung hat wartezeit ansonsten keine weiter bedeutung [/EDIT]

Credits:
Die faktoren können wie bisher verwendet werden. Sie dienen zur steigerung der chancen.
Um beim "verlosungs-bild" zu bleiben: Jemand ohne credits hat einen ball in der trommel - einer mit credits bis zu 10.

Upload-prios:
Werden ebenfalls wie credits entsprechend auf die chancenvergabe angerechnet.



Verlosung:

Zunächst einmal ist das ganze nicht sooo zufällig, wie es auf den ersten blick aussieht.
Wie bei jeder statistik und jeder umfrage ist es die masse, die entscheidet ob das ergebnis willkürlich oder doch repräsentativ ist.

Gehen wir einmal davon aus, dass

- jede quelle im schnitt mit 12kB/s hochlädt -> 4 slotts a' 3kB/s
- immer 5.400kB *)hochgeladen werden (ist trotz full-chunks-ul ca. der schnitt in meinen stats)
- somit pro slot und stunde 2 personen bedient werden ( 5.400kB:3kB/s = 1.800s = 30min )
- jeder user im schnitt bei 1000 quellen ansteht

ergibt das: 4 * 2 * 1000 = 8.000 verlosungen pro stunde.
Sind wir da nicht in der größenordnung einer "repräsentativen" umfrage? - ich denke schon!
Das ist der eigentliche knackpunkt an der geschichte.
Vielleicht kann ja jemand, der sich in wahrscheinlichkeitsrechnung gut auskennt ein paar worte dazu sagen.

---------------------------------------

Fakt ist auf jeden fall:

-das system ist "gerecht", da alle die gleichen chancen haben
-die dl's starten unmittelbar ohne lange anlaufzeiten und sind konstant bis zum schluss (heisst nicht gleichmäßiger speed!).
-SUQWT wird unnötig.
-Temporär-nutzer haben keine nachteile gegenüber dauernutzern. Sie sind nur stärker vom zufall abhängig.

Noch immer so abwegig?

warum einfach wenns auch kompliziert geht oder wo is da der sinn?

lass sie doch tictactoe spielen, der gewinner kriegt alles

Das ist sicherlich im Ausgangszustand ein sinnvoller Weg Uploadslots zu verteilen, man muss nur dem Zufall vertraunen (würde der Statistiker sagen). Man kann dabei sogar Credits mit einbeziehen (ist dann als ob man bei einer Lotterie mehr Lose gekauft hat). Hast du aber Glück gehabt und bist "früh" drann gekommen kanst du auch früher wieder in die Warteschleife, hast also dann gleich wieder die Chance aufs große Los, das ist dann unter Umständen schon nicht mehr so fair, man müsste mal einen Simulator dafür schreiben. Wenn z.B. 25% der Slots per Zufall vergeben würden wäre ich voll dafür.

Ich sehe den Sinn des ganzen nicht so ganz, weil SUQWT den angepeilten Zweck besser erfüllt. Die Dauernutzer/Temporärnutzer-Probleme wird das nicht lösen, weil du immer noch von der Wartezeit ausgehst. Statistisch gesehen haben immer noch diejenigen mit hoher Wartezeit (also Dauernutzer) hohe Chancen, während bei SUQWT jeder gleichberechtigt ist, denn jeder ist pseudo-Dauernutzer.

Ein weiteres Gegenargument ist, dass eine faire und effiziente Implementation des Zufallsalgorithmus nicht ganz einfach ist... (bzw. sehr viel CPU-Leistung verlangt).

@ Limette

Ich hatte nicht vor wartezeit in irgendeiner form einfliessen zu lassen.
Wer länger ansteht, nimmt an mehr verlosungen teil -sonst nichts.

Und alles dem zufall überlassen will ich ja auch gar nicht.

wie soll eine verlosung ablaufen heißt das, man meldet sich bei dem client von dem man was haben will dieser speichert einen dann und sagen wir mal alle 3-5stunden findet eine verlosung stat ????

der rest ist für mich soweit ganz einleuchtend.
ich steh dem ganzen auch recht positiv gegenüber weil er neuen leuten eine bessere chance gibt.

wenn man es geschickt implementiert könnte man auch verwaltungsaufwand der quellen abfrage reduzieren da man sich einmal anmeldet und nur noch über einen ip wechsel die quelle informiert. bzw. neu vorbei schaut wenn die quelle ne neue ip hat. das könnte man aber etwas umgehen in dem die quelle die in der trommel befindlichen anfragen informiert. und durch die overhead einsparung lässt sich wieder ein höherer upload realisieren und es können die clients schneller bedient werden.

sorry wuestenbrot, hab mir jetzt nicht alles durchgelesen, da dein Eingangspost schon einer Fehleinschätzung unterliegt.

o.K., du verstehst es nicht oder ich. In deinem Eingangspost steht doch, das du bei der "Verlosung" oder "Ziehung" der uploadslots keine Gleichverteilung der clients in der Warteliste hast, sondern gewichtet nach dem bisherigen Bewertungssystem. Und sei versichert, da kommt über einen representativen Zeitraum nichts anderes raus wie bisher.

@ seppl12

Gewichtung selbstverständlich ohne anrechnung von wartezeiten (also nur credits und prios) - ich denke, da liegt das Mißverständnis.

Nein, CS ist aktiviert. Und verwechselt habe ich auch nichts.

Wartezeit ist nun mal einfach der dominierende Faktor (es sei denn du hast eine andere Definition davon, was dominierend bedeutet).

Wartelistenpunkte = Sekunden_gewartet * Credits * Dateipriorität

Wenn man das so sieht, könnte man meinen alle drei Faktoren wären gleichgestellt, aber da Credits und Dateipriorität nur einen sehr kleinen Einfluss (maximal eine verzehnfachung der anderen Werte bei den Credits z.B.) haben, die Wartezeit aber bis zu mehreren Tagen betragen kann, hat diese den größten Einfluss auf das Ergebnis.

@ seppl12

Du hast recht, die gewichtung des creditsystems sowie der ul-prios habe ich nicht angetastet. Rein von der wahrscheinlichkeit ändert sich also nichts.
Das war aber auch gar nicht das ziel!

Lies es dir vielleicht nochmal in ruhe durch.

der vorteil liegt einfach darin, dass, egal wann du dazustößt, deine chancen immer gleich sind - ab der ersten minute.
Du kannst emule mal kurz für ein paar stunden ausmachen um deine fp zu defragmentieren. Sobald du wieder einschältst, bist du voll dabei -auch ohne SUQWT.


@ Wo bleiben den die wahrscheinlichkeits-mathematiker?
Mich würde interessieren, wie groß bei dem angegebenen beispiel die chancen stehen, dass ein wert vom durchschnittswert abweicht.
Wie groß ist z.b. die wahrscheinlichkeit, dass man nur 80%, 50%, 10% oder aber 125%, 200% oder 1000% des errechneten durchschnittsdownloads innerhalb von
5h, 10h, 100h erhält?
Wie wird das gerechnet - gibts da eine einfache formel, die für die verschiedenen fälle angewendet werden kann?

Zunächst mal als Anmerkung was hier vielleicht für etwas Verwirrung sorgt ist dass mein Modell die Wartezeit mit einbeziehen soll und das Modell von wuestenbrot nicht.

@ seppl12

@ seppl12

Deine aussagen sind alle richtig

Doch leider bist du so von dem gedanken das bewertungssystem des CS verbessern oder ändern zu wollen besessen, dass du alles nur unter diesem gesichtspunkt siehst.
Dabei hat dieser thread damit überhaupt nichts zu tun (worauf ich jetzt schon mehrfach hingewiesen habe!).


Beispiel:
Ich habe geschrieben:

wuestenbrot, auch wenn du es nicht erkennen kannst oder willst, wer hier das Bewertungssystem ändern will, bis ja wohl du!

Um es in dem anschaulichen Kugelmodel zu sagen, wenn ihr nicht exakt die Anzahl der Kugeln gleicher Farbe nach dem bisherigen Wartepunktemodell verteilt, ändert ihr das Bewertungssystem. Und alle eure bisherigen Ausführungen deuten genau darauf hin - Punkt

Also um das mal zusammen zu fassen:

Bisher ist das Wartelistensystem wie folgt aufgebaut:

@ seppl12

Ich weiß genau, was ich schreibe und meine argumentation ist, denke ich, auch schlüssig.
Was nicht heissen muß, dass jeder zuzustimmen hat.

Das system unterscheidet sich im grundsatz völlig von der gängigen praxis.
Der eintrittszeitpunkt in eine warteschlange, der ja bislang entscheident war, wird unrelevant.

Vielleicht sollten wir mal den begriff "bewertungssystem" klären.

Wenn du unter "bewertungssystem" das bisherige ermittlungsverfahren zur auswahl des nächsten downloadkandidaten verstehst, dann ändere ich es selbstverständlich.
Ich öffne ja wohl nicht einen thread um zu schreiben, dass alles so bleiben soll, wie bisher!

Ich habe aber bislang den begriff "bewertungssystem" nicht verwendet. Ich spreche von "bewertung" und benutze den begriff so, wie er normalerweise auch in den docs verwendet wird:

wuestenbrot, wenn ich vom "bisherigen Bewertungssystem" (=Berechnug der Wartelistepunkte) und "Wartelistepunkte" schreib, dann sollte zumindest für dich klar sein, was gemeint ist. Und das Creditsystem ist ein wesentlicher Bestandteil der Bewertung. Hierzu aus deinem ersten Post:

@ seppl12

Erstmal: Es war nicht ich, der eine kurve kriegen musste.
Ich argumentiere geradlinig - es gibt keinen einzigen satz, den ich zurücknehmen oder korrigieren brauche.

Majesty hat keine "Schwachstelle" aufgedeckt sondern die logische konsequenz jedes losverfahrens in seine eigenen worte gafaßt.
Natürlich war und ist mit das völlig bewußt - und wohl auch jedem anderen, der sich ernsthaft mit dem system auseinandersetzt.

Du sagst, es reichen 1.000.000 ziehungen nicht aus; warum nicht 10mio, 100mio, 1 mrd? Wenn du das nicht weiter belegst, sind das stammtischparolen, die nicht weiterhelfen.

Es geht gerade darum, die wahrscheinlichkeiten abzuwägen und vor allem zu versuchen die zu erwartenden abweichungen vom durchschnittswert greifbar zu machen.

Dazu habe ich den thread eröffnet.


PS.: Filesharing ist filesharing solange files gesharet werden (und das habe ich weiterhin vor!).

wuestenbrot, es ging doch zunächst mal festzustellen, wieviele Ziehungen braucht man, um "representativ" zu sein. Die Binomialverteilung beschreibt ganz allgemein das Auftreten eines qualitativen Merkmals in einer Stichprobe vom Umfang n mit Zurücklegen. Qulitatives Merkmal bei uns hier ist, das ein bestimmter client genau einmal zu einem uploadslot kommt (daher k=1). Da die Wahrscheinlichkeit 1 prinzipiell nie erreicht werden kann, sollten wir uns fragen, bei welchen n (wieviele Ziehungen) die Wahrscheinlichkeit z.B. 80% oder 90% ist. (Mit Gauß- oder Lorentzverteilungen fangen wir hier im diskreten Raum nichts an).

Werde mir mal den Rest überlegen.

/edit
sehe gerade, das die Beantwortung deiner Fragen unmittelbar mit meiner Antwort zusammenhängt!

/edit2
brauchst dazu nur den k Wert veränder. sagen wie mal, bei einem slot kommen 5Mb. Wenn du nun mit 50MB rechnen willst, entsprechen das 10 slots (k=10). Hast du das n, sagen wir mal für 80% Wahrscheinlichkeit berechnet, dann kanns aus deinem Eingangspost die zugehörige Zeit bestimmen.

Vielleicht noch 2 punkte zum thema "lottospielen":

1. Für wen bringt es vor- und für wen nachteile?
Wie jeder weiss, hat emule eine "anlaufphase".
Während der ul sofort startet brauchts bei den dl's immer eine gewisse zeit. Nach einem normalen reconnect ist das vernachlässigbar, da man ja seine bisherigen QR's behält. Bei neustarts aber kann das ganz schön lange dauern - oft mehrere stunden, weil man sich ja bei den meisten ganz hinten anstellt.
Gelegenheitsnutzer und alle leute, die emule nur zu bestimmten zeiten des tages nutzen können oder wollen, haben daher im momentanen system die arschkarte.
Sie uppen zwar von anfang an, müssen aber den computer meistens wieder ausschalten, bevor sie überhaupt in die nähe eines uploadplatzes gekommen sind.
Man könnte auch sagen, sie werden von dauernutzern geleetcht!
[verteidigungsmodus: ON ]

Sie wären daher auch die klaren gewinner, da ihre chancen bei einem zufallssystem von anfang an gleich wären (was unter gleich zu verstehen ist, sollte mittlerweile klar sein).

Wo es gewinner gibt, gibt es auch verlierer.
Dauernutzer müssten wohl mit einbusen rechnen - nicht weil sie vom zufallssystem direkt benachteiligt werden, sondern weil die bisherige benachteiligung für temporärnutzer entfiele und deren "mehr" an dl aus ihrem pott abgezweigt würde (von nix kommt nix). Moralisch ist es aber wohl kaum vertretbar auf ungerechten privilegien zu beharren!!
[verteidigungsmodus: STILL AKTIVATED ]


2. Wen treffen die bei einem zufallssystem zwangsläufig auftretenden "ungerechtigkeiten" (=extrem abweichungen vom durchschnittswert)

Auch ohne oder (wie ich) mit wenig wissen über wahrscheinlichkeitsrechnung ist jedem klar, dass zufallsbedingte ungerechtigkeiten mit zunahme der "ziehungen" abnehmen.
Beispiel: Man hat einen swimmingpool gefüllt mit 1.000.000.000 perlen.
1.000.000 perlen (1/1000 = 0,1%) davon sind schwarz.
Jemand, der die verteilung nicht weiß, nimmt eine probe mit einem kaffelöffel (10 perlen). Vermutlich wird keine einzige schwarze dabei sein - unter umständen aber doch (und wenns ganz dumm läuft vielleicht soger mehr wie eine). Er wird auf jeden fall kaum rückschlüsse auf die tatsächliche verteilung schließen können.
Seine ziehung ist nicht repräsentativ genug!
Anders sieht es aus, wenn er statt dem kaffeelöffel einen eimer oder gar eine baggerschaufel nimmt....

Je mehr ziehungen desto näher kommen wir also dem "gerechten" durchschnittswert.
Die anzahl der ziehungen wird ausser der quellenzahl hauptsächlich durch die laufzeit bestimmt. Je länger emuleläuft, desto geringer sind die abweichungen vom errechneten "gerechten" mittelwert.


Fazit:

Wir haben die gruppe der dauernutzer,
für die die abweichungen zum "gerechten" mittelwert eher gering wären.

Wir haben die gruppe der gelegenheitsnutzer,
die mit hohen abweichungen (nach oben und unten) rechnen müssen, dafür aber nicht mehr benachteiligt werden.



PS.:
Hab eigentlich mit mehr widerspruch gerechnet - wenn sich jetzt nicht ein paar leute mehr melden, liegt es entweder daran, dass sie
- die füsse in der kalten badewanne haben, aber dort kein internetanschluß ist
- der sangria-kübel ihnen die sicht auf den bildschirm verdeckt

(sch*** Sommerloch)

Da ich den Rechner nur ca. 10 Stunden am Stück laufen habe (das Drecksstück schmiert gern mal ab,aber nicht nur bei eMule), finde ich deinen Vorschlag sehr gut.
Aber ob es zu realisieren ist, wage ich nicht zu hoffen (wie schwülstig)!

nun warum nich beide systeme nutzen und zb. 4 upslots 50/50 auf die beiden systeme verteilen?

so hätte man dann 2 credit slots und 2 lotterie slots

Entschuldigt wenn ich mich hier einmische.
@seppl12 @wuestenbrot

Ich habe diesen Thread verfolgt und muss seppl12 zustimmen. Wenn Du(wuestenbrot) die Faktoren beibehalten willst(Upload,Prioritaet,Wartezeit) wird auch beim Zufallsauslosungsverfahren keine signifikante Änderung der vergebenen Slots erfolgen.
(daher die wahrscheinlichkeit an eben diesen slot zukommen steigt (perlen) wenn ich eben einen dieser Faktoren multipliziere).

Nun meine eigentliche Frage was willst Du erreichen?(@wuestenbrot)

Willst Du:
A. Neueinsteiger sollen schneller "Download Erfolge" haben.
B. .....
C. .....

Ich sehe keinen Zweck, weswegen ihr euch die Köpfe heiss macht.

Allerdings hätte ich eine Idee. (Die habe ich schon mal vor ca 1 1/2 Jahren hier beschrieben als das Crediet System aufkamm)

Gut genug der Einmischung

Gruss WG

OT:
Kann mir jemand erklären was dieses:
Warn: (0%)
links bei meinen Nick bedeutet.
Gruss WG

Wozu eine Sperrfrist oder eine Chancenreduzierung? Ich denke das ist quatsch. Bei dem aktuellen System wird man ja auch nicht nach erfolgreichem Download aus der Queue "verbannt". Sowieso wird die Chance ja reduziert weil die Bewertung nach dem Download schlechter ist. [Edit] Das setzt natürlich vorraus, dass man bereits Credits hatte. [/Edit]

Ich denke es reicht, die Chance während des Downloadvorgangs einfach auf 0 zu reduzieren und nach dem Downloadvorgang fragt der Client ja wieder nach und darf sich wieder ganz normal "anstellen".

Im großen und ganzen finde ich die Idee übrigens genial (auch wenn ich davon nicht profitieren würde, aber man könnte eMule ganz anders nutzen).

wuestenbrot, ich denk, das zunächst mal die einfachsten Modelle die besten sind, auch in Hinblick auf eine Simulation. Verfeinern oder modifizieren lassen sie sich dann immer noch. Und die gezogene Kugel aus dem Sack zu nehmen, halt ich nichts von, auch in Hinblick auf eine evtl. Umsetzung (glaubst du da erlich dran, das irgendein eMule Entwicker dies hier durchliest?) /edit Hat jemand einen uploadslot, so nimmt er natürlich bei den Ziehungen dieses clients nicht teil, wie bisher auch. /

Bei einigen Beiträgen ist mir aufgefallen, das ihr die Einzelwahscheinlichkeit (p) einfach mit der Anzahl von Ziehungen (n) multipliziert habt. Das stimmt so nicht. Genau dafür müßt ihr die Binomialverteilung benutzen (wer auf seinem PC Probleme hat, für die großen n die Fakultäten zu berechnen, kann in sehr guter Näherung die Poissonverteilung nehmen).

So, fangen wir mal an ein einfaches Modell zu entwickel.
Ich geh zunächst mal davon aus, das in den Warteschlangen 3000 gleichberechtigte clients sind (Credit und Prio sind spätere Modifikationen des Modells) und wie wuestenbrot schon sagte, heist das, das jeder client im Schnitt auch 3000 Quellen hat. Unser Modell startet in diesem Zustand.

Die Wahrscheinlichkeit p bei einer Ziehung (oder sollen wir in Zukunft Verlosung sagen?) auch gezogen zu werden ist p=1/3000

Führt man n Ziehungen unter dem Aspekt (Merkmal) durch, das genau ein (k=1) uploadslot (nicht Null, zwei oder mehr) erreicht wird, so berechnet sich Wahrscheinlichkeit nach der Binomialverteilung.

(Kleine Erläuterung dazu: Wie wuestenbrot schon richtig sagte, sieht die Binomialverteilung wie eine Gaußsche Glockenkurve aus, hat also ein Maximum. Das Maximum für einen bestimmten k Wert befindet sich immer bei k mal die Anzahl der Möglichkeiten (in unserem Fall für k=1 bei 3000). Warum ist das so? Mach ich weniger Ziehungen, wie es Möglichkeiten gibt, sinkt die Wahrscheinlichkeit für einen uploadslot. Mach ich mehr Ziehungen, sinkt ebenfalls die Wahrscheinlichkeit, genau einen uploadslot zu bekommen, da die Wahrscheinlichkeit für zwei uoloadslots zunimmt. Daher konzentrieren wir uns immer auf das Maximum!)

Die maximale Wahrscheinlichkeit, genau einen uploadslot zu bekommen, liegt also bei 3000 Ziehungen und beträgt 37%. Jetzt bitte nicht aufstöhnen, der Wert ist sehr gut! 37 % Wahrscheinlichkeit, bei den ersten 3000 Ziehung dabei zu sein, super (und die Wahrscheinlichkeiten für zwei und mehr uploadslots sind hier noch gar nicht drinn)

o.K., hab euer aufstönen vernommen, also machen wir weiter. Ihr wollt also 90%.
Schrittweises Rantasten:
Wir machen jetzt 6000 Ziehungen: P(k=1)=27% , P(k=2)=27% , P(k=3)= 18% , P(k=4)=9% , P(k=5)=4% , P(k=6)=1% , Rest unter 1%
Jetzt haben wir schon 86% Wahrscheinlichkeit für das erreichen eines uploadslot

Bei 9000 Ziehungen: P(k=1) = 15% , P(k=2) = 22% , P(k=3) = 22% , P(k=4)=17% , P(k=5)=10% , P(k=6)=5% , P(k=7)= 2% , Rest unter 1%
Also nach 9000 Ziehungen haben wir eine Wahrscheinlichkeit von 93%, einen uploadslot zu bekommen.

So, das waren meine ersten Überlegungen. Falls das überhaupt jemand liest und Interesse besteht, könnte ich eine Simulation schreiben. Ihr müßt halt sagen, was zunächst mal die Simmulation beinhalten sollte.

@ seppl12
Danke erst mal für die mühe.
Hab jatzt mal verucht das nachzuvollziehen und bin nach einigen recherchen im internet auch fündig geworden.
(ewig an dieser formel mit diesem "drecks-binominalkoeffizient" rumgemacht - und warum, zum donner, kann mein tabellenkalkulation keine fakultäten ausrechnen )
Ich bekomme jetzt die gleichen werte raus wie du - hab aber keine ahnung obs auch stimmt .

Ich befürchte allerdings, dass nicht jeder mit den werten wirklich etwas anfangen kann - ich glaube auch, dass zuviel mathematik nur abschreckt.
Ohne gehts natürlich nicht, aber

ich versuch das mal so einfach und nachvollziehbar, wie möglich in "emulisch" zu übersetzen.

Zuerst nochmal zur zeitlichen abfolge von losungen.
Ich bin ja anfangs von folgendem model ausgegangen:

Moin
Gegenfrage: