Fritzbox 7170 mit HDD und Bittorrent

jesus.christ · 30 Apr 2006

lord-of-linux schrieb:
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 · 30 Apr 2006

debugger schrieb:
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.

debugger schrieb:
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.

jesus.christ schrieb:
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 · 30 Apr 2006

@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

Code:

				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 · 1 Mai 2006

Einige Tools

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 · 1 Mai 2006

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

olistudent · 1 Mai 2006

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

MfG Oliver

webogdal · 2 Mai 2006

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 · 2 Mai 2006

debugger schrieb:
@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 · 2 Mai 2006

lord-of-linux schrieb:
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 · 2 Mai 2006

debugger schrieb:
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:

http://www.qdecoder.org/about.qsp schrieb:
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 · 2 Mai 2006

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 · 2 Mai 2006

debugger schrieb:
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.

debugger schrieb:
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 · 2 Mai 2006

debugger schrieb:
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 · 5 Mai 2006

webogdal schrieb:
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.

webogdal schrieb:
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 · 10 Mai 2006

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 :blonk:

lord-of-linux · 10 Mai 2006

debugger schrieb:
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 · 10 Mai 2006

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 · 10 Mai 2006

debugger schrieb:
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 · 11 Mai 2006

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 · 11 Mai 2006

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

Fritzbox 7170 mit HDD und Bittorrent

Mitglied

Mitglied

Neuer User

Neuer User

Anhänge

Neuer User

IPPF-Urgestein

Neuer User

Neuer User

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

Neuer User

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

Neuer User

Statistik des Forums