DSL теряет синхронизацию несколько раз в неделю в течение длительных периодов времени

751
Scott Simpson

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

подробности

  • Замена провода на 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) вокруг этой проблемы в обоих линиях
  • Снимок экрана ниже

enter image description here

enter image description here

enter image description here


Перебои, которые я заметил с тех пор, как начал отслеживать

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. 

Packet loss

enter image description here

enter image description here

Side with better SNR shows less up time

enter image description here Bad length

1
У меня плохие новости для вас. Это только то, что ваш провайдер может определить и исправить. Ramhound 7 лет назад 2
* «Местные специалисты, которые говорят, что все проверили» * - Получите детали. Они «подготовили» линии, то есть провели сканирование (TDR), чтобы найти и удалить мостовые отводы (и нагрузочные катушки)? Читайте http://www.exfo.com/corporate/blog/2010/bridged-tap-detection-made-simple sawdust 7 лет назад 2
Это не ошибка ПК или внутренней сети, совсем нет, это чисто внешнее или DSL оборудование ... есть проблема с линией снаружи, L1 vs L2 бок о бок доказывает это, они должны быть почти идентичны, но У L2 намного более высокое отношение сигнал / шум, вероятно, свидетельствующее об отводе пары где-то в поле. И @sawdust абсолютно верен, простой прогон с TDR SLA в каждой строке должен что-то показывать, если нет, то они должны начинаться с MDF и прослеживать пары от CO до предпосылки одного AP / CP, ped или терминала в время и убедитесь, что линия сращена правильно и чисто. Если бы у меня был $ за каждый раз ... acejavelin 7 лет назад 3
Впечатляющие детали. (Особенно журналы. По крайней мере, это впечатляет стандартами типичных вопросов здесь.) Хорошая работа. TOOGAM 7 лет назад 1
Я пришел к выводу, что основным источником помех является радиолюбитель соседа. И - оказывается, что они не правильно определили падение с NID на пьедестал как старый «стиль C», который не защищает от помех. Scott Simpson 7 лет назад 0

1 ответ на вопрос

1
Dave

Скотт - я соучредитель 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

удачи,

Дейв

Похожие вопросы