核心要点：用户投诉"100M 套餐只跑到 40M"，八成不是线路故障，而是三层限制叠在一起：PON 上行本身是 1.25 Gbit/s 的共享带宽、DBA 给这条 ONU 的 T-CONT 只承诺了保证带宽、限速模板的双桶又把突发吃掉一截。这三层任何一层配错，测速都会掉到套餐的一半以下。本文把三层拆开算账，给出酒店、公寓项目可以直接照抄的带宽模板配置顺序，以及现场五步定位法。

一、先分清三个"带宽"，不然永远吵不清

同一个"100M"，在项目里至少指三件不同的东西，混着说就会变成互相指责：

• 套餐带宽（PIR）——营销页上写的 100M，是这条 ONU 允许跑到的上限，不是它随时能拿到的量。
• 保证带宽（CIR）——OLT 的 DBA 在忙时愿意为这条 ONU 预留的上行额度。这才是真正可以写进合同的数字。
• 实测带宽——终端跑出来的结果，还要再过一道 TCP 窗口、Wi-Fi、测速服务器距离的筛子。

关系是：实测 ≤ 忙时可用 ≈ min(CIR + 竞争到的剩余带宽, PIR)。只要 CIR 定得比 PIR 低很多，忙时实测就一定会明显低于套餐值，这是设计结果，不是设备坏了。

先算一笔最容易被忽略的账：GPON 上行线速 1.244 Gbit/s，扣掉开销实际可用约 1.1 Gbit/s；1:32 分光即 32 户共享 1.1 Gbit/s，平均每户 34M。若 30% 的户同时跑满（约 10 户），每户可分 110M；若全部同时跑，每户只剩 34M。忙时 40M 正落在这个区间。

所以要改的第一件事不是设备配置，而是报价措辞：写"最高 100M、保证 20M"，比只写"100M"安全得多。

二、GPON 上行为什么天生比下行紧张

GPON 是严格的非对称系统：下行 2.488 Gbit/s 广播式发出，所有 ONU 各取所需；上行只有 1.244 Gbit/s，而且是 TDMA 共享——所有 ONU 排在同一张时隙表里，谁拿到授权谁才能发。

这带来两个工程后果：

• 上行是排队制，不是独占制。一条 ONU 想跑满 100M 上行，得先向 OLT 申请到足够的授权；申请不到，物理链路再好也没用。
• 分光比直接等于拥挤程度。分光比每翻一倍，单户平均可得上行就砍一半，而施工成本只降一点点。

这张表说明一件事：如果你打算卖 100M 套餐，分光比就不该超过 1:16；用了 1:32 还想卖 100M，只能靠"忙时不一定跑满"的统计复用撑着，并且必须在合同里说清楚。

三、DBA 与 T-CONT：OLT 到底愿意给这条 ONU 多少

DBA（动态带宽分配）是 OLT 决定"下一个周期给谁多少时隙"的机制。它按 T-CONT 为单位调度，每条 ONU 上可以挂多个 T-CONT，分别承载不同业务。

标准里有五种 T-CONT 类型，工程上真正会用到的其实是三种：

• Type 1（固定带宽）——不管有没有流量都占着。只适合语音与专线，给住户用极其浪费上行。
• Type 2 / 3（保证 + 非保证）——保证带宽优先满足，剩余带宽可以抢。酒店客房、公寓住户应该用这一类。
• Type 4（尽力而为）——完全靠抢，适合访客网络、IoT、固件升级这类可以慢的业务。
• Type 5（混合）——三档齐全，配置最灵活，多数 OLT 的默认推荐。

DBA 模式上，SR（状态上报）让 ONU 主动告诉 OLT 自己队列里积压了多少，调度更准；NSR（非状态上报）靠 OLT 自己监测流量推断，实现简单但对突发业务反应慢。酒店、公寓这类以网页、视频、视频会议为主的场景，用 SR 更合适。

关键的一条配置纪律：每条 ONU 的 CIR 之和，不要超过 PON 口可用上行的 80%。剩下的 20% 留给突发和信令，否则一到晚高峰，所有 ONU 的保证带宽都兑现不了，等于承诺失效。

算一个 64 户的项目：1.1 Gbit/s × 80% = 880 Mbit/s，除以 64 户，每户保证带宽上限约 13–14M。这时候如果还按"每户保证 40M"去配，64 × 40M = 2.56 Gbit/s，是上行容量的两倍多，配置本身就自相矛盾。要么把 CIR 降到 12M 左右，要么把分光比改小，要么直接换 XG-PON。

四、限速模板：为什么第一次测速快、第二次就慢

限速模板（rate-limit profile / traffic profile）是第二层杀手，也是最容易被忽略的一层。它通常有两个桶：

• 峰值桶（PIR）——决定你能跑多快，对应套餐值。
• 突发桶（burst size）——允许短时间超额发送的额度，单位是字节，不是速率。

很多人只填 PIR，burst 留成默认小值（有的设备只有几十 KB）。后果是 TCP 慢启动刚把窗口涨上去就被掐一下，窗口回退再涨——单线程测速永远上不去，多线程反而好看。用户看到的就是"下载慢、测速软件却很快"。

经验值：burst 至少给到 PIR 一秒的字节数。100M 套餐就是 100 Mbit ÷ 8 ≈ 12.5 MB；给 12–16 MB 起步，再按实测微调。另外注意单位陷阱，模板里有的填 KB、有的填 Byte、有的填 bit，混一次就差了 8 倍。

还有一个更常见的错误：把限速模板套在 OLT 上联口，而不是每条 ONU 的业务端口上。结果是整栋楼共用那一个 100M——单户测速正常，两家同时测就各自 50M，十家同时用就集体卡死。单户限速必须在接入侧做。

五、限速应该放在哪一层

正确分工是：接入层做单户限速，汇聚层只做拥塞保护（阈值 85–90%），出口层只做认证与计费，不要重复限速。多层叠加时实际速率取最小值，这就是"100M 只跑 40M"的第三层来源。

六、三套可以直接照抄的模板

下面三组是工程建议起点，不是标准答案，必须按现场并发实测校准（尤其是入住率高的酒店和出租率高的公寓，忙时并发会明显高于办公场景）。

选择逻辑是容量梯度：32 户以内用 32 口设备最省；64 户且要留余量用 64 口；一旦要卖 200M 以上或上行明显不够，就别在 GPON 里挤，直接上 XG-PON——它真正的价值是上行从 1.25G 提到 2.5G。

七、现场五步定位：40M 到底卡在哪一层

1. 看光功率与误码。ONU 收光应在 -8 到 -27 dBm 之间，接近 -27 dBm 就先处理链路（脏端面、弯折、分光器级数），别急着调配置。
2. 绕过用户路由器，直连 ONU 端口测速。这一步排除用户自家路由、Wi-Fi、老旧网线。很多"带宽不够"最后是百兆路由或 2.4G Wi-Fi 造成的。
3. 查 T-CONT 实际授权与 PON 口上行利用率。如果上行利用率长期超过 80%，说明是容量问题，配置怎么调都没用。
4. 查限速模板的位置与 burst。确认模板挂在 ONU 业务端口而不是上联口，burst 不小于 PIR 一秒的量。
5. 查上联口与出口带宽。忙时利用率超过 70% 就要考虑扩容或调整收敛比，这一层的问题会在所有用户身上同时出现。

顺序不能乱：物理层 → 用户侧 → 调度 → 模板 → 汇聚出口。乱序最常见的后果是把容量问题当配置问题，改半天模板什么也没解决。

八、测速方法本身也会骗人

验收和投诉复现要分开做，因为两者的测试条件不一样。

• 单线程受 TCP 窗口限制。理论吞吐 ≈ 窗口 ÷ RTT。64 KB 窗口配 30 ms 时延，上限只有约 17 Mbit/s；256 KB 窗口约 68 Mbit/s；1 MB 窗口才能到 270 Mbit/s 左右。老设备单线程跑不满千兆，是协议问题，不是带宽问题。
• 测速节点距离会压低结果。跨境或跨运营商节点时延一高，单线程必掉，务必用本地同网节点。
• Wi-Fi 是常见的假故障源。手机在 2.4G 频段通常只能跑 40–70M，5G 频段才能接近套餐值。验收一律用有线 + 多线程，投诉复现才按用户原环境测。

九、几个反复出现的误区

• 以为分光比越大越省钱。省的是光缆和分光器，贵的是上行和投诉。分光比是容量决策，不是成本决策。
• 把 PIR 当 CIR 卖。合同写 100M，实际保证 40M，等于给自己埋了一年的工单。
• 只调上联口不限单户。结果是"人人都不快"，而且找不到具体责任人。
• 忽略 IPTV 组播的影响。组播走下行，不占上行，但会占用 ONU 的处理与缓存，配置不当时表现为"看电视时上网卡"。
• 认为 XG-PON 只是"下行更快"。对上行拥堵型项目，上行从 1.25G 到 2.5G 才是真正的解药。

结语

带宽投诉本质上是一道算术题，不是玄学。把"套餐值、保证值、实测值"三个数字分开写清楚，把 CIR 之和控制在 PON 口上行的 80% 以内，把限速放在接入层并给足 burst，绝大多数"跑不满"的工单在开局阶段就不会产生。剩下的才交给运维去定位。

对酒店和公寓项目来说，同一张 PON 还能承载客控、语音、IPTV 与监控，但每多一类业务，上行的账就要重算一次。先算账，再选设备。

联系我们

如果你正在规划酒店、公寓或园区的光网络，需要按实际户数与并发做一次带宽核算，欢迎直接联系我们：

• 邮箱：zhenghui.xu@sczhgx.com
• WhatsApp：+86 17612849559
• 官方商城：shop.sczhgx.com