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) вокруг этой проблемы в обоих линиях
Снимок экрана ниже
Перебои, которые я заметил с тех пор, как начал отслеживать
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.
У меня плохие новости для вас. Это только то, что ваш провайдер может определить и исправить.
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, и вы можете видеть, что проблема потерь почти полностью исчезла.