Beim x264 Benchmark hattest du mir mal eine 100 Frames Testdatei gegeben, damit ich vorab etwas testen kann und auch Ergebnisse habe, um zu vergleichen.
Wäre das hier auch möglich? 100 Frames wären eindeutig zu viel, vielleicht 10 Frames, damit hat der ja auch bereits etwas länger zu tun. Kleiner Lasttest wäre es auch.
Ich habe mir grade Bier #3 aufgerissen. In diesem Kontext möchte ich folgendes sagen: Klar, möglich ist das. Möglich ist viel. Aber der x265 Bench hat stark verschärfte Verifikationsroutinen, was derlei Dinge schwieriger macht.
Ich denke es müßte gehen, indem man das Inputvideo ersetzt und ein --rehash (bzw. /r, /R oder -r) ausführt. Das Inputvideo sollte aber wohl nicht rekodiert werden. Man müßte es an einem I-Frame abschneiden, was bedeuten würde, das ich die exakte Frameanzahl nicht voraussagen kann.
PS1: Ein Rekodieren ist sehr wohl möglich, aber mehr Arbeit. Mehr Arbeit ist böse. Man könnte sagen, ein Werk des Teufels! Das ist unter nahezu allen Umständen zu meiden!
PS2: Ich saufe jetzt mein Bier, schau Anime, und präpariere heute sicher keine Lösung mehr für dich! So schaut's aus! 
Kein Problem. Will dir dein Wochenende ja nicht vermiesen 
Erste Indikation: Um die 12% schneller mit einer M.2 NVMe SSD über den USB3-Port.
Aber der USB3-Port ist nur mit 4 Gbit/s angebunden beim RPi4B. Auf dem CM4 IO Board gibt es einen PCIe x1 Slot, der mit 5 Gbit/s angebunden ist.
Wenn ich mir mal ein 8GB CM4 hole, wird das auch getestet. Aber dafür habe ich aktuell keine sonstige Verwendung. Dafür sind 70€ dann doch etwas teuer 
Ja, das Teil nutzt UASP. Das hatte ich im Vorfeld schon geprüft.
Ich werde da wohl mal vorab ein paar kleine Messungen bzgl. Durchsatz machen. Dafür brauche ich ja keine 8GB.
Beim RPi4B hängt der USB-Controller an der einen PCIe-Lane, beim CM4 ist die PCIe-Lane direkt so nutzbar.
Ich gehe aber auch nicht von einem enormen Performancegewinn aus, aber vielleicht reicht es ja für die Sub-100h-Marke. Den Rest regelt der Takt dann.
In den nächsten Monaten wird auf Debian 11 gewechselt. Habe ja die leise Hoffnung, dass man auch etwas Leine lässt in Sachen maximaler Takt. Hoffung und zuletzt sterben und so.
Wenn das mit meinem Urlaub in knapp 2 Monaten zusammenfällt, wird das noch mal spannend.
Also so richtig funktioniert hat es mit Bash nicht.
1.5 GHz und M.2 NMVe SSD via USB3: 103h 01m 05s it is.
Es folgt 2.35 GHz und M.2 NVME SSD via USB3.
Wollen wir mal hoffen, dass es stabil ist.
Edit: 2.35 GHz ist nach 10,5% von Pass 1 gecrasht. Mal sehen, was 2.3 GHz so bringt.
0075:31:06.000 | Chosen_One | 1/4/4 | Broadcom BCM2711B0 (ARM Cortex-A72) @ 2.3 GHz | 8 GB LPDDR4-3200 | Raspberry Pi 4 Model B Rev. 1.4 | Raspberry Pi OS 10.9 (5.10.17-v8+) AArch64
Bitte bei all meinen Ergebnissen mit dem 8GB RPi4B die Revision auf 1.4 setzen, auch bei x264.
Den 8GB gab es nur als 1.4.
50% mehr Takt und 25% mehr Leistung. Ganz grob.
Demnächst folgt noch ein Lauf mit einem ARM64 Windows und dann sollte ich fertig sein 
Und mal sehen, was der Vergleich RPi4B vs. CM4 und SDHC vs. SSD so bringt.
Übertakten von der CPU bringt auf jeden Fall mehr Durchsatz.
habe auch fertig:)
bin gerade per remote auf meinem rechner, trage den Rest dann nach
PPT: 88W
ansonsten das gleiche system wie bei dem x264 test
GokuSS4 | 1/8/16 | AMD Ryzen 7 5800X @88W PPT | Asus TUF B450M-PRO GAMING| 32GB DDR4-3800 16-17-16-33-49-1T | Windows 10 v1809 17763.1999
TimeThis : Elapsed Time : 03:15:21.526
04:34:13.106 | RaVeNsClaw | 1/6/12 | AMD Ryzen 5 5600X 3.70GHz | 32GiB DDR4/3200 16-18-18-38-1T | Gigabyte X470 Aorus Ultra Gaming | X470 | Windows 10 20H2
Hm, da hatte ich mehr erwartet. Gerade 14 Minuten schneller als der 2700X und das bei schnelleren RAM Timings.
Ich muss mir mal die BIOS Einstellungen genauer anschauen.
@GAT: Was bedeutet das "w. PBO" bei deinem Ergebnis?
Ist drin GokuSS4 , jetzt weiß ich auch Mal, was für eine Windows 10 Edition & Version das genau ist
RaVeNsClaw : Hier war das System per AMD Precision Boost Overdrive Version 2 (also "PBO", v2) gut getuned. Das Feature verletzt die Garantiebedingungen, aber seit Zen 3 - glaube ich - ist es in Version 2 im UEFI verfügbar, sofern man eine AGESA Firmware hat, die für PBO2 neu genug ist. Damit lassen sich u.a. die hirnlos hohen Standardspannungen von AMD für den Betrieb unter voller Last reduzieren, was für durchgehend höher gehaltenen Boosttakt sorgt. Hauptverantwortlich für all meine Tweaks am Ryzen 5 5600X zeichnet sich 666psycho, der mich hier auf VA erstmals auf die Probleme der CPUs hingewiesen hatte.
Im Prinzip brauchst nur die Spannungen zu reduzieren, weil der Chip seine Taktziele auch ohne irre >1.4V(Core) schafft. Damit senkst du den Energiebedarf der CPU beträchtlich, was dazu führt, daß es zu keinerlei Power Throttling mehr kommt. Das Resultat? Weniger Hitze, weniger Verbrauch, mehr Leistung. Wie bei der Radeon, so auch beim Zen: Unterspannung ist hier der Weg zum Ziel. Und bei mir ist das besonders zu beachten, weil hier sitzt die CPU in einem Mini-ITX System mit nicht mehr als einem Dual-Fan Noctua NH-L12S drauf.
Davor hatte ich auch weit schlechtere Ergebnisse.
Ok, danke für die Aufklärung. 
Ich habe die CPU heute erst bekommen und noch keine weiteren Einstellungen außer dem RAM und der Lüfterkurve gemacht.
Und ja, HWInfo64 hat mir auch schon Kernspannungen über 1,4V ausgespuckt. Da muss ich mal etwas am Spannungsoffset schrauben...
Also die SSD über NVMe angebunden macht doch was her...
hdparm
sudo hdparm -t /dev/<device>
dd write
sudo dd if=/dev/zero of=/home/pi/test bs=8k count=50k conv=fsync; sudo rm -f /home/pi/test
iozone (v3.492)
iozone -e -I -a -s 100M -r 4k -i 0 -i 1 -i 2
14:12:02.712 | Maniac81 | 1/4/8 | Intel Core i5 8259U | Chuwi Corebook X | Intel Coffey Lake-U/Y | 16GB DDR-IV/2400 17-17-17-39 | Windows 10 Enterprise 21H1
Jetzt hat der kleine 16GB Ram und musste sich gleich mal durch den x265 als Stabilitätstest quälen.
14:21:45.409 | Hutzeputz | 2/6/6 | AMD Opteron 8439 SE | 32GB PC2-6400R ECC reg. RAM | MSI K9ND Speedster2 | MS-9661-nForce Pro 3600 rev A2 | Windows 7 Ultimate
War mal interessater Test... im vergleich zu Windows 10
Danke, ist drin.
Kurzes Gemecker: Kerne/Threads sind pro Sockel gemeint. Ich weiß, es verwirrt, aber das wären 2/6/6. Aber ist nicht gaaanz so wichtig, solange eine RESULTS.txt da ist.
Danke, ist drin.
Kurzes Gemecker: Kerne/Threads sind pro Sockel gemeint. Ich weiß, es verwirrt, aber das wären 2/6/6. Aber ist nicht gaaanz so wichtig, solange eine RESULTS.txt da ist.
Versteh ich gut was du meinst-... das war copyandpast aus einer vergangen Antwort... meine Hoffnung war: so wirds am ehensten passen 
