PeteUnraid

I just updated and it works great. Thanks again man.

Yeah its basically the exact same product anyway. Following guides for pfsense or opnsense works basically the same if you are setting things up and I had no problem changing to opnsense at home. I use pfsense at work still as you can buy support but the products are very close.

Hello. This docker is very nice. Does anyone know how to stop the world and start it again with a new random seed for a new world? Pete

I resolved this problem of cpu not scaling down by using the tweak and scheduling performance at 23:30 and powersave at 23:35. This would mean it switches back down every day even if something changes it.

@SweetPeachez Interesting and good info from testdasi. Maybe as a last test if you have time you could set the <vcpu placement='static'>24</vcpu> <cputune> <vcpupin vcpu='0' cpuset='1-47'/> <vcpupin vcpu='1' cpuset='1-47'/> ... <vcpupin vcpu='24' cpuset='1-47'/> and topology sockets='1' cores='24' threads='1'/> As I would be interested to know how that performed with all the other tweaks you have done, if you have the time. You would have to ensure you didnt run any other VMs while doing the benchmark though. The above does exclude core 0 (for unraid to use). P

This error I googled and it lead me to some people saying they changed the PSU here: mce: [Hardware Error]: CPU 2: Machine Check: 0 Bank 5: bea0000000000108 https://community.amd.com/thread/216084#comment

Oof I guess so, hopefully an update and fix is not far off

My bad, apologies. I should have noticed. Try with all 48 cores pinned as well.

Ok I am wondring as a workaround (I know this isnt normally recommended) he can test by trying to pin every single core (ie pin all 48 cpus) the the VM and not leave any free for unraid at all (and remove any isolation). It might make unraid a bit unhappy under heavy load but at the same time at least give him good scores until the bug is patched and most of the time I would imagine (even in gaming) he would not be maxing every single one of the cores all the time.

Is this relevant to the issue Jerky? https://bugs.launchpad.net/qemu/+bug/1856335 "AMD CPUs have L3 cache per 2, 3 or 4 cores. Currently, TOPOEXT seems to always map Cache ass if it was an 4-Core per CCX CPU, which is incorrect, and costs upwards 30% performance (more realistically 10%) in L3 Cache Layout aware applications." "On a 3-CCX CPU (3960X /w 6 cores and no SMT):" Also found this:

Thats crazy. How does assigning less cpu's and only using the odd cores produce a better result? Somoen would have to explain that to me.

Interesting. his suggestions were quite good so im surprised no improvement from that. The current best config looks like your original, except you have changed machine type and are using 46 cores now... Did you try with 44 cores (unpin cores 0,1,2,3) and see how the performance was? I wold be interested to know if there is actually a noticeable difference between 46 and 44 cores. It appears currently you are getting about 82% of the performance from the VM as opposed to bare metal - would you agree? If you can confirm exactly where we are I will go away and try to think of what other improvements could be tried and come back to you P

With that latest xml you just posted - is that giving you the 10089 score?

With the performance comparison... 10089 on VM compared to 12950 on baremetal. 12950 is 48 cores so an equivalent is 12950/48*44= 11870. So you are comparing 10089 to 11870 - this is 85% of the speed of baremetal, so we are getting closer. Can we get a new xml with the fastest speeds you were getting so we can review and tweak from there? The suggestions by testdasi and Jerky both sound good but should be tested at seperate times from each other. P EditL just saw you posted one while I wrote this, also the cores are now 46 so feel free to update the values as per what you are now using.

I solved this by downloading the ca user scripts plugin and adding this script to achieve what I wanted: #!/bin/bash ip route add 192.168.3.0/24 dev br0 echo 1 > /sys/kernel/mm/ksm/run