1

tl; dr В моей домашней сети недавно произошел скачок с 27 мс до 600 мс. Это происходит не всегда, и, кажется, часто происходит ночью. Какое оборудование я должен купить и провести тесты, чтобы определить причину?

Настроить

Мой дом имеет DSL 12Mb/800kb. Я живу в горах, вдали от других источников Wi-Fi. Исторически (в течение многих лет) я мог пинговать google.com и получать время ~ 27 мс. Если что-то затопит сеть или соединение (iPhone синхронизирует все фотографии с iCloud), пинг перейдет в диапазон 2000-6000 мс. Но обычно все было хорошо.

Однако в последнее время сеть остается привязанной к 600 мс в течение десятков минут за раз. Я не могу найти устройство, которое заполняет сеть. (Может существовать, но я не нашел его.) По утрам связь обычно совершенно нормальная, а по вечерам обычно плохая (именно тогда, когда мы хотим транслировать шоу в постели!)

Во время больших задержек эхо-запросы к другим устройствам в сети (некоторые из которых я пробовал) не изменяются (всегда <2 мс).

Неисправность и сбой с толку

Я приобрел все новое оборудование (модем DSL, маршрутизаторы Wi-Fi, сетевые коммутаторы), чтобы исключить это. Проблема сохраняется. Вот установка:

Домашняя сеть Phrogz

Я попытался использовать модем DSL в качестве маршрутизатора (PPPoE + DHCP + NAT) с базовыми станциями Wi-Fi в режиме моста. Я попытался перевести DSL-модем в режим прозрачного моста и получить первую версию Airport Extreme для обработки PPPoE, DHCP и NAT. Проблема сохраняется.

Я отключил все проводные соединения (оставив только модем DSL и базовую станцию Wi-Fi). Проблема сохраняется.

Я использовал только модем DSL (с PPPoE) и использовал собственный Wi-Fi. Проблема сохраняется. Я пытался выследить все старые планшеты, телефоны, ноутбуки по Wi-Fi и выключить их. Проблема сохраняется. Я переименовал SSID Wi-Fi и ввел в него пароль, подключив один ноутбук MacBook Pro через Wi-Fi. Проблема сохраняется. Я использовал другой ноутбук через Wi-Fi. Проблема сохраняется.

Я подключил ноутбук напрямую к модему через Ethernet, Wi-Fi отключен на модеме и больше ничего не подключено. Проблема уходит! (Я думаю ... возможно, что проблема была не в том, что я трижды проверял это).

В какой-то момент, просто подключив ноутбук через Ethernet, я включил Wi-Fi для модема, и проблема проявилась сама собой. Задержка пинга сразу же подскочила, как только я включил Wi-Fi, хотя я не верю, что какие-либо устройства были подключены через Wi-Fi.

Я использовал iStumbler, и между плохой задержкой и увеличением шума, похоже, нет никакой корреляции. Действительно, SNR выглядит хорошо последовательно по Wi-Fi.

Помните, что когда вещи плохие, они не всегда плохие. Даже если каждое устройство в доме включено и подключено, бывают случаи, когда задержка падает до 30 мс или около того в течение нескольких секунд (или минут, или часов), прежде чем снова произойдет сбой.

Следующие шаги?

Я думаю, что iStumbler показал мне, что проблема не связана с проблемами RF. (Может я не прав?) Поэтому я думаю, что это должен быть реальный трафик в сети.

Базовая станция Airport Extreme не поддерживает регистрацию SNMP. Так же как и Actiontec C1000A. У меня нет коммутатора с портом монитора или концентратора. Я никогда не использовал Wireshark раньше.

НО Я ХОЧУ БРОСИТЬ ДЕНЬГИ И ВРЕМЯ В ЭТОЙ ПРОБЛЕМЕ, чтобы РЕШИТЬ ЭТО

Что я должен купить? Где я должен ввести его в мою сеть? Что я должен искать? Как я могу наблюдать за каждым пакетом в сети и строить гистограммы и графики, чтобы определить, разрушает ли одно плохое устройство ситуацию для всех?


Редактировать 1: DSL Статистика, когда все хорошо

+-----------------+-------------+
|   Connection    |   Status    |
+-----------------+-------------+
| DSL Downstream: | 15.869 Mbps |
| DSL Upstream:   | 0.896 Mbps  |
+-----------------+-------------+

DSL Link Статистика

+------------------------------+---------------------+
|        Link Statistic        |       Status        |
+------------------------------+---------------------+
| Broadband Mode Setting:      | Auto Select         |
| Broadband Mode Detected:     | VDSL2 - 8A          |
| DSL Link Uptime:             | 0 Days, 10H:39M:57S |
| Retrains:                    | 1                   |
| Retrains in Last 24 Hours:   | 1                   |
| Loss of Power Link Failures: | 0                   |
| Loss of Signal Link Failure: | 0                   |
| Loss of Margin Link Failure: | 0                   |
| Link Train Errors:           | 0                   |
| Unavailable Seconds:         | 23                  |
| Estimated Loop Length:       | 2250                |
| Uncanceled Echo:             | N/A                 |
| Transport Mode:              | PTM                 |
| Path Parameter:              | 201                 |
| Priority:                    | 0                   |
| Service Type:                | PTM-Tagged          |
+------------------------------+---------------------+

DSL Power

+--------------+-------------------------+------------------------+
|    Levels    |       Downstream        |        Upstream        |
+--------------+-------------------------+------------------------+
| SNR:         | 16 dB                   | 10 dB                  |
| Attenuation: | (DS1)21.7, (DS2)58.8 dB | (US1)4.3, (US2)47.8 dB |
| Power:       | 16.4 dBm                | 7.8 dBm                |
+--------------+-------------------------+------------------------+

DSL Transport

+----------------------+------------------+---------------+
|      Transport       |    Downstream    |   Upstream    |
+----------------------+------------------+---------------+
| Packets:             | 1482864          | 1088249       |
| Error Packets:       | 0                | 0             |
| 24 Hour Usage:       | 1225940.68 Mbits | 2420.93 Mbits |
| Total Usage:         | 1225940.68 Mbits | 2420.93 Mbits |
| 30 Minute Discarded: | 0                | 3930          |
+----------------------+------------------+---------------+

DSL Channel

+----------------+-------------+-------------+
|    Channel     |  Near End   |   Far End   |
+----------------+-------------+-------------+
| Channel Type:  | Interleaved | Interleaved |
| CRC Errors:    | 0           | 0           |
| 30 Minute CRC: | 0           | 0           |
| RS FEC:        | 5873        | 29          |
| 30 Minute FEC: | 372         | 0           |
+----------------+-------------+-------------+

Изменить 2: отчет DSLReports Bufferbloat

Запуск speedtest во время нормального времени ожидания указывает, что проблема возникает во время загрузки

График, показывающий плохую буферную загрузку во время загрузки


Пинг раз ночью и ночью

Пик около 22:35 был одним компьютером, начинающим загружать в Dropbox.


Изменить 3: Техническая поддержка провайдера сказал:

Модем получает больше сигналов, чем положено. Если кабелей недостаточно для переноса нагрузки, которую мы отправляем, мы можем снизить ее до 100%. Чтобы проверить это, я должен понизить сигнал в течение 7 дней, и вы можете наблюдать, лучше ли просматриваете \ интернет. Через 7 дней наш сервер запустит тест и снова усилит ваши сигналы. И к тому времени у нас будет достаточно цифр, что делать дальше.

Наш сервер предоставляет вам больше, чем ваша покупка. Технически это должно сделать интернет быстрее, но если клиент наблюдает пинг и задержку, вызванные трафиком. Мы можем довести его до купленной скорости \ сигнала и наблюдать, являются ли линии DSL в помещении клиента кабелем для переноса нагрузки.

Фактические / Предусмотренные / Приобретенные скорости
Вниз: 15868/15872/12128 Мбит / с
Up: 896/896 / 896kbps

2 ответа2

2

Что-то не так. 24-часовая статистика говорит:

На 312 600 МБ меньше 247 500 МБ вверх

Вы не включили скорость ссылок, но 8А на 2 км дает вам ссылку 15/5. На 5Mb США вы можете загрузить только около 55 ГБ /24 часа. Даже при 10 МБ вы не достигнете 250 ГБ, поэтому не доверяйте этой статистике.

Тем не менее, это звучит так, как будто одноранговая / синхронизирующая / вредоносная программа в вашей сети самодостаточна.

ОБНОВИТЬ:

Ваше соединение сбалансировано, как ADSL-соединение более старого стиля (8D 0,5U, 12D 0,7U, 15D 1U) по сравнению с тем, что вы обычно делаете с VDSL (2) (15D, 3U). Это оставляет вас в ситуации, когда очень легко получить собственную ссылку.

Все, что работает в вашей сети, может вызвать очередь восходящего потока, где модем содержит серию кадров, которые пытаются отправить, но идут быстрее, чем он может их переслать. Так, например, вместо 1 мс от вашего ноутбука до модема, 20 мс от модема до обмена, 5 мс от обмена до веб-сайта у вас есть: 1 мс от вас до модема, 100 мс в буфере кадров, 20 мс для обмена и 5 мс до сайта. Чем больше будет отправлено, тем больше время ожидания.

Что нужно искать: Peer to Peer (бит-торрент, игровые пусковые установки) Синхронизация приложений: Windows 7/8/10 One Drive, Dropbox (esp Camera Sync), резервное копирование вне сайта iCloud, например Crashplan/Backblaze и т.д. Приложения VOIP/ видеозвонков: Skype, TS/ Mumble

Все, что отправляет данные в Интернет.

1

Симптомы, о которых вы сообщили, звучат как проблема с буферной загрузкой, когда ваш маршрутизатор, модем DSL или DSLAM вашего интернет-провайдера буферизует слишком много пакетов, когда канал перегружен, что приводит к высокой задержке. Как правило, TCP ищет пропущенные кадры как свидетельство перегрузки и отступает. Но если ваш маршрутизатор, модем или DSLAM буферизуют вечно и никогда не позволяют сбросить кадр, вы в конечном итоге значительно увеличите время ожидания, и у TCP не будет возможности вернуться назад для устранения перегрузки. Вы никогда не должны сильно увеличивать время ожидания только потому, что ваша пропускная способность в восходящем или нисходящем направлении насыщена. Если вы это сделаете, у вас почти наверняка есть буферная шлюза.

Запустите инструмент тестирования скорости dslreports.com. В отличие от других инструментов тестирования скорости, этот инструмент также измеряет и сообщает о проблемах с буферной загрузкой, которые могут вызвать высокую задержку всякий раз, когда что-то использует всю вашу полосу пропускания в нисходящем или восходящем направлении (например, когда вы решаете передавать потоковое видео ночью).

Тот факт, что вы уже доказали, что ваши задержки увеличиваются, когда что-то использует всю пропускную способность вашей загрузки (ваш пример синхронизации iCloud Photo), является хорошим признаком того, что вы страдаете от проблем с буферной загрузкой.

Ваш модем DSL, вероятно, является источником любых проблем с восходящей буферизацией. Одним из решений может быть покупка модема DSL, о котором известно, что у него нет проблем с буферной загрузкой. Я не исследовал этот рынок, поэтому не могу помочь вам с любыми предложениями. Ваш Google-фу, вероятно, так же хорошо, как мой.

В качестве альтернативы рассмотрите возможность покупки домашнего шлюза, который может работать с CeroWrt, OpenWrt или DD-WRT, и все они теперь имеют технологии защиты от буфера, такие как FQ_CoDel, которые впервые были разработаны / разработаны в CeroWrt. Используя такой флажок, чтобы искусственно ограничить пропускную способность восходящего и нисходящего каналов до чего-то немного более медленного, чем то, на что фактически способна ваша DSL-ссылка, и наличие этого флажка фактически отбрасывает кадры и отправляет уведомления о явных перегрузках (ECN) при достижении этого предела, вместо этого Постоянная буферизация позволяет TCP обнаруживать перегрузку и откатываться так, как должен делать TCP.

Вам не обязательно отказываться от модема DSL или AirPort Extreme, чтобы установить этот * Wrt box; Вы можете установить его как проводную коробку между вашим DSL модемом и вашим первым AirPort Extreme. Просто убедитесь, что весь трафик в / из вашей домашней сети проходит через это поле. То есть убедитесь, что у вас нет подключенных к DSL-модему устройств, кроме этого * Wrt box.

Если вы знаете, что у вас есть буферное хранилище, вам, вероятно, следует устранить его, прежде чем искать другие потенциальные источники всплесков задержки, иначе это будет препятствовать вашим попыткам найти другие источники задержки.

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