1

У меня есть служба DSL 12/2 от Frontier, которая теряет синхронизацию 3-4 раза в неделю в среднем по 1-3 часа. Я работал с местными техническими специалистами, которые говорят, что они проверили все и что они «сделали все, что они умеют делать». Они заменили ворота один раз. Я заменил провод от NID до внутреннего разъема. В настоящее время я работаю с поддержкой второго уровня. Они проверили проблему потери синхронизации - но говорят, что единственный тест, который терпит неудачу, является тестом синхронизации (и они больше не могут пропинговать мой шлюз). Поддержка уровня 2 рекомендует заменить модем (это будет 3-й) и проверить внутреннюю проводку. Поддержка уровня 2 также предполагает, что отношение сигнал / шум может быть слишком высоким, чтобы подтолкнуть 12/2 (что на самом деле составляет 3 на данный момент), и что мне, возможно, придется переключиться на 6/1. Ни один из 6 или около того техников, которые были в доме, не упомянул, что отношение сигнал / шум является проблемой.

подробности

  • Замена провода на NID, казалось, немного помогла моей общей скорости. Как правило, я получаю почти 12 и 3.
  • Поддержка уровня 2 показала 1 проблему синхронизации в 1:00, когда никто активно не использовал соединение. Однако мой компьютер мог обновляться.
  • Обычно шлюз теряет синхронизацию, а затем постоянно пытается выполнить повторную синхронизацию в течение 2-4 часов на одной или обеих сторонах.
  • Недавно модем перезагрузился сам, когда я транслировал видео со своего компьютера на AppleTV, а кто-то другой транслировал видео по требованию. Одна сторона потеряла синхронизацию на несколько часов. Мы не могли повторить эту аварию
  • Недавно он потерял синхронизацию на 3 часа, когда я открыл примерно 15 вкладок для уникальных веб-страниц.
  • Большинство проблем с синхронизацией происходит позже во второй половине дня - с 16:00 до 18:00.
  • Я использую шлюз Actiontec F2250.
  • Предусмотренная скорость соединения: 13923/2282 кб.
  • Перезагрузка шлюза не влияет на решение проблем синхронизации.
  • Кажется, есть проблема с раздуванием буфера
  • 2.8% потери пакетов при пинге при загрузке обновления программного обеспечения или при загрузке
  • Высокая задержка при загрузке или загрузке
  • 7400 футов в DSLAM
  • Сторона с лучшим SNR снизится, а сторона с лучшим SRN останется. (Смотрите скриншот)

    ОБНОВЛЕНИЕ 12-14-2016
  • Новый маршрутизатор 14 декабря - после установки нового маршрутизатора в строке 1 было меньше ошибок по битам, а в строке 2 улучшено SNR.
  • Через 2 часа после установки нового маршрутизатора обе линии отключились и сразу же синхронизировались. Для строки 1: после 14 минут безотказной работы 239 738 битовых ошибок, 2984 ошибок HEC, 8121 ошибок суперкадров (SNR Margin - 11,8) , Линия 2, которая была задействована в течение 10 минут, содержит ошибки 1225 бит, 21 ошибку HEC, ошибку 4097 суперкадров (SNR Margin - 10,3).
  • Ошибка: xt_TCPMSS: неверная длина (589 байт), за две минуты до последней проблемы синхронизации

    ОБНОВЛЕНИЕ 12-17-2016
  • Во время технического визита 12-14 я спросил технического специалиста, может ли он заменить карту DSLAM для линии 1 и была ли доступна другая линия. (Была очевидная проблема со строкой 1.
  • 12-15 роутер потерял синхронизацию около 7 вечера.
  • Что-то изменилось после потери синхронизации - шлюз теперь работает в течение 1 дня и 15 часов. Я надеюсь, что это было решено.

    ОБНОВЛЕНИЕ 12-18-2016
  • Потерялась синхронизация сегодня на 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 ответ1

1

Скотт - я соучредитель Firebind. Наше новое облачное решение ориентировано на непрерывное тестирование каналов ISP последней мили. Мы проводим серию из 11 тестов каждые 5 минут, собирая 3168 точек данных в день. Я согласен, что это звучит как проблема, которую может решить только провайдер. Но если вы хотите собрать больше данных и увидеть шаблоны в течение нескольких дней или даже нескольких недель, не стесняйтесь использовать нашу бесплатную пробную версию. Наш флагманский тест имитирует VoIP-вызов G.711 в течение 25 секунд в каждом направлении каждые 5 минут, посылая в общей сложности 360 000 пакетов в день через интервалы. Поскольку тест составляет 50 пакетов в секунду с использованием полезных нагрузок UDP (в отличие от ICMP), он обеспечивает гораздо более надежное представление о фактической потере пользовательских данных.

Проводя тестирование каждые 5 минут в течение нескольких дней, вы можете в конечном итоге увидеть определенные шаблоны времени дня, которые могут быть перекрестно связаны с чем-то, что происходит в сети ISP.

Ссылка ниже показывает скриншот результатов нашего смоделированного вызова G.711 VoIP. Левая часть графика до 4 декабря была подключена к широкополосной сети в Калифорнии. Синие всплески показывают потерю загрузки из-за "эффекта Netflix".

Затем 4 декабря этот сайт переключился на Comcast, и вы можете видеть, что проблема потерь почти полностью исчезла.

Пакет широкополосной волны потери, затем Comcast

удачи,

Дейв

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .