I am looking for an alternative to azure accelerated networking. Usecase remains the same. I wish to have better response times on my VM which has support for hyperthreading. My concern is around cpu core underutilization brought forth by the accelerated networking requirement of maintaining 4 CPUs. The application doesn't even use up 2 cores. Let me know if there are any possible solutions.
Receive Side Scaling (RSS) is one known option...
If the Windows VM supports Accelerated Networking, enabling that feature would be the optimal configuration for throughput. For all other Windows VMs, using Receive Side Scaling (RSS) can reach higher maximal throughput than a VM without RSS. RSS may be disabled by default in a Windows VM.
On Linux VMs, it is enabled by default.
Related
I want to use soft real-time performance on Windows 10 IoT Enterprise, but in the required steps it lists disabling the Windows Audio Service. Is there any way to keep audio on the machine while still utilizing RTP? This feature is exclusive to this version of Windows and is a drawing point for Kiosk Mode, but it removes any and all audio from your device. That doesn't seem like a fair trade...
One thought I had was dedicating a core(s) to the service because perhaps the issue was that the service was being pervasive to the CPU cores regardless of RTP which in turn affects RTP, but this was really just a shot in the dark since there is zero explanation as to why any of the services are required to be disabled in the first place. Regardless, it was not possible to even attempt this because Windows does not allow changing core affinity for Windows processes (from what little I have seen online on this subject).
We have Service Fabric application, that creates VMSS when we create the clusters. While creation we have to select the VM Size. We have 3 different regions where we have deployed our application.
Although the VM size selected is same for all 3 regions. The processor assigned is different. That's not a problem if the processors are similar in their performance. But it's not.
https://learn.microsoft.com/en-us/azure/virtual-machines/dv2-dsv2-series#dv2-series
Above link states:
Dv2-series sizes run on Intel® Xeon® Platinum 8272CL (Cascade Lake), Intel® Xeon® 8171M 2.1GHz (Skylake) or the the Intel® Xeon® E5-2673 v4 2.3 GHz (Broadwell) or the Intel® Xeon® E5-2673 v3 2.4 GHz (Haswell) processors with Intel Turbo Boost Technology 2.0.
With same code, one region is performing well, but other regions usually have CPU maxed out. On talking to Microsoft support, they said processors are assigned randomly and they cannot change it.
Only option suggested by support, that we try change the cluster and node by stopping and starting all VMSS instance at the same time in the Azure portal manually.
If we look at the performance benchmark for 2 processor assigned to us:
https://www.cpubenchmark.net/compare/Intel-Xeon-E5-2673-v4-vs-%5BDual-CPU%5D-Intel-Xeon-Platinum-8171M/2888vs3220.2
Now the only option we are left with is try restarting VMSS for n number of times or upgrade to different size.
Anyone faced similar situation? If yes what was the resolution?
Or any information, what are the design consideration by which Microsoft assigns a particular processor to the VM?
I wouldn't read too much into the comparative specs between each processor because you're ultimately not getting the full processor - you're only buying the vCPUs. Each is are supposed to have similar performance from one to another. This would suggest that Microsoft may pack more VMs onto an 8171M host than onto an E5-2673 so the vCPUs across either machine are closer in performance equivalency within the SKU series.
Put simply, you have no idea how many VMs Microsoft is running off any given processor and it would only make sense that they run more off a higher performing host system.
If you want to have full operational performance of the processor, you'd have to buy a dedicated host. Note that the pricing sheet names precisely which processor SKU you get for your money unlike the vCPU mix and match happening in the D#_v2 SKU series.
In production we're going to deploy a redis server and need to set the overcommit_memory=1 and disable Transparent Huge Pages in Kernel.
The issue is currrently we only have one giant server, and it is to be shared by many other apps. We only want those kernel configs in the redis server. I wonder if we can achieve it by spinning up a dedicated VM for redis. Doing so in docker certainly doesn't make sense. My questions is:
Will those Kernel configs take actual effect in the redis VM even if the host OS doesn't have the same configs? I doubt it since the hardware resource is allocated by the host machine in the end.
Will the kernel config in the redis VM affect other VMs that run other apps? I think it won't, just want to confirm.
To achieve the goal, what kind of VM or hypervisor should we use?
If there's no way to do it in VM, is having a separate server (hardware) for redis the only way to go?
If you're running a real kernel on a virtual machine, the VM should be able to correctly handle overcommitted memory.
The host server will grant a fixed chunk of memory to the VM. The VM should manage that memory as it sees fit, including overcommitting its own address space.
This will not affect other applications running on the host (apart from the fact that is has less memory available). If it does, there is a problem with your hypervisor.
This should work with any Hypervisor. KVM is a good place to start.
Note that I have not actually tried this -- experiment results are welcome!
I am thinking about running some graphics intensive programs on Windows Azure virtual machine, but not sure what kind of hardware do they have. Does all the VM have the same GPU? What is your experience of it?
The GPUs in Azure Virtual Machine are likely to be very basic and will most probably not have anywhere near the processing power you will need for carrying out intensive graphics manipulation. To my knowledge MS don't publish the details of the graphics hardware behind their Virtual Machines (If they actually use them at all?).
There's a question here on running WPF in an Azure cloud service which may be helpful.
Can Azure run WPF?
The N series Azure VMs support beefy GPUs. The NC series VM sports Tesla K80, with DDA (discreet device assignment) it supposed to provide close to bare metal performance. NV series VMs offer Tesla M60 with nVidia GRID.
More:
https://www.hpcwire.com/2015/09/29/microsoft-puts-gpu-boosters-on-azure-cloud/
https://blogs.technet.microsoft.com/hybridcloudbp/2016/12/13/n-series-azure-vms-with-gpu/
It's fascinating that there are FPGAs in Azure machines too (although not publicly accessible):
https://www.microsoft.com/en-us/research/project/project-catapult/
I have been searching for documentation on how to properly enable the HPET on a Hyper-V. I haven't been able to find anything specifying if it works or not, and if it does work, how to properly enable it. From our initial tests, it doesn't seem to be consistent with either the machines timer or the HPET.
We are deploying Lync and UCMA based applications and have noticed a significant performance difference between machines with HPET enable and HPET disabled in terms of their ability to handle capacity. We would like to be able to virtualize these machines, but the HPET is currently our limiting factor.
Can anyone point me in the right direction to find an answer?
I am not sure but I don't think we can enable HPET in VM .
Generally for a physical machine we can enable it
1.From BIOS enable HPET
and
2.From OS run bcdedit /set useplatformclock true and then reboot.
Looking at Microsoft's Hypervisor Top-Level Functional Specification, the only references to the HPET I can see relate to the hypervisor's own use of the HPET. It doesn't appear to provide a virtual HPET device.