Improving Windows VM performance for gaming


Recommended Posts

I am running a Windows VM, which I use for simple windows stuff as well as a gaming machine to gamestream from my Unraid server to light-devices in other rooms. I play both windows games (Forza Horizon) as well as dolphin emulator games (all streamed from my VM to devices across the house). My specs are as follows:

 

i7 7800X @ 3.5GHz (no OC)

32GB ram

A bunch of 10TB disks in an Unraid array

128GB Plextor M6E as cache drive (used for docker containers)

1TB Samsung NVME (hosting the VM, not barebone)

Nvidia 1060TI with 6GB ram

 

I have assigned 5C/5T, 16GB, and the Nvidia GPU (passthrough) to the VM. I have not done any CPU isolation and pinning.

 

Docker and Unraid performance seems flawless. Gaming performance is good, but not perfect. I am aiming for 1080p/60fp. Particularly emulator games (dolphin) face occasional stutters or low frame rates. I am thinking of ways how to improve?

 

* Upgrade CPU or GPU or add/assign additional ram?

 

* Do something around CPU pinning or isolation? Would need recommendation on settings

 

* Passthrough my NVME barebone and install the VM on it directly? Would need advice whether recommended to do on a live VM or need to start from scratch

 

* Any other ideas to improve performance

 

Thanks in advance for your help! Your setups and use cases seem very similar.

  • Like 1
Link to comment

I have a 7700K, 64GB, 2xNVME in Raid-0 cache drive, GTX1070 passed through to Win10...  I run the VM's off the Unraid Cache...

 

Make sure the VM is set to Q35-3.1.0 in the Unraid  6.7.0-rc2 or Q35-3.0.0 if you want the Unraid 6.6.6...  I had several issues when using the Unraid default of i440fx, some are performance related, some compatibility issues...  This is because the i440fx was an ancient chipset for the old Pentium 1+2 that knew about old PCI and AGP slots... and so has to translate everything PCIe into PCI, and other translation overhead...  The Q35 chipset actually knows about PCIe, and so skips all this...  Not as major as that sounds, it is still fairly fast, but it is noticeable, and as I said, it had compatibility issues for me, especially with UWP apps...

 

Also minor, but I set my VM "Drives" to use the SCSI driver, this allows a "Discard" setting which is the Linux version of SSD TRIM...

<disk type='file' device='disk'>
      <driver name='qemu' type='raw' discard='unmap'/>
      <source file='/mnt/user/domains/....................
                    ........

This is a minor speed up, and on some file operations actually slows things down, but allows Windows to pass the TRIM commands all the way down to the actual SSD you are running on...  This also shrinks VM image files, which for me actually speeds things up quite a bit... Full SSD's start slowing down alot, and so this is mainly a slowdown prevention measure...

 

Edit: Also avoid QCOW2 at all costs...

 

Probably the main thing is knowing how your processor works, and making sure you pass CPU cores in a way that makes sense for your CPU...  Let Unraid as well as the overhead from running KVM/Qemu run on its own core (Core 0)...  Don't do something silly like passthrough only the hyper-threading cores and all the main cores to a different VM or something else like that...

 

Edit: I don't have one, but I understand this is especially important with current AMD chips, because they have NUMA nodes as well to make sure they get right...

 

Some other manual edits I made to mine:

  <cputune>
    ...
    ...
    <emulatorpin cpuset='0'/>
  </cputune>
  <cpu mode='host-passthrough' check='none'>
    ...
  </cpu>
  <os>
	...
    <smbios mode='host'/>
  </os>

These make sure that KVM/Qemu share the primary core with the rest of Unraid, tell windows about what your CPU can do (potentially some good improvements here) and the info from your Motherboard BIOS and not the fake info from KVM/Qemu...

 

That is where I am at with my personal training on the subject...

Edited by Warrentheo
  • Like 1
  • Thanks 2
  • Upvote 1
Link to comment

Wow, great, thanks for the detailed note.

 

I’ll have a few clarification questions, but let me study first.

 

One immediate one is whether you run your VMs bare-metal on the nvme or as an image? If bare-metal, any advice how to set this up? There is a guide, but not clear whether that’s really possible to be done on a “fresh” machine”.

 

If nvme is passed-through, where do you put your docker containers?

Link to comment
1 hour ago, Warrentheo said:

I run the VM's off the Unraid Cache...

What I meant by that was no baremetal, run off of raw img files (again QCOW2 kills performance, avoid like the plague)... There really is no reason to run baremetal, since leaving it as Unraid cache lets all read/write performance to the host to be much faster usually... There will be minor times where this could be less than ideal if you are running something along the lines of a 300 thread BitTorrent share off the same drive or something else that constantly thrashes the drive... This will kill the VM with micro-stutters and other issues...

 

And because I don't passthrough, docker containers can share it also just fine...  It all really depends on the situation, but if you don't have any one thing that wants to max out the drive, it is best to share its performance with as many things as possible...  You can have hundreds of bad blocking file ops on an SSD drive before you start competing with the time you have to wait for one normal read on a platter based setup...  Hundreds of thousands if you have a good NVME with command queuing in Raid-0...  Spread the love around as best you can...

  • Like 1
Link to comment

Thanks, very clear.

 

So, running two gaming VMs on the same nvme seems a total non-issue.

 

I’m still a bit worried about the dockers. Wouldn’t sabnzbd, radars, sonarr and plex hammer the disk? and hence impact gaming performance on the VM?

 

And some more clarifications that I'd need based on your initial reply:

 

1) 2xNVME in Raid-0 cache drive - I have two NVME as well. Only one is a cache device. The other one is assigned as an unsassigned device. Do you see an advantage of using raid0 vis-a-vis my setup. I thought that mine give me the same speed and I'd only lose one of the NVME device data if a drive fails (vs. both if setting them in raid0 mode). I also thought that my setup would have a speed advantage over a raid0 setup. Only draw-back of my setup is that the vdisks cannot span over two disks, which I wouldn't mind. Anything I am missing and what's the reason why you chose a raid- setup?

 

2) My VMs are set for i440fx. Let me try to switch them to Q35. I haven't tried this, but should be an easy change. It may also solve one issue that I have been seeing. I tried to add a second vdisk (to put my games on an array drive as game folders may not need an SSD and I have plenty space on the array), but this failed due to some incompatibility issue.

 

3) SCSI driver: you referring to setting to SCSI instead of VirtIO? If so, can I just switch this in the VM settings? Does the "discard setting" require me to manually change the XML file. I prefer not to manually change the XML as all changes to the XML gets lost when I change ram allocation (and I don't want to remember to redo all XML changes manually each time I change ram allocation). Assume no work-around for this?

 

4) CPU pinning: I have now isolated cores 2-5 and HT 8-11. And pinned all dockers to cores 0-1 / HT 6-7. One VM uses cores 2-5 / HT 8-11, the other VM uses core 4-5 / HT 10-11. The first one is used for gaming, the second for low-intensity tasks. Does this read like the best setup?

 

5) Manual edits that you mention at the end: where do you make these manual edits? In the VM XML and (if so) you do them every time again when you change the ram allocation or anything else?

 

6) You have 64GB vs. "my" 32GB. Did you get any performance improvement from it or would be equally well set up with 32GB? If betterm what would you assign it to?

 

Thanks again for your great help!

Edited by steve1977
Link to comment

1) I have a setup with a single nvme as a cache drive for a couple VMs and dockers and another NVME passed through to my main Win10 VM for daily use. The advantage is that none of the dockers or other VMs in case they do heavy reads or writes on the cache affecting my main VM. Another advantage is, in case my Unraid USB stick dies i can switch the boot order in the BIOS and can boot straight from that NVME. 

 

2) For me i'am using the i440fx machine type for my VM since the beginning and i never saw any advantages over the Q35. Maybe something changed in the last half year. Worth a try to test again. For my main VM i have an extra SSD attached for mainly games that i play from time to time and an extra network share connected, sitting on the array for older Games. I didn't had any issues with steam so far running games from a network drive except it's way slower to start them. Map your share in the VM and set it as second library folder in steam and you can transfer the games in case you need them from the network share to the local drive.

 

3) You can't switch to SCSI. You have to install the driver first in the VM. Easy way is to add another drive to the VM lets say 1GB in the GUI of the VM settings, mount your Virtio Driver Iso to the VM, start it up and check your device manager in Windows and install  the driver from the mounted ISO. After that you can shutdown the VM, remove the 1GB temporary drive we created earlier and switch your main drive to SCSI. It should now use the driver you installed before. The unmap setting you have to do manualy in the XML. 

 

4) Sharing the cores between the VMs you can do, but expect that one VM can slow down the other when both run at the same time. 

5 hours ago, steve1977 said:

One VM uses cores 2-5 / HT 8-11, the other VM uses core 4-5 / HT 10-11

Keep in mind every OS is doin stuff in the background. Random OS updates (fu MS 😣), virus scans, file integrity checks etc. They all can affect the performance of another VM using the same cores at the same time. Shut down the light weight VM if you don't use it while gaming or separat the cores from the gaming VM. 

 

5) All these edits are made in the XML view. Why are you changing the RAM allocation at all? 16GB for the gaming VM should be enough, 4-8GB for the second VM should be also enough for lightweight use and you have 8-12GB left for Unraid itself. Depends on what else is running on Unraid, lets say tons of docker containers you might have to give Unraid more. I never changed the RAM allocation at all for my VMs. Set it and forget it. A couple of settings you make in the VM settings tab don't reset the custom edits btw. I think since version 6.6 limetech changed something to make the custom edits more persistent. What i always do is to save the XML content before i make some edits and compare them afterwards to make sure my custom settings aren't lost.

 

6) I also have 64GB of RAM available and using 16 for my main VM and 8 for the second one always running. From time to time i use 1-2 more VMs, mainly for testing but thats a rare case. The dockers I use (Unifi, Netdata, Nextcloud, Duplicati) aren't using that much RAM anyways. Can't tell what Sonar, Radar or Plex are using, but better have some spare ressources in case something needs it. In my case currently 32GB would be enough. With 3 Vms running right now I utilize 51% of my RAM. 

 

 

 

  • Like 1
Link to comment

Thanks. It seems I have found two great experts with similar setups as mine 🙂

 

re 1 - is there any other meaningful performance advantage of running bare-bone beyond a potential advantage when running other things at the same time? Let's assume I have two vdisks on one NVME and only one of them is active, would the performance be basically identical with running bare-bone?

 

re 2 - I just switched to QEMU. It didn't work as easily as the VM got stuck "updating", but it did work by creating a new VM based on th existing vdisk. As it may improve compatibility and you don't mention a downside, it seems like a no-regret to give it a try. Regarding the second half of your answer, how did you add the SSD and network drive? I've pointed Steam to it, but this created issues when using gamestream (which I ultimately do). Did you succeed to create a second vdisk on another disk? I am thinking that I could even have this second disk be the cache drive (still some space on it) or I could place it inside the array. I believe I had tried this before and once adding a second vdisk, the GPU passthrough no longer worked. I know that the two things shouldn't have anything to do with each other, but it was consistent. Also, I wonder whether it is smart to move a vdisk into the array anyways (even if just for "old" games). When moving my Windows VM vdisk to the array, it becomes insanely slow (night and day compared to having it as an UD or cache).

 

re 3 - Do both of you run it this way and is the improvement meaningful? It seems like a bit of work with some risk of breaking my VM. Also, the initial description said that it could even slow things down. Worth going this route?

 

re 5 - how do you "compare them afterwards"? You skim through the before and after on two screens?

Link to comment
9 hours ago, Warrentheo said:

Some other manual edits I made to mine:


  <cputune>
    ...
    ...
    <emulatorpin cpuset='0'/>
  </cputune>

  <cpu mode='host-passthrough' check='none'>
    ...
  </cpu>

  <os>
	...
    <smbios mode='host'/>
  </os>

These make sure that KVM/Qemu share the primary core with the rest of Unraid, tell windows about what your CPU can do (potentially some good improvements here) and the info from your Motherboard BIOS and not the fake info from KVM/Qemu...

 

I checked my XML. I've done the 1st and 3rd edit. Not sure about the 2nd as it seems that this is the status quo?

Link to comment
33 minutes ago, AntaresUK said:

Q35 didnt work for me with my lg 144hz monitor, couldnt set the resolution to 144. Will apply the other tips though, thanks

 

The Q35 should have nothing to do with video limitations unless you are using a virtualized (Fake) graphics card or VNC...  I passthrough an nVidia Geforce 1070, and have a dual G-Sync monitor setup connected to it, running at 144hz...

Link to comment
1 hour ago, steve1977 said:

would the performance be basically identical with running bare-bone?

Don't forget you have a layer of emulation between your VM and the real hardware. Emulation always adds some overhead and will never be the same as bare metal performance. If nothing else uses the NVME the vdisk is hosted on in perfect conditions it comes close to BM performance. Example if other stuff (Dockers, other VMs, Backround Backup tasks or parity checks) on your host pushing the system extrem to the limit, even if the NVME isn't touched outside the VM it can slow things down. 

 

1 hour ago, steve1977 said:

It didn't work as easily as the VM got stuck "updating"

There are a couple things already reported belongs to this, switching disk types or machine types causing errors or a hang like you experiencing. The devs are already informed and i guess it is a question of time for a fix.

 

1 hour ago, steve1977 said:

how did you add the SSD

I have added a unassigned 1TB SSD to my main VM with the following code

<disk type='block' device='disk'>
 <driver name='qemu' type='raw' cache='writeback'/>
 <source dev='/dev/disk/by-id/ata-Samsung_SSD_850_EVO_1TB_S2RFNX0J606029L'/>
 <backingStore/>
 <target dev='hdd' bus='sata'/>
 <alias name='sata0-0-3'/>
 <address type='drive' controller='0' bus='0' target='0' unit='3'/>
</disk>

In Steam this is my main location for installing games to. In Unraid I've created a share called GAMES and in Windows i mounted the share with the drive letter G and in Steam >>> Settings >>> Downloads >>> Library I added these network drive. Whenever i install a game i can choose where to install it to and installed games i can shift between both entries.

steam_library.png.f88943d225c1f58703615e6463eab536.png

steam_library2.png.6a48c1c45467751bab7c7a6d654b874b.png

The loading times for games sitting on the share on the array are way longer than on the dedicated SSD. It doesn't matter if you do it my way or using a extra vdisk sitting on the array. Sure you can place the vdisk on the cache drive if it's big enough to hold all your games. You also can put the vdisk on an unassigned disk (HDD, SSD, NVME) to not interrupt any caching of your files happen or slowdown any Docker or VM performance sitting on the cache. It all depends how your cache is setup and how large it is. Most games for me if they once loaded up from the array share they are running fine. Loading times for levels sure are longer but other than that it's ok. That might differ from game to game. Some copy protections or anti cheat tools will prevent you from starting up games from a network share. Couple people reported Uplay have some issues. It's up on you to test which game works with which configuration.

 

There are a couple improvements you can do inside the VM to increase the performance in the VM. For example setting the power plan to high performance, disable hibernation etc. You might check out SpaceInvaders Youtube channel if you're not already did. He has tons of useful stuff setting up VMs and configuring/tweaking stuff or use the search on the forum.

 

https://www.youtube.com/channel/UCZDfnUn74N0WeAPvMqTOrtA

 

1 hour ago, steve1977 said:

how do you "compare them afterwards"?

A copy from the original XML opened in an editor and the new changed XML in the webeditor. If i have a custom edit missing in the new XML I copy paste my custom edits back. Done.

 

Edited by bastl
Link to comment

Host Storage:

    2 x NVMe Samsung 960 EVO in Unraid Raid-0 with btrfs set as cache drive without a lot of Dockers or other services that use the drive much

VM Storage Settings:

    Raw image file, set to use the SCSI driver in the VM, with the Discard="UnMap" option set (Trim goes all the way from VM to the real drives...)

image.png.d3b6ca966116bd28bfcb3a18cdb6fd06.png 

-----------------------------------------------------------------------
CrystalDiskMark 6.0.2 x64 (C) 2007-2018 hiyohiyo
                          Crystal Dew World : https://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

   Sequential Read (Q= 32,T= 1) :  3878.403 MB/s
  Sequential Write (Q= 32,T= 1) :  2775.437 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   199.059 MB/s [  48598.4 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   150.607 MB/s [  36769.3 IOPS]
  Random Read 4KiB (Q=  1,T= 1) :    50.087 MB/s [  12228.3 IOPS]
 Random Write 4KiB (Q=  1,T= 1) :    40.228 MB/s [   9821.3 IOPS]

  Test : 1024 MiB [C: 52.0% (156.0/299.7 GiB)] (x5)  [Interval=5 sec]
  Date : 2019/02/03 7:23:40
    OS : Windows 10 Professional [10.0 Build 17763] (x64)
  

For reference, the official specs for a single drive running bare metal on a good system:

Sequential Read Speed    Max 3,200 MB/sec
Sequential Write Speed   500 GB: Up to 1,800 MB/sec 
RANDOM READ (4KB, QD32)  500 GB: Up to 330,000 IOPS (Thread 4) 
RANDOM WRITE (4KB, QD32) 500 GB: Up to 330,000 IOPS (Thread 4) 
RANDOM READ (4KB, QD1)   Up to 14,000 IOPS (Thread 1)

 

So definitely not a straight up 2x performance boost from the Raid-0...  Some performance is given up on my system due to having to request storage from the host on every write, and release that storage back to the host on every delete...  For me however I originally had several issues with the drive filling up and killing the performance of my VM's, this was all eliminated by switching to the SCSI driver with Discard (TRIM) enabled, as this made the storage self regulating...  Most of the real limiting factor is trying to max out two by 4x PCIe lanes for each drive through the PCH then to the CPU...  This maxes out the connection between the PCH and CPU on my system, and so is the real limiting factor...

Link to comment

@bastl

I did something similar, but created a second raw storage image file on the cache, and just setting the steam storage to have a location there, then just using the steam game move feature to allow me to just move the game there when It becomes a game I play for often, then archive it back to the Unraid host when I don't...

I found this to be by far the fastest loading times, but does mean that only one VM can have access to the data without a bunch of move options...  There are also some games that hate being run off of a UNC network share (\\servername\...) which steam does allow you to do...  This resolved that issue as well...

Link to comment

Thanks for all your replies. It seems that SCSI and bare-bone may not be as critical for my setup.

 

What seems an unlock though is if I can find a way to create a second vdisk on my cache disk. This way I could have one UD with my gaming VM and games I play most often. And a cache disk with dockers, second VM and second vdisk for games I play less often.

 

The only issue with this setup is that it doesn't work for me. Have you tried this before and did it work? GPU passthrough works for me as long as I provide the graphics rom bios. However, once I add a second vdisk, the GPU is no longer passedthrough. The VM still starts and I can use Windows. But it no longer uses the passthrough GPU.


Have you tried such setup and has it been working for you?

Link to comment
9 hours ago, steve1977 said:

3) SCSI driver: you referring to setting to SCSI instead of VirtIO? If so, can I just switch this in the VM settings? Does the "discard setting" require me to manually change the XML file. I prefer not to manually change the XML as all changes to the XML gets lost when I change ram allocation (and I don't want to remember to redo all XML changes manually each time I change ram allocation). Assume no work-around for this?

 

There is a solution to your i440FX vs Q35 issue, as well as your not wanting to make manual edits to your VM's XML...  Just create a "New" VM but point all its storage back to the current image files... This is the VM equivalent of moving the hard drive to a new system...

 

There are two ways to do this in Unraid, they both have their uses:

Version 1: 

    Create a "New" VM, this will generate a new fake BIOS entry for that VM, and disconnect several other things in the VM from the previous VM...  You can then re-setup everything with a different machine type or whatever settings you wish...  You can still use the existing VM's image files, just make sure if you delete the entry for the original VM, not to accidentally delete the image files as well...  If you do this, I recommend taking manual control of the image files storage location, as well as backup the image files just in case...

 

Version 2:

    Again, create a "New" VM, but just manually copy over all the data from the original VM as a manual edit of the new VM...  You can then make minor changes like having 2 or 3 VM entries that are nearly identical, but have different RAM settings, allowing you to pick your RAM by just picking the VM entry that suits you...

 

When moving from i440fx to Q35, make sure to do a backup... This is the same as moving the hard drive in a computer to a new computer...  It will take forever to boot the first time since every single device driver on the system will need to be reinstalled...  My own experience has shown this to not be a major issue, but that is not an excuse to skip the backups...

 

All this adds up to not being much of an issue for me doing manual edits to the XML... UnRaid has gotten much better at not throwing away all your edits when making a change in current versions...

 

I do manually edit nearly all my VM's with the following info (again, edit as needed for your system):

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' discard='unmap'/>
      <source file='/mnt/user/domains/....'/>
      <target dev='sda' bus='scsi'/>
    </disk>
  <cputune>
    ...
    ...
    <emulatorpin cpuset='0'/>
  </cputune>
  <cpu mode='host-passthrough' check='none'>
    ...
  </cpu>
  <os>
    ...
    <smbios mode='host'/>
  </os>

 

Link to comment

Thanks.

 

Successfully moved to QEMU.

 

Not gone the scsi path yet, but may give it a try.

 

CPU more is already my default setting. Am i overlooking anything?

 

Any thoughts whether one of you have succeeded to add a second vdisk to a VM. As described above, adding the second vdisk causes issues with my gpu pass through (windows boots, but gpu no longer passed through).

 

I’m undecided whether i give it a try whether bare-bone improves my performance. Have you installed it directly batebone or converted a vdisk to bare-bone? if the latter, was it worry-free?

Link to comment
On 2/3/2019 at 2:32 PM, steve1977 said:

Successfully moved to QEMU.

Are you noticing any performance improvements after switching to Q35-3.0.0? I've been happy so far with the gaming performance on i440fx-3.0 running BFV, R6, and PUBG.

 

Maybe, I'll give it a try and report back.

 

Also, I was trying to search on the forum, but is it imperative that we don't pin anything to CPU 0/1? I'm running a Threadripper and I think I would get better performance if isolating VM's to a single chip versus spreading the workload of the VM across the Infinity Fabric.

  1. Does Unraid OS specifically like the first CPU pinning slot?
  2. Or it doesn't matter as long as you leave a single core & hyperthread open for Unraid?

 

===

 

I also, want to link back to another thread that discusses Q35 and gaming performance so we have a cross-reference here.

 

Edited by Zer0Nin3r
Threw in another question about CPU pinning to 0/1
Link to comment

I didn't really see any difference in performance since switching to QEMU. Not for the worse, but also not visibly to the better. I'll keep watching it. Unfortunately, my issue of not being able to add a second vdisk without losing the GPU-passthrough prevails. Not a big deal, but it would make life easier.

 

Link to comment
On 2/4/2019 at 7:32 AM, steve1977 said:

I’m undecided whether i give it a try whether bare-bone improves my performance. Have you installed it directly batebone or converted a vdisk to bare-bone? if the latter, was it worry-free?

I am tempted to give it a try this weekend to run my VM bare-bone and see whether it improves performance. One advantage I see: dockers may sometimes max out non-allocated CPU and non-allocated ram. If I understand it directly, this would leave a bare-bone VM unaffected, while it may have a negative impact on a vdisk VM as some of the non-allocated CPU/ram is still required for visualization and may compete with the dockers? So while my initial worry about dockers and VMS hammerings the same NVME seems a minor issue, there still is an advantage of having the VM 100% isolated from Unraid/dockers (which can only be achieved bare-bone)?

 

If going this route, two questions for the gurus:

 

1) Did you convert the vdisk to bare-bone and (if so) did you do this on a live VM?

 

2) Is there any way back if I eventually decide that I may prefer to go back from bare-bone to vdisk?

Link to comment

Can someone chime in on what kind of games they're playing which are good performance?  I'm running the beta (yes I know but it works on bare metal OK) of the Division 2 and getting all sorts of GUI lags that make it a bit problematic. Much like when the fps and sync rate is out watching a panning scene on TV, but worse.  It's playable, but not very enjoyable.  Is it too much for Unraid?  Should mention Nvidia 1050ti from EVGA, dumped my own bios, but it actually seems to run the same without the bios for some reason.  On that, I just renamed the .dump file to .rom - I assume that's all good.

Link to comment
2 hours ago, Marshalleq said:

Should mention Nvidia 1050ti from EVGA, dumped my own bios, but it actually seems to run the same without the bios for some reason.  On that, I just renamed the .dump file to .rom - I assume that's all good.

Are you sure that your GPU pass-through is working? I had many issues how to get the pass-through working and - in some configurations - the VM even boots up well without any indication that it is not working.

 

I haven't tried Divsion 2, but other presumably similarly intense games like FF XV or FH 3 run without any issues.

Link to comment
19 hours ago, Zer0Nin3r said:

Are you noticing any performance improvements after switching to Q35-3.0.0? I've been happy so far with the gaming performance on i440fx-3.0 running BFV, R6, and PUBG.

 

Maybe, I'll give it a try and report back.

 

Also, I was trying to search on the forum, but is it imperative that we don't pin anything to CPU 0/1? I'm running a Threadripper and I think I would get better performance if isolating VM's to a single chip versus spreading the workload of the VM across the Infinity Fabric.

  1. Does Unraid OS specifically like the first CPU pinning slot?
  2. Or it doesn't matter as long as you leave a single core & hyperthread open for Unraid?

 

===

 

I also, want to link back to another thread that discusses Q35 and gaming performance so we have a cross-reference here.

 

The performance issues is minimal, there is some additional overhead from the PCIe to PCI translation that occurs with PCIe passthrough on the i440fx, while the speed change barely reached the level of perceptable for me, the main reason for the fix was I have had several issues with compatibility...  For a while, PUBG worked fine for me, then one day when they were adding in anti-cheat measures like battleye, it would fail battleye checks on my system and fail to load.  I also had issues with the UWP game Sea of Theives just refusing to load...  For me switching to Q35 gave me a minor but noticeable speed improvement, a noticeable reduction is minimum framerates in games (mico-stuttering), and suddenly games that refused to work or had issues no longer had those issues...

 

In the past the i440fx chipset was by far the one most polished by the Qemu community, and Q35 was just buggy or glitchy...  From my admittedly limited experience Q35 is fully ready to replace the i440fx machine now, UnRaid already defaults to Q35 for the Linux based VM templates, and I believe there is no longer a reason for the Windows based ones to default to i440fx since even on Windows it no longer seems that it brings any benefit over Q35, and only seems to cause problems...  Again, my opinion, and I am still looking for people that actually have issues with Q35...

 

Edit:

On you questions:

Quote
  1. Does Unraid OS specifically like the first CPU pinning slot?
  2. Or it doesn't matter as long as you leave a single core & hyperthread open for Unraid?

Linux in general, and therefore UnRaid likes to have its primary core on Core 0... Even if you try and isolate Core 0 Linux will still use it anyway...  You can isolate the Linux kernel from all the other cores, so you can even force all the UnRaid overhead and emulation down to just Core 0 if you felt the need...

 

There are 2 commands here that affect this sort of thing: The one for the Linux kernel itself is a config you put in your Syslinux config and looks like this:

kernel /bzimage
append isolcpus=1-3,5-7 initrd=/bzroot

This would on my system leave Core 0, and its mirror Hyperthread, which on my system is Core 4, still available for anything the Linux kernel wants to do... Anything that wants to use those other "Isolated" cores has to specifically request them, since the kernel wont hand them out automatically any more...

 

There is a performance hit to running emulation, there is some housekeeping and cleanup needed when running in a VM, and those need to go somewhere...  If you don't specifically specify where that work can be done, then if will go back to the Linux kernel to run this...  If you have not done any isolation of cores or any other things to mitigate this, it will sometimes run with a higher priority on the cores that the VM (Windows) kernel wants to use... This will cause noticeable pauses, and minor bumps to your performance...  We solve this by moving this overhead off the cores we assign to our VM by telling KVM/Qemu where to run this overhead at:

<cputune>
    ...
    ...
    <emulatorpin cpuset='0,4'/>
</cputune>

Remember, you have both a Linux kernel, and the VM kernel (Windows) not talking directly to each other, and so will sometimes try and schedule the same CPU core to do two different things at once...  So we trade some performance (some cores are now only used sometimes or even rarely) for a reduction in pauses and glitches (Cores are no longer double booked because we have 2 kernels fighting for the same cores)...  Adding NUMA nodes and infinity fabric into this mix makes things even more complicated, and unfortunately I don't have an AMD chip to give advice on that... Getting a good balance between performance and VM lag is up to you and the application/game you are running...

 

Currently I am running without CPU isolation, but the emulator pinned outside of the cores assigned to the VM on my system... This means the emulator isn't causing issues in the VM, but other UnRaid processes potentially could, however I don't run many docker containers or other UnRaid processes, and so for me UnRaid acts mostly as storage manager...

Edited by Warrentheo
  • Like 1
Link to comment
5 hours ago, steve1977 said:

Are you sure that your GPU pass-through is working? I had many issues how to get the pass-through working and - in some configurations - the VM even boots up well without any indication that it is not working.

 

I haven't tried Divsion 2, but other presumably similarly intense games like FF XV or FH 3 run without any issues.

The 1050ti is not the best performing of cards, but typically the way I understand it, you wont get the drivers to load in windows if you don't have a VBIOS for the NVidia card correctly passed through...  The GTX 10 series and RTX series and up all encrypt the VBIOS as well and the connection between the VBIOS and their drivers...  The VBIOS passthrough is a workaround to get this connection to work in a VM...

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.