therapist

@msalad no news is good news i have had zero call traces since implementing the fixes. have been without swap active going on a little over a week and all seems OK. aside from an occasional hiccup/stutter with a w10 VM that ive had operational forever I am liking unraid 7.0

Hey @msalad So I actually tested without the swap file plug-in and have not had any issues yet. With the swap file I was averaging 44 to 46% usage of RAM and went up to 56 to 57% after disabling which makes sense because the swap file had about 12GB used (10% of my 128GB) Thats the exact app I used though The added code changes "the number of fuse file descriptors" which ive never had to adjust before, but here we are. You dont actually have to add that line anymore...if you go to settings/global share settings you can set that parameter while array is stopped

checking in so far i havent had any call traces since implementing my fixes i still dont quite understand why i would need to use swap after all these years of not having it, but i am hesitant to get rid of it since ive made headway

installed newest version of unraid connect -- seems to have solved the logging issue

@bmartino1 I've implemented a number of "fixes" and preliminary testing is positive: added to boot options: append mitigations=off iommu=pt transparent_hugepage=never installed swap plugin and configured a 8gb swapfile on nvme added shareNOFILE="813384" to /boot/config/share.cfg I still dont quite get why swap is necessary after all these years of not using + having a load of "free" memory

just jumping in to say thanks for reviewing, but unraid is running baremetal and ive never needed swap before. Im going to digest your first post and see if that takes me anywheres

I had been on 6.11.5 forever and recently upgraded to 7.0 when my USB flash died. Aside from an issue with UNRAID CONNECT everything has been working well....but I noticed an intermittent call trace error relating to vmalloc Feb 18 14:10:55 CRUNCH kernel: warn_alloc: 1 callbacks suppressed Feb 18 14:10:55 CRUNCH kernel: lsof: vmalloc error: size 4194304, failed to allocated page array size 8192, mode:0x400cc2(GFP_KERNEL_ACCOUNT|__GFP_HIGHMEM), nodemask=(null),cpuset=/,mems_allowed=0-3 Feb 18 14:10:55 CRUNCH kernel: CPU: 12 PID: 3184246 Comm: lsof Tainted: P W O 6.6.68-Unraid #1 Feb 18 14:10:55 CRUNCH kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./EPYCD8-2T, BIOS P2.60 04/10/2020 Feb 18 14:10:55 CRUNCH kernel: Call Trace: Feb 18 14:10:55 CRUNCH kernel: <TASK> Feb 18 14:10:55 CRUNCH kernel: dump_stack_lvl+0x38/0x4a Feb 18 14:10:55 CRUNCH kernel: warn_alloc+0xfb/0x189 Feb 18 14:10:55 CRUNCH kernel: ? srso_return_thunk+0x5/0x5f Feb 18 14:10:55 CRUNCH kernel: __vmalloc_node_range+0x2bd/0x62b Feb 18 14:10:55 CRUNCH kernel: ? seq_read_iter+0x1de/0x353 Feb 18 14:10:55 CRUNCH kernel: kvmalloc_node+0xae/0xbc Feb 18 14:10:55 CRUNCH kernel: ? seq_read_iter+0x1de/0x353 Feb 18 14:10:55 CRUNCH kernel: seq_read_iter+0x1de/0x353 Feb 18 14:10:55 CRUNCH kernel: seq_read+0x91/0xbb Feb 18 14:10:55 CRUNCH kernel: vfs_read+0xa7/0x1d1 Feb 18 14:10:55 CRUNCH kernel: ? srso_return_thunk+0x5/0x5f Feb 18 14:10:55 CRUNCH kernel: ? __do_sys_newfstat+0x34/0x5c Feb 18 14:10:55 CRUNCH kernel: ksys_read+0x74/0xc0 Feb 18 14:10:55 CRUNCH kernel: do_syscall_64+0x57/0x7b Feb 18 14:10:55 CRUNCH kernel: entry_SYSCALL_64_after_hwframe+0x78/0xe2 Feb 18 14:10:55 CRUNCH kernel: RIP: 0033:0x14588a3106ed Feb 18 14:10:55 CRUNCH kernel: Code: 21 87 0e 00 f7 d8 64 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 80 3d 59 0b 0f 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec Feb 18 14:10:55 CRUNCH kernel: RSP: 002b:00007ffe7259dcc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 Feb 18 14:10:55 CRUNCH kernel: RAX: ffffffffffffffda RBX: 000000000043f600 RCX: 000014588a3106ed Feb 18 14:10:55 CRUNCH kernel: RDX: 0000000000000400 RSI: 0000000000448690 RDI: 0000000000000007 Feb 18 14:10:55 CRUNCH kernel: RBP: 000014588a3f81f0 R08: 0000000000000001 R09: 0000000000000000 Feb 18 14:10:55 CRUNCH kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 000014588a3f80a0 Feb 18 14:10:55 CRUNCH kernel: R13: 0000000000000000 R14: 0000000000001000 R15: 000000000043f600 Feb 18 14:10:55 CRUNCH kernel: </TASK> Feb 18 14:10:55 CRUNCH kernel: Mem-Info: Feb 18 14:10:55 CRUNCH kernel: active_anon:11403130 inactive_anon:2693854 isolated_anon:0 Feb 18 14:10:55 CRUNCH kernel: active_file:8358687 inactive_file:7968638 isolated_file:0 Feb 18 14:10:55 CRUNCH kernel: unevictable:836 dirty:30773 writeback:0 Feb 18 14:10:55 CRUNCH kernel: slab_reclaimable:886844 slab_unreclaimable:232381 Feb 18 14:10:55 CRUNCH kernel: mapped:395878 shmem:573300 pagetables:51966 Feb 18 14:10:55 CRUNCH kernel: sec_pagetables:195 bounce:0 Feb 18 14:10:55 CRUNCH kernel: kernel_misc_reclaimable:0 Feb 18 14:10:55 CRUNCH kernel: free:553088 free_pcp:41074 free_cma:0 Feb 18 14:10:55 CRUNCH kernel: Node 0 active_anon:16735288kB inactive_anon:1718592kB active_file:5798564kB inactive_file:6043816kB unevictable:32kB isolated(anon):0kB isolated(file):0kB mapped:313920kB dirty:20416kB writeback:0kB shmem:363020kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:17328128kB writeback_tmp:0kB kernel_stack:12820kB pagetables:54480kB sec_pagetables:176kB all_unreclaimable? no Feb 18 14:10:55 CRUNCH kernel: Node 1 active_anon:9206180kB inactive_anon:3987664kB active_file:9857148kB inactive_file:6922696kB unevictable:32kB isolated(anon):0kB isolated(file):0kB mapped:865512kB dirty:60296kB writeback:0kB shmem:1518372kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:9562112kB writeback_tmp:0kB kernel_stack:22916kB pagetables:46896kB sec_pagetables:264kB all_unreclaimable? no Feb 18 14:10:55 CRUNCH kernel: Node 2 active_anon:3228760kB inactive_anon:1957716kB active_file:11863852kB inactive_file:13841864kB unevictable:96kB isolated(anon):0kB isolated(file):0kB mapped:240120kB dirty:14400kB writeback:0kB shmem:210476kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:3741696kB writeback_tmp:0kB kernel_stack:12100kB pagetables:34144kB sec_pagetables:164kB all_unreclaimable? no Feb 18 14:10:55 CRUNCH kernel: Node 3 active_anon:16442292kB inactive_anon:3111444kB active_file:5915184kB inactive_file:5066176kB unevictable:3184kB isolated(anon):0kB isolated(file):0kB mapped:163960kB dirty:27980kB writeback:0kB shmem:201332kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:17127424kB writeback_tmp:0kB kernel_stack:18260kB pagetables:72344kB sec_pagetables:176kB all_unreclaimable? no Feb 18 14:10:55 CRUNCH kernel: Node 0 DMA free:15360kB boost:0kB min:12kB low:24kB high:36kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15984kB managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Feb 18 14:10:55 CRUNCH kernel: lowmem_reserve[]: 0 2831 31999 31999 31999 Feb 18 14:10:55 CRUNCH kernel: Node 0 DMA32 free:239148kB boost:0kB min:2968kB low:5864kB high:8760kB reserved_highatomic:0KB active_anon:124768kB inactive_anon:417300kB active_file:818600kB inactive_file:1064328kB unevictable:0kB writepending:40kB present:3027788kB managed:2935032kB mlocked:0kB bounce:0kB free_pcp:10604kB local_pcp:0kB free_cma:0kB Feb 18 14:10:55 CRUNCH kernel: lowmem_reserve[]: 0 0 29167 29167 29167 Feb 18 14:10:55 CRUNCH kernel: Node 0 Normal free:660640kB boost:32768kB min:63384kB low:93248kB high:123112kB reserved_highatomic:270336KB active_anon:16610520kB inactive_anon:1301292kB active_file:4979836kB inactive_file:4979072kB unevictable:32kB writepending:19872kB present:30395904kB managed:29867976kB mlocked:32kB bounce:0kB free_pcp:38796kB local_pcp:492kB free_cma:0kB Feb 18 14:10:55 CRUNCH kernel: lowmem_reserve[]: 0 0 0 0 0 Feb 18 14:10:55 CRUNCH kernel: Node 1 Normal free:125188kB boost:59392kB min:93244kB low:126268kB high:159292kB reserved_highatomic:2048KB active_anon:9206180kB inactive_anon:3987664kB active_file:9857148kB inactive_file:6922696kB unevictable:32kB writepending:60296kB present:33553920kB managed:33026000kB mlocked:32kB bounce:0kB free_pcp:34140kB local_pcp:3516kB free_cma:0kB Feb 18 14:10:55 CRUNCH kernel: lowmem_reserve[]: 0 0 0 0 0 Feb 18 14:10:55 CRUNCH kernel: Node 2 Normal free:1074724kB boost:114688kB min:148540kB low:181564kB high:214588kB reserved_highatomic:10240KB active_anon:3228760kB inactive_anon:1957716kB active_file:11863852kB inactive_file:13841864kB unevictable:96kB writepending:14400kB present:33553920kB managed:33026004kB mlocked:96kB bounce:0kB free_pcp:40912kB local_pcp:1552kB free_cma:0kB Feb 18 14:10:55 CRUNCH kernel: lowmem_reserve[]: 0 0 0 0 0 Feb 18 14:10:55 CRUNCH kernel: Node 3 Normal free:97796kB boost:0kB min:33848kB low:66868kB high:99888kB reserved_highatomic:2048KB active_anon:16442292kB inactive_anon:3111444kB active_file:5915184kB inactive_file:5066176kB unevictable:3184kB writepending:27980kB present:33553920kB managed:33022812kB mlocked:96kB bounce:0kB free_pcp:39252kB local_pcp:2512kB free_cma:0kB Feb 18 14:10:55 CRUNCH kernel: lowmem_reserve[]: 0 0 0 0 0 Feb 18 14:10:55 CRUNCH kernel: Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15360kB Feb 18 14:10:55 CRUNCH kernel: Node 0 DMA32: 12435*4kB (UME) 3931*8kB (UME) 1486*16kB (UME) 582*32kB (UME) 182*64kB (UME) 177*128kB (UME) 34*256kB (UME) 25*512kB (UME) 56*1024kB (UME) 1*2048kB (U) 0*4096kB = 238788kB Feb 18 14:10:55 CRUNCH kernel: Node 0 Normal: 47593*4kB (UMEH) 11404*8kB (UMEH) 2380*16kB (UMEH) 1763*32kB (UMEH) 851*64kB (UMEH) 411*128kB (UMH) 88*256kB (H) 66*512kB (H) 36*1024kB (H) 37*2048kB (H) 2*4096kB (H) = 660324kB Feb 18 14:10:55 CRUNCH kernel: Node 1 Normal: 859*4kB (UME) 5383*8kB (UME) 3166*16kB (UME) 670*32kB (UM) 73*64kB (UME) 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB (H) 0*4096kB = 125316kB Feb 18 14:10:55 CRUNCH kernel: Node 2 Normal: 24777*4kB (UME) 12657*8kB (UME) 11249*16kB (UME) 8873*32kB (UME) 5954*64kB (UME) 143*128kB (M) 3*256kB (M) 0*512kB 0*1024kB 5*2048kB (H) 0*4096kB = 1074652kB Feb 18 14:10:55 CRUNCH kernel: Node 3 Normal: 955*4kB (UME) 1415*8kB (UME) 671*16kB (UME) 1678*32kB (UME) 249*64kB (UME) 3*128kB (M) 0*256kB 0*512kB 0*1024kB 1*2048kB (H) 0*4096kB = 97940kB Feb 18 14:10:55 CRUNCH kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB Feb 18 14:10:55 CRUNCH kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB Feb 18 14:10:55 CRUNCH kernel: Node 1 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB Feb 18 14:10:55 CRUNCH kernel: Node 1 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB Feb 18 14:10:55 CRUNCH kernel: Node 2 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB Feb 18 14:10:55 CRUNCH kernel: Node 2 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB Feb 18 14:10:55 CRUNCH kernel: Node 3 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB Feb 18 14:10:55 CRUNCH kernel: Node 3 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB Feb 18 14:10:55 CRUNCH kernel: 16874061 total pagecache pages Feb 18 14:10:55 CRUNCH kernel: 0 pages in swap cache Feb 18 14:10:55 CRUNCH kernel: Free swap = 0kB Feb 18 14:10:55 CRUNCH kernel: Total swap = 0kB Feb 18 14:10:55 CRUNCH kernel: 33525359 pages RAM Feb 18 14:10:55 CRUNCH kernel: 0 pages HighMem/MovableOnly Feb 18 14:10:55 CRUNCH kernel: 552063 pages reserved Feb 18 14:10:55 CRUNCH kernel: 0 pages cma reserved I have not had any system hangs, or any evident operational issues -- diags attached I did read about setting /boot/config/share.cfg shareNOFILE="813384" Is this along the same route for remedy? crunch-diagnostics-20250218-1421.zip

did a little testing: logged out of unraid connect and logged back in -- errors continue logged out of unraid connect -- errors continue uninstall the unraid connect plugin -- errors no longer appearing in log reinstall of connect plugin results in errors resuming, even without logging in i have another server on same network segment which is humming along on unraid connect w/ no error

recently upgrade to 7.0 from 6.11.5 -- went smooth as butter, sans a few issues with USB hardware. notived that my log was filling up and I thought it was due to the previous USB issues, but upon replacement and restart I am getting my unraid-api.log file filling up with [15:11:11.268] [31mERROR[39m: [36mFailed to validate session [39m [90m{"logger":"api","req":{"id":"req-1te","method":"POST","url":"/graphql"},"context":"AuthService"}[39m [15:11:11.268] [31mERROR[39m: [36mError in handleRequest[39m [90m{"logger":"api","req":{"id":"req-1te","method":"POST","url":"/graphql"},"context":"GraphqlAuthGuard"}[39m [15:11:13.275] [31mERROR[39m: [36mFailed to validate session [39m [90m{"logger":"api","req":{"id":"req-1tf","method":"POST","url":"/graphql"},"context":"AuthService"}[39m [15:11:13.275] [31mERROR[39m: [36mError in handleRequest[39m [90m{"logger":"api","req":{"id":"req-1tf","method":"POST","url":"/graphql"},"context":"GraphqlAuthGuard"}[39m [15:11:15.281] [31mERROR[39m: [36mFailed to validate session [39m [90m{"logger":"api","req":{"id":"req-1th","method":"POST","url":"/graphql"},"context":"AuthService"}[39m [15:11:15.281] [31mERROR[39m: [36mError in handleRequest[39m [90m{"logger":"api","req":{"id":"req-1th","method":"POST","url":"/graphql"},"context":"GraphqlAuthGuard"}[39m Any assistance on how to rectify?

Having a bit of a formatting issue for some time now I am on 6.11.5 and have been using UD since its inception. Roughly 3-4 months ago I noticed after an update that the toggles and titles were not formatted correctly. I tried adjusting screen resolution but it happens across multiple viewing devices. Any input on what may be going on?

so i have a VM on this unraid box that is on a vlan (192.168.40.253) it connects to unraid SMB at 192.168.40.2 file transfer rates are close to reported bandwidth there are no wires, just the virtual 10gbe adapter and unraid i have reset the VM network settings to default, adjusted max rss to 6 to match cores on VM unraid has all default network settings except for buffers through tips & tweaks plugin...which shouldnt matter for a VM using br0.x, no? I get better than gigabit, but something isnt right since im not seeing anywhere near proper speeds

this is indicating nothing better than gigabit... all links are indicating 10gb any idea where to look into what i am doing wrong?

I have been doing my testing with both I have a EVO 860 SSD as my main cache disk...so current performance saturates that read/write I have an intel NVME disk installed for VM VHDs and can test full 10gbe bandwidth through that Copying a testfile from RAID1 "cache-protected" to nvme gets speeds I would expect from RAID1 SAS SSD --> NVME Benchmarking the VHD for the VM (which is on the nvme) gets results I expect iperf shows bandwidth is there But when I transfer to DISK share using SMB the speed doesnt translate I thought that it was a networking issue At first because originally my VM was coming out through br0 on unraid. I was able to pass through one of the 10ge ports from my motherboard directly to the VM and improved speed but not to where I think it should be

I have hit a bit of a speed limit on my setup iperf3 tests indicate 8+gb/s of available bandwidth between unraid and my test PC, but I cant transfer over SMB faster than 490-520 mb/s unraid v6.11.5 on EPYCD8-2T w/ 7551 eth0 10gb rj45 --> sfp+ @ mikrotik CRS305-1G-4S+ test share/disk = INTEL SSDPF2KX038TZ test pc = unraid VM w/ mobo eth1 passed through 24c 24gb memory disk = Seagate FireCuda 530 diagnostics attached crunch-diagnostics-20240129-1604.zip

I am working to improve SMB performance and have found a collection of settings that work well. I would like to deploy to all interfaces, but I get strange delays / drops when applied as written: server multi channel support = yes aio read size = 1 aio write size = 1 interfaces = "192.168.1.248;capability=RSS,speed=10000000000" "192.168.40.2;capability=RSS,speed=10000000000" with both interface characteristics specified the main vm on 192.168.1.x hangs on file transfer and transfers dreadfully slow if i remove the 2nd interface (192.168.40.2) main vm on 192.168.1.x works OK, but VM on that interface does not exceed ~175mb/s transfer are the interfaces listed correctly?

Is there a way to update FFMPEG inside this container? I am getting errors whenever a DVR'd program is converted to .mp4 through a script The script has been in use for a long time (years) and is only recently showing an error. The conversion completes and the video files are seemingly unaffected...but Id like to prevent error if possible. Any advice otherwise? transcode_internal.sh

adding diags crunch-diagnostics-20240109-1609.zip

I have finally taken the plunge to bring 10gbe into my network after many years of gigabit and multi-gigabit LAGG. All hardware is capable, but I am having issues with bandwidth. BASIC HARDWARE SPECS: UNRAID 6.11.5 - EPYCD8-2T w/ 7551 w/ built in x550 PFSENSE 2.7.0 - DELL 7010 i7-2600k + mellanox connectx core switch - ubiquiti usw-pro-24-poe 10gbe addon switch - mikrotik CRS305-1G-4S+ DAC cable from pfsense to port 1 on ubiquiti fiber between ubiquiti and mikrotik cat7 cables w/ spf+/rj45 adapters to mikrotik all connections report 10gb connectivity My main PC is a VM on unraid w/ latest virtio drivers -- I passed through one of the 10gbe ports from my EPYCD8-2T to the VM (192.168.1.192) VPN PC is a VM on unraid w/ updated (but not latest drivers-2021) running w virtio network driver on bridged vlan (192.168.40.253 @ br0.40) PINGBOX is a vm on unraid w/ old drivers (2017) running w virti network driver on bridged main lan (192.168.1.10 @ br0) When running iperf tests I am mostly not getting the 10gbe bandwidth I think should be there... from main pc to iperf docker @ unraid from main pc to VPN pc on other subnet from main PC to PINGBOX from main pc to iperf @ pfsense from PINGBOX VM to unraid iperf docker I feel like somehow its not routing properly, but I have no idea why. I understand some bandwidth loss between vlans, but no way it should be that much (only pfblocker, no IDS or suricata). At the very least I should see much closer to line speed on same subnet. For fun I set up L3 on ubiquiti and moved a speedtest docker to test. Theoretically the traffic should never route out of the switch, and i am not seeing anywhere near the speeds I should have Am I missing something with 10gbe? All MTUs are 1500 but I should see faster even with that, no? Any assistance would be hugely appreciated

I am running unraid on an EPYCD8-2T with dual INTEL x550 10gbe ports Up until recently I had a full 1gb network and both ports were bonded, but am finally upgrading my router / unraid box to 10gbe operation. Unraid uses port 0, and I would like to pass port 1 to my Windows 10 VM -- I am having issues with achieving full 10gb thruput with a single interface. Can I pass the device by adding to XML or do I have to stub first?

'memcache.local' => '\\OC\\Memcache\\APCu', 'memcache.locking' => '\\OC\\Memcache\\APCu',

Getting an error w/ nvme and ssd: I am positive that there are partitions on the disk

thank you -- after running i learned that i have a "legacy" cert and can no longer utilize SSL going forward on 6.9.2

Starting yesterday, I am no longer able to connect to my server UI by the regular https link. I normally type in "https://crunch/" and it is relayed to unraid.net for SSL/TLS. This has been working fine for years at this point, but yesterday I know there were some backend issues that I think are still bleeding forward to today. All services are currently operational, and I can access the webUI by typing in https://IP_ADDRESS and dismissing the warnings. I have tried refreshing the cert and it says that my IP is updated with unraid.net, but on my end...no joy. I have also cleared local DNS cache, restarted LAN PCs, everything short of a full system restart (which shouldnt really be necessary....) Any advice would be appreciated

The screenshot from 3dmark is actually from a Q35 version I created to test exactly that. The Q35 template was bare bones w/ nothing but device pass thrus -- same results Id be okay with the performance -- maybe I am CPU limited now? But that big drop / stutter happens (see the graph) and it is jarring

I run a W10 gaming VM on my unraid 6.9.2 server which is built as follows: AsrockRack EPYCDT-2t w/ 7571 and 128gb DDR4 2133mhz ECC Geforce 1050 Geforce 3070ti 9305-8i w/ SAS3 expander Various NVME / UD disks VM xml is below: <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>GEIST v2</name> <uuid>3b6ceeeb-ee73-fb44-2964-80e165976161</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>16777216</memory> <currentMemory unit='KiB'>16777216</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>24</vcpu> <cputune> <vcpupin vcpu='0' cpuset='26'/> <vcpupin vcpu='1' cpuset='58'/> <vcpupin vcpu='2' cpuset='27'/> <vcpupin vcpu='3' cpuset='59'/> <vcpupin vcpu='4' cpuset='28'/> <vcpupin vcpu='5' cpuset='60'/> <vcpupin vcpu='6' cpuset='29'/> <vcpupin vcpu='7' cpuset='61'/> <vcpupin vcpu='8' cpuset='30'/> <vcpupin vcpu='9' cpuset='62'/> <vcpupin vcpu='10' cpuset='31'/> <vcpupin vcpu='11' cpuset='63'/> <vcpupin vcpu='12' cpuset='14'/> <vcpupin vcpu='13' cpuset='46'/> <vcpupin vcpu='14' cpuset='15'/> <vcpupin vcpu='15' cpuset='47'/> <vcpupin vcpu='16' cpuset='10'/> <vcpupin vcpu='17' cpuset='42'/> <vcpupin vcpu='18' cpuset='11'/> <vcpupin vcpu='19' cpuset='43'/> <vcpupin vcpu='20' cpuset='12'/> <vcpupin vcpu='21' cpuset='44'/> <vcpupin vcpu='22' cpuset='13'/> <vcpupin vcpu='23' cpuset='45'/> <emulatorpin cpuset='1,33'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-5.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/3b6ceeeb-ee73-fb44-2964-80e165976161_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vpindex state='on'/> <synic state='on'/> <stimer state='on'/> <reset state='on'/> <vendor_id state='on' value='1234567890ab'/> <frequencies state='on'/> </hyperv> <kvm> <hidden state='on'/> </kvm> <vmport state='off'/> <ioapic driver='kvm'/> </features> <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='2' cores='6' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> <feature policy='disable' name='monitor'/> <feature policy='require' name='x2apic'/> <feature policy='require' name='hypervisor'/> <feature policy='disable' name='svm'/> </cpu> <clock offset='localtime'> <timer name='rtc' present='no' tickpolicy='catchup'/> <timer name='pit' present='no' tickpolicy='delay'/> <timer name='hpet' present='no'/> <timer name='hypervclock' present='yes'/> <timer name='tsc' present='yes' mode='native'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' discard='unmap'/> <source dev='/dev/disk/by-id/ata-Samsung_SSD_850_EVO_500GB_S3PTNF0JB57631J'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x02' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback' discard='unmap'/> <source file='/mnt/cnvme/VMS/VHD_BULK/GEIST/GEIST_Z.img'/> <target dev='hdd' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x01' function='0x0'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' discard='unmap'/> <source dev='/dev/nvme1n1'/> <backingStore/> <target dev='hde' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x04' function='0x0'/> </disk> <controller type='pci' index='0' model='pci-root'/> <controller type='pci' index='1' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </controller> <controller type='pci' index='3' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='scsi' index='0' model='virtio-scsi'> <address type='pci' domain='0x0000' bus='0x00' slot='0x11' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:f5:93:8b'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x0'/> </source> <rom file='/mnt/cache_protected/VMS/vbios/GeForce_RTX_3070_Ti.rom'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x1'/> </hostdev> <memballoon model='none'/> </devices> <seclabel type='dynamic' model='dac' relabel='yes'/> </domain> Ive only had the 3070ti in the system for about 2 months -- prior to this I had a 1070 which performed admirably but at its limits. I have felt that the 3070ti has been BETTER, but "underwhelming" since its installation, and recently I have been suffering from stutters in game and during benchmaks...this had never happened w/ the 1070. I have all the usual XML tweaks -- MSI has been applied The 3dMark benchmarks w/ the 1070 were 5500-5800 and with the 3070ti we're 9500-10500 which is definitely improved but is not consistent. Any advice?