Anforderung an Netzwerkbandbreite zur Aufnahme

[Thomas Milius]

Ich habe den Gigaset M740AV Reciever nun eine Woche und bin bis auf einige Kleinigekeiten sehr zufrieden. Die Entwicklung dieser Homepage in so kurzer Zeit läßt hoffen,
daß auch die verbliebenen Proleme schnell gelöst werden.

Mit der Aufnahme und Wiedergabe hapert es bei mir noch ein wenig. Dies liegt allerdings an meinem speziellen DV-Umfeld.

Der Reciever hängt an einer dLAN-Leitung und läuft darüber zu meinem Rechner. Dieser läuft unter dem relativ seltenen Betriebssystem RISC OS. Zur Zeit verwende ich einen SAMBA-Port für RISC OS zur Dateifreigabe für den Reciever.

Mein Problem ist die begrenzte Bandbreite des dLAN. Die Aufnahme funktioniert im Großen und Ganzen absolut ruckelfrei. Manchmal hackt es dann doch, hier wären noch ca. 20% mehr Bandbreite notwendig. Ganz übel sihet es bei der Wiedergabe aus. Der RISC OS Samba Port hat unglücklicherweise keine read prediction implementation und so geht wertvolle Zeit vom Eintreffen des Requests bei Samba bis zum Absenden der Daten verloren. In diesem Zeitraum ist das dLAn ungenutzt und holt dies auf Grund der begrenzten Bandbreite nicht mehr auf.

Deshalb meine Fragen:

1. Weiß jemand wieviel Kb/s an reiner Datenkapazität zur Aufnahme eiens Programms benötigt werden (mit/ohne Samba overhead)?
2. Es wäre toll, wenn man auf dem M740AV ein Netzwerkprotokoll mit weniger Overhead als Samba fahren könnte (z.B. FTP). Geht das? Telnet und FTP durch den Lemmi-patch sind im Prinzip Klasse (ich probiere es gleich mal aus), ein FTP-Client wäre für meine Zwecke aber nützlicher.

MfG

T. Milius

[kille]

Hi,


1. Weiß jemand wieviel Kb/s an reiner Datenkapazität zur Aufnahme eiens Programms benötigt werden (mit/ohne Samba overhead)?
Tja, das kommt wohl drauf an. Der Transport Stream hat zunächst mal eine variable Bandbreite. Zudem entscheidet der Sender, wieviel Bandbreite er dem Programm maximal zugesteht. Beim ZDF kann es schon mal mehr sein (zumindest hier in HH sind auf dem ZDF Multiplex nur 3 anstatt wie bei den anderen 4 Sender untergebracht, daher auch eine höhrer, mögliche Bandbreite).

Da das alleine noch nicht kompliziert ist: je nach Modulationsart, Fehlerschutz, Guard-Intervall, Bandbreite des Kanals und was weiß ich noch alles schwankt die Bandbreite eines Multiplex zw (über den Daumen gepeilt) 12,5 und 14,5MBit/s. Wie gesagt, den müssen sich meistens 4 Sender teilen, aber eben nicht statisch, sondern variabel...

Kleines Beispiel: Kanal 23 in HH, Bandbreite geschätze 14,5 MBit/s, aufgeteilt auf 3 Sender macht schonmal 4,8MBit/s im Mittel pro Sender, in Actionlastigen Szenen sogar mehr.

Die c't (Ausgabe 22/04) hat das mal exemplarisch an einem Film untersucht: im Mittel waren es 3,3MBit/s, Peak war 5,3MBit/s. Und das alles ohne SMB-Overhead...

Okay, das ist das Extrem, aber auch dafür soll gesorgt sein. Nicht so extrem war die 24-Folge vom letzten Mittwoch: 1,95MBit/s im Mittel, Peak glaube ich so um die 4,4MBit/s.


2. Es wäre toll, wenn man auf dem M740AV ein Netzwerkprotokoll mit weniger Overhead als Samba fahren könnte (z.B. FTP). Geht das? Telnet und FTP durch den Lemmi-patch sind im Prinzip Klasse (ich probiere es gleich mal aus), ein FTP-Client wäre für meine Zwecke aber nützlicher.
Hm, das Protokoll wird man sicherlich nicht so ohne weiteres austauschen können, dafür bräuchte es etwas in der Art wie Novells NetDrive (nur das das für Windows ist). Wenn du nur einen FTP-Client brauchst, dann kann ich dir helfen:
http://kille.cx/downloads/netkit-ftp.zip
Das Archiv ist recht groß, da auch die Sourcen dabei sind.

Kille

[Thomas Milius]

Vielen Dank für die Antwort. Die c't Messung kenne ich auch.
Fakt ist, daß die Aufnahmen schon mit Samba sehr wenig Störungen haben. Meine Logik:

Wenn es mir gelänge, den Overhead zu reduzieren, müßte es für die Aufnahmen reichen. Bei der Wiedergabe ist eindeutig
der RISC OS Samba Port das Problem.

FTP soll nach Aussagen diverser Leute unter allen Betriebssystemen besser als Samba abschneiden, da der Overhead geringer soll. Ich selber habe mit FTP bislang
auch nur sehr postivie Erfahrungen gemacht. Das Protokoll
dürfte überdies auch deutlich einfacher sein als das von
Samba, so daß ich mir eher einen RISC OS FTP-Server, der auf Geschwindgikeit getrimmt ist, notfalls selber schreiben kann, als im Samba Code rumzuändern.

Ein FTP Client der sich wie ein Laufwerk unter LINUX verhält, wäre für mich auf dem M740AV genau das Richtige. Ich mache mich mal bzgl Netkit, das du erwähnt hast mal schlau.

Nehmen wir mal an, dieser oder ein anderer Code wäre für den M740AV nutzbar und als GPL/LGPL/Open source verfügbar: Wie kriege ich das Ding dann für den M740AV compiliert? Selbst ein vi ist anscheinend eingebaut, aber wo kriege ich eine passende gcc-Mips-Version her? Ob die dann unter RISC OS läuft, wäre dann ein anderes Thema.

T. Milius

[kille]

Hi,


FTP soll nach Aussagen diverser Leute unter allen Betriebssystemen besser als Samba abschneiden, da der Overhead geringer soll.
Ohne Frage. Beim Kopieren von der USB-HDD auf ein SMB Share krieg ich meist um die 700-800kByte/s, beim transfer via FTP-Server 1-1,2MByte/s.

[QUOTE=Thomas Milius]Wie kriege ich das Ding dann für den M740AV compiliert?[/QOUTE]
Im Unterforum Linux-Project gibt es einen Thread, der beschreibt, wie man einen Compiler auf der Box zum laufen bringt. In dem Thread (glaube ich) wurde auch ein Image gepostet (von LinuxDoc, glaube ich), dass alles dabei hat, was du dafür brauchst. Allerdings muss alles wohl statisch kompiliert werden, aber das ist meistens kein Problem.

Kille

[Thomas Milius]

Das mit dem FTP/SMB overhead hört sich sehr vielversprechend an. Ich kriege vom Pocket Computer über die gleiche Verbindung 440 KByte/s nach Samba hineingedroschen.

Unterstellt man das FTP ca. 30% mehr an Daten schafft, müßte dies ausreichen, um Filme über dLAN bei mir aufzuzeichnen bzw. wiederzugeben.

Ich habe im Internet nach einem geeigneten Tool geforscht und glaube fündig geworden zu sein:

ftpfs

Es scheint mehreren LINUX-Distributionen wie z.B. Debian beizuliegen. Bliebe "nur noch" das Problem es auf den M740AV zu portieren. Arg viel LINUX-Erfahrtung habe ich nicht ...

Schauen wir mal.

T. Milius

[kille]

Hi,

hört sich wirklich nach dem an, was dafür gebraucht wird. Nur leider ist das ganze als Kernel Modul realisiert, was die Umsetzung für die Box schwierig macht. Aber kein Problem, denn wie es auf der offiziellen HP heißt: "This project has been obsoleted by LUFS (http://lufs.sourceforge.net/lufs/) (UserLand FileSystem)", welches, wie der Name sagt, im Userland arbeitet. Das ist dann genau das, was gebraucht würde.

Bleibt nur noch die Frage, ob das perforamter ist als SMB. Das muss wohl der praktische Test beweisen.

Kille

[Thomas Milius]

Wie ich schon andeutete bin ich mit LINUX nicht der fitteste. Aber ich glaube auch bei LUFS gibt es ein Problem:

Bei LUFS ist die Rede von einem Kernel-Modul. Dieses fängt die Zugriffe entsprechend ab und leitet sie dann an die einzelnen Unterdateisysteme weiter.

Besteht eine Möglichkeit dieses Modul auch in den Kernel zu laden? Wenn nein (d.h. recompilierung/Linking) brauche ich mir die Arbeit nicht zu machen, die 24MB für den Compiler über mein Analogmodem herunterzuladen.

Das Ganze wäre dann eher was für die Wunschliste an Siemens, so etwas irgendwann einmal mit einzubauen. Die Submodule wie ftpfs könnten dann ja bei Bedarf hinzugeüfgt und weggelassen werden. Auf dem LUFS Modul aufsetzend könnte Siemens dann aber auch sehr einfach andere Protokolle ergänzen, obwohl ich den Marktbedarf dafür leider deutlich unterhalb der Schwelle sehe, wo man als Programmierer üblicherweise die Erlaubnis erhält, so was einzubauen. Das Ganze wäre evt. interessant für eine ganze Reihe von Benutzern mit Netzwerk-Kapazitätsproblemen (dLAN allgemein, WLAN Timeshifting oder Nutzung für andere gleichzeitige Aufgaben).

Schade, ich denke es sieht nicht so optimal aus.

T. Milius