Xtreme Entwicklung - early alpha test thread

[Xman]

HL/MV .. meinst Du damit Hardlimit und Maximale Verbindungen ? Bei einem Hardlimit von 5000 * x Dateien, erreichst Du ja Mondwerte!

[drfreak2004]

es rennt nur so wie blöd.... 5600 quellen hab ich im moment... komm ich unter 4800 schläft er ein.... läuft so total geil... aber versteh du ich es net

[daenemark]

Ich komme auch auf über 5000 Quellen bei einem HL von 210 und MaxVerb. von 400 bei 26 Files
im DL.Aber 5000 HL und 8000 MV ist ja der Wahnsinn.Bei wie vielen Dateien denn ?

[Hanussen]

Fehler?!:

unter "Gefundene Quellen"
eD2K: 5801 (116.4%) <-- Aut was beziehen sich diese 116%?

Ist vielleicht unerheblich, ist mir aber eben gerade zufällig aufgefallen...

EDIT: Ach ja, "Gefundene Quellen: 5015" bei 35 Downloads mit einem Hardlimit von 250. Mal sehen wie sich das noch entwickelt, er läuft erst seit ca. 2 Stunden.

Gute Nacht

[Xman]

eD2k-Prozentzahl wird errechnet aus eD2k (also clients mit angegebenem Server) * 100 / gesante Quellen.
Interessanter Bug.. vor allem weil er mal wieder einen Codepart betrifft an dem ich nichts geändert hab. Und mal wieder die Frage: ist das beim offiziellen emule auch so ?

Edit: hab mir den Berechnungscode gerade genau zu Gemüte geführt.. er ist absolut makeslos. Hast Du vielleicht ein File pausiert/gestoppt oder wurde gestoppt wegen zu wenig Plattenspeicher ?

Edit2: ich glaube es liegt am "Stop File". Hab auf die schnelle nämlich nichts gefunden, daß die Zähler in diesem Fall auf 0 gesetzt werden... ist dann aber ein Bug im offiziellen Code.

[drfreak2004]

momentan 11 downloads.... dateien für ul 113..... ich teste gerade mal 800/800....

versteh tue ich es trotzdem net... dieses komische verhalten habe ich nur bei alle 0.4x versionen... xtreme 2.2 (0.30x) hab ich normale werte beim lauf....

i don't knopf i muss los zum kunden.....

mfg

[mav744]

@Xman
Es ist auch im offiziellen so, in der stats. Ich habe ziemlich viele Files angehalten, könnte also daran liegen. Ich würde es ja jetzt gerner reproduzieren, ob es an den gestoppten Files liegt, aber das kann ich erst heute nachmittag, muss jetzt zur Fortbildung (Computerkurs für Anfänger, echt wahr ).

Mit freundlichen und sich schon jetzt langweilenden Grüssen
mav744

[Xman]

Neue Testversion x3alpha3.1
-------------------------------

new:
- see On Uploadqueue: wie im Xtreme 2.2 seht ihr in der shared-filelist wieviele clients sich für ein File anstellen
- allow queueoverflow with minimumcontingent: wie im Xtreme 2.2, jedoch nicht mehr deaktivierbar, weil es hierzu keinen Grund gibt
- einie Code-Verbesserungen und Bugfixes
- Upload/Download Stop-Reason

to test:
alles was in der 3.0 auch schon angegeben war
plus: Ausschauhalten nach Verbose-Meldungen die mit "-->" beginnen... falls ihr solche seht, melden mitsamt den Meldungen welche binnen der nächsten Minute nach einer solchen Meldung auftauchten
plus: überprüfe die Werte der Splate "OnQueue" mit den Clients die Du in der Warteliste zählst... vor allem nach mehreren Stunden Laufzeit

hints: hab gerade noch einen kleinen "Kopierfehler" entdeckt... Statistik->Fehlgeschlagene Uploadsessions->Other, Wert wird falsch berechnet... nicht daran stören lassen.

Anmerkung:
Die Spalte "OnQueue" in den Shared-Files, ist leider die letzte, das kann ich aus Kompatibilitätsgründen auch nicht ändern.. ich schieb sie immer ganz nach vorne. Die Werte sollten so ziemlich der Anzahl Clients entsprechen, die man auch in der Warteliste zählen kann. Mit ziemlich mein ich: es kann passieren, daß ein Client sich nicht "richtig" anstellt, sondern mitten im Protokoll abbricht. "OnQueue" zählt diese nicht, sie werden aber in der Warteliste angezeigt. Solche Clients fliegen aber bald raus und somit sollte es keine größeren Abweichungen geben. Falls das Feature gut funktioniert, werd ich einen "fetten" Codeteil des offiziellen emules entfernen, und durch die Routinen von "See on Uploadqueue" ersetzen, da diese wesentlich effizienter arbeiten.


Download: binaries & sources


changelog
alpha3.1
- see on uploadqueue
- allow queue overflow with minimumcontingent (always activated, because there is no reason to deactivate)
- some code-improvemets to uploadqueue
- fixed: downloaded data of peercache, and url- downloads were not counted (thx phoenix-mod)
- few messages to find out a protocoll-error
- official bugfix, which shows wrong source-count in statistics
- bugfix in dynamic IPFilters
- other small code improvements
- Upload/Download Stop-Reason

[daenemark]

So die 3.1 läuft jetzt seit ca 2 1/2 Stunden.Werte der Spalte " OnQueue" stimmen mit der Warteliste überein bei "OnQueue" sind ca.50 weniger.Bisher sehr ohne Probleme.
allow queue overflow with minimumcontingent ->habe jetzt 3800 in der Warteschlange bei eingestellten 3200.

[Xman]

Zitat von daenemark

So die 3.1 läuft jetzt seit ca 2 1/2 Stunden.Werte der Spalte " OnQueue" stimmen mit der Warteliste überein bei "OnQueue" sind ca.50 weniger.Bisher sehr ohne Probleme.

entschuldigung.. aber verstehe Dich nicht so ganz... stimmen die Werte nun überein oder sind es 50 weniger ?

allow queue overflow with minimumcontingent ->habe jetzt 3800 in der Warteschlange bei eingestellten 3200.

Das muß nun aber nicht vom "allow queueoverflow with minimumcontingent" kommen.. sondern kann auch vom offiziellen Code kommen, welcher ja nun ein hard und ein softlimit kennt. Ist die Warteschleife bos zum Softlimit gefüllt, dürfen immer noch clients rein, welche viele Credits haben... bis die Warteschleife 25% über der eingestellten größe ist.

[daenemark]

Zitat von Xman

Anmerkung:
Die Werte sollten so ziemlich der Anzahl Clients entsprechen, die man auch in der Warteliste zählen kann.

Dachte die Werte entsprechen so ziemlich der Anzahl der Clients in der Warteliste bei
50 weniger.
Bei den vorherigen Versionen hatte ich Max 3500 Clienten in de Warteliste bei eingestellten
3200.
Das hat sich aber jetzt nach knapp 5 Stunden Laufzeit wieder auf max 3500 geregelt.

[Xman]

irgendwie reden wir glaub ich aneinander vorbei... weil ich weiß nicht was Du mit Deinen "50 weniger meinst".
Ich erklär einfach nochmal was ich meine:
"OnQueue" in der sharedfile-liste, zählt wieviele clients pro file in der Warteschlange sind. Die zahl kann man nur überprüfen, indem man sich die Warteschlange ansieht, nach Datei sortiert und manuell nachzählt. Klar, wenn man 500 Leute fürs gleiche File hat ist das mühseelig... doch wenns nur um die 10 sind kann mans ja mal nachkontrollieren.

[daenemark]

Ach so für jedes file.Ich habe die zahlen die unter OnQueue stehen zusammen gezählt und dann mit
der Zahl der warteschleife verglichen.
Ja gut dann muß ich das noch mal machen.

So habe das jetzt mal bei 8Files gemacht und ja OnQueue und Warteschleife zahlen
stimmen überein.

[Xman]

achso... nun weiß ich wie Du gemacht hast.. also alle zusammengezählt und mit der Gesamtzahl der Warteschleife verglichen... hmmm.. der Wert sollte eigentlich auch übereinstimmen. Waren hier die 50 Unterschied ? Und falls ja... wo waren 50 weniger?

Edit:
mal ein paar Informationen:
es kann vorkommen, daß die Anzahl der wartenden Clients zu einem File bei "OnQueue" in sharedfile-list geringer ist als die Anzahl der Clients in der Warteschlange zu diesem File .
Das hat nun folgenden Hintergrund:
Um sich bei einem Client in die Warteschlange einzureihen benötigt es 3 Protokollvorgänge:
1: Frage nach dem Filenamen
2: Frage nach dem Filestatus (welche parts hat er denn?)
3: Sage bescheid, daß Du Dich anstellen willst (antwort ist dann die QR)

"See On Uploadqueue" zählt nur dann, wenn das dritte Packet eintrifft... was ja auch richtig ist. Nun kann aber folgendes passieren:
Client ist bereits in Warteschleife, will nun aber ein anderes File (swapped).. er schickt dazu erst mal Packet 1 (+ evtl Packet 2). Nach erhalt des Packetes wird bereits in der Warteschleife der Filename geändert (was ich nicht für sinnvoll halte, aber so arbeitet der offizielle emule). Geht der client nun offline oder merkt, daß er sich für das neue File nun gar nicht anstellen will (z.b. ich bin eine NoNeededSource), so wird er in der Warteschleife bereits mit neuem File geführt, in der sharedfilelist aber noch mit altem. Bekommt ein solcher client nun einen Uploadslot ist die Wahrscheinlichkeit hoch, daß der Upload fehlschlägt (darum der Fix im Xtreme 2.2).
Es hat sich nur einiges im Protokoll geändert... und darum bin ich eben gerade am Analysieren.. und brauch dazu eure Hilfe.

[Paul 2]

x3alpha3.1 Laufzeit 9 Std
hatte 2 mal diese Meldung, beidemal die gleiche IP

14.03.2005 11:30:26: -->Adding client, but last packet was: 146, 81.47.16*.*** 'http://emule-project.net' (eMule v0.45a,OnQueue/Connecting)


14.03.2005 14:13:19: -->Adding client, but last packet was: 146, 81.47.16*.*** 'http://emule-project.net' (eMule v0.45a,NoNeededParts/Connecting)