[Resolved] Input latency [Host: Windows 10] [Guest: Manjaro-i3 Arch Linux 64bit]

[traeki]

Clearly variations of this kind of question are asked fairly often, so I apologize if this turns out to be redundant, but an initial search didn't find anything I could map directly to my issue:

I've got a guest system up and running, and mostly it seems to be great. But I'm seeing significant input latency when I'm using my guest.

Host: Windows 10, Dell XPS 15 9570 (brand new with updated drivers), 32 GiB RAM, 6 Cores, 2 TiB disk

Guest: Manjaro-i3, Arch Linux 64-bit, 16 GiB RAM, 4 Cores (100% cap), 200 GiB disk, 3D enabled

In previous exploration I had a Xubuntu machine running on the Ubuntu 64-bit guest template, and I think I was seeing comparable latency there as well, so I don't *think* the problem is in the guest (or at least not in the particulars thereof).

To be clear, the issue is that there's a 0.25-0.5 second lag between typing a key and seeing the character appear in a terminal, or similar with clicking/dragging with my mouse.

And the guest machine otherwise seems healthy (indeed, I'm overall pretty pumped with how pleasant the experience has been -- ASIDE from the annoying lag).

Suggestions? Thanks for your attention!

[socratis]

We're going to need a complete VBox.log, from a complete VM run:

• Gathering the necessary information:
  1. Start the VM from cold-boot (not from a paused or saved state).
  2. Observe the error, i.e. type a few characters in the Terminal, drag a window, etc.
  3. Shutdown the VM (force close it if you have to).
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

[traeki]

Got it.

I believe I've done as asked, let me know if I have failed.

Thanks!

[traeki]

Minor amendment: I think my "0.25-0.5 second" estimate was high.

It's enough latency to be disruptive, but probably no *more* than 0.25 seconds. Maybe more like 100 milliseconds, typically?

Anyway, the point is (obviously) I just want advice on how to *reduce* latency, whatever it's current depth.

I just added a Windows Defender exclusion for the folder containing the VM, in hopes that that might reduce host interference.

But that was the last idea I've had, so any tips are welcome. And if you're able to find explicit information in the log file that would of course be super cool. Indeed, I'd love to know how to do *that*, so meta-pointers about what you're looking for in that log (or links to guides on the subject) would be most welcome.

And finally, thanks once more for your attention to my problem! I really appreciate that anybody's out there talking back from the void for a free product like this.

[socratis]

00:00:02.396724 supR3HardenedErrorV: supR3HardenedMonitor_LdrLoadDll: rejecting
	'C:\WINDOWS\System32\DriverStore\FileRepository\nvdm.inf_amd64_0b61d575cd12b2ba\nvinitx.dll'
	(C:\WINDOWS\System32\DriverStore\FileRepository\nvdm.inf_amd64_0b61d575cd12b2ba\nvinitx.dll):
	rcNt=0xc0000190

Your NVidia drivers seem to have a hardening issue. Please read really carefully the following FAQ: Diagnosing VirtualBox Hardening Issues for some generic guidelines/ideas. Those are guidelines, you have to use your judgement...

00:00:02.887429 [/Devices/usb-ehci/0/Config/] (level 4)
00:00:02.887438 [/Devices/usb-ohci/0/Config/] (level 4)

You could switch to USB3, your guest supports it.

00:00:02.887452 VRamSize <integer> = 0x0000000002100000 (34 603 008, 33 MB)

I would maximize the VRAM to 128 MB, you can most certainly afford it.

Other than that, I don't see anything worth writing home about. What you could try is to lower your screen resolution and see if you get any lower latency. And of course, you got to take care of the NVidia drivers, I believe it's akin to not have 3D acceleration at all...


Off-topic

00:00:03.363654 Full Name: "Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz"

How does this thing feel? That's got to be the first i9 I've seen in a log...

[mpack]

Does the guest OS need 4 cores? If not then I'd try it with two. Preserving the status of every core has a performance cost whether the core is used or not. If the core is used then that cost is hopefully repaid. If it's not used then that cost is entirely overhead.

Otherwise, I'd look to the process list of the guest, see what it's doing. I'll bet there's a CPU or I/O hog in there.

[traeki]

Great tips, thanks SO much, guys. I'll take a crack at these and let you know how it goes.

@mpack: I assume that if I'm doing work down the line that wants more cores, it does benefit me to turn that dial up as needed, you're just saying not to drive all four cores with the VM during the more typical case where they'll be sitting idle, yeah?

[traeki]

@socratis: it's sweet as hell, but my previous machine is a 2013 MacBook Pro, so that was kind of going to be true. =P

[traeki]

Okay, so I installed the SDK, and ran signtool on the vbinitx.dll, and got:

C:\Program Files (x86)\Windows Kits\10\App Certification Kit>signtool.exe verify C:\Windows\System32\DriverStore\FileRepository\nvdm.inf_amd64_0b61d575cd12b2ba\nvinitx.dll
File: C:\Windows\System32\DriverStore\FileRepository\nvdm.inf_amd64_0b61d575cd12b2ba\nvinitx.dll
Index Algorithm Timestamp
========================================
SignTool Error: A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider.

Number of errors: 1

Which totally looks like it would cause a problem with DLL Hardening, yeah!

What can I do to fix that problem? Any ideas? Should I...

...complain to Dell that my drivers are unsigned?
...complain to NVidia that my drivers are unsigned?
...complain to somebody else that my drivers are unsigned?
...do something to greenlight this specific driver for VirtualBox?

It wasn't clear to me from the linked FAQ (super helpful!) what the next step is in this case.

Please advise, if you can!

Thanks as ever.

[traeki]

I updated to the very latest drivers via NVidia's update tools.

Same exact issue on the new .dll...

[andyp73]

...complain to Dell that my drivers are unsigned?
...complain to NVidia that my drivers are unsigned?
...complain to somebody else that my drivers are unsigned?
...do something to greenlight this specific driver for VirtualBox?

As they are NVidia's drivers I would complain to them. If you can get Dell to listen (not easy in my experience) they may also be able to lean on NVidia! You can if you wish complain to me but it won't get you very far as all complaints get filed using "> /dev/null 2>&1"

-Andy.

[traeki]

Okay, hmm. I'm confused now. My runs of the VM since updating drivers still fail in what looks like the same way, according to the VBox.log.

But I'm not getting a new VBoxHardening.log... at all.

I'm attaching the VBox.log, here's the analogous lines (the file name is a different form, but I'm assuming it's still the driver name, and it does in fact fail the signtool.exe check, as before).

***
00:00:01.880789 supR3HardenedErrorV: supR3HardenedScreenImage/LdrLoadDll: rc=VERR_CR_PKCS7_KEY_USAGE_MISMATCH fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskVolume3\Windows\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll: fKeyUsage=0x0, missing 0x1: \Device\HarddiskVolume3\Windows\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll
00:00:01.880907 supR3HardenedErrorV: supR3HardenedMonitor_LdrLoadDll: rejecting 'C:\WINDOWS\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll' (C:\WINDOWS\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll): rcNt=0xc0000190
00:00:02.031078 supR3HardenedErrorV: supR3HardenedScreenImage/LdrLoadDll: cached rc=VERR_CR_PKCS7_KEY_USAGE_MISMATCH fImage=1 fProtect=0x0 fAccess=0x0 cHits=1 \Device\HarddiskVolume3\Windows\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll
00:00:02.031115 supR3HardenedErrorV: supR3HardenedMonitor_LdrLoadDll: rejecting 'C:\WINDOWS\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll' (C:\WINDOWS\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll): rcNt=0xc0000190
***

When I look at the VBoxHardening.log, though, the timestamp isn't updated, file is unchanged from before.

Not sure what to make of that.

[andyp73]

00:00:01.880789 supR3HardenedErrorV: supR3HardenedScreenImage/LdrLoadDll: rc=VERR_CR_PKCS7_KEY_USAGE_MISMATCH fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskVolume3\Windows\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll: fKeyUsage=0x0, missing 0x1: \Device\HarddiskVolume3\Windows\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll
00:00:01.880907 supR3HardenedErrorV: supR3HardenedMonitor_LdrLoadDll: rejecting 'C:\WINDOWS\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll' (C:\WINDOWS\System32\DriverStore\FileRepository\nvdmi.inf_amd64_3c0166c794b8a36c\nvdlistx.dll): rcNt=0xc0000190

It does look as though some of the NVidia DLLs are still getting rejected. A search around the forums for that return code (VERR_CR_PKCS7_KEY_USAGE_MISMATCH) shows that it crops up from time to time on different NVidia files.

The typical recommendation is to purge your system of all of the NVidia related drivers / widgets / add-ons / etc. then reboot and let Windows re-detect the hardware and add an initial base driver (and nothing more).

-Andy.

[mpack]

@mpack: I assume that if I'm doing work down the line that wants more cores, it does benefit me to turn that dial up as needed, you're just saying not to drive all four cores with the VM during the more typical case where they'll be sitting idle, yeah?

I'm not sure how much you know about software.

Most apps spends 99% of their time waiting on user input: these hardly benefit from one core, they certainly have no use for >1.
Even if an app is CPU bound (as opposed to waiting on the user or on I/O) then it can still only benefit from multiple cores if it has been written to make use of multiple cores, which most apps are not.

In the main, the only thing making use of multiple cores is the OS. It will ideally have one core to service background events, and one core per running app. Note however that if apps are not CPU bound then one core can happily service multiple apps. Multiple cores will not speed up an I/O bound app.

Basically, the point is that it's rare for it to ever be useful to assign >2 cores to one VM. So assigning more than 2 cores will most likely have a negative effect.

[traeki]

I know quite a bit about software, just not much at all about firmware/drivers/virtualization...

I do data analysis that sometimes involves running on multiple cores explicitly, both with hand-rolled code and with multi-core capable utilities (e.g. http://bowtie-bio.sourceforge.net).

But except for that 2 cores should be fine. So I'll just plan to give the VM more cores when I'm booting it up for high-octane work. Shouldn't be a problem.