NFS bei den Atom Qnaps

    Hallo allerseits.


    Ich hätte da mal ne kleine Frage, bei der mir vielleicht einer der glücklichen Besitzer einer Atom basierten QNAP helfen kann.


    Im Moment habe ich eine 209II Pro, die ich aus verschiendensten Gründen gegen etwas schnelleres tauschen will.
    Einer der Gründe ist die miese NFS Performance.
    Die Qnap bietet einige NFS Freigaben, die über ein PowerLAN im Wohnzimmer von einem WDTV eingebunden werden.
    Die Geschwindigkeit liegt jedoch bei max. 1,7 MB/s via NFS und via SMB deutlich darunter. Zuerst dachte ich dass das PowerLAN halt nicht mehr hergibt, aber dann hatte
    vor einigen Wochen testweise eine Synology 209+ zuhause, welche über obige Konfiguration dann mal eben 4MB/s liefert per NFS, was mir vollkommen auch für HD Material ausreichen würden.


    Langer Rede kurzer Sinn, nun die Frage:
    Was für eine Max. Blocksize unterstützen die Atom Qnaps (speziell die SS439 und die TS439)?
    Auch nur 8K wie die 209Pro?
    Okay wenn wir schon dabei sind, wie siehts mit den x19 Geräten aus?


    Danke


    LG
    --Alex

    Hallo Alex,


    nur so am Rande die DS209+ hat mal eben 60% mehr Leistung in Hinsicht auf die CPU. Zur Nutzung von NFS via PowerLan kann ich nichts beitragen.


    Grüße
    Christian

    Zitat von "christian"

    Hallo Alex,


    nur so am Rande die DS209+ hat mal eben 60% mehr Leistung in Hinsicht auf die CPU. Zur Nutzung von NFS via PowerLan kann ich nichts beitragen.


    Grüße
    Christian


    Hallo Christian.


    Da die Sache mit den hohen 12,5er 2,5" Platten nicht geklärt ist, habe ich mir kurzerhand jetzt eine TS-439pro anstatt einer SS gegönnt.


    Du hast vollkommen recht, dass die Synology mehr Power hat, aber das ist hier wohl nicht entscheidend, DENN, die 439er liefert auch nicht mehr, zumindest nicht wenn man die Shares per UDP mountet. 1,7 MB/s das wars.


    Nach etwas Tuning komme ich jetzt aber auf fast das Doppelte. Ich mounte die NFS-Freigaben nun per TCP auf meinem WD-TV.
    Warum auch immer TCP schneller ist als UDP verstehe wer will. Auch ein Gegentest mit meinem MAC-Book hat das bestätigt.


    Was aber auch an der 439 genauso "schäbig" ist, wie an meiner alten 209II Pro ist, dass die Blocksize immer noch nur 8K beim NFS-Server ist.
    Ich finde das für ein Gerät aus der Profiklasse von QNAP nicht zeitgemäß.


    Hast Du ne Ahnung warum das so ist?


    Gruß
    --Alex

    ..hmmm - merkwürdig



    Ich habe eine 109Pro für 2 WD-TVs (und 2 Dreams) am laufen. Die Leseleistung des WD-TV liegt bei 5MByte/s (udp und 8k-Blocksize; tcp ist 1Mbyte/s langsamer; am WD-TV verwende ich den WII-USB-LAN-Adapter; der Belkin Gbit ist geringfügung schneller).


    Ich gehe nicht davon aus, dass die 209er sich bei diesem Stunt anders verhält als die 109er.


    Ich vermute bei Dir das Problem im DLAN....auch wenn die Synology damit offensichtlich besser zurecht kommt (vielleicht war das aber auch nur Zufall?).


    Anmerkung: Die Kastration der Blockgröße auf 8k ist auch für mich völlig unverständlich. Wurde hier im Forum bereits an anderer Stelle diskutiert...


    *edit: Schreibfehler berichtigt...

    Einmal editiert, zuletzt von Anonymous ()


    Ja sicher, das DLAN limitiert mich bei max. 4,5MB/s, wenn das MacBook dranhängt. Warum die Syno-Box schneller ist/war vestehe ich auch net so recht, vorallem, weil die per UDP schneller war als bei TCP, so wie das eigentlich auch sein soll :-). Die Differenz die nun zwischen den beiden (Syno/439pro) besteht, kann dann wohl noch auf die Blocksize zurückzuführen sein
    Verstehe das wer will ...


    Zitat von "rolano"


    Anmerkung: Die Kastration der Blockgröße auf 8k ist auch für mich völlig unverständlich. Wurde hier im Forum bereits an anderer Stelle diskutiert...

    hallo allerseits


    nachdem ich das thema schon länger verfolgt habe (was ja in diversen threads öfters diskutiert wurde), möchte ich auch mal meinen senf dazu geben :D


    soweit ich mal gelesen habe, muss das anscheinend im kernel spezifiziert werden. und werte über 8192 verursachen kompatibilitätsprobleme mit manchen clients gemäss qnap (z.b. tvix multimedia player).


    zur performance: genauso wie auch bei jumbo frames kann man auch bei nfs nicht generell sagen dass ein höherer wert eine bessere leistung erzielt. natürlich kann es deutlich besser sein, aber es hängt sehr stark von diversen faktoren wie dem lokalen netz als auch davon was man genau kopiert ab. 8192 liefert im schnitt werte die durchaus "ok" sind.


    ich verstehe zwar den unmut dass man es nicht höher einstellen kann, aber es ist anscheinend nicht grundlos so und ehrlich gesagt auch nicht sooo tragisch. denn es kann definitiv KEIN problem sein beim streaming.


    ich habe mal testweise eine nfs share eines TS-209 auf einem 509 eingebunden. die geräte sind nur mit 100 mbps ethernet angebunden. egal ob tcp oder udp, der durchsatz liegt bei rund 7 mbyte/s (56 mbps). das reicht auch für HD videos mehr als locker!


    wenn ich den 509 per nfs auf nem pc einbinde, ebenfalls nur 100 mbps, erhalte ich rund 10 mbyte/s netto. das entspricht in etwa dem maximum was auf einem 100er netz in der regel möglich ist.


    wenn ich den 509 per nfs auf einem TS-119 einbinde (womit der speed durch letzteren limitiert wird), diesmal per gigabit ethernet, komme ich auf rund 27 mbyte/s (216 mbps). der TS-509 an sich (und auch der TS-439) würde natürlich locker das doppelte erreichen wenn nicht mehr. das problem kann imho also nicht beim TS liegen.


    powerline ist genauso wie wireless kein zuverlässiges medium und es kann unter umständen schon reichen dass du den lichtschalter betätigst oder irgend ein anderes gerät einschaltet und schon hast du nur die hälfte der geschwindigkeit. ebenso kann das ergebniss beeinflusst werden wenn du noch einen weiteren powerline client im netz hast. du müsstest also schon über eine längere zeit mal tests machen (und unter 100% gleichen bedingungen bei einem vergleich) um ein aussagekräftiges ergebnis zu erhalten.


    apropos: bist du sicher dass das synology gerät einen höheren wert als 8192 unterstützt? ich konnte leider keine info dazu finden.

    Zitat von "IamQ"

    soweit ich mal gelesen habe, muss das anscheinend im kernel spezifiziert werden.

    Richtig. Konkret ist das die Kernelkonstante NFSSVC_MAXBLKSIZE .


    Zitat

    und werte über 8192 verursachen kompatibilitätsprobleme mit manchen clients gemäss qnap (z.b. tvix multimedia player).

    ..manche Netzwerkkomponenten vertragen auch keine 8k 8-) . Ist das aber ein Grund für eine unnötige Bremse? Ich denke nicht.


    Zitat

    zur performance: genauso wie auch bei jumbo frames kann man auch bei nfs nicht generell sagen dass ein höherer wert eine bessere leistung erzielt.

    Richtig. Generelle Aussagen gibt es da nie; deswegen lassen sich solche Parameter ja auch Clientseitig durch die Optionen beeinflussen. So gut wie alle mir bekannten NFS-Server arbeiten (ohne spezifische Angaben) mit 8k r-/wsize, eben weil dies die "ungefährlichste" Einstellung ist.


    Zitat

    natürlich kann es deutlich besser sein, aber es hängt sehr stark von diversen faktoren wie dem lokalen netz als auch davon was man genau kopiert ab. 8192 liefert im schnitt werte die durchaus "ok" sind.

    genauso ist es - deshalb muss man höhere (oder ggf. niedrigere) Werte testen.
    Wenn man sein System tunen möchte, dann weiß man doch (in der Regel) was man tut, oder? :D .


    Zitat

    denn es kann definitiv KEIN problem sein beim streaming.

    Gewagte Aussage :) . Gerade bei Clienten, die sich grenzwertig im Netzwerk verhalten (krasses Beispiel: DBox2) entscheidet die Blockgröße - neben einigen anderen Besonderheiten - über wohl und wehe ;) .


    Dass man bei den "alten" Kisten auch in Zukunft auf höhere Blockgrößen wird verzichen müssen - damit habe ich mich abgefunden. Für die aktuellen bleibt die Kastration (wenn sie denn tatsächlich vorhanden ist) zumindest für mich völlig unverständlich. Einen sachlichen Grund dafür kann ich jedenfalls nicht erkennen; QNAP verzichtet ja auch nicht auf Jumbo-Frames nur weil die auch mal zu Problemen führen können ;).


    Keine Ahnung warum ich mich gerade bei dem Thema "NFS bei QNAP" so "ereifere" :D ; wie Du richtig erkannt hast, sind die Auswirkungen in der Praxis eher marginal. Leider treten sie genau dann in den Fokus, wenn es bei bestimmten Clienten um ein paar Mbit/s hin oder her geht.....

    Zitat

    Für die aktuellen bleibt die Kastration (wenn sie denn tatsächlich vorhanden ist) zumindest für mich völlig unverständlich. Einen sachlichen Grund dafür kann ich jedenfalls nicht erkennen; QNAP verzichtet ja auch nicht auf Jumbo-Frames nur weil die auch mal zu Problemen führen können ;)


    keine ahnung... ich werd mal nachfragen ;) blöde frage zu meinem verständnis: wenn qnap die maximalgrösse erhöht, funktionieren alle niedrigeren werte auch noch? weil soweit ich es verstanden habe, hat qnap es auf standard 8192 gelassen weil es sonst nicht mehr funktioniert hätte mit clients die darauf beschränkt sind. aber vielleicht habe ich (oder qnap) da was falsch verstanden.


    Zitat

    Gerade bei Clienten, die sich grenzwertig im Netzwerk verhalten (krasses Beispiel: DBox2) entscheidet die Blockgröße - neben einigen anderen Besonderheiten - über wohl und wehe


    dann ist der client aber nicht gerade sehr doll :mrgreen: nein scherz beiseite, ich versteh schon was du meinst. ist halt für diesen spezifischen fall wichtig.


    aber dennoch möchte ich festhalten dass die NFS performance für generelle verwendungszwecke ja durchaus gut ist. weil wenn jemand diesen thread liest, dann könnte er dein eindruck erhalten der TS-439 liefert generell nur 1.7 MByte/s oder so... weil die aussage der nfs durchsatz sei schlecht, wurde sehr generell gemacht. und das wär ja definitiv falsch ;)



    EDIT:

    Zitat

    (wenn sie denn tatsächlich vorhanden ist)


    ähm ich hab's bisher ehrlich gesagt noch gar nicht getestet mit höheren werten :mrgreen:


    aber scheint zu gehen!! zwischen TS-119 und TS-509 zumindest:

    Zitat

    [/share/Public] # mount
    ..
    ..
    192.168.2.77:Public on /mnt/test type nfs (rw,udp,rsize=32768,wsize=32768,addr=192.168.2.77)


    korrekt?


    allerdings unterscheidet sich die transferrate kaum.

    Zitat von "IamQ"

    frage zu meinem verständnis: wenn qnap die maximalgrösse erhöht, funktionieren alle niedrigeren werte auch noch?

    Selbstverständlich. Du kannst das selbst testen, indem Du beim Client z.B. rsize=4096 mitgibst und Deine Mounts dann über die Console kontrollierst. Selbstverständlich kann man rsize und wsize auch mit unterschiedlichen Werten belegen...sie müssen grundsätzlich durch 1024 teilbar sein. Die DBOX z.B. versteht nur 4096, 8192, 16384 und 32768. Bei Werten dazwischen wird automatisch der nächst niedrigere zulässige genommen.


    Zitat

    weil die aussage der nfs durchsatz sei schlecht, wurde sehr generell gemacht. und das wär ja definitiv falsch ;)

    Richtig - eine generelle Aussage in dieser Richtung IST falsch. ;) .



    Zitat


    [/share/Public] # mount
    ..
    ..
    192.168.2.77:Public on /mnt/test type nfs (rw,udp,rsize=32768,wsize=32768,addr=192.168.2.77)


    korrekt?


    Korrekt :D

    hmm ich hab mal ne TS-209 share gemountet.... und auch da klappt es mit 32768 soweit ich das beurteilen kann...


    Code
    [/mnt] # mount -o udp,rsize=32768,wsize=32768 192.10.30.107:Public /mnt/test3
[/mnt] # mount
..
..
192.10.30.107:Public on /mnt/test3 type nfs (rw,udp,rsize=32768,wsize=32768,addr=192.10.30.107)


    :?:

    interessant - ich habe keine 209er mehr. Evtl. hat QNAP ja still und heimlich in der aktuellsten FW nachgebessert?


    Meine für das Streaming zuständige 109er habe ich seit Monaten nicht mehr angefasst; vielleicht sollte ich mal auf die 3-er aktualisieren um zu schauen, ob sich da tatsächlich was bewegt hat. :)


    s.a. dieser Thread: http://forum.qnapclub.de/viewtopic.php?f=35&t=1764


    Zu blöd, wenn QNAP das "repariert" hätte und keiner kriegts mit..... :D

    Zitat

    Meine für das Streaming zuständige 109er habe ich seit Monaten nicht mehr angefasst; vielleicht sollte ich mal auf die 3-er aktualisieren um zu schauen, ob sich da tatsächlich was bewegt hat


    ich bitte darum :) das würd mich jetzt doch sehr interessieren


    edit:
    so ich hab noch einen TS-109 Pro in ner ecke meines büros gefunden :mrgreen:


    auch hier scheint es zu klappen

    Code
    [/mnt] # mount -o udp,rsize=32768,wsize=32768 192.10.30.68:Public /mnt/test4
[/mnt] # mount
..
192.10.30.68:Public on /mnt/test4 type nfs (rw,udp,rsize=32768,wsize=32768,addr=192.10.30.68)


    gibt es noch eine andere methode um zu prüfen ob der wert wirklich auf 32768 ist?

    ich habe bei qnap nach einer info gefragt, da mir einige dinge nicht klar sind. habe aber noch keine antwort.


    wie auch immer, ich habe im englischen forum gerade eine sehr interessante info gefunden!


    von http://forum.qnap.com/viewtopi…7&t=11727&start=10#p86932:


    klingt gut und könnte vielleicht auch in anderen fällen helfen :)


    FYI: unfs = http://unfs3.sourceforge.net/

    ..danke für den Link - die Erkenntnis dort spricht gegen ALLE Theorien; man ist aber nie zu alt, sich auch mal überraschen zu lassen. Ich werde das bei Gelegenheit wohl mal testen :thumb: .


    @Q
    ..ich habe zwar immer noch keine 3er-FW auf der 109 :oops: , aber andersrum gehts ja auch:


    Code
    mount -t nfs -o rw,udp,async,nolock,rsize=32768,wsize=32768 192.168.0.16:/Qmultimedia /share/HDA_DATA/Public/movie/test


Die Ausgabe von 'mount'
192.168.0.16:/Qmultimedia on /share/HDA_DATA/Public/movie/test type nfs (rw,udp,nolock,rsize=32768,wsize=32768,addr=192.168.0.16)


    hier spielt die 409er Server und die 109er Client. Mit einer Dream-Box bekomme ich die 409er ebenfalls nicht mit > 8k gemountet.....Geschwindigkeitstechnisch habe ich da nix gemessen-wollte bloß Deine, mich irritierende mount-Ausgabe nachvollziehen können. Eh voila...irgendwas ist das "komisch".....


    We stay tuned

    Zitat von "alexfauss"


    Du hast vollkommen recht, dass die Synology mehr Power hat, aber das ist hier wohl nicht entscheidend, DENN, die 439er liefert auch nicht mehr, zumindest nicht wenn man die Shares per UDP mountet. 1,7 MB/s das wars.


    Nach etwas Tuning komme ich jetzt aber auf fast das Doppelte. Ich mounte die NFS-Freigaben nun per TCP auf meinem WD-TV.
    Warum auch immer TCP schneller ist als UDP verstehe wer will.


    Ich tippe, dass bei der Übertragung per UDP über PowerLine das ein oder andere Datagramm verloren geht und da hier nicht das Protokoll für die Sicherung der Verbindung zuständig ist sondern die Anwendung (NFS) wirds das wahrscheinlich sein.


    Siehe auch Wikipedia:

    Zitat

    UDP stellt einen verbindungslosen, nicht-zuverlässigen Übertragungsdienst bereit. Das bedeutet, es gibt keine Garantie, dass ein einmal gesendetes Paket auch ankommt, dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden, oder dass ein Paket nur einmal beim Empfänger eintrifft. Eine Anwendung, die UDP nutzt, muss daher gegenüber verlorengegangenen und unsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmaßnahmen beinhalten.


    Daher ist NFS über UDP und PowerLine eventuell nicht so super geeignet, da es bei Dateiübertragung und Zugriff schon so sein sollte, dass die ganze Datei richtig ankommt... ;)


    Jan

    http://forum.qnap.com/viewtopic.php?f=35&t=777&start=20 ff. gibt's installations- und konfigurationshilfe


    unter gewissen umständen verdoppelt sich die geschwindigkeit gegenüber dem integriertem nfs server! 8-) es kann aber natürlich auch sein dass es etwa aufs selbe rauskommt, hängt von diversen faktoren ab. und fragt mich nicht welche dies sind, weil ich weiss es nicht :mrgreen:


    ich hatte ja auf dem 209 bereits vorher eine relativ gute nfs performance mit 7 MByte/s in nem 100mbps netz. nach dem wechsel auf unfs ist die geschwindigkeit praktisch identisch.


    aber bolle der vorher nur rund 4 mbyte/s erreichte, kommt mit unfs auf 8!

    Also ich kriege es auf meiner Kiste (119) nicht gebacken. Er meldet zwar einen Erfolg beim installieren, aber wenn ich /etc/init.d/unfs3 start aufrufe findet er die Datei nicht (und sie ist auch tatsächlich nicht in dem genannten Verzeichnis) :shock:

    a) weil der NFS-Server der 119 eine lahme Gurke ist (ich habe mit SMB einen höheren Durchsatz und das kann es nicht sein)
    b) nein, es gibt ein extra Paket für ARM/Marvell