Thema: SkyNet Mod R32

[R32]

Keine Ahnung, kann ich nicht sagen. Ich benutze keine rules.

Der Code in diesem Bereich sieht recht teuer aus, was die Laufzeit angeht.
Wenn diese Programmteile schlimmstenfalls bis zu 2500 mal pro Sekunde (50 rules mit ca. 50 neuen http Files pro Sekunde) durchlaufen werden müssen, kann ich mir schon vorstellen, dass da nicht mehr viel geht. Zumindest müsste die Stromrechnung steigen. 
Wie sieht denn die CPU Last bei 50 rules aus?

R32   

[NewMan]

Nun nochmal eine Frage zu den Macadressen.

Gibt es eine Möglichkeit die Macadressen so in die Rules einzutragen, das nur die Files gezogen werden, die über diese Macadresse kommen? Mein Versuch ist hier gescheitert.

[bigobelix]

hi NewMan,

mit G im Menü alles deaktivieren und in der rules.txt folgendes eintragen:

m D05Cxxxxxx +            alles oder
m D05Cxxxxxx +[100k-]  alles größer 100k oder
m D05Cxxxxxx +[5M-]    alles größer 5MB

bigobelix

[bigobelix]

@R32

nichts gemerkt, Auslastung tümpelt noch immer bei 1-3% rum, geht mal kurz auf knapp 10%.

bigobelix

[NewMan]

mit G im Menü alles deaktivieren ...

Da kam ich einfach nicht drauf!

Vielen Dank!!!

[R32]

Mal wieder ein kleineres Update ...


Changes

1.21 - 2006/11/11
-----------------

neu:

- Linux Version aktualisiert

- Load/Save Files wieder integriert (Sitzungsübergreifendes Speichern)

- DreamBox Patch für alle PIDs (von Andrei V. Lavreniyuk)



Bugfix:

- HTTP Partial Content: Diverse Änderungen/Verbesserungen

- HTML: Namenserkennung aus <Title> Tag verbessert

[bigobelix]

Danke R32, wird getestet.

bigobelix

[woodie]

R32 hääte noch einen Wunsch: Könntest du vielleicht obenrechts noch eine Anzeige für die Empfangsqualität einbauen?

BIG THX

[pogo13]

Hi R32,

die neue Version ist mir heute Nacht irgendwann abgeschmiert. Habe nur mit nntp laufen lassen. Was mir bei deiner Version aufgefallen ist, daß im temp/nntp Verzeichnis die Dateien oft gleich von Anfang an in Größen von 400-800 MB liegen, obwohl der Strichlänge nach wenige MB gelaufen sind. Decodiert man diese kommt logischerweise nicht viel heraus.

@ woodie: die Empfangsqualität kannst du u.a. mit Server4PC beurteilen. Zur Antennenausrichtung kannst du auch FastSatFinder (hier im Forum zu finden) benutzen. Und auf schlechtes Wetter hat man so wie so keinen Einfluß (leider). Ich persönlich bin gegen Überfrachtung des Programmcodes mit Funktionen die eher sehr selten benötigt werden. Es frisst Resourcen und birgt das Risiko für weitere bugs.

Grüße
Pogo

[bigobelix]

Noch läufts bei mir, kann aber noch nicht viel sagen, weil sich die Bedingungen ja verändert haben. Muß erst wieder ein Gefühl dafür bekommen. Lasse zur Zeit SkynetX gegen R32 antreten.

bigobelix

[bigobelix]

@R32

bin sehr zufrieden, läuft seit ca. 48h fehlerfrei durch. SkynetX schafft es ca. 3 Wochen, habe aber jede Woche mal neu gestartet, weil die Ausbeute geringer wurde. Lasse Deine Version mal laufen, bis sie abschmiert.

bigobelix

[R32]

Danke Euch beiden fuer die Rueckmeldung! 

@bigobelix
Sehr schoen, das klingt besser, als ich gedacht habe.
Machst Du auch http oder nur nntp?

@pogo
Ja, die Stabilitaet hat wohl etwas gelitten durch die codeseitig recht grossen Erweiterungen/Umstellungen. Das wird jetzt wieder in den Mittelpunkt ruecken, da wohl die wenigsten staendig am Rechner sind, um das Programm wieder neu zu starten.
Die 1GB-Datei-Problematik bei nntp ist ein ziemlich grundlegender Fehler in den skynet 0.91er Abkoemmlingen. Ich hatte seinerzeit ja auch deswegen NNTPdefrag direkt in skynet integriert. Dann hat man wenigstens nur die gerade ladenden nntp streams auf Platte. Nach dem Defraggen sind es nur noch die kleinen UUDs. Der zweite Vorteil der Integration ist ja der Wegfall der nntp Nachbearbeitung. Wenn ich jetzt den Fehler in skynet finde und die Dateien dadurch kleiner werden, bleibt die Nachbearbeitung also immer noch uebrig. Von daher sehe ich momentan da keinen dringenden Handlungsbedarf. Oder?

[bigobelix]

Hi R32,

nein, ich mach dem Progi echt Streß, nntp und http. Http mache ich sonst nicht, nur ein paar Auserwählte.
und sorry, aber was kostet heute noch eine 2-300GB HDD? Speicherplatzprobleme dürfte man heute nicht mehr haben. Mußt ja nicht alle 20 Zwergeversionen auf der HDD liegen lassen 

bigobelix

[Plastic]

@R32,
Deine überarbeitete Version findet man ja bereits auf allen Foren und Downloadseiten!
z.B.: h++p://viaccessfree.biz/forum/showthread.php?t=24791&page=3

Die 1.21 konnte ich noch nicht testen, frühesten Sonntag möglich.

Folgende Verbesserungsvorschlage hätte ich für die nächste Version:
- ist es möglich die noch in temp-Verzeichnis befindlichen nntp-Daten mit dem eingebauten NNTPdefrag fertig umzuwandeln?
- Kann man die Dateien ohne „yend“ automatisch löschen lassen (Skynet.ini Löschen: Ja/Nein)? Grund: Speicherplatzreduzierung.


@Pogo

wo hast du getestet? Auf 8W 11222 kommen bei mir in 2h etwa 2-3 GB nntp Dateien zusammen.

Du hast recht, war ein Schreibfehler, ist ca 2GB

lässt du den virtuellen Speicher durch das System verwalten?

Ja, was/wie stellt man bei Windows bei 1 GB Arbeitsspeicher ein?

Noch zur Info habe in der skynet.ini-Datei folgende Werte geändert:
cache_scan=15000   #original 5000
cache_flush=60000   #original 10000


@R32

Das p2p_timeout sollte nicht zu niedrig eingestellt sein. Warum dürfte klar sein.

„timeout_xxxm=“ verstehe ich, aber was bewirkt „p2p_add=xxx“ in der ini-Datei?


@bigobelix

Noch läufts bei mir, kann aber noch nicht viel sagen, weil sich die Bedingungen ja verändert haben. Muß erst wieder ein Gefühl dafür bekommen. Lasse zur Zeit SkynetX gegen R32 antreten.

Wie testet Du? Lässt Du 2 Rechner parallel laufen,oder? Ich möchte wenn ich wieder zu Hause bin auch diverse Test durchführen wie bereits am „01 November, 2006, 14:55“ geschrieben.


@R32

Die 1GB-Datei-Problematik bei nntp ist ein ziemlich grundlegender Fehler in den skynet 0.91er Abkoemmlingen. Ich hatte seinerzeit ja auch deswegen NNTPdefrag direkt in skynet integriert. Dann hat man wenigstens nur die gerade ladenden nntp streams auf Platte. Nach dem Defraggen sind es nur noch die kleinen UUDs. Der zweite Vorteil der Integration ist ja der Wegfall der nntp Nachbearbeitung. Wenn ich jetzt den Fehler in skynet finde und die Dateien dadurch kleiner werden, bleibt die Nachbearbeitung also immer noch uebrig. Von daher sehe ich momentan da keinen dringenden Handlungsbedarf. Oder?

Das mit NNTPdefrag funktioniert, belaste aber auf Grund der zu großen Dateigröße die Hardware zusätzlich, auch ist die erste „uud-Datei“ immer beschädigt und Fehlt daher!

Zum Absturz, ein Freund hat die Version 1.21 getestet mit http und nntp und ist auch nach einiger Zeit abgestürzt, dabei hat er folgende Lösung gefunden. Wen er das nntp-Verzeichnis auf eine andere Festplatte speichert als das temp und die fertigen http-Dateien, stürzt er nicht ab! Keine Ahnung warum?

Plastic

[R32]

Deine überarbeitete Version findet man ja bereits auf allen Foren und Downloadseiten!
z.B.: h++p://viaccessfree.biz/forum/showthread.php?t=24791&page=3

Ja, so besonders begeistert mich das eigentlich nicht.
Genau diesen Thread habe ich mir letzte Woche schon mal durchgelesen (mit translator.ru übersetzt).
Das Ergebnis der automatischen Übersetzung ist ziemlich schlecht, so dass ich nicht besonders viel davon kapiert habe. Die Brocken, die man sich dann zusammenreimen konnte, waren aber ziemlich krass.
Es scheint dort in einen Kleinkrieg gegen den Mod auszuarten. Sogar die Jahreszahl 1941 ist gefallen ... 
Ich weiß nicht, was der Quatsch soll, aber damit möchte ich nichts zutun haben.

Vielleicht kann pogo13 ja mehr dazu sagen. Von ihr gab's in dem Forum auch einen Beitrag, wenn ich mich nicht irre.   


 

Folgende Verbesserungsvorschlage hätte ich für die nächste Version:
- ist es möglich die noch in temp-Verzeichnis befindlichen nntp-Daten mit dem eingebauten NNTPdefrag fertig umzuwandeln?
- Kann man die Dateien ohne „yend“ automatisch löschen lassen (Skynet.ini Löschen: Ja/Nein)? Grund: Speicherplatzreduzierung.

Eigentlich können dort nur nntp Files liegen, wenn skynet mal abgestürzt ist. Richtig?
Dann würde ich vorschlagen, das eigenständige NNTPdefrag einmal drüber laufen zu lassen und dann abzuräumen.

Das Löschen der "no_yend" Files kann ich gern einbauen. 


@R32

„timeout_xxxm=“ verstehe ich, aber was bewirkt „p2p_add=xxx“ in der ini-Datei?

p2p_add legt die zusätzliche Timeout-Zeit für P2P Files fest (in Sekunden). Dieser Wert wird bei P2P Files und Partial Content Files auf das timeout_xxx drauf gerechnet. Es liegt ja in der Natur der Dinge, daß P2P recht hohe Inactive Zeiten hat.

Das mit NNTPdefrag funktioniert, belaste aber auf Grund der zu großen Dateigröße die Hardware zusätzlich, auch ist die erste „uud-Datei“ immer beschädigt und Fehlt daher!

Das ist mir neu! Ist die erste wirklich immer defekt?
Lade bitte mal eine Testdatei hoch.
 

Zum Absturz, ein Freund hat die Version 1.21 getestet mit http und nntp und ist auch nach einiger Zeit abgestürzt, dabei hat er folgende Lösung gefunden. Wen er das nntp-Verzeichnis auf eine andere Festplatte speichert als das temp und die fertigen http-Dateien, stürzt er nicht ab! Keine Ahnung warum?

Hört sich nach Timingproblemen beim Schreibzugriff an. Schwer zu debuggen. Überhaupt nicht spaßig, besonders auf 19.2E mit dem enormen nntp Durchsatz...

Gute Nacht,
R32