[vbox-dev] Driver ISR call delayed for device interrupts

[Michal Necasek]

Hi Vic, 

Thanks for the update. We're glad to hear you sorted out the delays and that the cause was not VirtualBox :) 

Also good to hear that there is a noticeable improvement with the latest code. We know it's faster (because guests perform better) but did not specifically measure the latency the way you did. 


Regards, 
Michal 

----- Original Message ----- 
From: llyzs.vic at gmail.com 
To: michal.necasek at oracle.com, vbox-dev at virtualbox.org 
Sent: Wednesday, June 15, 2016 3:52:21 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna 
Subject: Re: [vbox-dev] Driver ISR call delayed for device interrupts 


Hi Michal & Ram, 


Thanks for you prompt response, in fact it has been very helpful. 


You were right that the suspicious delay at every 500ms was not in VirtualBox. I have identified that this was something else I was running on the host that caused it, so sorry for the confusion. 


I am on stable 5.0 source. The way I measure the interrupt is to record the timestamp (QueryPerformanceCounter) when I call PDMDevHlpPCISetIrq to raise the interrupt level, and another timestamp when the driver sends another I/O to lower the interrupt in driver's ISR, then compare the two, so I think this should be precise. And I log the ones that only exceed 1ms. 


So after I fixed my own problem, the ISR delay is now mostly below 10ms, which is acceptable for me. I am certainly not expecting real-time response from a VM. :) For completeness, I also tried with the latest 5.1 source from SVN. And you were right again that there was noticeable improvement there. The delay is not 100% eliminated (of course) but it happens much less frequent and the delay tends to be much shorter, mostly 1-3ms. 


Thanks again. 


Vic 


On Wed, Jun 15, 2016 at 3:50 PM Michal Necasek < michal.necasek at oracle.com > wrote: 



Hi Vic, 

It probably does not hurt to state that if you require real-time 
responsiveness, you should *not* be using a VM. There are no latency 
guarantees. 

You forgot to mention the most relevant fact... which svn revision of 
the OSE source code are you actually using? In fact you expect any kind 
of technical support, you might as well start by providing a VBox.log 
because all the information is in there. 

How exactly do you measure the delay? I assume it's from the device 
calling PDMDevHlpPCISetIrq to the guest accessing some device register 
in the ISR? 

There might be problems specific to Windows 8.1(?) hosts. If you could 
repeat the test on a different host OS (ideally not Windows), that might 
provide some hints. 

I don't know of anything in particular that would happen every 500 ms 
in VirtualBox, but it doesn't have to be the VM, it could be the host 
doing something as well. 


Regards, 
Michal 


On 6/15/2016 8:51 AM, llyzs wrote: 
> Hi Devs, 
> 
> I have a virtual PCI device added on VirtualBox OSE and a driver which 
> sends I/O to do some stuff in the host and receive interrupts when the 
> work is done. The interrupts work most of the time, however there are 
> random delays between PDMDevHlpPCISetIrq is called and the driver ISR is 
> called. Most of the time there is no delay (<1ms) but periodically there 
> is a delay from 10+ms to even 60+ms. One more strange thing is that the 
> delay mostly happen at exactly every 500ms. So anyone can give me some 
> hint on what is causing the interrupt delay? What kind of job inside 
> VirtualBox that runs every 500ms that might be causing interrupt delay? 
> 
> I am on Windows 8.1 x64 (both guest and host). Thanks in advanced. 
> 
> Vic 
> 
> 
> _______________________________________________ 
> vbox-dev mailing list 
> vbox-dev at virtualbox.org 
> https://www.virtualbox.org/mailman/listinfo/vbox-dev 
> 

_______________________________________________ 
vbox-dev mailing list 
vbox-dev at virtualbox.org 
https://www.virtualbox.org/mailman/listinfo/vbox-dev 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20160617/ed9df686/attachment.html>