☰

DSL 每周会长时间失去同步几次

tag-icon • tag-icon networking router sync dsl adsl2+
DSL 每周会长时间失去同步几次

我有 Frontier 提供的 12/2 绑定 DSL 服务，每周平均会失去同步 3-4 次，每次持续 1-3 小时。我一直在与当地技术人员合作，他们说他们已经检查了所有东西，并且“已经做了他们知道的一切”。他们更换了一次网关。我已经更换了从 NID 到内部插孔的电线。目前我正在与二级支持人员合作。他们已经验证了同步丢失问题 — 但表示唯一失败的测试是同步测试（他们无法再 ping 我的网关）。二级支持人员建议更换调制解调器（这将是第三次）并测试内部线路。二级支持人员还建议信噪比可能太高，无法推高 12/2（此时实际上是 3），我可能必须切换到 6/1。来过我家的 6 位左右的技术人员中没有一位提到信噪比是个问题。

细节

  • 更换 NID 的电线似乎对我的整体速度有一点帮助。一般来说，我的下载速度差不多是 12，上传速度是 3。
  • 2 级支持在凌晨 1 点显示 1 个同步问题，当时没有人主动使用连接。但是我的电脑可能正在更新。
  • 通常，网关会失去同步，然后在一侧或两侧不断尝试重新同步 2-4 小时。
  • 最近，当我将视频从我的电脑流式传输到 AppleTV 而其他人正在按需流式传输视频时，调制解调器自行重启。一方失去同步长达数小时。我们无法复制此崩溃
  • 最近，当我打开大约 15 个不同网页的标签时，它失去了同步长达 3 个小时。
  • 大多数同步问题都发生在下午晚些时候——下午 4 点到 6 点之间
  • 我正在使用 Actiontec F2250 网关。
  • 预配置链接速度：13923 / 2282 kb。
  • 重新启动网关对于解决同步问题没有效果。
  • 似乎存在缓冲区膨胀的问题
  • 下载软件更新或上传时 ping 数据包丢失率为 2.8%
  • 下载或上传期间延迟较高
  • 距离 DSLAM 7400 英尺
  • SNR 较好的一侧将会下降，而 SRN 较差的一侧将会上升。（见屏幕截图）

    更新日期：2016-12-14
  • 12 月 14 日安装新路由器 — 安装新路由器后，线路 1 上的比特错误减少了，线路 2 上的信噪比提高了。
  • 新路由器安装 2 小时后，两条线路“悄无声息地瘫痪”并立即重新同步，对于线路 1：启动 14 分钟后，出现 239,738 个比特错误、2984 个 HEC 错误、8121 个超级帧错误（SNR 裕度为 11.8）。线路 2 启动 10 分钟后，出现 1225 个比特错误、21 个 HEC 错误、4097 个超级帧错误（SNR 裕度为 10.3）。
  • 错误：xt_TCPMSS：长度错误（589 字节），上次同步问题发生前两分钟

    更新日期：2016-12-17
  • 在 12-14 技术访问时，我问技术人员是否可以更换线路 1 的 DSLAM 卡，以及是否有另一条线路可用。（线路 1 明显存在问题。
  • 12 月 15 日下午 7 点左右，路由器失去同步。
  • 同步丢失后，情况发生了积极的变化——网关现已运行 1 天 15 小时。我希望问题已经得到解决。

    更新日期：2016-12-18
  • 今天失去同步已 1.5 小时。
  • 此问题在两条线路上的错误秒数都很高（高达 521）
  • 下面的截图

在此处输入图片描述

在此处输入图片描述

在此处输入图片描述


自从我开始跟踪以来，我注意到的干扰

Sept 26, 2016 — 2:55pm — Confirmed modem offline. Rebooted modem via admin. Back up at 3:06 with 5.44 down and .52 up. 1 line is down. Intermittent lines at 3:52.  Both lines back before 4:19. Running at 7.5 down, 2.0 up
Sept 28 — 9:20 AM — Low bandwidth. 3.5 Mbps down. Resolved by 9:30    
Sept 30 — 4:35PM: — Low bandwidth 1.5 Mbps down, .81 up. One line down. Back up by 5:00pm    
October 1 6:00pm Low bandwidth. 1 line down. 2.55 down, 1.07 up    
October 4, 5:55 pm — Both lines down. 6:00pm, 1 line down.    
October 11, noon — very low bandwidth. — back up before 12:30
October 11, 3:30pm  down.
October 11, 5:52pm  down — back by 6:45    
October 12, 4:54pm — 1 side down. 2.96Mbps/.89Mbps    
October 13, 5:20pm — very low bandwidth. Unusable. One/both sides down.  1.64Mbps up, 1.76down    
October 18, 5:55pm — very low bandwidth. Unusable. .77 Mbps down, 2.88up. Unable to login to modem    
October 19, 6:30 — low bandwidth, 4.33 down, .72 up. High latency -- 408ms, high Jitter 836ms    
October 23, 6:17 – low bandwidth, 3.37 down, 1.22 up. 1 side down    
October 24, 3:37 – no bandwidth, one/both sides down.    
October 25, 5:25 – no bandwidth down - up works fine, one/both sides down, able to ping. Back by 6:30    
Nov 1, 8:15 — no bandwidth. Both sides down.    
Nov 2, 3:50 — low bandwidth, 3.57 down, 1.31 up One side down.    
Nov 4 — Frontier tech replaced wall jack    
Nov 7, 10:00 — one side down, both sides down. No bandwidth down. No bandwidth up. Cannot connect to modem. 1 side still down at 5:30p.    
Nov 11, 1:40 — both sides down. No bandwidth — back at 1:43
Nov 11, 5:40 — both sides down. No bandwidth — back by 6:20    
Nov 15, 4:30 — both sides down.    
Nov 18 3:50 — both sides down, one side back by 4:00    
Nov 23 10:00p — very low bandwidth    
Nov 24, 8:56a — both sides down.
Nov 24, 4:50p — both sides down.    
Nov 25, Noon — 1 side down. Low bandwidth, then both sides down.    
Nov 27, 2:40  both sides down
Dec 2, 5:55  One side down    
Dec 4 — Replaced wire from NID to gateway (1 wire now).    
Dec 6 6:30 - Router went offline, rebooted automatically (Crashed, this has happened before, but rarely). 
Dec 6 6:55 - One side down    
Dec 8 — two short drops possible. (Lost connectivity with GotoMeeting)    
Dec 9 — 2:40 — Down — appeared to happen by sending multiple HTTP requests. Still down at 5:45. Keeps trying to sync.

数据包丢失

在此处输入图片描述

在此处输入图片描述

SNR 较好的一侧显示正常运行时间较短

在此处输入图片描述 长度不好

答案1

Scott - 我是烈火束缚。我们的新云解决方案专注于对最后一英里 ISP 电路进行持续测试。我们每 5 分钟进行 11 次测试，每天收集 3,168 个数据点。我同意这听起来像是一个只有 ISP 才能解决的问题。但是，如果您想收集更多数据并查看几天甚至几周内的模式，请随时使用我们的免费试用版。我们的旗舰测试每 5 分钟模拟一次 G.711 VoIP 呼叫，每个方向持续 25 秒，在间隔内每天总共发送 360,000 个数据包。由于测试使用 UDP（而不是 ICMP）有效负载每秒 50 个数据包，因此它提供了实际用户数据丢失的更可靠视图。

通过每 5 分钟测试一次，持续几天，您最终可能会看到某些时间模式，这些模式可能与 ISP 网络上发生的某些事情相互关联。

下面的链接显示了我们模拟的 G.711 VoIP 通话结果的屏幕截图。12 月 4 日之前的图表左侧是加利福尼亚州的 Wave Broadband 连接。蓝色尖峰显示由于“Netflix 效应”导致的下载损失。

然后在 12 月 4 日该网站切换到康卡斯特，你可以看到丢失问题几乎完全消失了。

数据包丢失波宽带然后康卡斯特

祝你好运，

戴夫

相关内容