virtualbox.org

Hi,
I have a windows 10 guest on a scientific linux server host. The way it currently works is I ask for time on the cluster with specific number of processors and RAM and it assigns me a node to work on. The current node I have has 8 physical cores and 42GB of RAM. So I give the VM 7 cpus and about 20gbs of RAM. However, the windows guest is extremely slow. It detects that I have 7 cpus but if I run something on it, it is just so very slow and it slows down more if I run multiple things. I just wanted to utilize the 7 cores to run 7 simulations but like this I can't use more than 1 and would have to setup 7 vms which is a bit of a waste of hard disk space. So is there a way to speed my guest up?
I have attached the log of the vm.

Probably it's just the graphics that are slow. The following implies that you enabled 3D acceleration on a host that doesn't have hardware 3D.

00:00:04.829521 OpenGL Info: Render SPU: Opening display localhost:50.0
00:00:04.991882 OpenGL Info: Render SPU: Opening display localhost:50.0
00:00:05.461777 OpenGL Info: Render SPU: GL_VENDOR: Mesa Project
00:00:05.461818 OpenGL Info: Render SPU: GL_RENDERER: Software Rasterizer
00:00:05.461825 OpenGL Info: Render SPU: GL_VERSION: 2.1 Mesa 10.1.2

I also don't see any evidence that you installed the Guest Additions (see chapter 4). That alone will give you slow everything, since all it has access to is simulated hardware, no host API.

You should also upgrade VirtualBox: support for the 5.1.x branch ended in 2018. Even if you wanted to stick to that branch, the final release was 5.1.38 whereas you are still on 5.1.2, i.e. on the buggy end of the 5.1.x series.

I also don't see any evidence that you installed the Guest Additions (see chapter 4). That alone will give you slow everything, since all it has access to is simulated hardware, no host API.

Sorry, but I did install it later and the issue still persists. The performance is still extremely slow and does not feel like I have 7 physical cores. For reference, the program I want to run can only utilize physical cores and treats all threaded cores as non existent.

You should also upgrade VirtualBox: support for the 5.1.x branch ended in 2018. Even if you wanted to stick to that branch, the final release was 5.1.38 whereas you are still on 5.1.2, i.e. on the buggy end of the 5.1.x series.

Unfortunately I don't have control over that since this is over a server. I will make a note to the server administrator if he can get us a newer version but that is a bit unlikely at the moment.

As an experiment, please make a new guest with just two processors, try its performance. Folks have reported mor peppy guests when cores are reduced to 2. We can try increasing later.

? The log already showed two cores, otherwise I would certainly have mentioned it.

First of all, I'd suggest to set System > Processor > Execution Cap to 100%. I haven't heard much positive feedback about reducing it.

walee wrote:The performance is still extremely slow and does not feel like I have 7 physical cores.

While there have been some educated guesses what you could be talking about, you didn't mention what you really are talking about, and feelings are subjective. Some major VM components, each with their own performance characteristics, are vCPUs, memory I/O, disk I/O, and graphical output. So what do you mean by extremely slow?

mpack wrote:The log already showed two cores

Sure enough! I missed that. Was going off all the 7-core stuff in the OP.
(walks away mumbling to self: "always read the log, always read the log...' )

fth0 wrote:First of all, I'd suggest to set System > Processor > Execution Cap to 100%. I haven't heard much positive feedback about reducing it.

I reduced it from 100% as a last ditch effort to see if it would have any effect on the performance.

walee wrote:The performance is still extremely slow and does not feel like I have 7 physical cores.

While there have been some educated guesses what you could be talking about, you didn't mention what you really are talking about, and feelings are subjective. Some major VM components, each with their own performance characteristics, are vCPUs, memory I/O, disk I/O, and graphical output. So what do you mean by extremely slow?

Yes, that was my bad entirely. Let me elaborate, I have a software which requires a physical core to run on and it does not recognize hyperthreaded cores. So, if I have 4 core setup normally, I can run at least 3 instances of the software while saving one core for the system. However for this configuration, whenever I run more than 1 instance, the software start to overlap each other and fight for the total core usage and as a result double or triple the total run time depending on how many instances I have running of the software. Now, I don't know if the VM asks for real cores or hyperthreads as well, which is why I started with 7 cores and thought I could at least run 3 to 4 instances of my software but as it stands I can't.
I am in no way complaining about the overall boot time or the processing speed of the system as it may just all be being controlled by a single core. Though in all fairness the installation of the Windows system took me about >1 hr which is something that was also very weird to me but I don't really know which generation these processors are.
Hope I could elaborate on the issue.

I would try installing a new setup with 2 cores and bump it up later as well as follow the other guesses. I realize they may not work as some of these suggestions, which I would try first, are outside my control as they require the server administrator's go ahead. Not to mention the overall scientific Linux distribution on the server is quite old as well, which may just be another bottleneck.

walee wrote:Let me elaborate, I have a software which requires a physical core to run on and it does not recognize hyperthreaded cores.

Thank you for the detailed explanation. I'll try and describe some parts of the vCPU handling that may be of interest here:

In the VM configuration, you provide <n> virtual CPUs (vCPUs) to the VM. The VirtualBoxVM process, which is being run in the Linux host OS to execute the VM, creates several threads (e.g. 40 + <n>) (*), among them <n> threads corresponding to the <n> vCPUs, which are usually named EMT-<i> (i = 0 .. n-1). The Linux host OS then decides itself how to schedule the 40 + <n> threads on the physical CPU cores and hyperthreads. Note that the threads are usually not bound to a specific CPU core or hyperthread, but are jumping around, with potentially negative effects on the CPU caches.

IMHO, your best bet is to start the VM first, and then set the affinity of the EMT-<i> threads in the Linux host OS (using taskset), before starting your software. Depending on if or how the software tries to discover what it is running on, there could be additional obstacles ...

(*) When I first investigated this a few years ago, I coincidentally counted 42 threads. Kudos to Douglas Adams.

I'm curious: Did you make any progress?