1. Window -> Preferences 菜单，点击进入。
2. General -> Appearance -> Colors and Fonts
3. Basic -> Text Font

最近在使用 chatgpt 进行学习，这篇文章记录使用的过程备忘和一些注意点。

另外，这篇文章默认你身处海外，如果国内则不适用，相关网络问题略去不表。

一、chatgpt 3.5

使用步骤分为两步：

1. 准备海外的手机号
2. 邮箱注册

由于 openai 的运营策略，免费版的chatgpt3.5根据服务器的负载情况，有可能出现每几个对话就有断线，需要刷新页面重连。当然也有很大可能和你使用的网络有关系。一开始配置不好，我的也经常断开，后来调整了一些，几个小时也没有断的。

最近听说同一个 ip 登录多个账号，也有可能导致无法访问甚至账号禁用，还请注意：

1. 准备海外手机号

首先，登录一个国外临时手机号购买网站：https://sms-activate.org/

点击右上角的注册：

输入邮箱、设置密码完成账号注册。

注册成功后，在账号中，点击右上角的充值。

选择支付宝进行充值：

输入金额：0.2美元，点支付。（近期改变了策略，似乎需要2美元）

然后进入支付宝扫码付款页面，扫码支付即可。

自动汇率换算支付人民币：

支付成功后，回到账号后台，点击左侧的OpenAI（或者在服务搜索中搜索OpenAI）。

买一个手机号

ps，图中的英格兰，其实和Guernsey共用44打头的号码。

购买后，账号页面右侧，可以看到你购买的手机号：

关于这个国外手机号说三点：

• 这是一个临时手机号，有效时长20分钟
• 20分钟内如果没有收到验证码，可以点右侧的叉号，退订，费用还会返还。（注：一般在ChatGPT注册页面发出验证码后一分钟左右便可以收到验证码。收不到验证短信可以在20分钟到期前退订，三分钟以上收不到验证码建议就不用再等了）
• 如遇到无法登录的情况，请打开谷歌浏览器的无痕窗口进行登录，一般会很快登录账号。

另外保留这个显示国外手机号的页面处于打开状态即可，便于第三个步骤中快速回来查收验证短信。

2. 邮箱注册

打开ChatGPT的官方网站：https://openai.com/

点击API。

点击注册按钮：

输入邮箱，并点击继续：

打开邮箱，点击OpenAI发来的验证邮件，点击验证按钮。

选择手机号国别，并输入第二步中购买的手机号码，点击发送验证短信（send code）：

然后返回到第二步中购买手机号的页面，查收短信：(一般一分钟左右可以收到短信）

输入验证码即可。验证后，恭喜你已获得一个ChatGPT账号。

3.了解ChatGPT后台

登录后首先是账户概览（overview）:

可以看到ChatGPT提供的主要功能：

• 文字生成、编辑
• 代码生成、编辑、及解释
• AI图片生成
• 微调：为自己的使用训练ChatGPT
• 嵌入：用于搜索、分类、对比文本

4. 工具文档

其次是ChatGPT的文档介绍。你可以理解为ChatGPT的使用说明书。

比如，里面涵盖了ChatGPT各种功能的使用指南介绍。

5.示例

这里包含了ChatGPT应用的各种示例，也可以理解为一个工具FAQ。

注意这里可以选择不同的应用场景来试用ChatGPT:

点击“try it now”, 进入ChaGPT工具使用界面。

在对话框中输入指令，开始使用ChatGPT工具。

二、chatgpt 4.0

1. ChatGPT 与 ChatGPT plus 的区别

Plus为升级版，使用免费版本的时候，经常会遇到隔几分钟就要刷新一次的情况，服务器拥挤导致无法使用的问题。Plus版本则很少出现。

Plus是需要付费的，每个月20美元，普通版本是免费的。

Plus为开发人员构建应用程序和服务的 API。

Plus版本可以拥有使用GPT4.0的权限.

2. ChatGPT 3.5 与ChatGPT 4.0 的区别

上图是OPAN AI网站的解释，一共三个方面。

• 4.0拥有更多的参数，给出的答案更具有参考性（实际体验过程中，因为要结合更多的数据，所以导致会话反而变慢）
• 可以识别图片
• 提供更长的上下文（这一点解决了GPT3.5的痛点）

3. 是否推荐升级GPT4.0

如果你是作为一个运营人，会经常涉及到一些文案的工作，建议可以去升级4.0。

如果你只是偶尔使用一下，3.5的开源就可满足你，也不必再去瞎折腾。

4. 升级流程

如果你有开户地为美国或非中国地区的信用卡，可以直接升级。

否则可以参考如下流程：

1. 欧易平台购买 USDT
2. 提现到 Depay 钱包
3. 兑换成美刀充进 Depay 信用卡
4. 购买 ChatGPT Plus

4.1 USDT充值的欧易账户申请

由于Depay不支持人民币直接充值，因此需要利用交易所平台来完成人民币至USDT再兑换为USD美元的过程。

在Depay账户中获得USD美元后，再进行充值。这里简单介绍一下USDT：它是一种名为泰达币的虚拟货币，与USD挂钩，因此安全性无需担忧。

注册欧易账户后，下载并安装其APP。如果在安装过程中系统提示安全风险，无需担忧，因为虚拟货币相关的应用通常会引发误报。从官方网站下载的应用是安全的，可以忽略此提示。

安装成功后，打开欧易App，点击首页——选择购买币种——快速购买——选择USDT——至少购买23USDT（约合200元人民币）——支持使用支付宝、微信或银行卡进行购买。

4.2 申请虚拟信用卡 Depay

ChatGPT要求使用美国信用卡，而国内的双币卡和全币卡均无法使用。对于没有美国信用卡的国内用户，可以选择知名的Depay美国虚拟信用卡。

注册Depay账户，可以使用电子邮件或手机号，如果未收到验证码，请检查垃圾邮件箱。注册成功后，下载并安装Depay App。

苹果手机需要登录海外Apple账户，安卓手机可以直接下载apk文件进行安装。安装完成后，使用刚刚注册的账户和密码登录Depay。

4.3 申请首张虚拟信用卡

点击界面左上角的“申请卡”以开通虚拟信用卡。在开卡时可以选择0开卡费或10USDT开卡费。0开卡费的卡需要完成KYC认证，即上传身份证（国内身份证可用）进行认证。建议选择0开卡费的卡以长期使用。

开通虚拟信用卡后，可以将USDT充值到Depay。下一章节将详细介绍这一步骤，需使用前述注册的欧易账户进行USDT充值。

4.4 充值USDT至钱包

• 打开Depay App钱包，找到钱包——USDT——充币，复制你的充值地址。请务必确认屏幕上显示的是TRC20主网。千万不要复制错了充值地址。

  

• 打开前述第2步注册的欧易App，在首页中找到资产选项。然后，选择提币——USDT——链上提币。在提币地址处填入Depay钱包的充值地址。

  在提币网络选项中，务必选择TRC20（千万不能选错，否则无法到账）。提币数量选择大于23USDT的数字即可，足够充值1个月的ChatGPT Plus会员费用。提交提币请求，等待到账。

  

• 当欧易成功提现至Depay后，请打开Depay App钱包，然后选择“兑换”选项。将所有的USDT都兑换成USD美元。

  

• 完成将所有USDT兑换成USD美元后，在Depay App首页中点击“To Card”选项，将兑换得到的美元存入虚拟信用卡中。至此，Depay充值的全部流程就完成了。

4.5 开通ChatGPT Plus

在第4步向其中充值了20多美元。足够订阅1个月的ChatGPT Plus服务。

现在，登录ChatGPT后，可以在左下角找到升级至Plus的选项——”Upgrade to Plus”。点击该选项，按照提示输入您的虚拟信用卡信息进行支付，即可成功开通ChatGPT Plus。

三、chatgpt api

你可能会遇到一些国内的chatgpt的套壳网站，要求输入api keys，拥有不需要使用任何翻墙就可以直接与chatgpt对话的能力。

原理是调用了chatgpt账户的api接口，它允许任何企业或个人在他们自己的应用程序、网站、产品和服务中使用 ChatGPT 功能，并且是最新的训练模型，$0.002/1K tokens的价格看起来也似乎非常诱人。链接：https://platform.openai.com/account/api-keys

按照步骤二 chatgpt 4.0 中完成付款信息填写：

OpenAI 官方针对每一个新注册的账户，提供$18免费token使用额度。不过需要注意的是，免费额度有时间限制，过期了额度就作废。

收费标准是 $0.002/1K tokens，大概 750 词。虽然1k个token看起来很多。但其实，发送一段供API响应的文本可能就会花费不少token。据观察，基本问1个问题就要耗费100~200个token，算起来其实不少的，尤其在连续会话中，为了保持对话的连续性，必须每次都要回传历史消息，并且输入都要算 token 数算钱的，满打满算，按量付费其实也不便宜。

按照一般的经验来看，在英语中“一个 token 通常对应大约 4 个字符”，而1个汉字大致是2~2.5个token。

举一个官方的说明例子可能更直观一些：根据 OpenAI 官方文档，“ChatGPT is great!”这组单词就需要六个 token—— 它的 API 将其分解为“Chat”、“G”、“PT”、“is”、“great”和“!”。

如果想查询一串指定的文本到底需要耗费多少个token，官方有提供一个免费查询计算器：

四、bing

直接访问 http://www.bing.com/new：

登陆即可。只要能访问到这个界面，微软账号不需区分国内国外都可直接使用聊天功能。

五、Google Bard

Google 在两年前推出了可以进行多轮对话的 AI 模型 LaMDA，并在 2022 年推出了 AI Test Kitchen，一个面向开发者和研究者的，以帮助他们学习、演练和使用人工智能技术的平台。

Bard 则是基于 LaMDA 和 AI Test Kitchen 相结合开发而来的轻量级优化版本，它能与用户协作，帮助提高工作效率，例如规划生日派对、起草邀请函、创建赞成反对名单或理解复杂主题等。

值得注意的是，目前 Bard 测试范围限制了仅支持美国，其他国家地区还得等待！也就是说，你现在必须要有美国的 IP 才能申请。

在官网排队申请中：https://bard.google.com。

申请完成后界面如下，目前我觉得的还是有点白痴：

六、文心一言

排队中界面如下：https://yiyan.baidu.com/welcome

通过后的界面如下：

参考资料

• ChatGPT注册教程攻略：解决手机无法接收验证码问题
• 收藏：如何注册Chat GPT以及10个使用技巧（Chat GPT的完整使用教程）

原文：http://arthurchiao.art/blog/traffic-control-from-queue-to-edt-zh/

译者序

本文组合翻译了 Google 2018 年两篇分享中的技术部分，二者讲的同一件事情，但层次侧重不同：

• Netdev 2018: Evolving from AFAP: Teaching NICs about time， 视角更宏观，因果关系和历史演进讲地较好；
• OCT 2018: From Queues to Earliest Departure Time，更技术和细节一些。

另外翻译过程中适当补充了一些与 Linux/Cilium/BPF 相关的内容。

由于译者水平有限，本文不免存在遗漏或错误之处。如有疑问，请查阅原文。

以下是译文。

1 网络起源

如果能对网络协议和网卡之间的契约（contract between protocols and NICs） 做出些许改动，就能解决很多问题。解释清这一点需要从历史讲起。

1.1 技术需求与网络起源

时间回到起点。如果你在上世纪 70 年代说“网络”这个词，那它大概长这下面这样：

Fig. IBM 3790 Controller (1974)

这是当时 IBM 新发布的网络架构，称为 SNA（Systems Network Architecture）， 可以看到其中有很多打印机和终端，这就是当时所谓的网络。

左上角是一台 IBM 小型机（mainframe），它非常昂贵，只有高端企业才买得起。而另一方面， IBM 想把小型机打入更广阔市场，这就意味着他们需要把小型机推销给一些小客户， 比如那些只有几个分支机构的银行。 要实现这个目标，在技术上就需要实现分支机构和总部互连，但这一点在当时是做不到的： 当时的计算机都是围绕数据中心模型设计的，昂贵的外设都环绕在计算机附近，距离不过百尺。

因此，为了解决远程互连问题，他们设计了一些远程控制器，能驱动显示控制器（display controller）， 这样客户的分支机构只需要安装相对便宜的显示终端，就能和总部的小型机连通，成本也就下来了。 比如上图中，小型机的成本就可以被 12 个分支机构平摊；此后，大量的银行、金融机构和零售商开始购买 IBM 小型机。

这就是网络（network）最初的样子， 这一时期（70 年底早期和中期）各种网络协议互相竞争，但可以分为两类：

1. 政府资助研究项目：英国的 NPL 网络、美国的 ARPANET（互联网的前身）、法国的 CYCLADES 等；
2. 计算机厂商私有：IBM 的 SNA、DEC 的 DECnet 等。

1.2 私有协议和厂商锁定

计算机厂商开发计算机网络（computer network）的目的其实非常简单：

1. 通过卖设备（小型机和远程终端等）给企业客户赚钱；
2. 通过私有协议锁定客户（lock-in customers），卖更多设备给他们赚更多钱。

计算机厂商的首要目的是卖硬件，不希望客户用竞争对手的产品，因此首先要做的是在产品上锁定客户。 如果你认为网络的出发点是连接全世界，让每个人的每个设备都能彼此自由通信，那就太理想主义了； 网络的起源没有这么高尚，而是纯商业行为：每个计算机厂商都希望客户购买自己的网络设备， 并且只能和自己厂的设备通信，其他厂商的设备一概不能连接。

1.3 早期厂商网络方案的问题

私有协议和厂商锁定导致的几个后果：

1. 研发显示器、打印机、读卡器等等这些外设（peripheral devices）的 工程师主导了网络设计，这一点对后世影响深远。

   对此时的厂商来说，外设和功能才是重要的，网络只是一个从属地位。 因此，我们会看到网络协议中包含很多直接与设备相关的东西，非常怪异，例如与打印机 通信时，需要考虑到它打印和弹出纸张的速度，可能是一条命令发送过去，然后传输 协议里规定等待两秒（等待打印过程），设计的非常傻（那时也没有多少内存可用， 内存非常稀缺和昂贵）。

2. 通信链路非常慢（300bps/2.4Kbps/56Kbps），导致协议被过度简化。

   有钱的金融客户使用的可能才只是 2.4Kbps，如果真的非常非常有钱，才会考虑 56Kbps，这是当时的上限。由此导致的两个设计：

   • 尽量减小头开销（header），头越小越好；
   • 协议要精简/简化，不要太啰嗦。例如，避免明确回复对方说 “包我收到了”，而是假设在大多数情况下，包都能在 timeout 之前正常被设备接收。

3. 由于以上两点，需要针对不同设备/控制器型号有不同的数据包封装格式。

不难猜到，这种架构和产品并不成功。 我们关注的不应该是什么人或什么设备在使用网络（what’s using the network）， 而是如何使得网络可用和好用（making the network usable）。 由此引出今天的事实标准 —— TCP/IP 协议 —— 的诞生。

1.4 TCP/IP 协议模型

TCP/IP 的设计吸取了以上教训。这里主要强调三点：

1. Simplicity：加到协议里的东西必须是有用、清晰、无异议的；
2. Expressive abstractions：网络模型（抽象）必须有很强的表达能力，能用于解决不同的实际问题；
3. Implementable contracts：协议层之间的契约可实现，不能过于理论导致落地困难。

TCP/IP 最大的特点是没有对周边（应用类型、协议效率、网络结构等）做出限制。 有些东西理论上很美好，但实现起来会巨复杂，和当初设想的完全不一样； TCP/IP 架构组的每个人都亲自实现过协议，在 ARPANET 工作过，经验丰富，因此避免了很多之前已经出现过的问题。 最后，他们只设计了两个主要协议，构成了如今的 TCP/IP 模型：

• IP：网络层协议
• TCP：传输层协议

1.4.1 IP：尽力而为传输（best effort delivery）

IP 层传输的是接口到接口的小消息（interface to interface small messages）。

IP（Internete Procotol）是不可靠的（unreliable）尽力而为传输（best effort delivery）。

计算机厂商的私有网络方案和 IP 方案是竞争关系，因此他们看到这个方案时会说：你们这个 IP 方案只有传输数据包的功能，我们的方案还能做 XX、YY、ZZ …，但我要强调的是，这些并不属于 best effort 的范畴： 网络层应该只有唯一功能，那就是传输数据包（deliver packets）， 如果你给一个包它无法传输，那唯一原因应该是它正在传输其他包，其中的竞争条件需要你等待。 “尽力而为”并不是什么都做，而是聚焦在一个功能点，尽最大职责把这个功能做好。

“尽力”的另一层意思是可能会有失败，因此需要想好应对方案。这就轮到 TCP 层出场了。

1.4.2 TCP：最终可靠传输（eventual delivery）

TCP 与 IP 层之间的契约：

• IP 层尽力而为，
• TCP 在 IP 的基础上实现最终的可靠通信。

最终可靠性很重要，因为我们不知道什么时候会失败，因此需要 重试等机制来保证传输结果最终是成功的。

1.4.3 小结

TCP/IP 的成功并不是因为它们规定了什么，而是它们没规定什么： 没有对上层应用、协议效率、网络结构、代码实现做出任何假设。 在设计方案时，做出某些假设、前提、限制很容易，但以后想把其中一些限制去掉时， 就很难甚至不可能了，因此前期的设计非常重要。

网络有了，接下来进入本文正题：网络传输过程中的流量控制。

2 网络传输

2.1 技术需求：越快越好（或尽可能快，AFAP）

网络传输的需求是尽可能快（as fast as possible），这一点是显然的。

那我们看看 TCP 发送机制中，哪些因素会制约发送速率。

2.2 TCP 发送机制：只限制发送多少，未限制发送多快

TCP 的设计机制是可靠传输，它限制了发送多少 （how much is sent），但没有限制发送多快（how fast）。 理解这一点非常重要。越快越好是天然需求，既然 TCP 机制没对发送速率做出限制，那 发送端就自然就出现了“尽可能快”（AFAP）这样一种事实发送机制 （即所谓的 “work conserving”）。

那么，怎么实现 AFAP 呢？一般是通过所谓的流量整形/整流（traffic shaping）。

2.3 基于 queue 做流量整形

实际中，流量整形通常通过 device output queue（设备发送队列）实现；

• 最快发送速率就是队列的 drain rate；
• 传输中的最大数据量（inflight data） 由 RX window 或 queue length 决定。

下面具体看怎么做整流。

2.3.1 流量整形器（shaper）原理：以 token bucket queue 为例

如下图所示，原理比较简单：

Fig. 通过多个 token bucket queue 实现一个 shaper

1. 主机的出向流量（egress traffic）经过一个分类器（classifier）进行分类；

   这里的 egress 流量一般都来自 socket buffer，可能是主机自己的流量，也可能是里面 VM/container 的流量。

2. 分类之后的流量分别放到不同的 queue（缓冲队列），各 queue 的发送速率限制可能是不同的；

3. 某个调度器（scheduler）负责统一调度以上所有 queue 的发包，将包从 queue 中取出放到主机网卡的 TX queue 中；

4. 网卡将 TX queue 中包无差别地发送出去。

中间的三件套：

1. 分类器（classifier）
2. 缓冲队列（queue）
3. 调度器（scheduler）

就组成了一个流量整形器或称整流器（shaper）。

2.3.2 AFAP shaper 历史贡献：支撑 TCP/IP 在过去 25 年速度 10000x

以上这种 AFAP shaper 在过去 25 年支撑了 TCP/IP 从 10Mbps 演进到 100Gbps， 速度快了一万倍，几乎完美贴合摩尔定律：

Fig. 以太网 25 年的带宽变化，从 10Mbps 增大到了 100Gbps

在这 25 年里，“多快”取决于 queue 的 drain rate，因此发送速率上限取决于主机侧（local）； 对于网线来说，限制是在上游（发送端主机是上游，交换机、路由器、接收端等等是下游）。 当希望发送更快时，只需要将网卡及网线从 100Mbps 换成 1000Mbps，非常简单直接。 主机外面的东西不用担心，自然会有人和技术能支撑主机的线速发送（下面会讨论）。

2.3.3 面临的问题：延迟和丢包

刚才提到，这种机制的前提是发送瓶颈在主机端，因此主机发送多快都没关系， 不用担心会把主机外面的什么设备或网络路径打爆。 这就意味着，主机端（更准确地说是此时的瓶颈）有时 —— 甚至是长时间 —— 运行在 100% 的。 更具体地说，你可能用的是线速 10Gbps 的网卡，但主机上的应用流量太大了， 导致以上 shaper 长时间把速度限制在 10Gbps，超过 queue 的包只能丢弃了。 排队论（queuing theory）也从数学上告诉我们，这是不稳定的（e.g. for M/D/1）：

Fig. 根据排队论，实际带宽接近瓶颈带宽时，延迟将急剧上升

因为这种情况下的到达速率持续大于离开速率，队列爆了。 离开速率是网卡线速，没法调整了，因此只能调整到达速率，也就是从源头控制发包。

2.3.4 缓解/避免丢包的方式（2012 年之前）

这个问题比较棘手，因为实际上不止是主机侧，在网络传输路上上多个地方都有 buffer queue， 有些地方并不受你控制：

• 可能是在距离你 9 跳之外的某个 buffer 非常小的交换机；
• 或者是某个 ISP 与家庭的 buffer 非常小的连接处

因为他们都尽量用便宜的交换机。

如果满足以下几个条件之一，延迟/丢包就可以避免：

1. 带宽与延迟乘积（bw * delay，BDP，也就是正在传输中的数据量） 非常小；

   这一点在 1995 年之前是成立的，因为早期的内存非常昂贵，带宽也非常低（几 KB/s），因此这个乘积非常小。这种情况下没有大 queue 也不会丢包。

2. 每个网络瓶颈处都有一个大缓冲区路由器（fat-buffered router）；

   1995 年之后，路由器厂商开始制造大量的大内存（大缓冲区）路由器，（交换机）内存很便宜，交换机厂商也借此赚了不少钱。 如果每个可能的瓶颈点都放了 buffer 很大的路由器，能支撑很大 inflight BDP，也可以解决丢包问题。

3. 服务器到置顶交换机（hosts to TORs）的速度比交换机之间（fabric）要慢。

   这一点类似通信厂商：拉开接入带宽（access bw）和交换带宽（fabric bw）的差距。 例如，接入是 10Gbps，路由器之间的交换带宽是 100Gbps；或者接入 40Gbps，交换 400Gbps。 这种情况下服务器 AFSP 并不会有问题，因为上面有更快的交换网络（实际上是一个 fat pipe）。

第 2 点和第 3 点的缺点是会带来额外延迟（下游的路由器上）， 例如 Gbps 级别的路由器可能就会带来秒级的延迟。但这还不是最糟糕的， 最糟糕的是2012 年之后，即使愿意忍受更大的延迟也无法避免丢包了， 因为摩尔定律失速了，这也意味着主机侧 AFAP 模型（主机全速发送，不需要考虑外面的瓶颈和延迟）走到头了。

2.3 带宽摩尔定律失速（2012 年之后）

技术层面上，从摩尔定律看以太网的发展，明显能看到两段曲线：

• 早期（2000 年之前）：每 12 个月带宽就能翻一番，明显快于标准摩尔定律的 18 个月；

• 后期：需要 24 个月，也就是慢于标准摩尔定律，这种增长方式已经不可持续了；

  如果你年纪够大的话，应该记得 计算机世界在 2000~2005 年发生了根本性变化： 之前我们已经习惯了处理器每 18 个月性能翻一番，但到了 2003 年 Intel 突然告诉我们下一代奔腾处理器不能快一倍了 ——甚至实际上还会慢一点， 然后通过多核来提升整体性能：给你 2 个或 4 个核。受限于物理限制，我们无法做 到更快了，此后提升应用整体性能的方式就是多核并行。

Fig. 真实以太网演进速率与摩尔定律理论速率

这种不可持续性打破了园区网和数据中心网络建设的传统模型（“fabric 带宽永远比 access 带宽高一个数量级”）， 因为更高的带宽上不去了，或者能上去一些但是成本太高了，最后的结果就是 服务器的网卡带宽（access bw）追平了交换机之间的互联带宽（fabric bw）。 这样一来，交换机就不再能 buffer 大量的服务器包了，尤其是多个主机访问同一个目的端、命中通过一个交换机端口的时候。 不管是数据中心网络还是边缘网络都面临这个典型问题。

单核摩尔定律的突然终结深刻影响了网络和计算，但对网络的影响更大。

• 这打破了之前的带宽层级（bandwidth hierarchy）模型， 我们无法造出速度永远比网卡快一个数量级的交换机了。
• 原来单核或但主机能完成的事情，现在必须分散到大量机器上来并行处理，这给交换网络造成了巨大挑战。 之前只需要原地升级 CPU 就能解决，不需要动网络，该怎么连接到 fabric 的还是怎么连， 现在只能分发到多个 CPU、机器上去。

网络模型发生了本质变化。

3 Google 网络团队的一些创新

以上讨论意味着，基于缓冲队列（queue）的机制已经不符合当前网络现状了， 不能再简单基于网卡的最大工作速率来发包。

3.1 思路转变：从基于 queue 到基于 time

Google 的解决思路是：感知网络瓶颈，以瓶颈处的最大发送速率发送数据包（determine what’s AFAP at the bottleneck and run at that rate）。做到这一点，依赖的最重要 因素不再是 queue，而是时间（time）。

3.2 一些已发表论文

应用分散到多台机器并行计算再将结果汇总，这样跟之前的单机运算为主模型完全不同， 对网络的影响非常大，对网络影响和问题数量是成倍的，例如我们在我们的 fabric 中遇 到的问题，在 jupiter paper 中讨论了一些。

如果中间丢包太严重了，就只能将流量管理前移到主机上。此时网络可能已经是无缓冲区 交换机了，因为你在发送大量随机流量，而多个突然流量重叠时，交换机根本没有能力缓冲。 此时，你唯一有能力缓冲也有能力控制的，就是发送端主机。

因此我们做的工作就是在源点主机，这些文章都是一个主题：让我们回到源点来解决问题： 哪里是瓶颈，瓶颈决定了 AFAP；不能拥塞 TOR，它已经在全速工作了。需要知道下游 的一些状态，来控制本地发送速率，以避免给下游造成过大压力。

Google 近些年所做的一些工作：

• HULL (NSDI’12) – Less is more: trading a little bandwidth for ultra-low latency

  Traditional measures of network goodness—goodput, quality of service, fairness—are expressed in terms of bandwidth. Network latency has rarely been a primary concern because delivering the highest level of bandwidth essentially entails driving up latency—at the mean and, especially, at the tail. Recently, however, there has been renewed interest in latency as a primary metric for mainstream applications. In this paper, we present the HULL (High-bandwidth Ultra-Low Latency) architecture to balance two seemingly contradictory goals: near baseline fabric latency and high bandwidth utilization.

  用到了：

  • Phantom Queues that deliver congestion signals before network links are fully utilized and queues form at switches
  • DCTCP, a recently proposed congestion control algorithm
  • Packet pacing to counter burstiness caused by Interrupt Coalescing and Large Send Offloading

  Our implementation and simulation results show that by sacrificing a small amount (e.g., 10%) of bandwidth, HULL can dramatically reduce average and tail latencies in the data center.

• BwE (Sigcomm’15) – Flexible, Hierarchical Bandwidth Allocation for WAN

• FQ/pacing (IETF88’13) – TSO, fair queuing, pacing: three’s a charm

• Timely (Sigcomm’15) – RTT-based congestion control for the datacenter

• BBR (CACM v60’17) – Congestion-based congestion control，中文版

• Carousel (Sigcomm’17) – Scalable traffic shaping at end hosts

4 从基于队列到基于时间戳：qdisc/EDT 详解

本节从技术层面介绍和分析两种模型。

4.1 基于 queue 的整流器

更多关于 tc qdisc 的内容： （译）《Linux 高级路由与流量控制手册（2012）》第九章：用 tc qdisc 管理 Linux 网络带宽

Fig. 通过多个 token bucket queue 实现一个 shaper

原理前面介绍过了。存在的问题：

• CPU 和内存开销：可能很大
• 需要同时满足网络带宽策略和拥塞控制需求，例如 TCP
  • Pace packets
  • Provide backpressure
  • Avoid HOL blocking

4.1.1 示例一：HTB

Fig. HTB shaper 原理

问题：

1. CPU 开销随 queue 数量线性增长；
2. 多个 CPU 共享多个 queue，导致 CPU 之间的同步（锁/竞争）开销。

4.1.2 示例二：FQ/Pacing

Fig. FQ/pacing shaper 原理

性能开销问题和上面的 HTB 一样。

4.1.3 小结

如果去掉 queue，就可以避免上面两项开销：我们的思路是把时间 （time）作为一个基础元素，同样能实现整流目的，但所需开销非常低。

为此，引入了 EDT（earliest departure time）模型：

• 给每个包设置一个 EDT 时间戳，控制何时发送这个包；
• 在网卡前或网卡中执行调度机制（enforcement mechanism），根据时间戳控制 egress 发包。

Carousel 正是这样一种机制。

4.2 Carousel：基于 EDT 的整流器

Fig. 传统基于 queue 的流量整形器 vs. 新的基于 EDT 的流量整形器

如上图所示，核心理念：用两项简单工作替换原来缓慢、脆弱、级联的排队系统：

1. 给每个包（skb）打上一个 Earliest Departure Time (EDT) 时间戳；

2. 用一个时间轮调度器（timing-wheel scheduler）代替原来 网卡前或网卡中的发包缓冲队列（queue）。

   时间轮模型，可参考 Hashed and Hierarchical Timing Wheels, Varghese & Lauck, SOSP 87.

下面再展开介绍一下。

4.2.1 原理及特点

Fig. Design

1. 调度复杂度：O(1)，待发送的包都是按时间戳排好序的；
2. 调度器能直接给 socket 反压，控制 socket 发送速率；
3. 每个 CPU 一个 shaper，无锁，开销低。

4.2.2 Life of a packet in Carousel

Fig. Life of packet in Carousel

4.2.3 与基于 queue 的 shaper 的对比

timing wheel 能完成 queue 的功能，它不仅能做的事情更多，并且做的更快：

1. 插入和删除操作都是 O(1)，复杂度和 queue 一样，但是开销更低，
   • cache friendly (no pointer chains)
   • RCU friendly (single slot to update) Driver (or NIC) gets to choose ‘event horizon’ (wheel length) so can do BQL-like tuning for long enough to fill wire but short enough to not blow away caches.
2. Packets that would be sent after event horizon can get TSQ-like callback when they can be sent or get an ETooFar. This replaces TSQ and fixes problem of many simultaneous writers generating huge queues.
3. It also puts hard bounds # of active output bytes, increasing probability of L3 cache hits for systems that can DMA from L3.

4.2.4 qdisc 功能变化

有了 EDT， qdisc 能做的事情更多，同时开销也更低了： qdisc 变成了一个纯计算模块，不再需要维护内部队列了（intermediate queues），

• driver gets to see all packets in its event horizon so can easily do informed interrupt mitigation, lazy reclaim, (wifi) endpoint aggregation…
• sender learns packet send time on send() and can handle deadlines, seek alternatives, do phase correction…

In essence, timing wheel is an in-memory representation of how packets will appear on wire. It can represent almost any causal scheduling policy.

(Policies like ‘Maximize Completion Rate’ are impossible to express with rates but easy with timestamps so we can finally make transactions ‘fair’ without stupidly slowing everything down.)

4.3 小结

• 主机侧的网络模型应该从 AFAP 切换到 EDT 了；
• EDT 比 AFAP queue 更加高效和简洁；
• 基于 EDT 不仅能实现传统基于 queue 的 shaper 的各种调度策略，而且还能实现更多新的调度策略。

5 Linux EDT 支持与实践（译注）

较新的内核版本已经支持。

5.1 Cilium pod egress 限速

Cilium 用了 EDT 做容器 egress 限速：

• (译) 为容器时代设计的高级 eBPF 内核特性（FOSDEM, 2021）
• (译) 为 K8s workload 引入的一些 BPF datapath 扩展（LPC, 2021）

原文：http://blog.nsfocus.net/ussf/

一、前言

作为信息时代建立起来的唯一美国军种，美国太空军（USSF）拥有“先天数字”的独特机遇。我们要抓住这个机遇。太空是一个作战领域，我们面临的威胁以极快的速度跨越了遥远的距离。我们必须接受我们所掌握的信息时代工具，确保该领域对我们这一代人和下一代人来说都是安全、稳定、可访问的。USSF将成为世界上第一个全数字化军种。我们将成为一支互联、创新、数字主导的部队。

成为数字军种不仅仅是一个代际机会，也是作战的必要条件。这一必要条件主要由两大因素驱动：（1）威胁的性质和（2）太空军的规模。我们知道，潜在对手正在以惊人的速度发展一系列威胁，直接挑战我们在太空中的稳定性以及我们作为一个航天国家所享受的诸多好处。为了对抗这些威胁，我们必须改变模式。我们必须在领导、采办、工程、情报和作战的各个方面采取更加迅速和果断的行动，从而在对手的观察、定位、决定、行动（OODA）循环中占据永久的位置。此外，鉴于USSF的规模相对较小，实现这一目标需要我们积聚一群技术娴熟、“数字流利”的太空军成员，这支队伍比历史上任何一支部队都要熟练、高效、灵活。

这份前瞻性的文件首先阐述了推动我们成为数字军种的必要条件。然后，它描述了理想愿景，即什么是数字军种，包括引入和定义形成我们的集体数字流利度的基础的关键概念。本文件还解释了四大数字重点领域及其范围、重要性和相互关系。这些重点领域为愿景实现提供了框架，形成了即将发布的数字转型路线图。

虽然我已经委托我们的技术和创新办公室来主导美国太空军的数字转型，但这并不仅仅是他们的责任。事实上，我们都是美国太空军的先驱；我们每个人都有责任将自己打造成一个接受协作、勇敢、持续学习、多样性和包容性以及适应性的数字军人。每一个守护者，无论职业领域或背景如何，都应该抓住机会，采用新技术，将日常活动迁移到“数据空间”，并在必要的时候鼓励队友。

这是我们对数字军种的愿景，也是我对每一个守护者的行动呼吁。通过共同努力，我们可以实现这一愿景。我渴望看到我们将创造的不可思议的未来。

二、为什么是数字的？为什么是现在？

我们的军种创建的根本原因决定了我们为什么必须成为数字军种：威胁真实存在，而且迫在眉睫。目前，潜在对手正在努力抵消美国在太空领域的优势，并迅速缩小差距。他们正以比我们更快的速度迫切地部署太空、反太空、网络空间和电磁频谱（EMS）能力，在某些情况下，他们甚至正在超越我们。鉴于太空能力作为现代联合作战环境的一部分所发挥的重要作用，这对美国国家安全和经济繁荣来说是不可接受的风险。为应对威胁，我们必须立即采取行动。我们需要以极快的速度和极高的熟练度利用信息和数据，加速开发、部署、运营联合太空能力。我们必须利用数字解决方案，适应充满敌意的复杂动态环境，实现蓬勃发展。与任何其他国防领域或任务相比，这个环境在本质上更受技术的约束和驱动。事实上，太空是唯一一个没有人类进行军事行动的物理领域。我们的作战人员关于该领域的所有体验，都来自于从太空接收到的数据以及我们快速分析对我们有利的数据的能力。鉴于这一作战现实，再加上我们必须更广泛地利用数据和信息、争取在竞争激烈和拥挤的作战环境中占上风，USSF将采用现代技术和方法开展大规模的文化和技术转型，成为真正的数字军种。这一数字转型旨在使我们能够在美国率先开创的领域重新获得主动权、保持优势。太空军的规模为数字转型提供了另一个令人信服的理由：要凭借小型的专业化军种来完成庞大使命，我们必须非常熟练、高效。虽然有些人可能认为我们相对精简的军种有碍成功，但事实上，这可能是我们最大的优势之一。尽管国防部的太空任务通常涉及多领域，但是由极其专业化的团队中相对不重要的基干官兵来完成的，推动着前沿技术领域。换句话说，USSF的使命和人员与信息时代完美匹配，这就是我们摆出独特的“先天数字”姿态的原因。此外，我们有机会在招募、留任和培训时进行精挑细选，从而确保塑造一支技术娴熟、“数字流利”的精英队伍。归根结底，一支精简、专注的部队天生就具有更强的适应能力，使我们能够快速转移和进化，以应对高度动态的环境。

成为数字军种，我们能变得更加熟练、更加高效、更加敏捷。通过这一数字转型，我们将创造环境，在能力开发的各个方面培育快速转变、创新的解决方案。结合正确的政策和流程，我们将摧毁官僚主义，使各级能够以数据为驱动，作出快速的决策。通过先进的培训和适当的职业激励，我们将在协同事业中释放精英队伍的力量。一支数字太空军不仅会产生大规模的竞争优势、决定未来太空冲突的条件，还会使我们在探索作战领域的可能性方面成为姐妹军种的典范。这种需求再清楚不过了——USSF必须迅速而主动地行动起来，成为数字军种，为国防航天事业各个方面的改革创造历史性机遇。这将是什么样子，以及它将如何从根本上改变我们的行事方式，将在本文件的其余部分进行描述。在采取行动时，我们必须确保数字军种在网络空间和整个电磁频谱中的安全性。我们认识到这一转型需要时间，我们需要应对一系列挑战，从而实现目标。虽然我们正在努力改善与美国空军（USAF）共享的数字基础设施，但仍有许多工作要做。我们必须利用我们的行业和政府伙伴关系，确保我们所依赖的数字基础设施能够满足现代需求。此外，我们必须结合数字转型进行文化转型，培育鼓励勇敢、透明、持续创新以及与潜在机会相平衡的有计划的风险承担的环境。我们还需要重新考量过时的政策和流程，这些政策和流程使我们无法比对手更快地进行适应和创新。克服这些挑战需要综合计划，将多个正在进行和计划进行的活动联系起来。这一计划的制定对我们的长期成功至关重要，将在即将发布的路线图中加以阐述。

三、数字太空军愿景

威胁日益增长，而专门的守护者人数较少，这一严峻的现实清楚地表明了数字转型的紧迫性。我们必须回答的下一个问题是，“数字军种意味着什么？”为了使利益相关者对我们期望方向的理解没有偏差，必须对数字军种是什么样子及其提供的好处提出一个统一的概念。因此，本节的目的是确立并解释数字太空军愿景的全部范围。数字太空军愿景被定义为：一支互联、创新、数字主导的部队。下面将讨论这三大原则，包括它们之间的相互关系，以及它们如何相继建立一支熟练直观地利用数字技术保持太空优势的世界级战斗部队。

• 原则一：互联性

一支互联的部队有效且高效地与各种利益相关方分享有关信息，支持任务。这必然包括所需的人员和基础设施，实现并促进不受限制的信息和思想交流。

数字基础设施是互联部队的基础，要真正做到“以数据为中心”，必须将其视为关键战略资产。数据网络必须有足够的带宽，同时在对抗频谱环境中保持可靠性，并在多个安全级别上保证安全性。共享数据存储库也必须对相关人员开放访问权。以这种健全的数字基础设施为基础，我们将建立一个可信的、可理解的协作环境，囊括用户工具和应用程序，实现与受保护的数据的安全交互。此外，USSF必须支持不再局限于单一物理位置的世界。这可以使USSF让守护者作为“数字游牧民”灵活地进行虚拟运营，作为一支内在移动部队，无缝支持来自不同位置的各种任务。我们必须寻求与站点无关的解决方案，实现基于服务的分布式功能，而不考虑所支持的任务或所涉及的数据保护要求。所有这些元素也必须完全关联、能够互操作。

实现普遍的互联不仅需要一个强有力的数字环境，还必须解决人文方面的问题。在所有利益相关者之间建立、鼓励公开、透明的沟通机制，在部队内部开展协作展望未来，所有守护者默认必须倾向于通过集成解决方案开展协作；每个人都应该努力维护全局，并帮助他人实现同样的目标。这要求我们在太空军内部培育一种坦率互信的文化，这既包括横向，也包括纵向。在这个快节奏、高威胁的环境中，我们必须时刻牢记：我们都是一个团队的。互联部队的另一个重要方面是构成联系的广度。与工业界建立有针对性的伙伴关系，获得快速发展的技术。通过吸引新的有远见的公司与USSF合作，巧妙地增加我们在任务活动中对商业数据的使用，我们可以共同实现远远超过我们单独所具有的能力。此外，与学术机构合作将为我们提供获取学位和证书的机会，助力我们培养和发展训练有素的专业队伍以及研发协作机制。寻求和加强与姐妹军种、美国机构和国际盟国的合作，可以扩大我们的影响力，同时抵消过渡成本的负担。在建立这些伙伴关系时，确保我们拥有提升灵活性和控制力的适当的数据权利至关重要。归根结底，我们知道，在可互操作的数字协作环境中，有着内在的力量、效率和集体的创造力，这个环境扩展到更广泛的利益相关者群体，我们将积极参与，为了所有人的利益建立和加强这些伙伴关系。

• 原则二：创新性

一支创新的部队经常采用新方法，乐于挑战现状，慎重承诺实现持续发展、改进、进步。在数字军种的背景下，这种创新必然涉及到新技术的开发和采用，以便更有效地应对动荡、竞争环境中的不确定性。向队伍授权，对愿景的这一方面至关重要，因为守护者不仅需要具备有效创新的适当技能，还需要适当的支持和鼓励。作为小型精简军种的一部分，太空军每名成员都必须是变革的推动者，能为棘手的问题提供大胆而创新的解决方案。为了支持这种精神，持续学习和个人成长将是我们的口头禅。所有人员都有责任不断提高自身的数字流利度，磨练自身技能，从而在这个高度动态的数字环境中不落伍。此外，USSF将通过及时、相关的学习活动来支持这些价值观，这些活动可以通过最先进的形式进行。结合上文讨论的协作互联的力量，太空军专业人员将获得与当前和新兴技术相关的培训、教育和行业深造机会，实现并保持集体的“数字优先”思维。我们还需要从各种渠道吸引和留住具有适当技术能力和态度的人，确保我们拥有顶尖的数字人才和必要的视角。我们将利用为实现互联而建立的伙伴关系，接触和争取非传统渠道，实现我们的招募目标。近期，我们将在全社会聘请技艺精湛、积极性高的技术专家，同时为培养未来的年轻领导者和创新者打下基础。此外，使我们成为数字游牧民的相同技术也将激励更广泛的用户群体。这将有助于我们实现思想和专业知识的多样性以及背景和经历的包容性，从而实施最佳想法，避免趋同思维，推动创新。再加上我们为造就一支数字流利的队伍而进行的投资，我们还必须培育环境，释放投资潜力。这包括为守护者配备适当的技能利用工具。先进的、由用户驱动的技术代表了行业必须提供的最佳能力。为了适应性地应对对手威胁，USSF将把自己定位为这些技术的积极的早期采用者。这种环境的另一个重要方面是获得适当的数据权利，确保USSF对其能力具有必要的影响力。最重要的是，进行真正改变游戏规则的创新需要守护者能够按照他们的想法采取行动。必须给予USSF成员心理上的安全感和专业上的激励，使其在适当的时候能坚决果断地冒险。为了支持这种模式转变，我们将修改我们的绩效评估框架，识别并重视这些特征。此外，我们还将激励每个人成为数字转型的导师和领导者、坚持不懈地最大限度地推动决策的可行性。通过培育创新文化，我们将摆脱传统消极思想，建立自下而上的有机创新环境，促进数字转型。

• 原则三：数字主导

一支数字主导的部队将其累积的技术实力转化为强大的力量倍增效应，比任何潜在对手更快、更有效地开发、部署和运营能力。要获得持久的数字主导地位，需要我们将互联和创新要素集成至联合作战任务的各个方面。

数字主导的关键是人才。我们必须建立一支资源充足、权力充分、数字流利的队伍，能够并有动力时刻支持创新。基于肯定的文化、精简的业务流程和强大的数字工程生态系统（DEE），守护者将在“数据空间”中直观地思考和行动，充分准备应对我们面临的动态挑战。最终，我们必须设法使所有人员都能充当“内部企业家”，接受数字技术，推动创新，在整个组织内推动流程和操作的执行范围。

拥有数字优先的思维方式和成为数字主导需要具有创新精神且精通数字技术的太空军专业人员组建一个广泛的网络，这些专业人员本能地将可用知识排在静态产品（如报告、评估、图表、简报图表等）前面。传统的以产品为中心的模式主要关注创造孤立的静态产品，这些产品必然是不完善的工业时代的信息转换。更糟糕的是，在不为任务或决策流程提供相应的价值的前提下，这些过时、孤立的产品往往难以创造和管理。优秀的模式是以数据为中心。这一办法将使我们能够在数据空间内迅速获取和交换所需的信息和知识，包括产生与任务有关的行动和成果相关的精简、动态、同步的输出。最终，我们的数字太空军将作出数据驱动的决策，以今天看来难以想象的速度部署和运营突破性的太空能力。通过上述互联创新渠道，我们的数字军种能够快速获取、开发和部署改变游戏规则的能力，使我们能够利用精简的部队来超越威胁。我们将建立和培养与其他军种、美国机构、国际合作伙伴、学术和研究机构以及商业部门的关系，使我们能够成为颠覆性技术机会的驱动者和采纳者。将这一广泛的数字协作与我们组织严密、技术熟练的部队的有机能力结合起来，我们将成为数字主导力量。通过数字主导，我们将快速敏捷地推动较于竞争对手和敌手的优势，保持太空优势。

四、数字化重点领域

太空军《太空作战规划指南》（CPG）强调了“创建数字军种来加速创新”的迫切需要。为了更好地了解所需变革的范围，并建立实施这些变革的框架，CPG还确定了四大重点领域：数字工程、数字人才、数字总部及数字作战。要落实数字军种愿景的原则——互联、创新和数字主导，我们需要在每个重点领域进行重大的配套投资。这些投资的长期优势几乎是无限的，使我们能够用一支小而强的部队对抗并战胜威胁。然而，我们也将获得一系列短期利益，包括支持新军种的智能路径和实现CPG中要求的效率的方法，例如将人才培训的驻留时间缩短15%。

这些重点领域无法通过孤立的办法达到完美。USSF需要与更多的空军部官员和美国空军伙伴合作，促进重点投资，振兴共享的数字基础设施，确保其满足所有任务的需要。根据2020年“国防部数据战略”，我们将开展更广泛的合作，确保整个“技术栈”的设计、采购和实施从一开始就以数据和流程互操作性为核心需求。我们还将联合国防部、学术界、工业界和国际合作伙伴的创新思想领袖，他们正在着手进行自己的数字转型。我们即将发布的路线图包含详细的实施指南以及有形的投资和相关的指标。这些投资和指标将抓住合作机会，并根据这四个重点领域进行安排。

重要的是，要在一开始就明确每个重点领域的范围，明确我们期望他们如何为数字太空军愿景作出贡献。重点领域有着千丝万缕的联系；如果我们不能发挥任何一个重点领域的潜力，我们将无法成为真正的数字军种。重点领域有所重叠，相互依存而又协同地促进成为数字军种。通过推动所有四大重点领域的数字主导地位，我们将实现数字太空军愿景，巩固我们在数字化领域的优势，为实现更大的太空优势目标做准备。

• 数字工程

与2018年“国防部数字工程（DE）战略”一致，DE的一个关键目标是管理当代武器系统采办的复杂性，加速从概念到部署、再到作战和后勤保障的整个能力开发生命周期，实现该生命周期的现代化。我们将以权威的数据源为动力，结合大数据方法，利用基于模型的系统工程等技术，并以共享建模与仿真（M&S）框架为基础，管理从作战人员到开发人员的需求和测试，并在整个技术栈中作为一个连续的虚拟数字线程再次进行。我们将开发企业级架构，捕获与威胁模型和预期作战效果相关的优化部队设计，同时支持更广泛的国防部企业战略意图、合作与合伙努力。我们将采用敏捷实践，快速创建和部署增量解决方案，建立开发安全运营工厂，促进软件开发，从一开始就考虑安全问题。我们将逐步、持续地使所有利益相关者能够有针对性地参与，同时确保USSF遵守与关键采办决策点相关的适用法律和政策，而不是在为数不多的参与者中进行里程碑式、基于工件的技术评审。我们还将建立“数字孪生”，将所有这些要素联系在一起，实现与任务合作伙伴的协作，最终实现能力敏捷开发和测试以及向作战和持续性后勤保障的无缝过渡。

改进和加速能力生命周期在很大程度上依赖于拥有由最先进的、可互操作的、低延迟的网络驱动的安全、有活力、有弹性的数字基础设施。除了这个基础设施，USSF将建立必要的工具、应用程序和接口，允许用户生成并操纵数据、模型和分析，所有这些都构成了一个完全联合的数字工程生态系统（DEE）。该DEE可实现从几乎任何地方都能进行及时、可靠和多层次的安全访问，同时促进各个重点领域的所有任务相关活动的守护者之间的敏捷协作。此外，持续的投资将通过与不断发展的能力和威胁同步的定期技术更新保持DEE性能的相关性和安全性，确保守护者随时掌握现代可靠的技术。有了这个DEE，再加上正在进行的采办简化，USSF可以以与作战相关的速度引领能力开发和交付的革命，从而免受威胁。

• 数字人才

“数字人才”这一关键领域由互补的两方面组成：能力与态度。在能力方面，我们将实施一项大胆的新守护者战略，利用每个人的独特优势，为互联的高绩效团队提供动力。我们将利用我们小型军种固有的选择性，从全国各地吸引和招募技术熟练人才，并在一体化的数字人才队伍中管理。为了实现和维持数字流利度战略，我们将确保守护者能够及时获得合适的学习机会，提高和更新技术相关技能，以便他们能够凭直觉优先考虑以数据为中心的解决方案，而不是以产品为中心的流程。此外，还要向主管提供必要的工具和见解，使其在人事招募决策、发展机会和职业发展作出明智而有效的决策。最后，还将建立新职业体系、晋升框架和替代评估方案，以创建与有机建模、数据科学和软件开发（如“太空军程序员”）相关的专业知识，培育数字优先思维的支配性创新文化。

在态度方面，USSF数字人才既受到激励进行协作，又有权采取行动。每一名太空军成员在各个层面上的军种能够“发挥其应有的作用”。例如，鼓励守护者倾向于与他人分享知识和专长，这样，我们的军种就能够“发挥其应有的作用”。例如，鼓励守护者在了解安全需求的同时分享信息。信息分享不仅是在其各自的任务范围内，而且涉及更广泛的利益相关者群体，目的是获得不同的观点并宣传企业观点。最重要的是，要授权太空军的每名成员采取与其责任水平相称的快速行动。“否定指挥”将是默认的立场。在这种立场下，守护者将被授权和鼓励采取行动，除非上级指挥梯队明确保留权限。我们希望确保数字人才不会受到官僚程序的过度阻碍，这些官僚程序只会阻碍其行动的响应性和大胆性。归根结底，我们必须用适当的技能武装人才，让他们获得成功，同时为他们的发展创造正确的环境，然后让路。

• 数字总部

数字总部的概念并不是指一个地点，而是一种功能，它是指在USSF的每一个梯队都能有效和高效地作出决策的能力。为作出有效决策，需把数据视为一种战略资产，利用数据对不确定性进行数字管理，并推动作出灵活的、数据驱动的决策。传统的文档通信是不完善的中间通信形式。认识到这种烦琐性，我们将转而促进直接在数据空间中与决策者以及决策者之间的不加修饰的协作。同时，通过沉浸式可视化和可定制的仪表板从大量数据中辨别相关信息。这些仪表板是最新的，可以随时随地访问。最后，由于真正的决策都涉及风险管理、优先级划分和资源分配，我们将实施数字准备、数字能力组合管理和数字项目目标备忘录（POM）规划等概念。这些概念将提供分析基础，支持敏捷和知情的运营风险管理、运营准备、投资规划和成本能力交易，确保稀缺的资源和能源得到应用，为USSF事业获得最大的任务价值和优势。为了提高效率，我们将建立数字基础，支持快速、数据驱动的决策，并且从不增加价值或通过自动化更好地实现的遗留人员配置和协调活动中解放人才。首先，我们将废除或改造业务流程和政策，去除各级官僚作风，以便我们能够在适当的时间将决策和支持信息传达给适当的人。对于剩余的增值流程，我们将在适当的情况下利用机器学习和扩充，将单调的人员配置活动分配给人工智能（AI）程序或机器人过程自动化，从而使守护者有更多的时间和精力参与训练、教育和作战模拟，向成为世界级作战部队的目标迈进。进一步加快决策制定，根据数字人才的授权原则，确保决策权力下放给最低级别的领导人，消除微观管理的倾向。最终，有效和高效的数字总部将使我们能够以前所未有的敏捷性和效率组织和输送强大的数字能力。

• 数字作战

数字作战代表其他三大重点领域的顶峰。它通过强大的DEE和普及的数字线程嵌入了采办工作，受到了正确的专业激励和创新授权的鼓舞，受到了深思熟虑的授权和独特的发展机会的推动。我们将利用自身先进的DEE和数字游牧民的倾向，对来自不同地点的大多数任务进行分散、优化的卫星作战。我们将通过在我们的野战司令部、三角洲和驻军设施中建立作战发展团队（CDT）来推进数字作战，为这些团队配备所需的数字技能、工具和资源，以设计快速、创新、集成的解决方案，解决当前和不断发展的一系列能力中最紧迫的痛点。例如，与启动后几个月的检测和学习相比，使用共享的数字孪生和持续的利益相关者交流，能更快地起到激励作用。这是因为系统开发人员了解当前的威胁和潜在的战术、技术和程序（TTP），而作战人员甚至可以在系统部署之前获得“实践”经验。在部署后，数字孪生作为强大的异常解析工具将继续发挥其价值，实现全面的故障排除，同时最大限度地降低作战风险。最后，共享建模与仿真基础设施的使用将使作战人员能够在实战虚拟训练场景中磨练作战技能，以应对可预见的遭遇，而我们对适应性和批判性思维的根深蒂固的强调将使守护者能够在突发事件中作出明智反应。

显然，作出明智、快速、数据驱动的决策对我们的愿景至关重要，但在作战领域却显得尤为紧迫，因为在作战领域，时间被压缩，我们的行动会被放大为对生死攸关的结果产生影响。从根本上说，不管任务属于冲突的哪一范围，每一级战争的守护者都必须在组织上得到授权，并配备数字化武器，完全专注于任务。自动化和机器学习对这一目标尤为重要，帮助作战人员以对手无法比拟的迅捷和杀伤力实现联合“杀伤网”。复杂的、数据注入的用户定义的作战画面能以前所未有的精确度和速度实现这一目标。该画面能够融合并呈现多源情报，并与多域指挥与控制能力同步，实现联合作战效果。总之，数字作战综合利用其他重点领域来创建一支致命的太空作战部队，确保将数字主导地位转化为保持太空优势的能力。

五、行动呼吁

鉴于我们的军种规模，数字太空军对于有效应对威胁、支持美国国家安全目标至关重要。我们将为数字军种的运作方法制定标准，通过向人才授权和利用改变游戏规则的技术的力量，打造数字文化。对数字军种的含义达成共识，将为持久和可实施的数字转型创造必要的环境。关键是，每一个守护者都必须大胆地发现朝着数字军种愿景创新和演变的机会。我们必须勤勉地不断寻找改进太空军工作的各个方面的方法；创新必须在整个军种中持续和普及。本着协作和赋权的精神，我们将继续为本次对话以及当前和计划中的数字转型举措的信息共享提供场所。这将有助于为我们即将发布的路线图提供信息并使其成熟，为实现我们的愿景奠定基础。根据这一愿景的前提，我们将迅速制定这一路线图的初始版本，该版本大胆而创新，它将是战略之一，会不断更新，随时适应不断变化的环境。最后，数字太空军愿景以及实现这一愿景的数字转型，仅靠高层领导是无法实现的。从入门级到最高领导层的每一个守护者都可以在实现这一愿景中发挥作用；我们的成功取决于为整个部队努力建立一个统一的支持基础。今年晚些时候，技术和创新办公室将牵头制定实施数字太空军愿景的路线图，将四大数字重点领域提炼为具体目标和举措，持续努力实现互联、创新、数字主导的部队的愿景。永远向上！

术语表

青云中的 agent 程序，使用下面的命令卸载掉。

systemctl stop gapd.service
systemctl disable gapd.service

rm -rf /usr/sbin/zabbix_agentd /etc/zabbix/zabbix_agentd.conf /usr/bin/gapd /etc/init/gapd.conf /usr/lib/systemd/system/gapd.service

http://yann.lecun.com/exdb/mnist/

说明

MNIST 包括6万张28x28的训练样本，1万张测试样本，很多教程都会对它”下手”几乎成为一个 “典范”，可以说它就是计算机视觉里面的Hello World。所以我们这里也会使用MNIST来进行实战。

前面在介绍卷积神经网络的时候说到过LeNet-5，LeNet-5之所以强大就是因为在当时的环境下将MNIST数据的识别率提高到了99%，这里我们也自己从头搭建一个卷积神经网络，也达到99%的准确率。

下载这个文件 pytorch-m1-gpu-mnist.py，源码我贴到文末。

上传到jupyer：

新建一个运行文件

在jupter种运行文件：

%load pytorch-m1-gpu-mnist.py
%run pytorch-m1-gpu-mnist.py

点击Run：

最后输出大致是这样：

Train Epoch: 5 [0/60000 (0%)]	Loss: 0.046214
Train Epoch: 5 [1280/60000 (2%)]	Loss: 0.054890
Train Epoch: 5 [2560/60000 (4%)]	Loss: 0.126030
Train Epoch: 5 [3840/60000 (6%)]	Loss: 0.037496
Train Epoch: 5 [5120/60000 (9%)]	Loss: 0.082181
Train Epoch: 5 [6400/60000 (11%)]	Loss: 0.037875
Train Epoch: 5 [7680/60000 (13%)]	Loss: 0.085949
Train Epoch: 5 [8960/60000 (15%)]	Loss: 0.060418
Train Epoch: 5 [10240/60000 (17%)]	Loss: 0.118635
Train Epoch: 5 [11520/60000 (19%)]	Loss: 0.023937
Train Epoch: 5 [12800/60000 (21%)]	Loss: 0.182207
Train Epoch: 5 [14080/60000 (23%)]	Loss: 0.076019
Train Epoch: 5 [15360/60000 (26%)]	Loss: 0.033017
Train Epoch: 5 [16640/60000 (28%)]	Loss: 0.055296
Train Epoch: 5 [17920/60000 (30%)]	Loss: 0.028324
Train Epoch: 5 [19200/60000 (32%)]	Loss: 0.049647
Train Epoch: 5 [20480/60000 (34%)]	Loss: 0.056441
Train Epoch: 5 [21760/60000 (36%)]	Loss: 0.079691
Train Epoch: 5 [23040/60000 (38%)]	Loss: 0.065786
Train Epoch: 5 [24320/60000 (41%)]	Loss: 0.064102
Train Epoch: 5 [25600/60000 (43%)]	Loss: 0.165235
Train Epoch: 5 [26880/60000 (45%)]	Loss: 0.047473
Train Epoch: 5 [28160/60000 (47%)]	Loss: 0.123398
Train Epoch: 5 [29440/60000 (49%)]	Loss: 0.044776
Train Epoch: 5 [30720/60000 (51%)]	Loss: 0.070954
Train Epoch: 5 [32000/60000 (53%)]	Loss: 0.048687
Train Epoch: 5 [33280/60000 (55%)]	Loss: 0.129717
Train Epoch: 5 [34560/60000 (58%)]	Loss: 0.075629
Train Epoch: 5 [35840/60000 (60%)]	Loss: 0.026882
Train Epoch: 5 [37120/60000 (62%)]	Loss: 0.035822
Train Epoch: 5 [38400/60000 (64%)]	Loss: 0.020158
Train Epoch: 5 [39680/60000 (66%)]	Loss: 0.037771
Train Epoch: 5 [40960/60000 (68%)]	Loss: 0.024614
Train Epoch: 5 [42240/60000 (70%)]	Loss: 0.070286
Train Epoch: 5 [43520/60000 (72%)]	Loss: 0.104104
Train Epoch: 5 [44800/60000 (75%)]	Loss: 0.021874
Train Epoch: 5 [46080/60000 (77%)]	Loss: 0.027039
Train Epoch: 5 [47360/60000 (79%)]	Loss: 0.029215
Train Epoch: 5 [48640/60000 (81%)]	Loss: 0.033327
Train Epoch: 5 [49920/60000 (83%)]	Loss: 0.008433
Train Epoch: 5 [51200/60000 (85%)]	Loss: 0.058720
Train Epoch: 5 [52480/60000 (87%)]	Loss: 0.039366
Train Epoch: 5 [53760/60000 (90%)]	Loss: 0.109450
Train Epoch: 5 [55040/60000 (92%)]	Loss: 0.042343
Train Epoch: 5 [56320/60000 (94%)]	Loss: 0.077304
Train Epoch: 5 [57600/60000 (96%)]	Loss: 0.021365
Train Epoch: 5 [58880/60000 (98%)]	Loss: 0.090809

Test set: Average loss: 0.0475, Accuracy: 9853/10000 (99%)

源码

"""
MNIST with PyTorch on Apple Silicon GPU

Script will be linked in the description as a Github Gist.

Install PyTorch nightly with this command:
pip3 install --pre torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/nightly/cpu

Code borrowed from PyTorch Examples.
"""

import torch
from torch import nn, optim
import torch.nn.functional as F
import torchvision
from torchvision import datasets, transforms

EPOCHS = 5

class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = nn.Conv2d(1, 20, 5, 1)
        self.conv2 = nn.Conv2d(20, 50, 5, 1)
        self.fc1 = nn.Linear(4*4*50, 500)
        self.fc2 = nn.Linear(500, 10)

    def forward(self, x):
        x = F.relu(self.conv1(x))
        x = F.max_pool2d(x, 2, 2)
        x = F.relu(self.conv2(x))
        x = F.max_pool2d(x, 2, 2)
        x = x.view(-1, 4*4*50)
        x = F.relu(self.fc1(x))
        x = self.fc2(x)
        return F.log_softmax(x, dim=1)

def train(model, device, train_loader, optimizer, epoch):
    model.train()
    for batch_idx, (data, target) in enumerate(train_loader):
        data, target = data.to(device), target.to(device)
        optimizer.zero_grad()
        output = model(data)
        loss = F.nll_loss(output, target)
        loss.backward()
        optimizer.step()
        if batch_idx % 10 == 0:
            print('Train Epoch: {} [{}/{} ({:.0f}%)]\tLoss: {:.6f}'.format(
                epoch, batch_idx * len(data), len(train_loader.dataset),
                100. * batch_idx / len(train_loader), loss.item()))

def test(model, device, test_loader):
    model.eval()
    test_loss = 0
    correct = 0
    with torch.no_grad():
        for data, target in test_loader:
            data, target = data.to(device), target.to(device)
            output = model(data)
            test_loss += F.nll_loss(output, target, reduction='sum').item() # sum up batch loss
            pred = output.argmax(dim=1, keepdim=True) # get the index of the max log-probability
            correct += pred.eq(target.view_as(pred)).sum().item()

    test_loss /= len(test_loader.dataset)

    print('\nTest set: Average loss: {:.4f}, Accuracy: {}/{} ({:.0f}%)\n'.format(
        test_loss, correct, len(test_loader.dataset),
        100. * correct / len(test_loader.dataset)))

def main():
    print("PyTorch version:", torch.__version__)
    print("Torchvision version:", torchvision.__version__)

    device = torch.device("mps")
    print("Using Device: ", device)

    train_loader = torch.utils.data.DataLoader(
        datasets.MNIST('../data', train=True, download=True,
                       transform=transforms.Compose([
                           transforms.ToTensor(),
                           transforms.Normalize((0.1307,), (0.3081,))
                       ])),
        batch_size=128, shuffle=True)
    test_loader = torch.utils.data.DataLoader(
        datasets.MNIST('../data', train=False, transform=transforms.Compose([
                           transforms.ToTensor(),
                           transforms.Normalize((0.1307,), (0.3081,))
                       ])),
        batch_size=128, shuffle=True)

    model = Net().to(device)
    optimizer = optim.SGD(model.parameters(), lr=0.01, momentum=0.5)

    for epoch in range(1, EPOCHS + 1):
        train(model, device, train_loader, optimizer, epoch)
        test(model, device, test_loader)

if __name__ == "__main__":
    main()

参考资料

• https://pytorch.org/tutorials/
• PyTorch training on M1-Air GPU
• pytorch-m1-gpu-mnist.py
• PyTorch：训练MNIST数据集