Hi ho,
offensichtlich gibt es ja ein wenig Unstimmigkeiten mit "ruckeligem Streaming" und immer sind Diskussionen um die Performance des Netzwerks aufgetaucht.
Um das ganze mal ein bischen genauer zu untersuchen, habe ich ein kleines Script geschrieben, dass die Bandbreite beim Lesen und Schreiben auf der DB misst.
Dabei habe ich das folgende festgestellt:
- NFS ist besser als man glaubt: wenn es um das Streamen vom NFS-Share in die DB geht, so sollte man NFS via TCP wählen und die üblichen 8k-Blockgrössen (rsize/wsize) wählen. Damit erreicht meine DB lesend wie schreibend ca. 24Mbit/s.
NFS via TCP ist nicht der Default, d.h. man muss den Mount-Options noch "tcp" hinzufügen. - Um einen Stream von der DB auf ein NFS-Share aufzuzeichnen, sollte man NFS via UDP wählen (dies ist auf der Default).
Meine DB erreicht damit ca. 6.5MBit/s lesend und ca. 30MBit/s schreibend.
Ändert man die default-mässig vorgegebenen Lese-Blockgrösse von 8k auf 2k, so lässt sich damit die Lese-Geschwindkeit auf ca. 17.5MBit/s erhöhen.
Warum? Nun: der Server sendet seine Daten in 8k-Böcken, da der Client es so angefordert hat. Allerdings muss dann der Client durch die hohe Anzahl der IP-Fragmentierung so viel rechnen, dass er im Endeffekt mit kleineren Blockgrössen schneller ist. - CIFS habe ich ebenfalls getestet, allerdings lagen die Geschwindigkeit unterhalb denen von NFS (evtl. lässt sich da auch noch ein bischen dran drehen).
Mein Vorschlag:
- Mounted /hdd mit NFS via UDP und Lese-Blockgrösse von 2k.
Mount-Options: "rw,udp,rsize=2048,wsize=8192,nolock,hard" - Wenn ihr die DB zur Wiedergabe verwendet, mounted das jeweilige Share mit NFS via TCP und Blockgrösse von 8k.
Mount-Options: "ro,tcp,rsize=8192,wsize=8192,nolock,hard"
Ihr könnt natürlich auch beide Shares gleichzeitig mounten (ich verwende ein Share zum Aufzeichnen und ein weiteres zum Abspielen von "Konserven").
gromeck