Fritzbox 7170 mit HDD und Bittorrent

[jesus.christ]

Gutes Verhältnis? Wenn ich über BitCommet am Win-Rechner oder sauge, dann läuft das ganze mit 380 KByte down bei ca. 20-40 KByte Up. Wieso kann transmission keine solchen Werte liefern?
Mit der Geschwindigkeit ist ja auch eine Festplatte an der Fritz fast unsinnig.

naja, ob man jetzt eine hdd an der box hängen hat mit niedrigem speed oder gleich en ganzen pc anhat mit hohem speed macht wohl doch noch einiges aus (bzgl stromkosten)... ich hab lieber 3 tage die platte (2,5") an der box hängen als einen tag den pc nonstop an.

[lord-of-linux]

Da BitTorrent ein P2P Netz ist, darfst du nicht unbedingt erwarten, dass es deine Leitung voll ausnutzt. Wenn ich es noch richtig weiß, kann man den Tracker z.B. so einstellen, dass der Download nur so groß wie der Upload ist. Und es müssen natürlich genügend Leute im Netz sein, die dir Daten senden, wobei die Verteilung nicht immer ganz durchsichtig ist. Als Beispiel bei mir kein Upload, aber andere Clienten, denen Teile fehlten, die ich schon hatte, bekommen laden trotzdem nichts.

Vieleicht ist es ja wirklich der Tracker, der mich runterbremst. Nur finde ich es komisch, das transmission zwischendurch so langsam geworden ist.

Wenn du wirklich einen Vergleich anstellen willst, müsstest an verschiedenen IPs die gleiche Datei gleichzeitig runterladen. Um fair zu bleiben, müsstest du Transmission auch auf einem PC laufen lassen (oder bleibt die CPU / RAM Belastung unkritisch?). Auch alle komplexen Sachen (UDP, eigene Tracker) in BitComet etc. ausschalten, die Transmission für die Box unbrauchbar machen würde.

Transmission frisst ca. 20-25% der Prozessorleistung und ist gerade bei 13% Speicher. Wenn ich BitComet ohne den zusätzl. Funktionen laufen habe, da ist es auch langsam.
Naja, ich werde mich damit auch abfinden.

naja, ob man jetzt eine hdd an der box hängen hat mit niedrigem speed oder gleich en ganzen pc anhat mit hohem speed macht wohl doch noch einiges aus (bzgl stromkosten)... ich hab lieber 3 tage die platte (2,5") an der box hängen als einen tag den pc nonstop an.

Ja klar, ist schon günstiger. Ich werde mal drüber nachdenke, was ich mache.
Ich will vieleicht sowieso mal noch ne NSLU2 oder nen VIA Epia als Homeserver. Dauert aber noch ein bisschen.

[debugger]

@hsudek Hast du die libtransmission verändert? Bei mir passen einige Prototypen nicht. Sorry, falls ich nur wieder einen Patch übersehen habe...

*edit
Als Beispiel: Was bedeutet

				else if( s->error & TR_ETRACKER )
				{
					textSize = snprintf( text, 100,"%s\n", s->trackerError );
				}

Es gibt doch schon TR_TRACKER_ERROR und dann tor->error (Jedenfalls wenn ich mir das oben richtig vorstelle)

[cobobi]

Hallo,

in diesem thread war die Frage aufgeworfen (und auch schon
später beantwortet) worden, ob denn die Box für der Aufgabe
gewachsen ist. Daher habe ich die proc-Utilities und iostat
übersetzt. Dabei sind in diesem Paket
iostat, vmstat, top und snice. Zu top ist zu sagen, dass
zunächst

export TERMINFO=`pwd`

im Verzeichnis des Pakets einzugeben ist.

Claus

[Ricotchet]

Hi habe gerade auch festgestellt das man mit transmission 0.5 keine files über 2 GB ziehen kann.
jemand eine idee

[olistudent]

Du musst ein transmission-Binary nehmen, das statisch gegen eine uClibc mit LFS (Large File Support) gelinkt ist!

MfG Oliver

[webogdal]

1. Leider habe ich festgestellt dass die FritzBox (CPU?) oft mit nur einem Torrent überlastet wird und dann neu startet. Download/upload wird dabei unterbrochen und muss wieder neu gestartet werden...

2. Überprüfen von bereits heruntergeladenen Dateien dauert sehr, sehr lange. Bei einem ca. 4 GB Torrent über zwei Stunden. Kann man das vielleicht umgehen oder verkürzen ?

[hsudek]

@hsudek Hast du die libtransmission verändert? Bei mir passen einige Prototypen nicht. Sorry, falls ich nur wieder einen Patch übersehen habe...

Sorry, habe vergessen zu erwähnen, daß ich die SVN-Version 244 als Basis benutzt habe. Damit sollte alles funktionieren.

[debugger]

Ich arbeite mit hsudek an einem Interface und wir haben auch schon ein Konzept. Die realisierung des Webinterfaces wird durch ein Framework im DS-Mod sehr vereinfacht.

Ist damit libmodcgi.sh und libmodfrm.sh gemeint? Wenn ja, meint ihr nicht, dass ein C Framework wie qdecoder einfacher als Shell wäre? Dort gibt es auch sehr einfache Funktionen, mit den man .torrent Dateien hochladen könnte oder Vorlagen wie bei webcm ausfüllen kann. CGI damit sind mit ~40 KByte größer, aber ich denke, dass ist auch im RAM vertretbar.

[lord-of-linux]

Ist damit libmodcgi.sh und libmodfrm.sh gemeint? Wenn ja, meint ihr nicht, dass ein C Framework wie qdecoder einfacher als Shell wäre? Dort gibt es auch sehr einfache Funktionen, mit den man .torrent Dateien hochladen könnte oder Vorlagen wie bei webcm ausfüllen kann. CGI damit sind mit ~40 KByte größer, aber ich denke, dass ist auch im RAM vertretbar.

Ich kenne mich noch nicht wirklich mit C aus. Außerdem scheint qDecoder nur mit folgenden Servern zusammen zu arbeiten:

Web Server: Apache Web Server, Netscape Enterprise Server, Oracle Application Server, Microsoft Internet Information Server

Meiner Ansicht nach ist sowieso der Upload der Torrent-Dateien das einzigste Problem am ds-mod-Interface.

[debugger]

Also jedenfalls würde ich mit printf, etc. schon HTML vorformatieren, denn sonst wird das in den Skripten (Damit kenne ich mich wiederum nicht aus ) etwas mühsam das zu sortieren. Oder nicht?

Spricht etwas dagegen, in transmissiond mit fdopen conn zu öffnen und dann mit fprintf zu arbeiten. Wäre einfacher als mit snprintf und write und zumindest auf x86 geht das problemlos.

[lord-of-linux]

Also jedenfalls würde ich mit printf, etc. schon HTML vorformatieren, denn sonst wird das in den Skripten (Damit kenne ich mich wiederum nicht aus ) etwas mühsam das zu sortieren. Oder nicht?

Das könnten wir uns überlegen. Mal schauen. Aber es sind ja auch noch ein paar Kleinigkeiten zu klären. Wenn dies mit hsudek besprochen ist, dann werden wir hoffentlich bald ein Ergebnis vorweisen können.

Spricht etwas dagegen, in transmissiond mit fdopen conn zu öffnen und dann mit fprintf zu arbeiten. Wäre einfacher als mit snprintf und write und zumindest auf x86 geht das problemlos.

Damit kenne ich mich auch nicht aus. Hier sollte sich hsudek überlegen, wie er es machen will.

[hsudek]

Spricht etwas dagegen, in transmissiond mit fdopen conn zu öffnen und dann mit fprintf zu arbeiten. Wäre einfacher als mit snprintf und write und zumindest auf x86 geht das problemlos.

Ich denke nicht, dass etwas dagegen spricht. War einfach nur mein erster Einfall, da transmissioncli auch snprintf benutzt.

[debugger]

1. Leider habe ich festgestellt dass die FritzBox (CPU?) oft mit nur einem Torrent überlastet wird und dann neu startet. Download/upload wird dabei unterbrochen und muss wieder neu gestartet werden...

Eher RAM, aber das ist ohne weiteres schwer zu sagen.

2. Überprüfen von bereits heruntergeladenen Dateien dauert sehr, sehr lange. Bei einem ca. 4 GB Torrent über zwei Stunden. Kann man das vielleicht umgehen oder verkürzen ?

Das ist nur bedingt ein Problem von Transmission. 4 GB holen dauert halt, auf PCs Minuten, über 12 MBit/s Leitung länger (schon theoretisch ~1h und realistisch eben 2). Eigentlich werden deshalb .resume Dateien beim ordentlichen Beenden gespeichert. Du musst halt HOME=/beschreibares/nicht/flüchtiges/verzeichnis/deiner/wahl ./tr... aufrufen. Bei FBox Abstürzen ist aber wenig zu machen...

[debugger]

Ich habe jetzt einen ersten Entwurf "fertig". Leider habe ich keinen cross compiler, da müsste sich jemand anders finden. Auf x86 läuft es aber schon mal. Fürs CGI wird noch qDecoder benötigt.

Achtung: SEGV

[lord-of-linux]

Ich habe jetzt einen ersten Entwurf "fertig". Leider habe ich keinen cross compiler, da müsste sich jemand anders finden. Auf x86 läuft es aber schon mal. Fürs CGI wird noch qDecoder benötigt.

Ich dachte wir waren uns einig, dass wir einen Daemon machen, den Wir über das normale Interface ansprechen (Per Socket). Oder wie sieht es aus?

[debugger]

transmissiond.c ist der Daemon
transmissiondc.c ist der shell Client (Status Ausgaben noch anzupassen)
transmissiondcgi.c ist mehr ein Experiment/Funktionstest/Spielerei

[lord-of-linux]

transmissiond.c ist der Daemon
transmissiondc.c ist der shell Client (Status Ausgaben noch anzupassen)
transmissiondcgi.c ist mehr ein Experiment/Funktionstest/Spielerei

OK,
muss nur noch jemand compilen.

EDIT:
Welche funktionen sind den nun vom Client steuerbar?

[debugger]

• init Torrent hinzufügen
• start|stop einzelner Torrent oder alle mit id 0
• info wie -i
• scrape wie -s
• status listet alle Torrents mit der Zeile wie in cli auf

Das CGI kann auch diese Funktionen, ist halt weder optisch noch technisch hübsch, zeigt dafür aber schon ähnlich ausführlich Daten wie Azureus

[Ricotchet]

wo kann ich die version für dateien über 2 gb runterladen?