FTPFS Probleme seit Ende Januar

[petgun]

*Nach Firmware-Update such*.

..fuer Deinen Switch? Der wird Dir imo nix nuetzen...selbst wenn es sowas fuer Deinen Switch gibt...soetwas loest man imo per Hardware und nicht per Software...was ist das denn fuer ein Teil?

[gryzor]

Nachdem ich den Thread verfolgt habe, möchte ich meine aktuelle Erfahrung mit dem Speedtest und NFS sowie FTPFS nochmals posten:

Verbindung dbox2 <-> PC Suse Linux (NFS/FTPFS)

Ergebnisse laut speedtest
Geschwindigkeit NFS (UDP,ASYNC) Standard Neutrino Options:
7111
8677

Geschwindigkeit FTPFS (rw,ftpactive):
6243
7757

Für FTPFS wurde das speedtest.sh Skript von mir nach Gutdünken angepasst
Keinen Anspruch auf Korrektheit. Skript liegt bei (speedtest2.sh).

Daher stelle ich fest, dass die Übertragungsrate von der Dbox zum PC bei FTPFS deutlich geringer ist als bei NFS.
Je nach Übertragungsrate der Sendung kann also 1 MBit/s zwischen den Übertragungsvarianten einen deutlichen Unterschied ausmachen.
Daher wird auch das FTPFS-Streaming deutlich häufiger zu Aussetzern führen.

Einen Unterschied beim Streamen zwischen den einzelnen yadi-Versionen konnte ich, wie schon auf der ersten Seite des Threads gepostet, rein subjektiv nicht feststellen. FTPFS ist bei allen Versionen schlechter geeignet als NFS.

Grüße, gryzor

Code: Alles auswählen

#!/bin/sh
# speedtest2.sh share > ftpfs.log
V=$1
IP=192.168.100.100
USER=ftp
PWD=ftp
umount /mnt/filme
insmod lufs
lufsmount ftpfs://$USER:$PWD@$IP:21/$V /mnt/filme -o rw,ftpactive
a=`date +%s`
time dd if=/dev/zero of=/mnt/filme/test bs=8k count=8192
z=`date +%s`
n=`expr $z - $a`
expr 512000 / $n
umount /mnt/filme
lufsmount ftpfs://$USER:$PWD@$IP:21/$V /mnt/filme -o rw,ftpactive
a=`date +%s`
time dd of=/dev/null if=/mnt/filme/test bs=8k count=8192
z=`date +%s`
n=`expr $z - $a`
expr 512000 / $n
mount | grep /mnt/filme
umount /mnt/filme
rmmod lufs

[spiridon]

[quote="freefall"]Du hast da einen Zahlendreher drin. 8 MByte sind 8192 und nicht 8129. Ich weiß aber nicht, ob das jetzt ein Problem darstellt.

siehe oben, kein Zahlendreher, warum das NAS NFS solche Werte gibt , weiss ich auch nicht...

[Zaphot]

Ups, das war dann wohl mein Zahlendreher

[freefall]

Puhh... Ich hatte eine schlechte Nacht...

*Nach Firmware-Update such*.

..fuer Deinen Switch? Der wird Dir imo nix nuetzen...selbst wenn es sowas fuer Deinen Switch gibt...soetwas loest man imo per Hardware und nicht per Software...was ist das denn fuer ein Teil?

Das ist ein Allnet ALL0277, der baugleich zum Linksys WRT54G V1.0 ist. Dementsprechend habe ich jetzt auch eine Sveasoft Satori 4.0 Firmware für den Linksys-Router geflasht.

Um es vorweg zu nehmen: Die neue Firmware hat das Problem nicht gelöst.

Der Linktest für FTPFS hat mich dann endgültig desillusioniert. Die Lösung wird niemals stabil laufen, denn ich komme mit FTPFS nicht mal auf die von gryzor gemessenen 6,2 MBit sondern liege irgendwo bei 5,6 MBit. Offenbar schwanken die Werte sehr stark, was erklärt, warum manche Tests funktionierten und andere nicht. Ursache dafür ist wohl die Prozessorauslastung der Dbox. Der lufsd schlägt mit rund 50% Auslastung zu Buche.

Es ist wohl Zeit für eine offizielle Entschuldigung an dich, petgun. Denn das alles hast du bereits früher in diesem Thread gesagt. Ich hab's nur einfach nicht richtig einordnen können. Gleichzeitig möchte ich Danke sagen, dass du trotzdem die Geduld behalten hast...

Aber jetzt bleibt die Frage, wie ich das NFS-Protokoll stabil zum Laufen bekomme, ohne meinen WLAN-Router in die Tonne treten zu müssen?

Have fun,

freefall.

[freefall]

Ich werde heute abend (nacht) mal probieren, in den Rechner eine 3Com-Karte einzubauen. Das ist ein Aldi-Rechner mit Realtek-chipsatz on Board. Vielleicht ist das ja das Problem.

Dann bliebe noch die Möglichkeit, eine NIC nur für die Verbindung zur Dbox einzusetzen.

Beide Ansätze könnten allerdings noch an akutem Platzmangel im PC scheitern...

Have fun,

freefall.

[petgun]

hi,
@freefall
..ich glaube nicht dass Dir eine (zusaetzliche) 3ComNIC entscheidend weiter hilft. Ich habe auch eine 3Com NIC in meiner Kiste und bei meinen Tests war eine direkte CrossKabel Verbindung zur Box _langsamer_ als die Verbindung ueber den absoluten billig Switch DLink DES-105 (5Ports)...den bekommst Du fuer ca. 17€...ist also auch noch preiswerter als die 3ComNIC!
Daran kannst Du dann die DBox/XBox/Streaming PC/Laptop anschliessen und dann letztendlich nur noch eine Verbindung zu Deinem Router/Switch/WLAN-AP der die Probleme macht...dass muesste imo gut funktionieren.

viel Erfolg,
peter

[freefall]

Hmm... Nicht schön, aber selten...

Werde ich auch ausprobieren.

*In Schrank kram* Da war doch noch so ein Switch...

Ich werde berichten. Nur wahrscheinlich erst morgen. Heute abend habe ich keine Zeit und heute nacht muss ich zur Abwechslung mal schlafen...

Have fun,

freefall.

[Mosher]

Hallo,

melde mich auch mal zurück, habe das Thema weiter verfolgt mich aber ausgeklinkt, da ich mit Netzwerktechnik nicht so viel am Hut hab. kurz: konnte nichts konstruktives beitragen

Mich würde allerdings brennend interessieren, ob die 3Com-Karte was gebracht hat, da ich eine Realtek-Karte im PC hängen habe und ständig mit niedrigen Traffic-Raten zu kämpfen habe.

Gruß
Mosher

[DrStoned]

Also bei mir lagen Welten zwischen der Realtek und der 3Com, seit die 3Com drin ist, kaum noch irgendwelche Fehler beim Streamen.

Greetz von DrStoned

[freefall]

Der Einbau der 3Com-Karte hat das Problem auf jeden Fall schonmal entschärft. Es findet jetzt ein vernünftiger Download und Upload statt. Aber der Durchsatz lässt noch immer zu wünschen übrig: 7,1 MBit im Upload sind wohl weniger als möglich.

Am Wochenende werde ich noch mit dem Switch experimentieren.

Have fun,

freefall.

[freefall]

Die gute Nachricht: Nach Einsatz eines Switches wurde der Durchsatz nochmals besser. Jetzt komme ich in beide Richtungen bei udp, async auf rund 8,3 MBit.

Die schlechte Nachricht: Mit Yadi 2.0.0.9 habe ich noch immer keine brauchbare Aufnahme hinbekommen. Abbrüche finden mindestens alls 5 Minuten statt.

Es nimmt kein Ende...

Have fun,

freefall.

[freefall]

Der Kreis ist geschlossen. Aber ich bin nicht schlauer...

Ich habe das Wochenende über eine "Messreihe" durchgeführt. Dabei habe ich über die drei Parameter

• "Netzwerkkarte" (Realtek / 3Com)
• "Infrastruktur" (Router / Switch)
• "Image" (Yadi 2.0.0.7 / Yadi 2.0.0.9)

variiert und jeweils einen Speedtest einmal über NFS (udp,async) und einmal über FTPFS gefahren. Hier die Ergebnisse:

Code: Alles auswählen

                            NFS         FTPFS 
                            Up    Down  Up    Down
2.0.0.9   3Com      Router  7013  8126  5224  8000
2.0.0.9   3Com      Switch  8393  8393  6320  8126
2.0.0.9   Realtek   Router  7111  n/a   5278  7876
2.0.0.9   Realtek   Switch  8533  n/a   6564  8000
2.0.0.7   3Com      Router  7111  8126  5505  8258
2.0.0.7   3Com      Switch  8393  8393  6481  7641
2.0.0.7   Realtek   Router  7211  n/a   5333  8126
2.0.0.7   Realtek   Switch  8533  n/a   6481  8258

(n/a besagt, dass der betreffende Test überhaupt nicht durchgeführt werden konnte!)

Die Ergebnisse bestätigen zunächst einmal die Aussagen von petgun, dass nämlich FTPFS wesentlich schlechtere Durchsätze erzielt als NFS und dass bei mir ein Netzwerkproblem vorlag. Der Switch hat den Durchsatz beträchtlich verbessert. Der Realtek-Chipsatz in meinem Medion-Computer versagt bei NFS-Downloads ganz.

Abgesehen davon lassen die Ergebnisse auch keinen Rückschluss auf Unterschiede zwischen den verschiedenen Image-Versionen zu.

Damit ist auch klar, dass die beste Konfiguration mit Hinblick auf den Durchsatz das NFS-Protokoll über eine 3Com-Karte an einem Switch ist.

Schön und gut. Nur leider sprechen die erzielbaren Aufnahmeergebnisse eine andere Sprache. Es ist mir nach wie vor nicht möglich - in welcher Konfiguration auch immer - stabile Aufnahmen über NFS zu erzielen. In unregelmäßigen Intervallen, die zwischen 1 und 20 Minuten lang sind, wird die Aufnahme mit folgender Fehlermeldung (im Serial-Log) unterbrochen:

nfs: server 192.168.0.2 not responding, timed out
[stream2file]: error in write: Input/output error
[stream2file] pthreads exit code: 4294967293

Und auch, wenn die Messungen dagegen sprechen: Eine Aufnahme des gleichen Senders (ZDF) über mehrere Stunden mit FTPFS erfolgte unterbrechungsfrei und ergab im Serial-Log nur einmal folgede Meldung:

__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process neutrino
avia_gt_napi: lost sync on queue 4 (lost 188 bytes)

Fazit

Dies wiederum belegt nun eindeutig, dass der Durchsatz allein nicht die Ursache für die Abbrüche ist. Es muss also noch eine andere Ursache für die massiven Probleme geben. Und hier tappe ich nach wie vor absolut im Dunkeln.

Eine Frage, die damit vielleicht zusammenhängt: Warum kann ich mit der Realtek-Karte über NFS überhaupt keinen Download durchführen, über FTPFS dagegen ist der Durchsatz sogar eher besser als über die 3Com-Karte?

Have fun,

freefall.

[petgun]

nfs: server 192.168.0.2 not responding, timed out
[stream2file]: error in write: Input/output error
[stream2file] pthreads exit code: 4294967293

...probier mal weiterhin mit NFS und der 3Com Dein Glueck und aendere die Mountoptionen von udp auf tcp und evtl. wsize auf 32768 hochsetzen...SFU kann damit gut umgehen und die Performance sollte damit auch noch hoch genug sein.

cu,
peter

[freefall]

Tja, was soll ich sagen: Es scheint zu funktionieren. Und zwar nicht nur mit der 3Com-Karte, sondern auch mit der Realtek-Karte.

Ich habe natürlich noch keine stundenlangen Aufnahmen gemacht, um wirklich sicher zu sein, aber die ersten Tests deuten darauf hin, dass es jetzt geht.

Der Wechsel von udp zu tcp hat den Umschwung gebracht.

Jetzt bleibt nur noch eine Frage: WARUM???

Have fun,

freefall.

[freefall]

War ich mal wieder zu hastig...

Meine letzte Amtshandlung gestern abend war ein Update auf 2.0.0.9 und der Start einer Testaufnahme - die dann heute morgen wieder in 50 Einzelteilen auf meiner Festplatte lag...

Hab's vor der Arbeit nicht mehr ganz geschaft, wieder 2.0.0.7 zu installieren und dort eine Testaufnahme zu starten. Werde ich aber heute abend nachholen.

Have fun,

freefall.

[petgun]

Meine letzte Amtshandlung gestern abend war ein Update auf 2.0.0.9

...und es war nicht zu spaet und Du hattest die Einstellungen mit 'tcp' und 'wsize=32768' auch gespeichert/kontrolliert ? Was zeigt 'mount' ?

[sullivan]

Hi ..


Also bei mir hat die einstellung von wsize=32768 und tcp auch zum erfolg geführt, hab mal 2 Stunden aufgenommen und dies in eine Datei also keine Unterbrechung.

Nehme wohl auf eine xbox mit Gentoox auf. FTPFS brachte mir bei der Kombination Xbox Dbox immer neue Dateien.


Mfg

Sulli

PS: Image ist das Yadi 2.0.0.9

[freefall]

Okay, hat ein bisschen gedauert, weil ich alle Tests jetzt mehrmals wiederholt habe.

Fazit:

Ob ich die Realtek- oder die 3Com-Karte verwende, spielt praktisch keine Rolle. Der Einsatz eines Switches vor meinem Router jedoch hat sich als unerlässlich herausgestellt. Über den Router geht offenbar mehr Bandbreite verloren, als ich das erwartet hätte. Hier habe ich auch nach wie vor ein Verständnisproblem, weil ich nicht direkt einsehe, wo der Unterschied liegt. Handelt es sich dabei um ein prinzipielles Problem von Routern oder ist es einfach nur ein qualitatives Problem meines Linksys-Nachbaus?

Die Hardware alleine hat aber noch keine Lösung gebracht. Gleichzeitig musste ich in den NFS-Mountoptionen udp durch tcp ersetzen und die Puffergrößen auf 32678 vergrößern. Ob man letzteres auch weglassen kann, habe ich jetzt nicht mehr ausprobiert, nur mit der Vergrößerung der Puffer war es jedenfalls nicht getan. Als Mount-Optionen ergibt sich damit:

Code: Alles auswählen

rw,soft,tcp
nolock,rsize=32768,wsize=32768

Mit diesen Einstellungen bekomme ich stabile Aufnahmen, auch unter Yadi 2.0.0.9, hin.

Ich möchte nochmal allen danken, die sich so intensiv an diesem Thread beteiligt haben, insbesondere natürlich petgun, der zwischendurch auch noch meinen Frust abbekommen hat...

Für die, die keine Lust haben, den ganzen Thread zu lesen, habe ich Im ersten Post dieses Threads nochmal eine Zusammenfassung angefügt.

Have fun,

freefall.

[freefall]

Einen habe ich noch:

Warum genau löst die Verwendung von TCP statt UDP das Problem?

Have fun,

freefall.

[gho]

Nachdem ich den Thread verfolgt habe, möchte ich meine aktuelle Erfahrung mit dem Speedtest und NFS sowie FTPFS nochmals posten:

Verbindung dbox2 <-> PC Suse Linux (NFS/FTPFS)

Ergebnisse laut speedtest
Geschwindigkeit NFS (UDP,ASYNC) Standard Neutrino Options:
7111
8677

Geschwindigkeit FTPFS (rw,ftpactive):
6243
7757

Für FTPFS wurde das speedtest.sh Skript von mir nach Gutdünken angepasst
Keinen Anspruch auf Korrektheit. Skript liegt bei (speedtest2.sh).

Daher stelle ich fest, dass die Übertragungsrate von der Dbox zum PC bei FTPFS deutlich geringer ist als bei NFS.
Je nach Übertragungsrate der Sendung kann also 1 MBit/s zwischen den Übertragungsvarianten einen deutlichen Unterschied ausmachen.
Daher wird auch das FTPFS-Streaming deutlich häufiger zu Aussetzern führen.

Einen Unterschied beim Streamen zwischen den einzelnen yadi-Versionen konnte ich, wie schon auf der ersten Seite des Threads gepostet, rein subjektiv nicht feststellen. FTPFS ist bei allen Versionen schlechter geeignet als NFS.

Grüße, gryzor

Code: Alles auswählen

#!/bin/sh
# speedtest2.sh share > ftpfs.log
V=$1
IP=192.168.100.100
USER=ftp
PWD=ftp
umount /mnt/filme
insmod lufs
lufsmount ftpfs://$USER:$PWD@$IP:21/$V /mnt/filme -o rw,ftpactive
a=`date +%s`
time dd if=/dev/zero of=/mnt/filme/test bs=8k count=8192
z=`date +%s`
n=`expr $z - $a`
expr 512000 / $n
umount /mnt/filme
lufsmount ftpfs://$USER:$PWD@$IP:21/$V /mnt/filme -o rw,ftpactive
a=`date +%s`
time dd of=/dev/null if=/mnt/filme/test bs=8k count=8192
z=`date +%s`
n=`expr $z - $a`
expr 512000 / $n
mount | grep /mnt/filme
umount /mnt/filme
rmmod lufs

Der Wert 512000 im og Script erscheint mir fehlerhaft. Hier eine veränderte Version...

Code: Alles auswählen

#!/bin/sh
SHR=f/vcr #server mount point
MNP=/mnt/custom #local mount point
IP=192.168.0.10
USR=xbox
PWD=xbox
FSZ=64 #test file size [MB]
BSZ=8 #dd block size [kB]

insmod lufs

umount $MNP
lufsmount ftpfs://$USR:$PWD@$IP/$SHR $MNP -o rw,ftpactive &&

for a in 1 #2 3
do
  t0=`date +%s` &&
  dd if=/dev/zero of=$MNP/speedtest bs=${BSZ}k count=`expr $FSZ \* 1024 / $BSZ` &&
  t1=`date +%s` &&
  d=`expr $t1 - $t0` &&
  expr `expr $FSZ \* 1024 \* 8` / $d  #kbps
done

umount $MNP

rmmod lufs

[ZeAr]

Hallo,

wahrscheinlich bin ich zu doof dafür. Ich bekomme die Scripte einfach nicht sauber zum Ausführen.
Das steht bei mir immer:

Code: Alles auswählen

Using /lib/modules/2.4.31-dbox2/kernel/fs/lufs/lufs.o
umount: /mnt: Invalid argument
./speedtest: 23: lufsmount: not found
umount: /mnt: Invalid argument
/var #

oder

Code: Alles auswählen

/var # ./speedtest2
umount: /mnt: Invalid argument
Using /lib/modules/2.4.31-dbox2/kernel/fs/lufs/lufs.o
./speedtest2: 9: lufsmount: not found
dd: /mnt/: Is a directory
Command exited with non-zero status 1
real    0m 0.03s
user    0m 0.01s
sys     0m 0.01s
expr: division by zero
umount: /mnt: Invalid argument
./speedtest2: 16: lufsmount: not found
dd: /mnt/: Is a directory
Command exited with non-zero status 1
real    0m 0.04s
user    0m 0.03s
sys     0m 0.02s
expr: division by zero
umount: /mnt: Invalid argument
/var #

wie geht es?

Vielen Dank

ZeAr

[mogway]

Code: Alles auswählen

./speedtest: 23: lufsmount: not found

Welches Image hast du?

Gruß
mogway

[ZeAr]

[MOD-EDIT] Illegales Image, Ende des Supports für Dich