1. 先把"峰值速率"这四个字拆开看

5G峰值速率计算这件事，我在不同场合被问过不下几十次，问的人有做网络优化的、有做终端测试的、也有刚入行想搞明白"为什么宣传说几个G、我手机上只有几百兆"的。多数人卡住的地方并非数学，而是没搞清楚自己在算哪一层的东西。有人把带宽直接除以子载波间隔就当成RB数，有人把256QAM的8比特直接乘上带宽却忘了扣控制信道开销，还有人拿FDD的算法去套TDD的现网配置，算出来的数字和实测差三倍还找不到原因。

这篇东西就是想把这条链路从头到尾捋一遍：从一帧10毫秒怎么切时隙，一个时隙里到底有多少个能装数据的资源粒子，每个粒子能塞几个比特，再乘上几层空间流，最后怎么扣掉那些"名义上属于你但实际上传不了业务"的开销。算完之后你手里会有一个可以自己改参数复现的模型，改带宽、改子载波间隔、改调制阶数、改层数、改TDD配比，都能立刻出结果。

适合谁看：做无线网络规划、终端射频与协议测试、网络性能优化、以及需要给非技术同事解释"为什么现场速率只有理论值一半"的同学。不需要你是3GPP专家，但最好知道RB、RE、MIMO层数这些词大概指什么，不知道也没关系，下面会顺手把必要的概念补齐。

2. 计算骨架：一条公式和它的五个输入项

2.1 三个层级的速率概念，别混着用

在动手算之前，先把三个经常被混为一谈的概念分清楚，否则后面全是糊涂账。

第一个是理论峰值速率，也就是在"所有资源全给你、信道条件无限好、没有任何重传和调度空档"这个理想假设下算出来的天花板。它是设备能力和网络配置的函数，与你在某个具体位置、某个具体时刻能不能达到没有关系。第二个是小区峰值吞吐，指的是一个小区在满配、单用户独占全部资源情况下能到多少，通常就等于理论峰值。第三个是用户体验速率，这才是测速软件上跳动的那个数字，它受制于同时接入的用户数、调度公平性、TCP窗口、服务器带宽、乃至你手机发热降频。

我见过最常见的错误，就是拿第三个去和第一个比，然后得出"这网络不行"的结论。实际上从理论峰值到体验速率，中间要过三道扣减：协议开销、帧结构（TDD上下行配比）、以及实际调度效率。这三道扣减叠起来，能留下六成已经是很好的现网了。

所以在做任何计算之前，先问清楚自己：我要的是哪个数？是给终端能力定规格，还是给站点容量做规划，还是解释现场测速结果？目标不同，参数的取法完全不同。

2.2 通用公式与它的五个输入项

把公式写出来其实很短：

单载波峰值速率 = 每时隙可用RE数 × 每RE比特数 × MIMO层数 × 每帧时隙数 ÷ 帧长 × (1 − 开销比例) × TDD有效占比

看着简单，难的是每一项怎么取。展开成更细的形式：

速率 = (N_RB × 12 × N_sym × N_slot × J × v) ÷ T_frame × (1 − OH) × α

这里每个符号的含义分别是：

• N_RB：给定带宽和子载波间隔下的传输带宽配置，单位是资源块。注意这是标准里硬性规定的表值，不是你用带宽除出来的。
• 12：一个资源块在频域上固定包含12个子载波，这是NR和LTE共有的约定。
• N_sym：一个时隙内的OFDM符号数，常规循环前缀下是14。
• N_slot：一个无线帧内的时隙数，由子载波间隔决定。
• J：调制阶数折算的每RE比特数，QPSK是2，16QAM是4，64QAM是6，256QAM是8。
• v：MIMO空间复用层数，也就是同时能传几路独立数据流。
• T_frame：帧长，10毫秒，算速率时用0.01秒。
• OH：控制信道、解调参考信号、同步信号等占掉的比例。
• α：TDD场景下的下行或上行时间占比，FDD场景取1。

五个输入项里，N_RB、N_sym、N_slot、J、v是"硬"的，查表和查终端能力就能定；OH和α是"软"的，不同厂家、不同配置、不同算法取法差别很大，这也是为什么不同来源给出的峰值数字经常对不上。

提示：算速率时单位统一用比特和秒，最后再换算成Mbps。千万别在中途混用千进制和1024进制，1Gbps就是1000Mbps，不是1024Mbps，这个坑我见过有人在汇报材料里踩过，被当场指出来很难看。

3. 带宽、子载波间隔与RB数：最容易算错的第一层

3.1 RB数不是你除出来的，是标准里查出来的

很多人第一反应是：100MHz带宽、30kHz子载波间隔，一个RB占12×30kHz=360kHz，那100MHz除以360kHz等于277.7，约等于278个RB。这个算法错在哪儿？错在它假设了整段频谱都能用来传输数据。

实际上一段标称带宽里，两头要留保护带（Guard Band），而且为了保护带和栅格对齐，还要做一些取整处理。3GPP在TS 38.104里直接给了一张传输带宽配置表，各种带宽和子载波间隔组合对应多少个RB，是写死的。NR的RB不要求中心频率对齐到某些特定栅格点，但会有"部分RB不用于传输"之类的情况。

正确的取法是这样：以FR1（Sub-6GHz）为例，100MHz带宽配30kHz子载波间隔，标准表里给的是273个RB。同样100MHz如果配60kHz子载波间隔，只有135个RB。这就是为什么同样标称带宽，子载波间隔越大，能用的RB越少——每个RB在频域上更宽了，能塞的RB数量自然减少。

这个关系必须记牢：RB数由（带宽，子载波间隔）这个二元组共同决定，缺一不可。只报带宽不报子载波间隔，这个信息是不完整的。

3.2 常用配置速查表与换算示例

下面这张表是我自己常用的，把FR1和FR2的常见组合都列进去了，直接抄走就能用。

看这张表要抓两个规律。第一个规律：同样的标称带宽，子载波间隔翻倍，RB数大致减半。100MHz在30kHz下是273个RB，在60kHz下是135个，差不多正好一半。第二个规律：子载波间隔翻倍，每帧时隙数也翻倍，所以每帧的符号总数是不变的，永远是20×14（30kHz）或者80×14（120kHz）这类组合，其实都是10ms里有140个符号乘以某个系数——准确说，子载波间隔翻倍，符号时长减半，帧内的符号总数就翻倍。

这两个规律一抵消，你会发现：在同样的标称带宽下，改变子载波间隔并不能改变理论峰值速率的量级，因为RB数减半、时隙数翻倍，乘积基本不变。子载波间隔真正影响的是时延、移动性支持和调度粒度，不是峰值速率。很多人以为"子载波间隔越大速率越高"，这是彻底的误解。

举个具体换算例子。100MHz带宽、30kHz子载波间隔、273个RB，每RB 12个子载波，每个时隙14个符号，那么一个时隙的RE总数是：

273 × 12 × 14 = 45,864 个RE

而100MHz配60kHz，135个RB，40个时隙每帧：

135 × 12 × 14 = 22,680 个RE/时隙，但每帧有40个时隙，所以每帧总RE是907,200 而273×12×14=45,864 × 20 = 917,280 个RE

两者差1%左右，这个微小差异来自保护带取整，不是本质区别。所以我说，别在子载波间隔上纠结峰值速率，纠结不出东西来。

注意：FR2（毫米波）的RB数算法和FR1不完全一样，因为毫米波频段宽、保护带占比可以做得更小，所以400MHz配120kHz能拿到264个RB，而按FR1的比例外推你可能算不出这个数。做毫米波测算一定要单独查表，别用FR1的规律硬套。

4. 调制与MIMO：决定容量倍数的两个变量

4.1 每个RE能装几个比特，由调制阶数说了算

调制的本质是把比特映射成星座图上的点，阶数越高，一个符号能承载的比特就越多，但点与点之间的距离越近，对信噪比的要求也就越苛刻。

• QPSK：4个星座点，每RE 2比特。信道条件差的时候用，比如小区边缘。
• 16QAM：16个点，每RE 4比特。中等信道质量。
• 64QAM：64个点，每RE 6比特。良好信道质量。
• 256QAM：256个点，每RE 8比特。需要很高的信噪比，通常要求SINR在20dB以上。

峰值速率计算默认取最高的调制阶数，下行取256QAM，这是NR下行支持的最高阶调制。上行呢？NR上行也支持256QAM，但实际网络里很多配置只到64QAM，原因后面讲上行的时候会展开。

这里有个细节容易被忽略：256QAM不是"开了就一定能用"，它取决于终端上报的CQI、基站配置的MCS表（NR有64QAM表、256QAM表、低码率表三套）、以及实际信道质量。算峰值的时候按8比特算没问题，但要清楚这是"最好情况"，一旦用户走到小区中远点，MCS回落，每RE比特数立刻掉到6甚至4，速率跟着断崖式下跌。这就是为什么实测速率在小区中心能到1.4Gbps，走到覆盖边缘只剩200Mbps。

4.2 层数怎么影响速率，以及为什么它最容易被高估

MIMO层数v，是空间复用能同时传几路独立数据流。每一路流在频域上占用同样的RE，但走不同的空间路径，所以理论上前提是信道之间相关性足够低。

对峰值速率来说，层数是一个纯粹的乘法系数：4层就是2层的两倍。但这里有两个现实约束，必须清楚。

第一个约束是终端天线的数量。下行4流接收需要终端至少有4根接收天线，这就是常说的4R。市面上很多手机是2R，也就是只能做2层下行，理论上限直接砍半。所以你看参数表写"支持4×4 MIMO"，先确认是基站侧支持4发还是终端支持4收，这两个是完全不同的东西。

第二个约束是层数不等于天线数。终端有4根接收天线，但信道条件不好、或者基站侧的预编码没配好，终端上报的RI（Rank Indicator）可能只有2甚至1，实际只跑2层。也就是说，4根天线不代表一定跑4流，层数是由信道条件动态决定的。

峰值测算里，层数一般这么取：

这张表很重要，因为它解释了为什么同样标称"100MHz、256QAM"，不同终端能跑出的峰值差一倍。做测算的时候，一定要先锁定终端能力，再谈网络配置。

心得：给非技术同事讲速率的时候，我习惯先说"我们这100MHz的载波，如果终端是2流的手机，理论上限大概是1.5Gbps不到；如果换成4流的CPE，理论上限能到2.9Gbps"。这一句话就能把"为什么同样的网，不同设备测出来不一样"讲明白，比长篇大论有用。

5. 完整算一遍：100MHz、30kHz、4流的FR1下行

5.1 裸容量推导，每一步数字都摆出来

现在把参数全填进去，从零算到Gbps。配置假设：FR1，100MHz带宽，30kHz子载波间隔，256QAM下行，4层MIMO，不考虑任何开销和TDD配比。

第一步，单时隙RE总数：

273 (RB) × 12 (子载波/RB) × 14 (符号/时隙) = 45,864 RE

第二步，单时隙比特数（256QAM，8比特/RE）：

45,864 × 8 = 366,912 bit

第三步，每帧（10ms）共有20个时隙（30kHz SCS）：

366,912 × 20 = 7,338,240 bit/帧

第四步，换算成单层速率：

7,338,240 bit ÷ 0.01 s = 733,824,000 bit/s ≈ 733.8 Mbps

第五步，乘上4层：

733.8 × 4 = 2,935.3 Mbps ≈ 2.94 Gbps

这个2.94Gbps就是不含任何开销的裸容量（也叫理论峰值上限）。如果你在某个文档里看到"100MHz 5G峰值2.9Gbps"，它大概率就是这个数，是一个没扣开销的毛值。这个数字本身没错，但它不能直接拿来和现网实测比。

顺手再算一个2层的版本，这是绝大多数手机的真实情况：

733.8 × 2 = 1,467.6 Mbps ≈ 1.47 Gbps

所以同样100MHz，手机（2流）的上限只有CPE（4流）的一半，这个差距在测算阶段就必须体现出来，否则后面的所有结论都是错的。

5.2 开销扣减：从2.94Gbps到2.34Gbps中间少了什么

裸容量不能全用来传业务数据，有一部分RE被各种"管理性"信号占用了。这些开销主要有四类，我按实际占用量从大到小排：

第一类是PDCCH（下行控制信道）。它占用每个时隙开头的若干符号，用来告诉终端"这一时隙的数据在哪些RB上、用什么调制编码"。NR的PDCCH占用是可变的，1到3个符号，常见配置是1到2个符号。按2个符号算，占用比例大约14.3%；按1个符号算约7.1%。现网多数配置接近1到2个符号。

第二类是DMRS（解调参考信号）。终端要靠它估计信道才能解调数据。NR下行支持前置DMRS单符号或双符号配置，单符号约占1/14（7.1%），双符号约14.3%。高移动性场景或者高阶MIMO会用双符号，开销翻倍。

第三类是SSB（同步信号块）。终端搜索小区、做时频同步要靠它。SSB在时域上周期性发送，常见周期20ms，占用4个符号。分摊到10ms一帧，占比其实很小，1%到2%量级，但如果算得精细也要考虑。

第四类是各类其他参考信号。CSI-RS用于信道状态测量，TRS用于时频跟踪，还有PT-RS（相位跟踪参考信号，256QAM在高频段必备）。这些信号的开销随配置变化极大，从2%到10%都有可能。

把这四类加起来，下行开销的经验取值在**20%到25%**之间。按20%算：

2,935.3 × 0.8 = 2,348.2 Mbps ≈ 2.35 Gbps

这个2.35Gbps，正好和3GPP TS 38.306里给出的参考峰值基本吻合。那份规范里的算法是逐项扣除的，思路和我上面说的一致：先算满配，再扣PDCCH、扣DMRS、扣其他开销。所以如果你需要一个"标准答案"，可以直接引用规范值；如果你需要针对自己的网络配置算，就按上面这个逐项扣减的方法来，参数可以从网管侧取到实际配置。

开销这个系数是整套计算里最"活"的一项。同一个基站，把PDCCH从2符号改成1符号，把DMRS从双符号改成单符号，开销能从22%降到16%，峰值直接多出7个百分点。所以做测算的时候，我一般会准备三档：乐观（开销16%）、常规（20%）、保守（25%），然后告诉决策方"峰值是在这个区间内"。

5.3 TDD配比折算：为什么现网只能跑到一半多

前面算的都是"全时隙都用于下行"的假想情况。FR1主流频段用的是TDD制式，上下行在时间上分时复用，下行只能用一部分时隙。

常见的帧结构配置有这么几种：

特殊时隙（S时隙）里有一部分符号用于下行、一部分用于上行、中间留保护间隔，做估算时按70%左右归入下行即可。

取DDDSU这种最常见的大下行配置，下行占比约74%，但要扣掉"下行时隙里的第一个时隙还要发SSB"这类细节，实际可用的业务下行占比通常在70%到72%。

把这个系数乘上去：

2,348.2 × 0.72 ≈ 1,690.7 Mbps ≈ 1.69 Gbps

到这一步，1.69Gbps就是一个相当接近现实的"单用户理论可达"数字了。现网实测我们实验室里的4R CPE能跑到1.5到1.6Gbps，手机（2流）能跑到800Mbps到1.1Gbps，和这个模型对得上。

把整条链路整理成一张表，看起来更清楚：

第4步的调度效率95%是我加的经验项。理论上调度器可以做到100%占满，但实际上总有些保护间隔、测量间隙、零星的重传，留5%的余量比较实在。

6. 上行与毫米波：两组对照计算，别套错公式

6.1 上行峰值为什么只有下行的三分之一

很多人第一次算上行会算出个离谱的数字，然后把下行公式里的层数一改就完事，结果和实测差得远。上行有三处和下行不一样，必须单独处理。

第一是层数。手机体积限制，上行发射天线很难做到4根，而且上行多流对终端功放和散热要求极高。现网主流是上行1流或2流，2流通常配合2T4R（2发4收，接收时4根天线合路）的终端形态。高端CPE可以做到2流，4流上行在现网极少见。

第二是调制阶数。上行256QAM虽然标准支持，但对终端发射信号的EVM要求非常苛刻，需要极好的信道条件。绝大多数网络配置上行最高到64QAM，也就是6比特/RE。

第三是TDD上行占比。DDDSU配置下，上行只占1/5的时隙，即使算上特殊时隙里的上行符号，也就28%左右。

把这三个因素代进100MHz、30kHz的配置：

45,864 RE/时隙 × 6 bit = 275,184 bit/时隙 × 20 时隙/帧 = 5,503,680 bit/帧 ÷ 0.01 s = 550.4 Mbps（单层） × 2层 = 1,100.8 Mbps ≈ 1.10 Gbps

扣开销。上行也有PDCCH等价物（叫PDCCH，上行控制走PUCCH），但上行没有SSB，DMRS开销和下行类似，整体开销经验值取15%左右：

1,100.8 × 0.85 = 935.7 Mbps

再乘上行时间占比28%：

935.7 × 0.28 ≈ 262 Mbps

这个262Mbps，和现网实测手机上行200到300Mbps的量级完全吻合。所以下次有人问"为什么上行只有下行的一个零头"，你可以直接把这三个系数甩给他：层数减半、调制少2比特、时间占比只有28%，三个乘起来正好是三分之一到四分之一。

6.2 毫米波场景：带宽翻四倍，但配比和开销都变了

毫米波（FR2）算起来要换一套参数，最典型的配置是400MHz带宽、120kHz子载波间隔、4层、256QAM。

第一步算RE：

264 RB × 12 × 14 = 44,352 RE/时隙

第二步算每帧时隙数，120kHz下每帧80个时隙：

44,352 × 8 bit = 354,816 bit/时隙 × 80 = 28,385,280 bit/帧 ÷ 0.01 = 2,838.5 Mbps（单层） × 4层 = 11,354 Mbps ≈ 11.35 Gbps

这个11.35Gbps是裸容量。扣开销要注意，毫米波必须开PT-RS（相位跟踪参考信号）来补偿相位噪声，开销比Sub-6高，经验值取22%到25%：

11.35 × 0.78 ≈ 8.85 Gbps

再乘TDD占比。毫米波帧结构更灵活，常见配置下行占比能到75%左右：

8.85 × 0.75 ≈ 6.64 Gbps

所以单载波400MHz毫米波的理论可达是6.6Gbps量级，实际设备能跑到4到6Gbps。这个数字看着吓人，但毫米波覆盖半径小、穿透差，实际部署里更多用在体育场馆、交通枢纽这类高密度热点，或者是固定无线接入场景。做容量规划的时候，一家一户能分到多少才是关键，单用户峰值高不高其实没那么重要。

6.3 载波聚合和双连接怎么叠加

单个载波算完，运营里几乎一定要做载波聚合（CA）。CA的叠加原则很简单：总速率等于各载波峰值之和，但每一载波要独立扣自己的开销和配比，不能拿总带宽算完再乘个系数，那样会高估。

举个例子：100MHz（30kHz）+ 60MHz（30kHz）下行CA，都是4层256QAM，DDDSU配比。

100MHz载波：2,935 × 0.8 × 0.72 = 1,691 Mbps 60MHz载波：162 RB × 12 × 14 = 27,216 RE/时隙，×8 bit ×20时隙÷0.01 = 435.5 Mbps单层，×4 = 1,742 Mbps裸容量，×0.8×0.72 = 1,003 Mbps

合计约2,694Mbps。注意，60MHz载波虽然带宽只有100MHz的59%，但速率只有它的59%左右，比例是对的，说明算法正确。

但CA有两个现实折扣。第一，主载波要承担控制面信令和寻呼，开销比辅载波略高；第二，跨载波调度如果开启，辅载波上的PDCCH可以省掉，等于降低开销，反而能提一点速率。这两项一正一负，做规划时通常忽略不计，误差在2%以内。

双连接（EN-DC或者NR-DC）则是另一回事，它是两条独立的空口链路，速率可以近乎线性相加，但终端的总发射功率、基带处理能力、发热都会成为瓶颈。实际测下来双连接的峰值往往达不到两条链路峰值之和，能到八成就不错了。

注意：给项目做容量规划时，千万不要把CA峰值当成小区容量。CA峰值是一个用户独占所有载波所有资源的极端情况，真实小区里几十个用户分，人均速率是另一个数量级。这两件事要分开建模。

7. 理论值和实测差一截：排查思路与速查表

7.1 从终端能力到空口配置的排查顺序

现场测速不达标，我的排查顺序是固定的：先从下往上，不要一上来就怀疑网络。

第一步，看终端能力。查终端支持的频段组合、最大调制阶数、MIMO能力、支持的层数。很多"速率上不去"的案子，最后发现用的是2流终端却按4流算的预期。这一步用终端的信令日志就能看到，几分钟的事。

第二步，看实际调度的RB数。理论计算假设273个RB全给你，实际调度器可能只给你200个，甚至因为你信道质量不好只给你50个。日志里能直接看到每次调度的RB分配，这个数字一出来，问题就定位了一半。

第三步，看实际用的MCS。终端上报的CQI决定了基站给你什么调制编码。如果CQI只有8到9，那就是64QAM甚至16QAM，256QAM根本没开起来。查一下是不是256QAM功能没开通、或者终端不支持、或者SINR压根不够。

第四步，看层数（RI）。终端上报的RI一直是1，说明只能单流。原因可能是信道相关性太高、终端只有1根有效天线、或者SRS配置不对导致基站没法做正确的预编码。

第五步，看帧结构配比。确认小区实际配置的TDD配比是不是你预期的那个。有些站点因为上下行业务需求变化，配比会和规划值不一样，按DDDSU算出来的速率自然对不上。

第六步，看是不是被限速。这一条听起来很傻，但它是最常见的。签约速率、APN限速、切片策略、QoS配置，任何一个环节设了上限，你算得再准也没用。我见过一个案子，几个人花了两天排查空口，最后发现是核心网侧给这个测试卡配了个500Mbps的限速。

第七步，看服务器和传输。测速服务器的带宽、传输网的瓶颈、甚至是测试终端的USB接口速率，都可能成为限制因素。用本地服务器做测速，或者用iperf打流，能排除掉这一层。

7.2 常见问题速查表

7.3 几个我踩过的坑

坑一：把标称带宽当可用带宽。有些配置标称100MHz，但因为频率协调或者保护带的原因，实际只配了80MHz甚至更少。算的时候按100MHz，实际只给80MHz，差了20%，怎么也对不上。做测算前先确认小区实际配置的传输带宽。

坑二：忽略特殊时隙的贡献。DDDSU里的S时隙不是全浪费的，它有下行符号。有人算TDD占比时直接按3/5=60%算，忽略了S时隙里的下行部分，结果低估了10个百分点。

坑三：用错帧长。算速率时如果用时隙长度去除，容易在单位上翻车。稳妥的做法是统一算"每10ms帧传多少比特，再除以0.01秒"，这样不会错。

坑四：把SSB开销重复扣。SSB是周期性发的，20ms一次，不是每个时隙都有。有人把它摊到每个时隙去扣，把开销算高了。正确做法是按周期摊薄，占比很小。

坑五：毫米波忘记PT-RS。Sub-6的测算里PT-RS经常可忽略，但毫米波用256QAM必须开PT-RS，不开的话相位噪声会导致解调失败。算毫米波峰值时，开销至少要比Sub-6多2到3个百分点。

8. 一些实操层面的补充

写到这里，公式和流程都齐了。最后补几点我在实际项目里觉得有用、但文档里一般不写的东西。

做测算一定要留参数表。我习惯用一个表格把所有输入参数列出来：带宽、SCS、RB数、调制、层数、开销、TDD配比、调度效率，每一项旁边标注来源（标准表、网管配置、经验值）。这样别人拿到你的结果，能一眼看出哪个参数和他们的认知不一致，沟通成本能降一大半。最怕的就是给一个孤零零的"峰值1.7Gbps"，没人知道你是怎么来的。

同一套模型要能算三种口径。裸容量（不扣任何开销）、标准峰值（扣开销不扣TDD）、可部署峰值（全扣）。这三个数在项目里的用途完全不同：裸容量用于和芯片规格对比，标准峰值用于写宣传材料或者应答标书，可部署峰值用于容量规划。混用会出事。

注意终端的散热和功耗墙。所有的峰值都是短时峰值，跑满一分钟，手机会发热降频，速率会掉。做长时间测试的时候，看到前30秒1.2Gbps、后面掉到800Mbps，这不是网络问题，是终端的热设计功耗到了。测峰值要快，测持续速率要控制时长并记录温度。

实际配置和标准表可能不一致。标准给的RB数是"最大可用"，现网可能因为各种原因配置得更少。比如某些场景为了留保护带，只配260个RB。这种偏差在5%以内，做精确测算时要去网管确认。

多用交叉验证。算完之后，拿一个已知的实测值反推：如果实测是1.5Gbps，反推出来的等效开销和TDD占比是多少？和你假设的值对不对得上？对不上就说明某个假设错了。这个方法比正向算一遍更容易发现问题，我一般会正着算一遍、反着验一遍，两边对上才敢往外发结论。

最后说一句关于精度的话。这套算法给出的结果，误差在5%以内就算很准了，不要追求小数点后两位。因为开销、调度效率这些参数本身就是区间值，你把它算到小数点后三位，反而显得不懂行。给别人报数的时候，说"1.6到1.7Gbps之间"，比说"1.691Gbps"更专业，也更诚实。