4

我正在尝试在 NVIDIA 的 K10 GPU 上运行我的代码。我正在使用 5.0 CUDA 驱动程序和 4.2 CUDA 运行时。问题是内核所花费的时间随着迭代而增加，其中每次迭代使用相同数量的源和目标（或粒子）。正因为如此，内核最终会花费大量时间，并且代码会因运行时错误而崩溃，这类似于“GPU 从总线上掉下来”。

可以在此处看到显示随着迭代次数增加内核运行时间的行为的图：

https://docs.google.com/open?id=0B5QLL4ig3LVqODdmVjNBTlp5UFU

我尝试运行 NVIDIA “nbody” 示例来了解这里是否也发生了同样的事情，是的。对于粒子/物体的数量 (Np) = 1e5 和 10 次迭代，代码运行良好。对于 Np=1e5 和迭代 = 100，或 Np=1e6 和迭代 = 10，代码进入挂起整个系统的模式。

当我在使用 Tesla C2050 NVIDIA 卡（CUDA 驱动程序版本：3.2，运行时版本：3.2）的另一台机器上运行我自己的内核以及 NVIDIA 的 nbody 示例时，没有问题，并且内核每次都花费相同的时间迭代。

我试图了解装有 K10 GPU 的机器上发生了什么。我在这台机器上尝试了 CUDA 驱动程序和运行时版本的不同组合，这就是我得到的：

对于 5.0 CUDA 驱动程序，4.2 运行时，它只是挂起，有时会说“GPU 从总线上掉下来”。

对于 4.2 CUDA 驱动程序、4.2 运行时，代码（nbody 以及我的代码）崩溃并出现错误：“CUDA 运行时 API 错误 39：遇到不可纠正的 ECC 错误。”

对于 5.0 CUDA 驱动程序，5.0 运行时，它只是挂起，有时会说“GPU 从总线上掉下来”。

这是一台 64 位的 linux 机器，我们最近组装了 NVIDIA K10 GPU 卡。我正在使用 gfortran44 和 gcc44。

如果有任何其他信息，请告诉我。需要跟踪问题。

在此先感谢您的帮助！

米

4

1 回答 1

4

我主要只是创建一个答案，因此我们可以将此问题称为已关闭，但我会尝试添加一些细节。

Tesla GPU 有 2 个不同的类别：有风扇的和没有风扇的。那些有风扇的人（此时）带有“C”名称，尽管 K20 产品系列的命名会略有不同：

这些不是详尽的列表：

  1. 带风扇的 Tesla GPU：C870、C1060、C2050、C2070、C2075、K20c（“C 级”）
  2. 不带风扇的 Tesla GPU：M1060、M2050、M2070、M2075、M2090、K10、K20、K20X（“M 级”）

（请注意，目前没有带有风扇或“C”标识的 K10 类型产品）

带风扇的Tesla GPU旨在插入各种 PC 盒和机箱，包括各种工作站和服务器变体。由于他们有自己的风扇，他们需要低于一定温度水平的进气供应，但鉴于此，他们会保持自己凉爽。随着工作量的增加，产生的热量增加，他们会转动自己的风扇来保持凉爽。搞砸此过程的主要方法是限制进气流量或将其置于比其最大进气规格更热的环境空气环境中。

没有风扇的特斯拉 GPU有一个叫做被动散热器的东西，它们不能独立保持冷却并采取被动冷却过程中的作用。他们仍然有一个温度传感器，但是服务器 BMC（基板管理控制器）负责监控这个温度传感器（这直接在硬件/固件级别完成，独立于任何操作系统或任何针对 GPU 的活动)，并根据其指示的温度在卡上引导足以保持卡冷却的气流水平。BMC 通过增加服务器机箱中设计的任何风扇来控制 GPU 上的气流来做到这一点。通常情况下，机箱内会有护罩/管道以帮助完成此过程。集成这些卡的服务器制造商承担着各种责任，并且必须遵循 NVIDIA 的各种技术规范才能完成这项工作。

如果您碰巧在没有风扇的情况下使用 Tesla GPU，并且只是将其放在某个随机机箱中，那么您几乎可以保证具有此问题中描述的行为。出于这个原因，特斯拉“M”系列和“K”系列 GPU 通常只出售给经过认证流程的 OEM。

由于普通的系统管理员/系统组装人员不太可能设计出合适的闭环风扇控制系统，并且通常无法轻松访问定义温度传感器和访问方法的必要规范，因此如果您有其中一个，则唯一的 klugey 解决方法只是必须玩，就是在卡上引导高水平的连续气流，无论您放置它的任何设置。请注意，这很可能会很吵。如果您没有嘈杂的气流水平，则可能没有足够的气流来保持处于高工作负载情况下的卡冷却。此外，您可能应该留意 GPU 温度。请注意，nvidia-smi监控 GPU 温度的方法不适用于所有 M 级 GPU（即没有风扇的 GPU）。不幸的是，M 级 GPU（不同于 C 级 GPU）的 Fermi 和之前的温度传感器访问方法无法通过 nvidia-smi 命令在系统内轻松监控，因此在这些情况下，您将无法从 nvidia-smi 获得温度读数，这使得这种方法更难管理。随着 Kepler 一代的出现，情况发生了变化，因此现在可以通过 nvidia-smi 方法和服务器 BMC 在硬件/固件级别监控温度。

带有风扇的 C 级产品的温度可以通过 nvidia-smi 进行监控，无论代数如何。但这通常不是必需的，因为该卡有自己的控制系统来保持自身凉爽。

正如评论中提到的，所有的 GPU 还具有多种保护机制，但没有一种可以保证防止损坏。（如果你把卡扔进火里，就没有办法了。）但是第一个典型的机制是热节流。在接近 GPU 最大安全工作范围的某个预定义高温下，GPU 固件将独立降低其时钟以试图防止进一步的温度升高。（如果显卡的时钟速度较慢，那么它产生热量的能力通常也会有所降低。）这是一个粗略的机制，当这种热节流发生时，冷却领域中的某些东西已经错误的。该卡设计为在正常操作条件下永远不会进入热节流。如果温度继续升高（此时没有太多的净空），卡将进入其最终保护模式，即自行停止。此时 GPU 已对系统无响应，并且在操作系统级别，诸如“gpu has fall of the bus”之类的消息是典型的。这意味着冷却失效，保护机制失效。

于 2012-12-13T03:22:19.910 回答