分类： 网络&硬件

nvidia-smi GPU性能状态(Performance State)含义

我正在使用Nvidia GTX Titan X进行深度学习实验。
我正在使用nvidia-smi来监视GPU的运行状态，但是提供的工具的性能(性能)状态没有意义。

我已经查看了nvidia-smi手册，它表示以下内容：

Performance State
The current performance state for the GPU. States range from P0 (maximum performance) to P12 (minimum performance).

如果不在GPU上运行任何进程(空闲状态)，则GPU性能状态为p0。
但是，当运行一些计算繁重的过程时，状态变为p2。

我的问题是，为什么我的GPU闲置时处于P0状态，但是在执行繁重的计算任务时切换到P2？ 不应该相反吗？

另外，有没有办法使我的GPU始终在P0状态下运行(最高性能)？

令人困惑。

但是，nvidia-smi手册是正确的。

当一个或一组GPU处于空闲状态时，在计算机上运行nvidia-smi的过程通常会使其中一个GPU退出空闲状态。这是由于该工具正在收集的信息-需要唤醒其中一个GPU。

此唤醒过程最初会将GPU置于P0状态(最高性能状态)，但如果GPU空闲或不是特别忙碌，GPU驱动程序将监控该GPU，并最终开始降低性能状态以节省功耗。

另一方面，当GPU在工作负载下处于活动状态时，GPU驱动程序将根据其自身的启发式方法不断调整性能状态以提供最佳性能，同时使性能状态与实际工作负载相匹配。如果没有达到热或功率限制，则对于最活跃和最重的连续工作负载，性能状态应达到最高水平(P0)。

周期性很重但不连续的工作负载可能会导致GPU功耗状态在P0-P2级别附近波动。由于热(温度)或电源问题而"受限制"的GPU也可能会看到P状态降低。这种限制是显而易见的，并在nvidia-smi中单独报告，但是可能并非所有GPU类型都启用这种报告。

如果要在GPU上查看P0状态，我可以提供的最佳建议是运行短暂，繁重且连续的工作负载(例如，执行大型sgemm操作的工作)，然后在该工作负载期间监视GPU。在这种情况下应该可以看到P0状态。

如果您使用的是正在使用cuDNN库的机器学习应用程序(例如Caffe)，并且正在训练大型网络，则应该可以不时看到P0，因为cuDNN会执行类似于sgemm的操作通常情况下。

但是对于零星的工作负载，最常见的状态很有可能是P2。

要始终"强制" P0电源状态，可以尝试通过nvidia-smi工具尝试持久性模式和应用程序时钟。使用nvidia-smi --help或nvidia-smi的手册页了解选项。

尽管我认为这通常不适用于Tesla GPU，但除非特别设置更高的应用时钟，否则某些NVIDIA GPU可能会在计算负载下将自身限制为P2功耗状态。使用nvidia-smi -a命令查看可用于GPU的当前应用程序时钟，默认应用程序时钟和最大时钟。 (某些GPU(包括较旧的GPU)可能会在其中某些字段中显示N / A。这通常表明应用程序时钟无法通过nvidia-smi进行修改。)如果在计算负载期间卡似乎以P2状态运行，则可能通过将应用程序时钟增加到最大可用时钟(即最大时钟)，可以将其增加到P0状态。使用nvidia-smi --help了解如何格式化命令以更改GPU上的应用程序时钟。修改应用程序时钟或启用可修改的应用程序时钟可能需要root / admin特权。设置GPU持久模式也可能是理想的或必要的。这将防止驱动程序在GPU活动期间"卸载"，这可能导致驱动程序重新加载时重置应用程序时钟。

对于这种情况下受影响的卡，此默认行为是在计算负载下限制为P2，这是由GPU驱动程序设计的。

参考链接

[华硕主板] 支持ECC内存的AMD Ryzen™处理器列表

下表列出了支持带ECC功能内存模组的Ryzen™处理器的列表；它们的官方名称；以及是否支持B550和X570系列。

请注意，当涉及到APUs（Ryzen 3000/4000 G系列），只有PRO处理器（例如Ryzen 3 PRO 3200G）支持ECC内存。

官方名称

支持B550系列

支持X570系列

ECC功能

UDIMM ECC

REG ECC

AMD Ryzen™ 5000 Series Processors

V

V

支持

V

 

AMD Ryzen™ 4000 G-Series Processors

V

V

只有PRO支持

V

 

AMD Ryzen™ 3000 Series Processors

V

V

支持

V

 

AMD Ryzen™ 2000 Series Processors

 

V

支持

V

 

AMD Ryzen™ 3000 G-Series Processors

 

V

只有PRO支持

V

 

注意，Ryzen™处理器只支持二手UDIMM ECC，不支持更便宜的二手REG ECC。

这个问题简单解释一下，新的REG ECC从性能到价格都是远远高于UDIMM ECC的，但是REG ECC不能用在家用主板上，导致大量淘汰的二手内存需求量不高，因而价格偏便宜。

继续阅读[华硕主板] 支持ECC内存的AMD Ryzen™处理器列表

运维中tcp_tw_recycle net.ipv4.tcp_timestamps引发的坑

在NAT环境下，遇到因为tcp_tw_recycle=1和net.ipv4.tcp_timestamps=1引起 Nginx upstream timed out 后，一直没在遇见，今天在朋友的阿里云环境下又重新再一次出现；因此在这炒一次冷饭，让运维新手或者刚上云的朋友大概了解一下，避免再一次采坑。

故障情况：

阿里云账号A的A机房，内网里面部署两台Nginx，通过网络出口（NAT），代理用户访问到阿里云账号B的B机房服务。A机房的Nginx出现：upstream timed out 。

故障的诱因是：net.ipv4.tcp_timestamps=1

抓包图：

注意，这个选项生效的前提是，报文的发出方必须在TCP头部的可选项中增加时间戳字段，否则这个设置是不生效的。

直接上当年的笔记：

先看看TCP IP 对tw的一些解析：
RFC 1323里有这样的定义：

大概的中文意思就是：TCP协议中有一种机制，缓存了每个主机（即ip）过来的连接最新的timestamp值。这个缓存的值可以用于PAWS（Protect Against Wrapped Sequence numbers，是一个简单的防止重复报文的机制）中，来丢弃当前连接中可能的旧的重复报文。而Linux实现这个机制的方法就是同时启用net.ipv4.tcp_timestamps和net.ipv4.tcp_tw_recycle 这两个选项。
这种机制在 客户端-服务器 一对一的时候，没有任何问题，但是当服务器在负载均衡器后面时，由于负载均衡器不会修改包内部的timestamp值，而互联网上的机器又不可能保持时间的一致性，再加上负载均衡是会重复多次使用同一个tcp端口向内部服务器发起连接的，就会导致什么情况呢：

负载均衡通过某个端口向内部的某台服务器发起连接，源地址为负载均衡的内部地址——同一假如恰巧先后两次连接源端口相同，这台服务器先后收到两个包，第一个包的timestamp被服务器保存着，第二个包又来了，一对比，发现第二个包的timestamp比第一个还老——客户端时间不一致。服务器基于PAWS，判断第二个包是重复报文，丢弃之。

反映出来的情况就是在服务器上抓包，发现有SYN包，但服务器就是不回ACK包，因为SYN包已经被丢弃了。为了验证这一结果，可以执行netstat -s | grep timestamp 命令，看输出里面passive connections rejected by timestamp 一项的数字变化。

在tcp_ipv4.c中，在接收SYN之前，如果符合如下两个条件，需要检查peer是不是proven，即per-host PAWS检查：

  • 收到的报文有TCP option timestamp时间戳
  • 本机开启了内核参数net.ipv4.tcp_tw_recycle

解决办法：

tcp_tw_recycle=0 或（和）net.ipv4.tcp_timestamps=0同时从4.10内核开始，官方修改了时间戳的生成机制，所以导致 tcp_tw_recycle 和新时间戳机制工作在一起不那么友好，同时 tcp_tw_recycle 帮助也不那么的大。

此处的时间戳并不是我们通常意义上面的绝对时间，而是一个相对时间。很多情况下，我们是没法保证时间戳单调递增的，比如业务服务器之前部署了NAT，LVS等情况。相信很多小伙伴上班的公司大概率实用实用各种公有云，而各种公有云的 LVS 网关都是 FullNAT 。所以可能导致在高并发的情况下，莫名其妙的 TCP 建联不是那么顺畅或者丢连接。

而这也是很多优化文章中并没有提及的一点，大部分文章都是简单的推荐将net.ipv4.tcp_tw_recycle设置为1，却忽略了该选项的局限性，最终造成严重的后果(比如我们之前就遇到过部署在nat后端的业务网站有的用户访问没有问题，但有的用户就是打不开网页)。

参考链接

Brotli压缩

Brotli是一种全新的数据格式，可以提供比Zopfli高20-26%的压缩比。据谷歌研究，Brotli压缩速度同zlib的Deflate实现大致相同，而在Canterbury语料库上的压缩密度比LZMA和bzip2略大。

链接：Google开源Brotli压缩算法 。

微软使用了一种基于谷歌提供的C代码的实现，向.NET Core 2.1添加了Brotli压缩支持。由于Brotli得到了许多Web浏览器和Web服务器的广泛支持，所以.NET Core提供对这项技术的支持是非常有用的。

什么是 Brotli 压缩算法
Brotli最初发布于2015年，用于网络字体的离线压缩。Google软件工程师在2015年9月发布了包含通用无损数据压缩的Brotli增强版本，特别侧重于HTTP压缩。其中的编码器被部分改写以提高压缩比，编码器和解码器都提高了速度，流式API已被改进，增加更多压缩质量级别。新版本还展现了跨平台的性能改进，以及减少解码所需的内存。

与常见的通用压缩算法不同，Brotli使用一个预定义的120千字节字典。该字典包含超过13000个常用单词、短语和其他子字符串，这些来自一个文本和HTML文档的大型语料库。预定义的算法可以提升较小文件的压缩密度。

使用brotli替换deflate来对文本文件压缩通常可以增加20%的压缩密度，而压缩与解压缩速度则大致不变。使用Brotli进行流压缩的内容编码类型已被提议使用“br”。

Brotli 的实际压缩效果，需要根据需要来具体分析，目前并不是每个网站都有较好的加速效果，另外，目前仅仅被限制在HTTPS上，HTTP是不支持的。

在 ubuntu 20.04 系统上自带的 apache 2.4.41 上启用 brotli 压缩算法的方式如下：

在 Apache 2 的配置文件增加 brolti 的配置信息，如下：

重启服务，如下：

测试结果

参考链接

SSL相关漏洞解决方法

本次涉及漏洞

1.漏洞名称：SSL 3.0 POODLE攻击信息泄露漏洞(CVE-2014-3566)【原理扫描】

2.SSL/TLS 受诫礼(BAR-MITZVAH)攻击漏洞(CVE-2015-2808)【原理扫描】

 

知识普及1：SSL协议要点

SSL(Secure Sockets Layer 安全套接层)是一种基于Web应用的安全通信协议，最早由Netscape（网景）公司提出。SSL介于TCP协议和应用层协议之间，主要作用就是将HTTP、FTP等应用层的数据进行加密然后依托可靠的TCP协议在互联网上传输到目的地，其中最典型的应用就是https。

SSL提供3个基本的安全服务：

1）身份合法性：数据发送方和接收方要确认彼此身份，要确保各自的身份不会被冒充。

2）数据机密性：所有传输的数据都进行加密，并且要确保即使数据被截获也无法破解。

3）数据完整性：确保收到的数据与发送方发出的数据一致，没有被篡改。

SSL协议主要采用的数据加密算法：

1）非对称加密算法：数据加密和解密使用不同的密钥，如RSA公钥加密算法。优点是安全级别高，很难被破解；缺点是加密解密的速度慢，因此只适用于小量数据的加密。SSL协议采用非对称加密算法实现数字签名，验证数据发送方（或接收方）的身份，同时也用非对称加密算法交换密钥（用于数据加密的对称加密算法的密钥，以及用于数据完整性验证的MAC算法）。

2）对称加密算法：数据加密和解密使用同一个密钥，如DES、3DES、RC4等都是对称加密算法。优点是加解密速度快，适用于大数据量的加密，但安全性较差。SSL协议采用对称加密算法对传输的数据进行加密。

3）MAC算法：Message Authentication Codes，即消息认证码算法，MAC含有密钥散列函数算法，兼容了MD和SHA算法的特性，并在此基础上加入了密钥。SSL协议采用MAC算法来检验消息的完整性。

 

知识普及2：SSL协议的版本

目前在用的SSL协议主要有5个版本，分别是SSL2.0、SSL3.0、TLS1.0、TLS1.1和TLS1.2，这里的TLS（Transport Layer Security，传输层安全）协议是SSL协议的升级版。

在SSL协议曝出Poodle漏洞后，微信公众平台将取消对SSLv2、SSLv3两个版本的支持，浏览器及其他采用SSL协议的平台也会逐渐取消对SSLv2、SSLv3的支持，目前只建议使用TLSv1.0、TLSv1.1和TLSv1.2三个版本。

 

1.漏洞名称：SSL 3.0 POODLE攻击信息泄露漏洞(CVE-2014-3566)【原理扫描】

涉及设备漏洞服务

 此次设备受此漏洞波及影响主要是因为上述系统部署了Tomcat 的https服务，而Tomcat https服务默认情况下支持SSL 3.0协议（目前在用的SSL协议主要有5个版本，分别是SSL2.0、SSL3.0、TLS1.0、TLS1.1和TLS1.2.SSL3.0是已过时且不安全的协议，目前已被TLS 1.0，TLS 1.1，TLS 1.2替代）

漏洞描述和利用

SSL3.0是已过时且不安全的协议，目前已被TLS 1.0，TLS 1.1，TLS 1.2替代，因为兼容性原因，大多数的TLS实现依然兼容SSL3.0。

为了通用性的考虑，目前多数浏览器版本都支持SSL3.0，TLS协议的握手阶段包含了版本协商步骤，一般来说，客户端和服务器端的最新的协议版本将会被使用。其在与服务器端的握手阶段进行版本协商的时候，首先提供其所支持协议的最新版本，若该握手失败，则尝试以较旧的协议版本协商。能够实施中间人攻击的攻击者通过使受影响版本浏览器与服务器端使用较新协议的协商的连接失败，可以成功实现降级攻击，从而使得客户端与服务器端使用不安全的SSL3.0进行通信，此时，由于SSL 3.0使用的CBC块加密的实现存在漏洞，攻击者可以成功破解SSL连接的加密信息，比如获取用户cookie数据。这种攻击被称为POODLE攻击(Padding Oracle On Downgraded Legacy Encryption)。此漏洞影响绝大多数SSL服务器和客户端，影响范围广泛。但攻击者如要利用成功，需要能够控制客户端和服务器之间的数据(执行中间人攻击)。

继续阅读SSL相关漏洞解决方法

ubuntu 20.04 & ubuntu18.04快速开启TCP BBR实现高效单边加速

Linux Kernel 内核升级到 4.9 及以上版本可以实现 BBR 加速，由于Ubuntu 18.04 默认的内核就是 4.15版本的内核，由于Ubuntu 20.04 默认的内核就是 5.4 版本的内核，并已经默认编译了 TCP BBR 模块，所以可以直接通过参数开启。

新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT) 可以让服务器的带宽尽量跑慢，并且尽量不要有排队的情况，让网络服务更佳稳定和高效。

修改系统变量：

保存生效

执行

如果结果是这样

就开启了。 执行 lsmod | grep bbr ，以检测 BBR 是否开启。

一般建议重启系统，重启后执行

参考链接

WOL网络唤醒在微星主板上开启(ubuntu 20.04/Windows 10双系统)

网络唤醒

微星H97I-AC的板子开启WOL网络唤醒

主板：微星 H97I-AC，集成 Realtek 千兆网卡,这个网卡自带网络唤醒功能，但是需要在操作系统中通过驱动开启这个功能，BIOS中无法直接开启。
操作系统：Windows 10/ubuntu 20.04双系统，双系统都需要进行配置，才能实现全部系统关机之后都能正常唤醒。

BIOS 设置

  1. 高级–整合周边设备–网卡ROM启动，设置为允许
  2. 高级–电源管理设置–Eup 2013，设置为禁止
  3. 高级–唤醒事件设置–PCIE设备唤醒，设置为允许

Windows 10 设置

  1. 控制面板–所有控制面板项–网络连接
  2. 在网卡适配器点击鼠标右键–属性，弹出的属性对话框中
  3. 选择网络选项卡–配置
  4. 选择高级选项卡，将关机 网络唤醒设置为开启，将魔术封包唤醒设置为开启
  5. 电源管理选项卡，勾选下面三个选项，允许此设备唤醒计算机。

ubuntu 20.04设置

里面的内容如下：

启用服务

远程唤醒

参考链接

认识ARM64汇编

之前说过学习汇编就是学习寄存器和指令，查看代码请连接真机。

寄存器

在arm64汇编中寄存器是64bit的，使用X[n]表示，低32位以w[n]表示

在64位架构中有31个64位的通用寄存器。

可以通过register read查看

继续阅读认识ARM64汇编