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是216QAM是464QAM是6256QAM是8。vMIMO空间复用层数也就是同时能传几路独立数据流。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×30kHz360kHz那100MHz除以360kHz等于277.7约等于278个RB。这个算法错在哪儿错在它假设了整段频谱都能用来传输数据。实际上一段标称带宽里两头要留保护带Guard Band而且为了保护带和栅格对齐还要做一些取整处理。3GPP在TS 38.104里直接给了一张传输带宽配置表各种带宽和子载波间隔组合对应多少个RB是写死的。NR的RB不要求中心频率对齐到某些特定栅格点但会有部分RB不用于传输之类的情况。正确的取法是这样以FR1Sub-6GHz为例100MHz带宽配30kHz子载波间隔标准表里给的是273个RB。同样100MHz如果配60kHz子载波间隔只有135个RB。这就是为什么同样标称带宽子载波间隔越大能用的RB越少——每个RB在频域上更宽了能塞的RB数量自然减少。这个关系必须记牢RB数由带宽子载波间隔这个二元组共同决定缺一不可。只报带宽不报子载波间隔这个信息是不完整的。3.2 常用配置速查表与换算示例下面这张表是我自己常用的把FR1和FR2的常见组合都列进去了直接抄走就能用。频率范围带宽子载波间隔RB数每帧时隙数时隙长度FR120MHz15kHz106101msFR120MHz30kHz51200.5msFR140MHz30kHz106200.5msFR160MHz30kHz162200.5msFR180MHz30kHz217200.5msFR1100MHz30kHz273200.5msFR1100MHz60kHz135400.25msFR2100MHz60kHz66400.25msFR2200MHz60kHz132400.25msFR2400MHz120kHz264800.125ms看这张表要抓两个规律。第一个规律同样的标称带宽子载波间隔翻倍RB数大致减半。100MHz在30kHz下是273个RB在60kHz下是135个差不多正好一半。第二个规律子载波间隔翻倍每帧时隙数也翻倍所以每帧的符号总数是不变的永远是20×1430kHz或者80×14120kHz这类组合其实都是10ms里有140个符号乘以某个系数——准确说子载波间隔翻倍符号时长减半帧内的符号总数就翻倍。这两个规律一抵消你会发现在同样的标称带宽下改变子载波间隔并不能改变理论峰值速率的量级因为RB数减半、时隙数翻倍乘积基本不变。子载波间隔真正影响的是时延、移动性支持和调度粒度不是峰值速率。很多人以为子载波间隔越大速率越高这是彻底的误解。举个具体换算例子。100MHz带宽、30kHz子载波间隔、273个RB每RB 12个子载波每个时隙14个符号那么一个时隙的RE总数是273 × 12 × 14 45,864 个RE而100MHz配60kHz135个RB40个时隙每帧135 × 12 × 14 22,680 个RE/时隙但每帧有40个时隙所以每帧总RE是907,200 而273×12×1445,864 × 20 917,280 个RE两者差1%左右这个微小差异来自保护带取整不是本质区别。所以我说别在子载波间隔上纠结峰值速率纠结不出东西来。注意FR2毫米波的RB数算法和FR1不完全一样因为毫米波频段宽、保护带占比可以做得更小所以400MHz配120kHz能拿到264个RB而按FR1的比例外推你可能算不出这个数。做毫米波测算一定要单独查表别用FR1的规律硬套。4. 调制与MIMO决定容量倍数的两个变量4.1 每个RE能装几个比特由调制阶数说了算调制的本质是把比特映射成星座图上的点阶数越高一个符号能承载的比特就越多但点与点之间的距离越近对信噪比的要求也就越苛刻。QPSK4个星座点每RE 2比特。信道条件差的时候用比如小区边缘。16QAM16个点每RE 4比特。中等信道质量。64QAM64个点每RE 6比特。良好信道质量。256QAM256个点每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根接收天线但信道条件不好、或者基站侧的预编码没配好终端上报的RIRank Indicator可能只有2甚至1实际只跑2层。也就是说4根天线不代表一定跑4流层数是由信道条件动态决定的。峰值测算里层数一般这么取场景下行层数上行层数说明手机FR1典型212R终端上行单流最常见手机FR1高阶424R终端上行2T4R或2T2RCPE/工业模组42天线空间充足可做高阶FR2手机21毫米波终端受体积限制多为2RFR2 CPE42固定无线接入可上4层这张表很重要因为它解释了为什么同样标称100MHz、256QAM不同终端能跑出的峰值差一倍。做测算的时候一定要先锁定终端能力再谈网络配置。心得给非技术同事讲速率的时候我习惯先说我们这100MHz的载波如果终端是2流的手机理论上限大概是1.5Gbps不到如果换成4流的CPE理论上限能到2.9Gbps。这一句话就能把为什么同样的网不同设备测出来不一样讲明白比长篇大论有用。5. 完整算一遍100MHz、30kHz、4流的FR1下行5.1 裸容量推导每一步数字都摆出来现在把参数全填进去从零算到Gbps。配置假设FR1100MHz带宽30kHz子载波间隔256QAM下行4层MIMO不考虑任何开销和TDD配比。第一步单时隙RE总数273 (RB) × 12 (子载波/RB) × 14 (符号/时隙) 45,864 RE第二步单时隙比特数256QAM8比特/RE45,864 × 8 366,912 bit第三步每帧10ms共有20个时隙30kHz SCS366,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流的上限只有CPE4流的一半这个差距在测算阶段就必须体现出来否则后面的所有结论都是错的。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/147.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制式上下行在时间上分时复用下行只能用一部分时隙。常见的帧结构配置有这么几种帧结构周期下行时隙特殊时隙上行时隙下行占比估算DDDSU2.5ms单周期5个时隙311约74%DDDSU DDSUU2.5ms双周期321013约60%DDDDDDDSUU5ms单周期10个时隙712约75%DSUUU2.5ms113约40%特殊时隙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和这个模型对得上。把整条链路整理成一张表看起来更清楚步骤操作数值1裸容量100MHz/30kHz/256QAM/4层2,935 Mbps2扣除空口开销20%2,348 Mbps3折算TDD下行占比72%1,691 Mbps4折算调度效率95%1,606 Mbps5现场实测4R CPE1,500-1,600 Mbps第4步的调度效率95%是我加的经验项。理论上调度器可以做到100%占满但实际上总有些保护间隔、测量间隙、零星的重传留5%的余量比较实在。6. 上行与毫米波两组对照计算别套错公式6.1 上行峰值为什么只有下行的三分之一很多人第一次算上行会算出个离谱的数字然后把下行公式里的层数一改就完事结果和实测差得远。上行有三处和下行不一样必须单独处理。第一是层数。手机体积限制上行发射天线很难做到4根而且上行多流对终端功放和散热要求极高。现网主流是上行1流或2流2流通常配合2T4R2发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但上行没有SSBDMRS开销和下行类似整体开销经验值取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。第一步算RE264 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的叠加原则很简单总速率等于各载波峰值之和但每一载波要独立扣自己的开销和配比不能拿总带宽算完再乘个系数那样会高估。举个例子100MHz30kHz 60MHz30kHz下行CA都是4层256QAMDDDSU配比。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甚至16QAM256QAM根本没开起来。查一下是不是256QAM功能没开通、或者终端不支持、或者SINR压根不够。第四步看层数RI。终端上报的RI一直是1说明只能单流。原因可能是信道相关性太高、终端只有1根有效天线、或者SRS配置不对导致基站没法做正确的预编码。第五步看帧结构配比。确认小区实际配置的TDD配比是不是你预期的那个。有些站点因为上下行业务需求变化配比会和规划值不一样按DDDSU算出来的速率自然对不上。第六步看是不是被限速。这一条听起来很傻但它是最常见的。签约速率、APN限速、切片策略、QoS配置任何一个环节设了上限你算得再准也没用。我见过一个案子几个人花了两天排查空口最后发现是核心网侧给这个测试卡配了个500Mbps的限速。第七步看服务器和传输。测速服务器的带宽、传输网的瓶颈、甚至是测试终端的USB接口速率都可能成为限制因素。用本地服务器做测速或者用iperf打流能排除掉这一层。7.2 常见问题速查表现象可能原因排查手段处理方向速率只有理论值一半终端只跑2流看RI上报值换4R终端或改善信道速率卡在固定值不动签约或策略限速查QoS和APN配置调整签约速率速率波动大峰值上不去调度RB数不足看调度日志的RB分配检查小区负载和调度策略MCS一直是中低阶256QAM未开通查小区功能开关开通256QAM并确认终端支持上行特别低上行功率受限看终端发射功率和PHR优化覆盖或调整功控参数CA没生效频段组合不支持查终端能力与网络配置补充CA组合配置峰值达标但持续速率低缓冲区和TCP窗口用UDP打流对比调整TCP参数或换测试方法靠近站点速率反而不高过覆盖导致RI降级看不同位置的RI变化调整下倾角或功率7.3 几个我踩过的坑坑一把标称带宽当可用带宽。有些配置标称100MHz但因为频率协调或者保护带的原因实际只配了80MHz甚至更少。算的时候按100MHz实际只给80MHz差了20%怎么也对不上。做测算前先确认小区实际配置的传输带宽。坑二忽略特殊时隙的贡献。DDDSU里的S时隙不是全浪费的它有下行符号。有人算TDD占比时直接按3/560%算忽略了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更专业也更诚实。