PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [topf] Aufnahmen werden auf einer NFS Freigabe stotternd geschrieben



Hank
27.09.2013, 16:33
Hallo,

ha, ich freu mich tierisch, dass es wieder ein Enigma Forum gibt, nachdem das AAF irgendwie sich zerschossen hat. An dieser Stelle nochmal vielen Dank an den User, der mich auf dieses Forum brachte.

Ich habe nun folgendes Problem und bin mit meinem Latein am Ende. Ich speichere die Aufnahmen nicht auf dem Topfield, sondern auf einer NFS Freigabe. Zunächst ein bischen Vorgeschichte dazu. Ich hatte einen iMac als NFS Server. Funktionierte einwandfrei. Dann habe ich einen Drobo an den iMac angeschlossen und dessen Volume genutzt. Dann stotterten die Aufnahme stark. Bis ich drauf gekommen bin, die rsize und wsize im Topf hoch zu stellen. Danach klappte das einwandfrei. Dann habe ich mir einen Linux Server mit der Distri yaVDR 0.4 (Die basiert auf Natty) angeschafft und dort eine CIFS Freigabe eingerichtet und die Töpfe (Ich habe 5 Stück) darauf gemountet. Klappte auch einwandfrei. Später habe ich dann den Server auf NFS umgestellt und die Töpfe darauf gemountet. Klappte auch einwandfrei.

Jetzt habe ich mich von dem yaVDR Server verabschiedet und auf diese unveränderte Hardware Linux Ubuntu 12.04 Precise Pangolin Server installiert. Tja, und die NFS Freigabe funktioniert mit anderen Clients einwandfrei. Ich komme auf richtig hohe Lese- und Schreibzugriffsgeschwindigkeiten von anderen Clients aus. Der Flaschenhals ist eher das Gigabit LAN. Aber wenn ich eine Aufnahme auf die Freigabe per Topf speichere, stottert es wie Sau. Eine SD Aufnahme geht halbwegs, stottert zwischendrin auch. Dann habe ich mir die Datei auf nem Rechner gezogen und auch dort stottert es. Dann mal ne alte Aufnahme mit dem Topf von der Freigabe geschaut und es funktioniert einwandfrei. Es scheint also irgendein Schreibproblem zu sein.

So, alle Möglichen Parameter am Server überprüft, passt alles, so das ich den derzeit eher ausschließe.

Dann habe ich mit einem Skript die NFS Schreib- und Lesegeschwindigkeiten per Telnet überprüft und komme auf http://pastebin.com/Hhhb6H1x



Results for write throughput:
41.297 Mbit/s with udp,async,wsize=32768
34.636 Mbit/s with udp,async,wsize=16384
27.531 Mbit/s with udp,async,wsize=8192
25.565 Mbit/s with tcp,async,wsize=32768
23.860 Mbit/s with tcp,async,wsize=16384
20.648 Mbit/s with udp,async,wsize=4096
18.512 Mbit/s with tcp,async,wsize=8192
14.510 Mbit/s with tcp,async,wsize=4096
Results for read throughput:
38.347 Mbit/s with udp,async,rsize=16384
34.636 Mbit/s with tcp,async,rsize=32768
32.537 Mbit/s with udp,async,rsize=32768
29.826 Mbit/s with udp,async,rsize=8192
29.826 Mbit/s with tcp,async,rsize=16384
23.860 Mbit/s with tcp,async,rsize=8192
21.053 Mbit/s with udp,async,rsize=4096



Also flux geschaut, wie gemountet ist. Mount gibt u.A. das aus

(rw,relatime,vers=3,rsize=32768,wsize=32768,namlen =255,hard,nolock,proto=tcp,port=65535,timeo=70,ret rans=3,sec=sys,mountport=65535,addr=192.168.2.10)

Das bedeutet, die Schreib- und Lesegeschwindigkeiten liegen bei etwa 3MByte/s und 4,25 MByte/s, da ich tcp verwendete. Ich habs mit udp versucht, änderte nichts.

Dann habe ich eine CIFS Freigabe am Server eingerichtet und am Topf gemountet. Dort aufgenommen und siehe da, es fluppt einwandfrei.

Also auch hier einen Geschwindigkeitstest vom Topf aus gemacht

Dauer: 61 Sekunden Durchsatz: 17602324 bit/s

Also etwa 2,1MByte/s. Noch weniger als per NFS, obwohl das schon sehr wenig ist. Aber es funktioniert einwandfrei.

Was auffällt, dass der Server bei top über 20%wa anzeigt beim schreiben, beim lesen etwa 13%wa. htop zeigte, dass die cpu recht viel auf io wartete. Passt ja auch.

So langsam bin ich am Ende, ich weiß nicht mehr weiter. Hat noch Jemand ne Idee oder Lösungsansätze?

Die Enigma Version ist von AAF und die Nummer 37. Ich hoffe, ich darf das hier überhaupt so erwähnen, weil es ja von AAF ist.

Die exports-Zeile sieht so aus

/home/... *(rw,fsid=2,async,no_subtree_check,all_squash,anon gid=1000,anonuid=1000)

Ich hatte es auch auf sync versucht, gleiches Problem. Die ... habe ich jetzt nur gesetzt, in der echten Zeile ist es schon korrekt.


Vielen Dank an euch und Gruß

Hank

normann
27.09.2013, 16:52
Hallo und Willkommen
Die Ethernetschnittstelle am Topf ist schon echt grenzwertig. Wenn ich es recht verstanden habe, ist das Problem erst nach Server OS Wechsel entstanden. Hardware ist gleich geblieben.
Kenne mich mit den Linux Distis nicht wirklich aus, aber kann es sein, dass auf der "großen" Ubuntu Server noch Zeug mitläuft, auch auf Netzwerkbasis, was auf den "kleinen" nicht drauf ist?

Hank
27.09.2013, 16:56
Hallo und vielen Dank!

Ja, die Hardware ist absolut identisch. Ich habe nichtmal einen Stecker verändert.

Mh, NFS Server ist NFS Server. Außer vielleicht die Version. Aber generell läuft es ja schnell genug. Aber selbst wenn, was soll das Netz denn so belasten? Zumal CIFS läuft, was langsamer ist als NFS. Auch das habe ich getestet.

Es stottert ja nicht nur gelegentlich mal, sondern so richtig derbe.


Danke und Gruß

Hank

normann
27.09.2013, 16:59
Stottert das bei UDP und TCP oder nur bei einem von beiden? Wenn es bei UDP stottert, kann es klar sein, weil keine Fehlerkorrektur stattfindet und wenn es bei TCP stottert kann es klar sein, weil der Flaschenhals Ethernetschnittstelle des Topfes zu lahm ist.

TheChip
27.09.2013, 17:42
@Hank, mal ne ganz blöde Frage, Du hast ja geschrieben, das Du mehrere Töpfe am laufen hast. Wenn Du Aufnimmst, sind die anderen Töpfe da im Deepstandby oder im Softstandby?

Ich Frage aus einem bestimmten Grund: Momentan hat sich wieder der fehler mit den gleichen MACs beim Topf eingeschlichen. Und wenn da mehrere Töpfe mit der selben MAC im Netz gleichzeitig im Betrieb sind, hab ich auch schon die seltsamsten Effekte beobachtet. Kannst ja mal schauen (mit Telnet und ifconfig) ob die MAC identisch sind wenn ja, mal alle Töpfe außer einem abschalten und dann nochmal probieren.

santa
27.09.2013, 17:50
So wie ich ihn verstanden habe, hat er kein hdmu drauf

Hank
27.09.2013, 18:02
Hallo,

vielen Dank für die Antworten.

Norman:

Das Problem tritt bei UDP und TCP auf. Aber die Datenraten sollten gut genug sein. Meiner bescheidenen Meinung nach.

The Chip:

Die Töpfe waren alle, außer einer, im Deep Satndby. Außerdem haben sie alle eine feste IP. Klar, auch unterschiedliche. Und auch alle eine unterschiedliche Mac Adresse. Habe ich geprüft. Ich arbeite übrigens mit DNSmasq. Dementsprechend sind alle Daten in /etc/hosts und /etc/dnsmasq.conf. In der letzteren Config auch die Macadressen der Töpfe. Das passt auch, habe ich überprüft. DNSmasq lief auf dem vorigen Linuxserver auch.

santa:

Richtig, ich habe kein hdmu drauf. Vielleicht ändere ich das ja mal ;)

Alle:

Ich denke, dass es keine EInstellung am Topf ist, sondern irgendeine Inkompatibilität zwischen dem NFS Server und Client. Aber ich habe keine AHnung, was ich noch probieren kann, um dem Fehler auf die Spur zu kommen.


Vielen Dank und Gruß

Hank

normann
27.09.2013, 18:04
Den Router mit einbezogen?

Hank
27.09.2013, 18:05
Den Router mit einbezogen?

Worin?

normann
27.09.2013, 18:07
Worin?

In die Betrachtung. Nicht, dass da was klemmt.

Hank
27.09.2013, 18:12
norman, wie gesagt, ich arbeite mit einem getrennten Switch (
HP ProCurve 1810G - 24 GE) und sowohl das DNS als auch DHCP läuft nicht im Router. Dementsprechend habe ich keine Idee, was der Router da "vermurksen" könnte.


Gruß

Hank

normann
27.09.2013, 18:19
OK, dann scheidet der aus.

Hank
27.09.2013, 18:41
Mh, wie hat sich denn HDMU entwickelt? Ich nehme an, es basiert auf AAF. Falls ja, wurde denn an den NFS Einstellungen, Versionen oder sonst irgendetwas verändert? Welche NFS Version wird verwendet?

Danke und Gruß

Hank

santa
27.09.2013, 18:48
Auf AAF basiert bei uns nichts, unser E2 basiert auf openPli, aaf auf uralt dream E2.
Treibertechnisch nutzen wir die selben, was es eben öffentlichen tdt-git gibt,
wobei da auch wieder das aaf Jahre älter ist.

Hank
27.09.2013, 18:49
Ah, ok. Vielen Dank.

Vielleicht sollte ich einfach mal einen Topf "updaten"...


Gruß

Hank

Edith: Mh, läuft die aktuellste Version denn stabil und nicht langsamer und kann ich quasi "einfach" updaten, damit die Einstellungen erhalten bleiben oder muss ich den Topf komplett neu konfigurieren? Wird Softcam genauso umfangreich unterstützt?

TheChip
27.09.2013, 19:06
Du mußt die Töpfe in jedem Fall neu konfigurieren. Das einzige, was Du übernehmen kannst sind die Kanallisten und die Aufnahmen (kannst also mit partition=0 installieren). Die sonstigen Settings und Softcams kannst Du nicht übernehmen, aus dem Grund den santa genannt hat. Aber wir haben auch eine ganze menge Softcams am Feed. Solltest also was passendes finden. Die configs davon (z.b. Oscam.server usw.) kannst Du auf alle Fälle übernehmen. Die binaries für die cams sind auch weiter nutzbar, nur die startscripte dafür sind anders.

Hank
27.09.2013, 19:18
Ah ja, vielen Dank. Ich werde es bei Gelegenheit mal probieren. Dennoch ist mein Problem dadurch nicht gelöst :(


Danke und Gruß

Hank

Hank
28.09.2013, 16:28
Hallo,

so, ich bin ein Stückchen weiter.

Ich habe einfach mal die Freigabe im Topf ausgeschaltet. Den Topf dann rebootet und danach die Freigabe wieder aktiviert und nochmal rebootet. Und schwups klappt es. Auch die top und htop Werte am Server sehen jetzt gut aus. Ich frag mich nur, was ist anders. Ein mount per Telnet hat dann ergeben, dass die Ausgabe nun timeo 7 anzeigt und vorher war es 70. Ich will das nochmal in Ruhe nachvollziehen, ob es wirklich DAS Problem ist/war. Es ist aber auf mehreren Töpfen, mittlerweile 3 Stück, reproduzierbar. Die letzten 2 will ich mal so lassen, da ich schauen möchte, wie die mit dem "Fehler" eingestellt sind.

Nun meine Frage, ich habe keine Configdatei und keinen Menupunkt gefunden, in dem man das eingeben kann. Also Dinge wie timeout oder ob hard oder soft etc. Hat Jemand ne AHnung, wo das definiert wird?


Danke und Gruß

Hank

P.S. Eine neue Platte als Testplatte für HDMU ist bestellt ;)