Ist euch eigentlich bewusst das auch bei den VUnderboxen Stille herrscht was neue Hardware angeht....warum wohl
Da ist nicht nur bei der HW Stille, auch Softwaretechnisch tut sich da nix mehr 
Beiträge von gr1nd
-
-
touch legt erstmal nur den Inode an, keine Payload. dd if=/dev/zero of=/path/to/testfile bs=1M count=100 ist da aussagekräftiger.
-
Eben genau dieses meine ich. Und da die CPUs in den Boxen immer schneller werden, ist das auch langsam wieder eine Option, zumindest für die Codecs, die der SoC nicht unterstützt.
Dass hw-decoding enabled ffmpeg auch nicht mehr codecs beschleunigt abspielen kann als gstreamer stimmt natürlich und auch, dass es keinen widevine support in ffmpeg gibt. Von daher ist es sehr begrüßenswert, dass DP hier eine eigene DASH Variante gebaut hat.
-
Da stimmt so nicht, das erfordert HW-Support, es geht also nur was die HW eh schon die ganze Zeit auch kann.
Je nachdem, um welches Format es geht und wie schnell die CPU ist, stimmt das so pauschal nicht.
-
Dank Dir! Unter MacOS (10.14) compiliert die qt5 Variante, aber zumindest der gst Teil (1.16.0) läuft nicht rund: das initiale Buffering dauert recht lange und auch dann stockt es. Ich hab zwar weder c++, noch gstreamer Erfahrung, aber vielleicht finde ich ja was. Womöglich liegt es aber gar nicht am Code, sondern an gstreamer selbst
-
Wäre super, wenn du das auf github stellen könntest
-
Code
# dd if=/dev/zero of=foobar bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.0GB) copied, 11.303146 seconds, 90.6MB/sMal CIFS getestet, geht eigentlich auch ganz gut.
-
Hört sich so an als wäre nicht gemounted gewesen und er hat es in das lokale FS geschrieben. Ich selbst mounte auch via fstab um genau sowas möglichst zu vermeiden.
-
Die Zahnräder wurden doch durch andere Spinner getauscht
Das ist aber tatsächlich mega nervig und man kann sich nur mit Workarounds behelfen... Naja, nicht mehr lange
-
Das ganze hier hat mit Software *Entwicklung* recht wenig zu tun, da es um runtime geht. Anstelle deiner unkostruktiven Antwort aus #2 hättest du auch einfach "sehr kurz" den link aus #7 posten können oder ein "Mach die Augen auf, gibt's schon!" und jegliche weitere Diskussion hätte sich erübrigt.
-
Das ist korrekt, falsch ist der Disclaimer deswegen trotzdem nicht. Jetzt haben wir aber beide genug klug geschissen.
-
und dein "Disclaimer" ist eigentlich auch ... falsch ...
Weil?
-
Gut, dann gilt mein Disclaimer von oben
Das hätte man dem TE aber auch höflicher sagen können.
% wget http://www.dreamboxupdate.com/opendreambox/2.6/unstable/r0/dreamone/deb/armv7vehf-neon-vfpv4/lib32-libc6_2.25-r0.2_armhf.deb
--2019-07-06 15:55:37-- http://www.dreamboxupdate.com/opendreambox/2.6/unstable/r0/dreamone/deb/armv7vehf-neon-vfpv4/lib32-libc6_2.25-r0.2_armhf.deb
Auflösen des Hostnamens www.dreamboxupdate.com (www.dreamboxupdate.com)… 82.149.226.170
Verbindungsaufbau zu www.dreamboxupdate.com (www.dreamboxupdate.com)|82.149.226.170|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 840952 (821K) [application/x-debian-package]
Wird in »lib32-libc6_2.25-r0.2_armhf.deb« gespeichert.
lib32-libc6_2.25-r0.2_armhf 100%[========================================>] 821,24K 1,77MB/s in 0,5s
2019-07-06 15:55:38 (1,77 MB/s) - »lib32-libc6_2.25-r0.2_armhf.deb« gespeichert [840952/840952]
% ar x lib32-libc6_2.25-r0.2_armhf.deb
% tar xf data.tar.xz
% file lib32/libc.so.6
lib32/libc.so.6: ELF 32-bit LSB pie executable ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib32/l, for GNU/Linux 3.2.0, stripped
Passt
-
Genau darum geht es doch in diesem Feature Request: Eine 32bit runtime in einem 64bit OS bereitstellen (Loader, Basis libs). Daher kann ich die Dislikes erstrecht nicht verstehen, zumal die genau von den zitierten kommen.
Kodi (oder der player, der für die Wiedergabe aufgerufen wird und gegen den widevine gelinkt sein soll), muss eben in 32bit vorliegen, benötigt dazu alle libs von denen er abhängig ist (mit ldd zu prüfen) auch in 32bit.
-
Vielleicht weil man denkt "32 ist ja alt und böse". Dass es aber noch proprietäre libs nur als 32bit shared object, wie z.B. widevine gibt, wissen sie ggf. nicht.
Aber vielleicht hat ja auch jemand connections zu google und kann ein arm64 widevine organisierenDisclaimer: Habe keine One, daher: Falls libc, ld-linux usw. schon in 32bit vorhanden sind ignoriert meinen Beitrag
-
Alles anzeigen
Ok die Verschlüsselung werden wohl die meisten nicht verwenden die nur lokal ihre Dreambox auf das NAS schreiben lassen.
Das kostet auch Performance.
Ich hatte aber bezüglich NFS V4 was performance anbelangt was anderes gelesen.
In Tests war da eher von einem Vorteil von 15-20 % für NFS V4 zu lesen (ohne Verschlüsselung).
Auch sonst sehe ich nur Vorteil für NFS V4
Wie z.b. das man kein rpcbind mehr braucht (da bin ich beim manuellen mounten auch schon gescheitert bis ich das raus gefunden hatte) , kann UTF-8, das File-locking wurde verbessert (Wenn noch andere z.b. über smb darauf zugreifen. Mache ich oft, das ich was auf dem PC anschaue, auch wenn diese Aufnahme noch läuft.)
Und eben den Performance Vorteil wegen verbessertem caching.
NFS V4 ist einfach komplett runderneuert und kein Flickwerk mehr wie V3.
Alleine schon deshalb wüsste ich nicht weshalb ich auf NFS V4 verzichten sollte, wenn ich schon moderne System im Einsatz habe die das unterstützen.
Und Probleme hatte ich auf der DM900 bisher noch nicht damit, bis auf die erhöhte avarage load bei >= NFS V4.1.
Wobei die höhere avarage load keine CPU Last erzeugte und auch sonst funktionierte.
Aber ein fader Beigeschmack hat das schon hinterlassen, weshalb ich nun einfach V4 verwende.
Zumal ich die Features in >= V4.1 nicht benötige.
Deine Zeilen beweisen, dass du dich vermutlich nie mit Storage Protokollen, SunRPC, Buffer Size, TCP/UDP und der vermeintlicher Mehrperformance auseinandergesetzt hast. NFSv3 ist keinesfalls ein Flickwerk, sondern ein wohldefiniertes Protokoll, mitsamt nfsd, portmapper (rpcbind) und mountd. Ja, es ist Firewall unfreundlich und hat keine ernst zu nehmende Authentifizierung, aber das ist oftmals nicht nötig, insbesondere hier im Heimeinsatz. Der Hauptvorteil von NFSv4 sind ACLs, aber auch diese sind wohl bei einer Box, bei der fast alles als root läuft kaum notwendig.
Das einzige Flickwerk bei klassischem NFSv2/v3 ist der lockd, da der tatsächlich nicht ursprünglich Bestandteil des Protokolls war. Aber mittlerweile funktioniert dieser gut, wenn man weiß was man tut.
Du zitierst irgendwelche Tests und hast keinerlei praktische Erfahrung. Ich nutze NFS seit v2 und kann dir anhand aktuellen Einsatzes mit Netapp und selbstgebauten ZFS Büchsen in sowohl v3 wie auch v4 in 10 und 40 Gbit/s Netzwerken versichern, dass du bei sequentiellem Traffic sogar bei v3 leichte Performance Vorteile hast. Bei IOPS hat v4 leicht die Nase vorn. Beides ist aber nur messbar und zeigt praktisch keinerlei Auswirkung.
Wenn es um Performance geht sollte man sich eher mal Gedanken über die defaults des TCP Stacks sowohl beim Client wie auch beim Server, über Jumbo Frames sowie über die mount Optionen machen.
Wie du auf Verschlüsselung kommst weiß ich nicht, denn der Traffic kann bei NFSv4 nur encrypted werden, wenn getunnelt wird. Dies ist prinzipiell natürlich auch bei v3 möglich. Oder meinst du Krb? Das hat aber nichts mit dem Datenstrom zu tun und daher auch nichts mit der Performance.
Es gibt Gründe, weshalb NFSv4 nach wie vor nicht weit verbreitet ist und die meisten Storage Hersteller dies auch nicht sonderlich propagieren. Aber NFSv4 hat auch vorteile, ACLs habe ich oben schon genannt und dank Statefulness, gibt es z.B seitens VMware ESX deutliche Verbesseurngen wie Storage IO Control, was vorher nicht möglich war.
Systemload hat übrigens nicht zwangsweise etwas mit CPU usage zu tun, sondern auch oft mit IOwait. Evtl rührt dein Problem daher.
-
Ja, definitiv. Man kann auch ruhig auf 256k gehen, es geht hier um die Chunksize bei der Datenübertragung.
Das was hier alles zu NFSv4 geschrieben wurde, möchte ich in Frage stellen. Gerade hier (0815 NAS mit STB, wo kein Kerberos benötigt wird und wohl auch keine Firewalls dazwischen sind) hat dies 0 Vorteile, insbesondere nicht in der Performance, da höherer Overhead. Ich würde immer auf NFSv3 mit TCP gehen. UDP macht nur Sinn, wenn man nur 100Mbit/s hat, dann hat man Teils noch performance Vorteile.
-
Sieht doch schon richtig gut aus!
-
Da wurde aber auch mal was von Dream kommuniziert.
Jetzt kauft man sich irgendwas wo Dreambox draufsteht und kann nicht sicher sein das das alte System dahintersteht und das wirklich alles das läuft was man so gewohnt ist.
Dann kauf dir einfach was von Technisat. Da weißt du dann auch, was du (nicht) bekommst. Dafür ist es dann "stabil".
-
