Netzwerk Geschwindigkeitstest NFS

[GSX-R 1000]

Habe jetzt mal den kcore-Test gemacht:

/var # time cat /proc/kcore > /mnt/record/test1

real 1m 4.18s

user 0m 0.29s

sys 0m 13.56s

/var # time cat /mnt/custom/test1 > /dev/null

cat: /mnt/custom/test1: No such file or directory

Command exited with non-zero status 1

real 0m 0.05s

user 0m 0.02s

sys 0m 0.02s

/var #

[ion]

Die Werte sind in Ordnung - und wenn Du jetzt den kcore-Test selbst umrechnest, dann siehst du auch warum ich den bevorzuge   - damit biste in 3 Minuten fertig und weisst dasselbe, wie wenn Du 20 Minuten auf das Netztestergebnisse wartest

Der "netztest" hat auch seinen Vorteil:er miesst mit verschiedenen Werten ,dann kann man die beste Kombination in der Box eintragen.

[ion]

cat: /mnt/custom/test1: No such file or directory

Command exited with non-zero status 1

real 0m 0.05s

user 0m 0.02s

sys 0m 0.02s

/var #

Ersetze custom mit record.

[GSX-R 1000]

So, habs gemacht:

 

/var # time cat /mnt/record/test1 > /dev/null

real 1m 1.96s

user 0m 0.17s

sys 0m 8.04s

 

Finde die Dateien nicht, für die ich die Rechte freigeben soll, deshalb kann ich den anderen Test leider nicht durchführen. Aber was sagt der hier aus? Ist mein Netz zu lahm? Wollte heute etwas von Premiere Direkt aufnehmen, kurz vor Ende wurde die Aufnahme dann aber in viele kleine .TS Dateien gesplittet.

[ion]

Finde die Dateien nicht, für die ich die Rechte freigeben soll, deshalb kann ich den anderen Test leider nicht durchführen.

Die musst du doch nach tmp kopiert haben.Wenn du zwischenzeitlich neugestartet hast sind die nicht mehr da.Du musst sie wieder hinkopieren.Mach den netztest auch dann können dir die Jungs mehr helfen.

[paulamann]

Sorry dass ich jetzt so reinplatze, wollte nur mal kurz ne Info geben:

Der Netztest war bei mir immer erfolgreich, auch der von guschtav gepostete Weg zum Testen der Geschindigkeit war bei mir immer erfolgreich, immer so um die 57,x bzw. 58,x Sekunden.

Habe vorhin versucht auf Premiere Sport zu Streamen, das ging direkt in die Hose.

Habe danach den WOL-Timer deaktiviert und die Box neugestartet: Dann konnte ich das Spiel auf ZDF ohne Probleme durchstreamen (8,9 GB).

Weiss jetzt nicht, ob es wieder mal ne Glückssache war, oder ob der WOL-Timer bei Direkt-Aufnahmen evtl. dazwischenfunkt...

Ich habe nur gemerkt, dass ich auf Premiere Sport GAR NICHT aufnehmen konnte, bei bis jetzt allen Versuchen, ein WM-Spiel aufzunehmen, ist der Stream abgebrochen. Muss irgendwie an Premiere liegen, einige Leute haben ja auch von Aussetzern und Rucklern während der Spiele berichtet. Auf ZDF ging es gerade ohne Probleme - und die dürften eine deutlich höhrere Datenrate haben.

 

Bin in soweit schonmal beruhigt, dass mein Netzwerk i.O. ist, sowie das KW-Image (da hatte ich eigtl. eh nie einen Zweifel dran).

 

Also meine Streaming-Abbrüche hatten wohl etwas mit dem Programm = Premiere zu tun, ansonsten klappt es wunderbar.

 

BTW: Kann es sein, dass der WOL-Timer Probleme bei einer Direkt-Aufnahme bereitet, da er versucht, WOL zu machen, zu mounten etc.? Oder war die ganze Sache doch nur Zufall bei mir? Habe sonst eigtl. nur per WOL-Timer aufgenommen, daher kann ich es gerade nicht nachvollziehen.

[GSX-R 1000]

Hatte die Dateien ausgewählt und da war überall ein Häkchen dran. Hab jetzt die Häkchen weggemacht und wieder hin und siehe da, es geht. Nun auch noch diese Ergebnisse (Danke an ion):

 

4096, 4096

8192+0 records in

8192+0 records out

real 1m 17.22s

user 0m 0.22s

sys 0m 12.68s

6649

8192+0 records in

8192+0 records out

real 1m 18.78s

user 0m 0.25s

sys 0m 12.80s

6481

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=4096,wsize=4096,soft,udp,nolock,addr=192.168.0.20)

 

6144, 6144

8192+0 records in

8192+0 records out

real 1m 17.68s

user 0m 0.21s

sys 0m 12.59s

6564

8192+0 records in

8192+0 records out

real 1m 18.15s

user 0m 0.22s

sys 0m 12.15s

6481

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=4096,wsize=4096,soft,udp,nolock,addr=192.168.0.20)

 

8192, 8192

8192+0 records in

8192+0 records out

real 1m 5.86s

user 0m 0.25s

sys 0m 10.93s

7757

8192+0 records in

8192+0 records out

real 1m 9.77s

user 0m 0.16s

sys 0m 8.81s

7314

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.0.20)

 

9216, 9216

8192+0 records in

8192+0 records out

real 1m 5.93s

user 0m 0.23s

sys 0m 11.39s

7757

8192+0 records in

8192+0 records out

real 1m 9.52s

user 0m 0.24s

sys 0m 8.63s

7420

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.0.20)

 

10240, 10240

8192+0 records in

8192+0 records out

real 1m 6.46s

user 0m 0.37s

sys 0m 11.07s

7641

8192+0 records in

8192+0 records out

real 1m 9.39s

user 0m 0.29s

sys 0m 8.58s

7314

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.0.20)

 

11264, 11264

8192+0 records in

8192+0 records out

real 1m 5.38s

user 0m 0.29s

sys 0m 11.54s

7757

8192+0 records in

8192+0 records out

real 1m 9.82s

user 0m 0.22s

sys 0m 8.75s

7314

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.0.20)

 

12288, 12288

8192+0 records in

8192+0 records out

real 1m 6.20s

user 0m 0.38s

sys 0m 11.15s

7757

8192+0 records in

8192+0 records out

real 1m 10.26s

user 0m 0.28s

sys 0m 8.72s

7211

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.0.20)

 

16384, 16384

8192+0 records in

8192+0 records out

real 1m 6.09s

user 0m 0.26s

sys 0m 10.76s

7757

8192+0 records in

8192+0 records out

real 1m 7.24s

user 0m 0.26s

sys 0m 9.19s

7641

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=16384,wsize=8192,soft,udp,nolock,addr=192.168.0.20)

 

24576, 24576

8192+0 records in

8192+0 records out

real 1m 5.67s

user 0m 0.29s

sys 0m 11.62s

7757

8192+0 records in

8192+0 records out

real 1m 6.68s

user 0m 0.26s

sys 0m 9.26s

7641

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=16384,wsize=8192,soft,udp,nolock,addr=192.168.0.20)

 

32768, 32768

8192+0 records in

8192+0 records out

real 1m 5.69s

user 0m 0.21s

sys 0m 11.65s

7757

8192+0 records in

8192+0 records out

real 1m 3.27s

user 0m 0.22s

sys 0m 8.44s

8000

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.0.20)

[Gast guschtav]

Die Werte sind in Ordnung - und wenn Du jetzt den kcore-Test selbst umrechnest, dann siehst du auch warum ich den bevorzuge   - damit biste in 3 Minuten fertig und weisst dasselbe, wie wenn Du 20 Minuten auf das Netztestergebnisse wartest

Der "netztest" hat auch seinen Vorteil:er miesst mit verschiedenen Werten ,dann kann man die beste Kombination in der Box eintragen.

Und was meinst Du, was Du da an Erkenntnissen gewinnen kannst, wenn Du mit geringeren als den max. möglichen werten arbeitest? . Schreiben ist IMMER mit 32k (wenn möglich) am schnellsten. Beim lesen gibts genau 2 Möglichkeiten: bricht das lesen mit 32k ein - NIC auf HDX. Ist das nicht möglich, rsize auf 8192 oder 4096. Thats all! Wirds dann immer noch nicht besser: Einfach mal tcp probieren - das gibt zwar bei den Messungen schlechtere Werte als udp - kann aber in der Praxis den entscheidenden Vorteil bringen.

 

So: Und jetzt hören wir hier auf uns über Vor- und Nachteile der verschiedenen Testmethoden zu unterhalten. Wer Probleme mit den Scripten hat (Newbies ) hat ne Alternative.

 

Jeder nach seinem Geschmack

 

@paulamann:

Premiere hat in den Spitzen auch hin und wieder "echte Spitzen" > 8,9. Die durchschnittliche Datenrate liegt aber trotzdem weit unter dem, was wir uns alle wünschen. Insofern sind Abbrüche nicht wirklich ungwöhnlich.

 

*edit*

@all

Mit dem kcore-Test kann man übrigens auch die Geschwindigkeit per ftp und cifs testen, da der tatsächliche Mount genutzt wird . Alle anderen mir bekannten Testscripts setzen einen NFS-Mount voraus....

*edit-off*

bearbeitet 9. Juli 2006 von guschtav

[Astranase]

Also dieser Thread hat es in sich...

 

Ich habe jetzt etwa 42 Seiten gelesen und bin kein bisschen schlauer (im Gegenteil)

 

Wenn ich alles richtig verstanden habe - korrigiert mich wenn ich falsch liege! - gibt es keine Lösung.

 

Da es schon mit einer Direktverbindung nicht läuft, wird es mit switch, router und Co. sicher nicht besser. (Auch wenn noch hunderte von Messergebnisse gepostet werden.

Mit WindowsXP geht es jedenfalls nicht.

 

Warten wir also auf Vista und hoffen auf Besserung.

 

Wenn einer der OP's mich jetzt bestätigen würde und dann diesen Thread schliessen würde, wäre allen Normalsterblichen geholfen.

[Gast guschtav]

Deine Schlussfolgerung ist zwar falsch - es gibt (fast) immer eine Lösung, aber

ansonsten hast du völlig recht! Der Thread ist schon seit einiger Zeit nicht mehr als Referenz zu gebrauchen. An anderer Stelle - ich weiss jetzt nicht mehr wo - hatte ich die admins/mods mal gebeten zu überlegen, ob nicht ein Unterforum unter "Streaming" Sinn machen könnte.

 

NAS

SFU

Linux-Teile

Streamingserver

 

oder so ähnlich....

 

Gruß

Guschtav

[ion]

192.168.0.100:/Movies on /mnt/record type nfs (rw,v3,rsize=4096,wsize=4096,soft,

udp,nolock,addr=192.168.0.100)

192.168.0.100:/Movies on /mnt/record type nfs (rw,v3,rsize=16384,wsize=8192,soft

,udp,nolock,addr=192.168.0.100)

Warum habe ich,da,immer zwei Eintragungen?

[Gast guschtav]

Weil Du zwei Mounts hast - warum auch immer . Einfach mal Deine Mounteinstellungen auf der Dbox kontrollieren

[ion]

Weil Du zwei Mounts hast - warum auch immer . Einfach mal Deine Mounteinstellungen auf der Dbox kontrollieren

Ja in der Tat.Aber ohne IP-Adresse:

 

 

network_nfs_ip_0=192.168.0.100

network_nfs_ip_1=192.168.0.111

network_nfs_ip_2=

network_nfs_ip_3=

network_nfs_ip_4=

network_nfs_ip_5=

network_nfs_ip_6=

network_nfs_ip_7=

network_nfs_local_dir_0=/mnt/record

network_nfs_local_dir_1=/mnt/filme

network_nfs_local_dir_2=/mnt/filme

network_nfs_local_dir_3=/mnt/record

network_nfs_local_dir_4=

network_nfs_local_dir_5=

network_nfs_local_dir_6=

network_nfs_local_dir_7=

 

 

Wird gelöscht.

[Gast guschtav]

@GSX

Sorry, dass Dein Problem etwas untergegangen ist .

 

Habe jetzt mal den kcore-Test gemacht:

/var # time cat /proc/kcore > /mnt/record/test1

real    1m 4.18s

user    0m 0.29s

sys    0m 13.56s

/var # time cat /mnt/custom/test1 > /dev/null

cat: /mnt/custom/test1: No such file or directory

Command exited with non-zero status 1

real    0m 0.05s

user    0m 0.02s

sys    0m 0.02s

/var #

 

= max. Schreibleistung zwischen 7800 und 7900 Kb/s. Zum lesen, habe ich irgendwo geschrieben, dass ich versehentlich meinen alten Mountpoint hier gepostet habe - natürlich muss man von dort lesen, wo man auch hingeschrieben hat. Sorry nochmal.

 

Ersetze custom mit record.

 

Yepp - so ist es in diesem Fall.

 

So, habs gemacht:

 

/var # time cat /mnt/record/test1 > /dev/null

real 1m 1.96s

user 0m 0.17s

sys 0m 8.04s

 

= max. Leseleistung 8100 - 8200 Kb/s

 

32768, 32768

8192+0 records in

8192+0 records out

real    1m 5.69s

user    0m 0.21s

sys    0m 11.65s

7757

8192+0 records in

8192+0 records out

real    1m 3.27s

user    0m 0.22s

sys    0m 8.44s

8000

192.168.0.20:Aufnahme on /mnt/record type nfs (rw,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.0.20)

 

was auch nix anderes sagt, als kcore . Gut dauerte etwas länger .

 

Fazit: Du verwendest ganz offensichtlich SFU mit WinXP - wie das Zeugs verdrahtet ist, weiss ich nicht (cross-over, Switch, Router, welche NIC im Rechner......DAZU gibts in diesem Mega-Thread sicher die meisten Tipps). Die max. mögliche Schreibleistung die mir unter WinXP mit SFU bekannt ist, liegt bei etwa 8500; Optimierungspotenzial ist also vorhanden. Im derzeitgen Zustand wirst Du mit Streamabbrüchen (nicht immer, aber hin und wieder - insbesondere bei bitstarken Sendern) leben müssen. Empfehlung: Nur die Standardtonspur aufnehmen (Stereo) und AC3 (falls AC3-Junkie ;-))) ) nur bei bitschwachen Sendern (dann aber möglichst auf die weiteren Tonspuren verzichten).

 

Die Leseleistung ist erwartungsgemäß besser (32k wsize) - bleibt aber deutlich hinter dem max. möglichen zurück. Hier gilt sinngemäß dasselbe wie im Absatz vorher bereits erwähnt.

 

Gruß

Guschtav

 

Und: Deine Werte sind nicht wirklich schlecht - es gibt Leute mit weit größeren Problemen

[det-box]

Hallo,

 

habe seit dem Juni Image enorme NetzwerkProbleme bei der Direktaufnahme.

Mir ist bewusst das es nicht direkt mit dem KeyWelt-Image zusammenhängt, sondern

an dem CVS Stand. Einige im forum.tuxbox.org haben auch darüber geklagt.

 

Jetzt wollte ich mich mal an die Netzwerkoptimierung machen.

hier nochein test mit dem April-Image:

 

Results for write throughput:

3.890 Mbit/s with udp,async,wsize=32768

3.314 Mbit/s with tcp,async,wsize=32768

2.825 Mbit/s with tcp,async,wsize=16384

2.606 Mbit/s with tcp,async,wsize=8192

2.508 Mbit/s with udp,async,wsize=8192

2.130 Mbit/s with tcp,async,wsize=4096

1.551 Mbit/s with udp,async,wsize=4096

Failure with udp,async,wsize=16384

 

Results for read throughput:

3.486 Mbit/s with tcp,async,rsize=16384

3.158 Mbit/s with tcp,async,rsize=8192

3.121 Mbit/s with tcp,async,rsize=32768

2.581 Mbit/s with tcp,async,rsize=4096

2.113 Mbit/s with udp,async,rsize=8192

1.877 Mbit/s with udp,async,rsize=16384

1.483 Mbit/s with udp,async,rsize=32768

1.296 Mbit/s with udp,async,rsize=4096

 

ist nicht toll, ging aber.

 

Nun mit dem Juni-Image:

 

Results for write throughput:

8.947 Mbit/s with udp,async,wsize=32768

8.659 Mbit/s with udp,async,wsize=16384

8.134 Mbit/s with udp,async,wsize=8192

6.882 Mbit/s with udp,async,wsize=4096

6.710 Mbit/s with tcp,async,wsize=16384

6.547 Mbit/s with tcp,async,wsize=32768

6.391 Mbit/s with tcp,async,wsize=4096

6.242 Mbit/s with tcp,async,wsize=8192

 

Results for read throughput:

268.435 Mbit/s with udp,async,rsize=8192

268.435 Mbit/s with tcp,async,rsize=8192

134.217 Mbit/s with udp,async,rsize=4096

134.217 Mbit/s with udp,async,rsize=32768

134.217 Mbit/s with udp,async,rsize=16384

134.217 Mbit/s with tcp,async,rsize=4096

134.217 Mbit/s with tcp,async,rsize=32768

134.217 Mbit/s with tcp,async,rsize=16384

 

wer hat solche Werte schonmal gesehen??

 

binn für jede Hilfe dankbar.

 

Det

bearbeitet 10. Juli 2006 von det-box

[Gast guschtav]

Die Werte aus dem April-Image sind ein Joke, oder? Was hast Du denn damit gestreamt; ausser Premiere-Thema ging da sicher gar nix; oder die Werte sind falsch.

 

Die "neuen" habe ich auch schon mal gesehen - da ist ein Supereffekt, wenn man den chicken-test mit zu kleinen Dateien durchführt.

 

Mach den kcore-Test und poste wieder; am besten incl. Deiner Konfiguration (wohin streamst Du, Switch. Router.....).

[det-box]

Hi,

 

habe 64 Mb RAM in der Box, Dateigrösse ca 98MB

 

/var # /tmp/kcore-test.sh

 

berechne die Schreibleistung

real 1m 28.22s

user 0m 0.38s

sys 0m 18.70s

berechne die Leseleistung

Command terminated by signal 2

real 23m 44.98s

user 0m 0.05s

sys 0m 5.84s

 

 

lesen habe ich nach 23 Min mit Ctrl+C abgebrochen

 

Stream-Server ist eine SuSE-Linux (minimal install) und macht nichts anderes.

 

Netzwerk:

habe jetzt die Box und den Server an einem 100er Switch.

 

normaler weise sind meine DBoxen und PrintBox an einem 100er Switch und dieser Switch an einem 100er Switch mit dem Server , FireWall, PC's usw.

 

hier meine auto.net:

record -fstype=nfs,rw,soft,tcp,nolock,rsize=32768,wsize=32768 192.168.23.5:/mnt/rec

 

Aufnahme fängt an .TS Datei dann werden es *.0, *.1 und *.2 Dateien, manchmal kommt auch Aufnahme abgebrochen Daten wurden nicht schnell genug geholt.

 

Wieder gabe eine TS Datei geht gerade so (ein paar ruckler).

habe jetzt die richtigen Werte gefunden vom April:

Results for write throughput:

8.659 Mbit/s with udp,async,wsize=16384

6.391 Mbit/s with tcp,async,wsize=8192

5.478 Mbit/s with udp,async,wsize=8192

4.400 Mbit/s with udp,async,wsize=32768

3.677 Mbit/s with tcp,async,wsize=16384

3.397 Mbit/s with tcp,async,wsize=4096

3.314 Mbit/s with tcp,async,wsize=32768

-e 4067203 with udp,async,wsize=4096

 

Results for read throughput:

7.064 Mbit/s with tcp,async,rsize=8192

7.064 Mbit/s with tcp,async,rsize=4096

5.965 Mbit/s with tcp,async,rsize=16384

5.592 Mbit/s with tcp,async,rsize=32768

.135 Mbit/s with udp,async,rsize=16384

.126 Mbit/s with udp,async,rsize=32768

.114 Mbit/s with udp,async,rsize=8192

-e 105145 with udp,async,rsize=4096

 

Det

bearbeitet 10. Juli 2006 von det-box

[ion]

@2553311

Da es schon mit einer Direktverbindung nicht läuft, wird es mit switch, router und Co. sicher nicht besser. (Auch wenn noch hunderte von Messergebnisse gepostet werden.

Mit WindowsXP geht es jedenfalls nicht.

Das ist NUR deine Meinung mein lieber.

 

 

 

@GSX-R 1000

Ist mein Netz zu lahm? Wollte heute etwas von Premiere Direkt aufnehmen, kurz vor Ende wurde die Aufnahme dann aber in viele kleine .TS Dateien gesplittet.

Bei mir hat es am meisten geholfen in dem ich mir einen 8Port Fiberline Switch besorgt habe.

[Gast guschtav]

@det-box (zum kcore-Test)

Deine Schreibwerte sind absolut in Ordnung! (die Testdatei sollte bei einer Speichererweiterung so um die 95MB groß sein - bei Dir sinds 98MB; keine Ahnung warum).

 

Aufnahmeabbrüche (auf welchem Sender, mit welchen eingestellten Tonoptionen???) auch bei der jetzigen Konfiguration (Dbox und Server am Switch - keine weiteren Switches - keine Firewall mehr dazwischen)??????

 

Stell den SPTS-Modus dauerhaft auf ein - dann wird bei Aufnahmeabbrüchen weiterhin .ts geschrieben.

 

Du mountest TCP statt UDP und ohne den Parameter async; ausserdem steht die NIC Deines Servers offensichtlich nicht auf HDX - deshalb der dramatische Einbruch beim lesen (was Du ja auch in der Praxis an den Rucklern merkst).

 

TCP-Mount machst Du sicher, weil Dir der (alte???) Netztest sagt, dass TCP die besseren Werte bringt, oder?? ICH habe so ein Ergebnis noch nie gesehen - auch dass 16k-Blocksize wesentlich besser sein sollen als 32k ist mir noch nicht untergekommen - aber alles ist irgendwie irgendwann das erste Mal ;-)))

 

Mein Vorschlag an Dich (Dein Netzwerk ist m.E. in Ordnung!):

 

1. Dbox und Linux-Server an einen Switch hängen (ggf. das restliche Netz über diesen Switch anbinden) - was Du ja schon gemacht hast

2. auto.net

record -fstype=nfs,rw,soft,udp,async,nolock,rsize=32768,wsize=32768 192.168.23.5:/mnt/rec

- also udp statt tcp und async ergänzen!

3. NIC des Linux-Servers auf 100HDX (wenn lesen nicht besser 10HDX testen!)

4. sectionsd zur Aufnahme killen

5. umschalten bei Ankündigung aktivieren

 

kcore-Test mit NIC auf 100hdx und 10hdx durchführen.

 

Dein NFS-Server beherrscht 32k-Blocksize?

[det-box]

@guschtav

 

Danke erstmal für Deine empfehlungen.

 

Aufnehmen soll ich SAT1, Verliebt in Berlin. Manchmal einen Trickfilm auf Prem. mit allen Tonoptionen. Trickfilm wird damm eine DVD. Habe das so von Jan-April diesen Jahres gemacht.

 

Hatte jetzt auch mal das JtG-Image drauf, Aufnahme ging nicht.

Und die Aufnahme geht auf allen 3 Boxen so schlecht bis garnicht.

Habe eben novh festgestellt beim LiveView im Browser bricht die Box (alle 3) zusammen, es hilft nur reboot.

 

hier die Werte vom auto.net mit udp und async:

 

/tmp # ./kcore-test.sh

berechne die Schreibleistung

real 1m 48.66s

user 0m 0.28s

sys 0m 20.32s

 

berechne die Leseleistung

real 1h 18m 25s

user 0m 0.23s

sys 0m 24.06s

/tmp #

 

SPTS treiber ist jetzt immer an, sectionsd ist wärend der Aufnahme aus,

umschalten bei Ankündigung war und ist an.

 

Aufnahme läuft gerade, mal sehen!!

 

3Com Karte (3c905b), (ist die NWK im Stream-Server) ist noch auf 100 FD (autonegation).

 

für die 3Com karten umstellung auf HD muss ich erst mal die Quellen installieren um

die Optionen des Kertentreibers lesen zu können.

mach ich auf alle fälle noch

 

evtl komm ich am WE dazu

 

werde dann berichten

 

/Edit

wie war nochmal die Formel zum berechnen der Mb/s ??

(Dateigrösse/zeit*8192=)

und mit welchen Einheiten muss die Bestückt werden??

Danke

Edit/

 

Det

bearbeitet 11. Juli 2006 von det-box

[Gast guschtav]

Hmmmmh - das ist ungewöhnlich! Dein NFS-Server kann 32k-Blocksize???

 

Poste mal die Ausgabe von

 

mount

 

nach einem telnet auf die Dbox.

 

Lesen kannst du natürlich vergessen, wenn die NIC auf AUTO steht - das überrascht ja nicht. Der Schreibwert ist mit udp auch deutlich schlechter als das was du bisher gepostet hast .

 

Die (Einfach-) Berechnung

(Filegröße in MB/Zeit in Sek) x 8192 = Kb/s

 

ein etwas irritierter

Guschtav

[det-box]

@guschtav

 

vor ab erst nochmal par Infos:

have fun with KEYWELT on your Sagem D-BOX2 - Kernel 2.4.32-dbox2 (21:03:05)...

dbox login: root

 

 

BusyBox v1.1.2 (2006.06.24-20:22+0000) Built-in shell (ash)

Enter 'help' for a list of built-in commands.

 

/var # mount

/dev/root on / type squashfs (ro)

none on /dev type devfs (rw)

proc on /proc type proc (rw)

tmpfs on /tmp type ramfs (rw)

/dev/mtdblock/2 on /var type jffs2 (rw)

automount(pid146) on /var/autofs type autofs (rw)

192.168.23.5:/mnt/rec on /mnt/record type nfs (rw,v3,rsize=32768,wsize=32768,soft,udp,nolock,addr=192.168.23.5)

192.168.23.5:/mnt/plug on /mnt/plugins type nfs (ro,v3,rsize=32768,wsize=32768,soft,udp,nolock,addr=192.168.23.5)

/var #

 

wegen der Blocksize: Server ist NFS V4 mit V3 support

 

gestern und heute hat die Aufnahme (Verliebt in Berlin) geklappt

 

wiedergabe(ansehen auf dem FS) ist nicht möglich

 

muss es mir nochmal zur Kontrolle auf dem PC ansehen habe sehrviele ruckler in den

Aufnahmen gesehen.

 

Det

[Gast guschtav]

Sieht gut aus!

 

Stell zur Wiedergabe mal den rsize auf 8192 und wenns nicht besser wird auf 4096 (solange Du nicht auf HDX umstellen kannst).

 

Sollte subjektiv besser werden

[dbox_bastler]

hallo,

habe mal eben die 43 seiten überflogen und

auch sehr viele tests gefahren

meine testumgebung:

dbox nokia mit kalibo, dbox philips mit keywelt image,

SFU auf winXP (PIII 873 MHz mit 512MB RAM, NIC 3C905B),

vigor router, dlink des-1005 switch

 

meine best erzielten werte:

32768,8192

8533

8126

(nic auf 100MBit voll duplex, normalbetrieb über router und switsch)

 

zum ergebniss:

nic einstellungen hatten kaum veränderungen gebracht,

nur bei 10MBit/HD wurden sie schlechter;

dbox und nfs nur am router: schreibwerte schlechter(72xx), lesewerte besser (86xx);

dbox und nfs nur am dlink: schreibwerte besser (86xx), lesewerte etwa gleich;

keine unterschiede zwischen den dboxen selbst;

 

die schreibwerte wurden um ca. 30% schlechter wenn der pc aus irgendeinem grund bei 90% auslastung war - das erklärt auch die orf-aufnahmen-abbrüche (ca. eine von 10),

sonst aufnahme und wiedergabe von ard, zdf und orf ohne probleme;

 

 

zum weiteren testergebniss bräuchte ich mal hilfe

als server diente eine 7020 mit geminis 2.9 nfs-server

schreiben ohne probleme aber lesen ist nicht drin:

32768, 8192

8192+0 records in

8192+0 records out

real 1m 9.52s

user 0m 0.17s

sys 0m 10.96s

7420

dd: /hdd/movie/test: Input/output error

Command exited with non-zero status 1

real 0m 10.53s

user 0m 0.01s

sys 0m 0.01s

51200

192.168.1.210:/hdd/movie on /hdd/movie type nfs (rw,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.1.210)

 

gruß

[Worschter]

@dbox_bastler

 

versuch mal den Test mit der 7020 nen niedrigen Lesewert.

rsize=4096

oder 1024

 

möchte wetten, dann kommaen zwar schlechte aber realistische Werte bei raus.

Ursache dürfte das Halbduplex/Duplex Problem sein.

 

Frag mich nicht genau wie es geht, aber meineswissens kann man bei der Box

im Bios den NIC auf Halbduplex stellen.

Ethtool oder ähnliches geht so weit ich weiß nicht.