NFS langsamer als CIFS

  • 1) Wenn nicht gerade total viel anderes Zeug das Traffic verbraucht aktiv ist, dürfte QoS keinen Unterschied machen
    2) IGMP ist ein Routing-Protokoll... Das kann nichts mit der Übertragungsgeschwindigkeit zu tun haben, außer Du musst zwischendurch das Routing zum NAS anpassen, weil mehrere Router zwischen den Standorten von Dreambox und NAS sind und diese während der Übertragung umkonfiguriert werden oder ausfallen....
    3) Flow Control ist seit Full Duplex eh an. Und falls Du die TCP Flow-Control meinst, dann ist die auch immer an. Davon ab solltest Du im lokalen Netzwerk statt tcp eher udp für NFS mounts benutzen.


    Irgendwie haben ALLE Deiner Punkte gar nichts mit dem Problem zu tun. Du wirfst da anscheinend mit Begriffen um Dich, die zwar toll klingen, aber eher rumdoktern an der falschen Stelle sind.


    Dass NFS seit Ewigkeiten async kann, weisst Du aber schon, oder?

  • der output von einem simplen cat /proc/mounts wäre sinnvoller als die ganzen urbanen Legenden

    Einmal editiert, zuletzt von Lost in Translation ()

  • Und genau mit der Ausgabe von /proc/mounts fängt der erste von mir gepostete Link an... dann werden die darin enthaltenen Werte erklärt und danach geht es mit Sachen weiter, die nicht in der Ausgabe stehen. Bspw. MTU Anpassung usw. Jumbo Frames beschleunigen die Übertragung im lokalen Netzwerk ja zweifellos, davon sieht man aber in /proc/mounts gar nichts. Genausowenig wie von der socket queue. Was daran jetzt Urban Legend ist verstehe ich zwar nicht ganz, aber Du kannst ihm die Ausgabe von /proc/mounts auch gern manuell auseinander nehmen, statt auf einen Link zu verweisen, der genau das erklärt ;P

  • Er hat ja gesagt er hat noch herumgebastelt und jetzt ist es deutlich besser, wenn dann will ich eben die mount parameter von jetzt, und cat /proc/mounts zeigt auch die die du gar nicht eingestellt hast im unterschied zu irgendwelchen config files.

  • Ein kurzer Test mit dm920 als NFS server und Linux PC mit ubuntu 18.04 als client bringt bei mir 67 MByte/s als Lesegeschwindigkeit.
    Die Platte an der DM920 ist bei mir via USB 3 angeschlossen.


    grep '^dm920:' /proc/mounts
    dm920:/media/hdd /vol/dm920 nfs4 rw,relatime,vers=4.1,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=30,retrans=2,sec=sys,clientaddr=192.168.0.2,local_lock=none,addr=192.168.0.3 0 0


    Das gleichzeitige Aufzeichnen von 8 UHD-streams a 25 MBit/s bringen nur 200 MBit/s Datenrate, weit entfernt von den Möglichkeiten der DM9x0, auch mit dem langsameren Protokoll.

  • ...Irgendwie haben ALLE Deiner Punkte gar nichts mit dem Problem zu tun. Du wirfst da anscheinend mit Begriffen um Dich, die zwar toll klingen, aber eher rumdoktern an der falschen Stelle sind.


    Dass NFS seit Ewigkeiten async kann, weisst Du aber schon, oder?


    Ich weiß Maluhi, eigentlich dürfte das alles nicht viel ausmachen. Aber in ewigen Testreihen habe ich festgestellt, dass die o.g. Einstellungen wirklich noch das letzte Quentchen an Performance Bringen. Bei Flow Control werden durch Pause-Frames "Staus" aufm Netz verhindert. Durch IGMP-Snooping wird bei Multicast Traffic verhindert, weil Gruppen gebildet werden.


    Und ja NFS kann schon ewig async, deswegen war es ja bisher immer schneller. Nur nun kann auch CIFS async-io, weswegen nun das auch schneller ist.


    Aber ich beende jetzt den Thread, weil ihr nicht versteht, was ich ich eigentlich wollte. Vielleich habe ich mich auch unklar ausgedrückt. Auf jeden fall sind eure Antworten alle komplett am Thema vorbei. Ich wollte von euch VergleichsWerte haben, damit ich weiß, ob irgendwo hier noch ein Problem im Netz liegt, oder ob alles Normal ist.
    Nur Post 15 von Swiss-Mad war wirklich hilfreich.



    Ryker

    DM920UHD (seit 09.04.2019): 500GB SSD intern + QNAP extern, DVB-C FBC-Tuner