i was able to reduce it to 500~ can it be like 100 micro second somehow ? if i install the os on hardware with few tweaks i get around 70 micro second thx im trying to make gamer version of windows but i cant test it on hyper-v because of it
I'm using Hyper-V on a relatively weak machine (which does a lot of things, including running other VMs on VBOX and VMware) so I'm not so I'm not anywhere close to 500uS even on baremetal. But I use RFX enabled Hyper-V (last usable version in 1904x.868) to do gaming from remote machines. And DPC I get is a mere 1.1/1.2x worse than on baremetal.
did u disable the dynamic clock with this bcdedit /set disabledynamictick yes bcdedit /set useplatformtick yes bcdedit /deletevalue useplatformclock but if its not for gaming then no need
Thanks for your suggestion, but no I don't need to be paranoid about DPC. My server does a lot of things HTPC/router/deduplicated NAS/Virtualizzation host. I use it to manage the TV but I never do gaming there (I'll never get used to play with an awful console style controller). I use it to do light / older gaming REMOTELY via a dedicated 14393 Hyper-V VM machine. That because the fun of experimenting with RFX and also because most of my main Client machines are based con 1st generation Core i7, which means they are fast, but lacks on GPU side (say no OpenGL 3+). RFX allows me to take advantage of both the power of client's CPU while using the power and the features of the server's GPU In that scenario the DPC latency is my last problem. Also my server is ON h24, so something that worsen the energy saving, at the end of the year, will weight noticeably on the electrical bill (especially now that energy prices are skyrocketing)
DPC is great way to know how the os is doing i dont think it need to be turn on all the time games will run fast if the cpu is strong enuf
Although the thing is academical interesting, I still think that after 40 years playing/working with PCs, my eyes and my ears are trained enough to tell me if something is working OK or not. That said the value around 1000uS I got before started to look suspecting after I got more or less the same value, on my client machines on HV VMs, no matter if I had HV enabled or disabled, and so on... So I decided to change the measurement SW and finally I got more meaningful results. So scratch the values I wrote in my previous message. They are pointless. Actual results are ------------------------------------------------ Bare metal: Average, between 80 and 150uS (depending what the PC is doing) Peak value 280uS ------------------------------------------------ RFX (32bit) VM: Average, between 10 and 160uS (depending the moment and what the baremetal and other VMs are doing) Peak value past 300uS, but (not frequently) it can get even past 1500uS. ------------------------------------------------ As you can see the average value can be way better than baremetal's, which isn't that surprising given the scope of RFX and how a Type 1 hypervisor works. Sure, but given they are bootloader values, I had to dual boot, via two dedicated bootloader entries, to enable/disable them, so it's unpractical for a machine meant to stay on h24.
So true - I spent many years optimizing VMs on vSphere and one thing that I learned over time that when you look at a single metric it tells you very little if anything about the cause of the performance issue. The metrics are only useful if you carry out a comprehensive examination at multiple levels (i.e VM's OS, the apps, and the hypervisor and also CPU, i/o, memory, network) and then can you truly determine cause and effect. Furthermore when you have multiple VMs running, one tends to focus and try to fix the "problem VM". Ironically that VM is usually the victim. It's the other VMs that are prioritized higher that are actually the problem.