如何在vGPU环境中优化GPU性能

大家好，
让我在上述用户指南，演示文稿中总结优化和平，并添加更多内容。
1.禁用控制台VGA
2.使用“广度优先”分配（这不是默认值）
3.将VM的vCPU固定到连接到所使用的GPU的插槽（NUMA）（参见上面的Andy Currid演示文稿）
4.使用4个vCPU（取决于应用程序，但请记住，HDX3D Pro几乎使用整个vCPU进行编码，操作系统和应用程序也需要计算能力）
5.确保您的客户端操作系统在任务管理器中查看所有vCPU（http://support.citrix.com/article/CTX126524）
请随意添加您的经验......
Erik Bohnhorst |
解决方案架构师 -  GRID
NVIDIA公司



以下为原文

Hello All,

Let me summarise the optimization peaces in the mentioned User Guide, presentation and add more.

1. Disable console VGA
2. Use "breadth-first" allocation (this is not the default value)
3. Pin the vCPUs of the VM to the socket that is attached to the GPU that is used (NUMA) (see above presentation from Andy Currid)
4. Use 4 vCPU (depends on application but remember that HDX3D Pro uses almost an entire vCPU for encoding, OS and application needs computing power as well)
5. Make sure your Client OS sees all vCPUs in task manager (http://support.citrix.com/article/CTX126524)

Please feel free to add the experiences you have made ...

Erik Bohnhorst | Solution Architect – GRID
NVIDIA Corporation

None


以下为原文

Hi Erik.  I agree that Andy's GTC presentation was excellent.  Thanks for recapping the tuning information above.

I am currently rolling out a new infrastructure on XenServer with GRID K1 and K2 cards for XenDesktop 7.x.   I would like to pin the VM's to the socket that the GPU is adjacent to.   Is there a way to architect the solution so that HA and XenMotion can still function?  I am much more concerned about HA than XenMotion.

Thanks in advance for any advice you can provide!

Richard

你好再次Erik，
Andy在他的GTC演示中提出了一个很好的观点，即为高性能模式配置BIOS和/或管理程序，以便CPU的P状态保持高位。
当VDI环境中的高性能图形应用程序需要CPU时，没有任何延迟。
Andy在他的演讲中没有提到C-states，我还没有找到GPU / VDI专家来对C状态做出具体建议。
但是，Andy和其他人已经建议为一些密集的3D应用程序启用TurboBoost。
这是我对C状态和TurboBoost问题的解释：
如果某些内核处于非活动状态，TurboBoost会达到其最高频率。
因此，如果所有核心都处于活动状态，TurboBoost不太可能达到其最高频率。
换句话说，如果您希望TurboBoost在其最高级别运行，则应启用c状态。
c状态数越高，睡眠等级越深，返回活动状态所需的时间越长。
我正在寻找c状态的最佳点，以便TurboBoost可以达到高频，但核心在被唤醒时不会滞后。
或者，是否建议简单地禁用c状态？
那么，启用turbo-boost并让turbo-boost尽可能地与所有活动核心一起工作？
我正在使用的SuperMicro BIOS上的C状态选项是C0，C2，C6和“无限制”。它还有一个单独的C1E支持选项。
我们的环境规格如下：
SuperMicro X9DRG-HF + II
CPU：Ivy Bridge 10C E5-2690V2 3.0G 25M 8GT / s QPI
XenServer 6.2 SP1
XenDesktop 7.x
GRID K1和K2在环境中
Autodesk应用程序：Revit，AutoCAD，Maya，Inventor，3DsMax
VM的：6个vCPU / 16GB RAM
你或安迪有关于C州级别的建议吗？
谢谢！
理查德



以下为原文

Hello Again Erik,

Andy made a good point in his GTC presentation about configuring the BIOS and/or hypervisor for high performance modes so that the CPU's P-states stay elevated. Then there is no lag when high performance graphics apps in a VDI environment need the CPU.  Andy did not mention C-states in his presentation and I have not yet found a GPU/VDI expert to make a specific recommendation on C-states.  However, Andy and others have recommended enabling TurboBoost for some intensive 3D applications.   Here's an explanation of my question on C-states and TurboBoost:

TurboBoost reaches its highest frequencies if some cores are inactive. Therefore, TurboBoost is much less likely to reach its highest frequencies if all the cores are active. In other words, c-states should be enabled if you want TurboBoost to function at its highest levels. The higher the c-state number, the deeper the sleep level, and the longer it takes to return to an active state. I am looking for the sweet spot of c-states so that TurboBoost can reach high frequencies but the cores do not lag when being awakened.

Or, is it advisable to simply disable c-states? Then, enable turbo-boost and let turbo-boost work as much as it can with all active cores?

The C-state options on the SuperMicro BIOS I am working with are C0, C2, C6, and “No Limit.” It also has a separate option for C1E Support.

Our environment specs are below:

SuperMicro X9DRG-HF+II
CPUs: Ivy Bridge 10C E5-2690V2 3.0G 25M 8GT/s QPI
XenServer 6.2 SP1
XenDesktop 7.x
GRID K1 and K2’s in the environment
Autodesk apps: Revit, AutoCAD, Maya, Inventor, 3DsMax
VM’s: 6 vCPU / 16GB RAM

Do you or Andy have a recommendation on C-state level?

Thanks!

Richard

理查德，
对于与GPU关联的VM，仍然不支持Xenmotion。
关于首选的C状态设置和turbo模式，请参阅以下两篇非常有用的文章：
http://www.poppelgaard.com/citrix-3d-graphics-pack-vgpu和http://www.xenserver.org/partners/developing-products-for-xenserver/19-dev-help/138-xs-
DEV-穿孔 -  turbo.html
问候，



以下为原文

Richard,
There is still no support for Xenmotion for VMs associated with a GPU. Regarding preferred C-state settings and turbo mode, see these two very useful articles:

http://www.poppelgaard.com/citrix-3d-graphics-pack-vgpu and http://www.xenserver.org/partners/developing-products-for-xenserver/19-dev-help/138-xs-dev-perf-turbo.html

Regards,

谢谢你的快速反应，托比亚斯。
如果VM被固定到特定CPU，您知道HA是否有任何限制？
如果第一个脱机，VM可以在没有问题的情况下故障转移到另一个XenServer主机吗？
我仔细阅读了你发布的两篇文章。
我不相信他们实际上就与TurboBoost相关的c状态提出建议。
肯定有一些深入的信息，但我的问题是找到c-state与TurboBoost的最佳位置尚未得到解答。
再次感谢您提供的任何其他帮助！
理查德



以下为原文

Thanks for the quick response, Tobias.

Do you know if there are any limitations in HA if the VM's are pinned to a particular CPU?  Can the VM failover without issue to another XenServer host if the first goes offline?

I read through the two articles you posted again.  I don't believe they actually make a recommendation on c-states in relation to TurboBoost.  There are certainly some in-depth information there but my question about finding the sweet spot of c-state vs TurboBoost is not yet answered.

Thanks again for any other help you can provide!

Richard

嗨，理查德：
我要说的是，至少从围绕下一代XenServer（Creedence）的各种讨论来看，CPU固定可能没有以前那么大。
已经有一些实验表明，所有CPU都可用作dom0实例，并且没有固定，例如可以实现最佳I / O.
这部分是因为事情的处理方式与驱动程序和与内核的交互有所不同。
我之前玩涡轮增压模式，并且在繁忙的系统中发现事情看起来平均没有任何好转，因为事情太多而无法让最大的涡轮状态持续下去。
我认为您完全禁用C状态并在启用turbo模式的情况下测试环境的想法可能会产生快速统计数据，这可能至少可以让您决定哪种环境最适合您的环境。
我们都会对结果感兴趣。



以下为原文

Hi, Richard:

I would say that from at least various discussions revolving around the next gen XenServer (Creedence) that CPU-pinning is perhaps not as big a gain as it was before. There have been experiments that showed with all CPUs available as dom0 instances and no pinning that optimal I/O could be achieved, for example. This is partly because things are handled somewhat differently as to drivers and interactions with the kernel.

I played earlier with turbo mode and found on busy systems that things didn't seem any better on average, as things were too loaded to allow the maximum turbo state to be sustained. I think your idea of disabling C-states altogether and testing your environment with turbo mode enabled and also disabled might yield quick stats that may at least allow you to decide what's best for your environment. We would all be interested in the outcome.