Re: 4.3.0 massive DPC latency
Posted: 7. Nov 2013, 18:12
Another 4.3.3 test build can be found here. I would appreciate any statement if the DPC latency remains unchanged, got better or worse (the latter is unlikely). Thank you!
End user forums for VirtualBox
https://forums.virtualbox.org/
Please describe the host system briefly. What OS, CPU...? How exactly do you measure the DPC latency?Allen_ASU wrote:Installed 4.3.3 and it seems to be improved. LatencyMon still shows high latency, but music rarely skips now. Here is some details I notice in regards to this update
Please quantify.1. General VM performance is much improved over 4.3.2
Please quantify.2. Booting of VMs is still verrry slow.
So you're saying that the latest 4.3.3 build still has high DPC latency, much worse than 4.2.18?During this time, LatencyMon shows off the chart latency and music skips. Once the VM gets to a logon screen (Windows) and the guest tools load, latency comes back down(still high, but not pegged on the monitor) and music will stop skipping.
Whether the Guest Additions are installed or not has zero direct impact on DPC latency. It may be that overall CPU utilization is lower with GAs and that indirectly reduces the incidence of DPC latency spikes, but even that is questionable.3. VMs without guest tools installed are slow, DPC latency is very high, and music skips on the host.
That, to be honest, makes zero sense, except again as a side effect of reduced overall CPU utilization.4. Reducing the number of vCPUs helps reduce latency.
This however makes perfect sense. Not using VT-x completely changes everything.5. Turning off VT-x also reduces latency.
Please quantify.6. Host CPU usage is generally higher in 4.3.x over 4.2.18.
Agreed for the most part. Simply booting a VM should not cause issues on the host. The windows kernel should be able to handle the scheduling appropriately.michaln wrote:Please describe the host system briefly. What OS, CPU...? How exactly do you measure the DPC latency?Allen_ASU wrote:Installed 4.3.3 and it seems to be improved. LatencyMon still shows high latency, but music rarely skips now. Here is some details I notice in regards to this update
Dell Precision T3600
Intel Xeon E5-2665
32GB DDR3
256GB SSD, RAID 0 7200RPM for VM's
Win8.1 x64
DPC latency monitoring is done with LatencyMon.
I originally suspected I had a faulty driver. I didn't figure out that it was virtualbox until my colleague with a similarly spec'ed T3600 did not have audio issues with 4.2.18 installed. Rolling back to 4.2.18 fixed the audio problems.
Please quantify.1. General VM performance is much improved over 4.3.2
Just a seat-of-my-pants generalization.
Please quantify.2. Booting of VMs is still verrry slow.
4.8.18 would boot a Win7 VM to the CTRL+ALT+DEL screen in less than a minute consistently. 4.3.2 would take up to 3 minutes to complete while the host system suffers from high latency issues such as lagged mouse, stutters in audio, etc. This doesn't happen all the time, but it is reproducible.
So you're saying that the latest 4.3.3 build still has high DPC latency, much worse than 4.2.18?During this time, LatencyMon shows off the chart latency and music skips. Once the VM gets to a logon screen (Windows) and the guest tools load, latency comes back down(still high, but not pegged on the monitor) and music will stop skipping.
4.3.3 is better than 4.3.2 in this regard, but not compared to 4.2.18.
Whether the Guest Additions are installed or not has zero direct impact on DPC latency. It may be that overall CPU utilization is lower with GAs and that indirectly reduces the incidence of DPC latency spikes, but even that is questionable.3. VMs without guest tools installed are slow, DPC latency is very high, and music skips on the host.
This is just an observation from normal usage. I generally have to build VM's to pull images for our SCCM site. Some of my work with VM's is without GA installed. With 4.3.x, guests without GA installed VM performance is generally terrible, host latency is consistency high, and the related latency issues are present at all times. VM performance is another seat-of-the-pants judgement compared to 4.2.18, aside from the obvious host issues.
That, to be honest, makes zero sense, except again as a side effect of reduced overall CPU utilization.4. Reducing the number of vCPUs helps reduce latency.
This is just an observation. Another seat-of-the-pants judgement. It, however, does make sense if there is a bug in the VT-x code. The more vCPUs assigned to a guest the more chances the guest will call for bugged interrupt requests.
This however makes perfect sense. Not using VT-x completely changes everything.5. Turning off VT-x also reduces latency.
Agreed. However, if VT-x enabled causes DPC spikes, wouldn't be logical to assume that there is a regression in the VT-x code? VT-x is suppose to increase performance of a host and its guests, not degrade it.
Please quantify.6. Host CPU usage is generally higher in 4.3.x over 4.2.18.
Just by looking at CPU usage in task manager as VMs and the host sit idle. 4.2.18 would idle around 5-10% CPU usage. DPC latency shows fine in LatencyMon. 4.3.x (4.3.3 included) shows a consistent 20-25% usage while idle with DPC spikes occurring at a 2-3 sec interval.
Now just in case it's not obvious... the DPC latency spikes are directly related to how much CPU time the guest uses. With a more or less idle guest, there will rarely be any spikes no matter how the scheduling is handled by VirtualBox. When the guest is busy (such as when booting or performing lengthy calculations) is when the DPC latency may spike when the internal scheduling too aggressively executes guest code.
Yes, booting a VM is expected to take up quite a bit of the host's CPU and I/O bandwidth, but it shouldn't cause the DPC latency spikes. Unfortunately given the design of VT-x, playing nice with the host scheduler is a lot harder than it ought to beAllen_ASU wrote:Agreed for the most part. Simply booting a VM should not cause issues on the host. The windows kernel should be able to handle the scheduling appropriately.
For the moment it'd be interesting to know your host setup and how you determine the DPC latency, and how 4.2.18 compares with the latest 4.2.3 test build on your host.I realize that most of my information is subjective. If there is any useful quantitative information I can provide, please let me know what that is and I'd be happy to provide it.
michaln wrote:Yes, booting a VM is expected to take up quite a bit of the host's CPU and I/O bandwidth, but it shouldn't cause the DPC latency spikes. Unfortunately given the design of VT-x, playing nice with the host scheduler is a lot harder than it ought to beAllen_ASU wrote:Agreed for the most part. Simply booting a VM should not cause issues on the host. The windows kernel should be able to handle the scheduling appropriately.
For the moment it'd be interesting to know your host setup and how you determine the DPC latency, and how 4.2.18 compares with the latest 4.2.3 test build on your host.I realize that most of my information is subjective. If there is any useful quantitative information I can provide, please let me know what that is and I'd be happy to provide it.
AndrewG wrote:I can post info and results with that new version later.
Originally i was watching a videos with media player classic(windows) and hearing the massive audio stutter. To investigate furter i loaded dpclat.exe to get actual numbers, graphs, etc of the latency. If you google it, its first hit, avail at thesycon.de.
Confused here... I'm guessing the comments are wrong but the names of the log files correctly indicate the VBox version, i.e. 4.3.2 (when you say 4.2.18) and 4.2.18 (when you say 4.1.18)?Allen_ASU wrote:And here is 4.1.18.