Как предотвратить дополнительную задержку, вызванную загрузкой

472
Matin Lotfaliee

Я использую tcping, который пингует порт TCP, чтобы проверить соединение моего компьютера с определенным портом. Среднее время ответа определенного адреса и порта составляет 50 мс при обычном соединении. Теперь я начинаю загрузку с другого адреса, используя IDM, который разделяет файл и загружает файлы одновременно. Время отклика моего пинга увеличивается примерно до 1500 мс . Я уверен, что моя загрузка увеличила это время ответа, потому что, когда я приостанавливаю свою загрузку, время ответа возвращается к 50 мс .

Image of the problem

Я хочу предотвратить это увеличение времени ответа на зарегистрированные адреса и порты.

Я не хочу использовать NetLimitter или NetBalancer .

Я также попробовал это . Я проверил Wireshark, и я уверен, что DSCP установлен, но моя проблема не решена.

1
Какой интернет-пакет у вас есть от вашего провайдера? Что за роутер? Как компьютер подключен к Интернету? Julysfire 6 лет назад 0
Можете ли вы уменьшить количество одновременных подключений (одновременных загрузок / потоков) или как там это называется в IDM до количества ваших процессоров. Такой, что есть бесплатный процессор для tcping. Это помогает? HelpingHand 6 лет назад 0
Вы не хотите использовать именно те инструменты, которые не дадут вам насыщать ваше соединение и, следовательно, действительно излечат вашу проблему? Ну, единственные альтернативы - это избавиться от IDM или вообще прекратить загрузку. Если вы не скажете нам * почему * вы не хотите их использовать, будет немного бесполезно их исключать. Mokubai 6 лет назад 2
@Julysfire Мой маршрутизатор - Linksys X3500, компьютер подключен к маршрутизатору с помощью Wi-Fi, а маршрутизатор подключен к Интернет-провайдеру с помощью телефонной линии и ADSL2 +. Matin Lotfaliee 6 лет назад 0
@ Бисва Я хочу иметь возможность выбирать между портами. Некоторые порты медленнее, а некоторые быстрее. Matin Lotfaliee 6 лет назад 0
@ EMK нет, это ничего не меняет. Matin Lotfaliee 6 лет назад 0
@Mokubai Я хочу использовать это решение в своем собственном приложении, которое много использует интернет-трафик, и ему также нужно иметь хорошую поддержку с другим сервером. Matin Lotfaliee 6 лет назад 0
@ Бисва ОК. Но результаты одинаковы. Проблема все еще существует. Matin Lotfaliee 6 лет назад 0
@Biswa Проблема ОП не имеет ничего общего с тем, какие порты используются. Он испытывает спор о пропускной способности. Поскольку сетевой канал приближается к насыщению, * все * соединения (независимо от порта) страдают от повышенной задержки, если только не установлен какой-либо механизм для определения приоритетов одних соединений над другими (например, QoS). Twisty Impersonator 6 лет назад 0
@ Твисти, у меня для тебя хорошие новости: оказывается, это миф. Google "bufferbloat". С более интеллектуальными алгоритмами организации очередей, такими как CoDel, вы можете насыщать пропускную способность без задержки или QoS. Spiff 6 лет назад 0

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

-1
Andriy Berestovskyy

Каждое подключение к Интернету имеет два направления: от пользователя к Интернету и обратно. Каждое направление не зависит от термов QoS и направляет прохождение пакета.

Установка приоритета для пакетов OUTGOING не меняет приоритет пакетов INCOMING. Приоритет и QoS входящих пакетов все еще находятся под контролем вашего интернет-провайдера.

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

К сожалению, это не решение, но я надеюсь, что оно поможет вам понять проблему.

Итак, вы предлагаете мне зарезервировать пропускную способность самостоятельно. Правильно? Matin Lotfaliee 6 лет назад 0
@MatinLotfaliee, это единственный вариант, если 1) у вас нет контроля над QoS на стороне провайдера и 2) узким местом является входящий трафик (от вашего провайдера к вам). Конфигурации QoS помогут только тогда, когда узким местом является исходящий трафик (от вас к провайдеру). Andriy Berestovskyy 6 лет назад 0
-1
Spiff

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

Исправление для bufferbloat заключается в обновлении алгоритма организации очереди (так называемая дисциплина очереди, сетевой планировщик) устройства с ошибками до интеллектуального алгоритма организации очереди с учетом задержки, такого как FQ-CoDel.

Если вы не можете исправить фактическую коробку с проблемой, вы можете обойти ее, установив коробку с FQ-CoDel в начале вашей сети и настроив формирование трафика, чтобы сделать его небольшим узким местом как в восходящем, так и в нисходящем направлении. направления. Таким образом, FQ-CoDel начинает работать и позволяет управлению перегрузкой TCP работать до того, как очереди с раздутыми буферами могут нарастить на багги.

Вы можете сделать это самостоятельно с помощью дистрибутивов прошивки маршрутизатора с открытым исходным кодом, таких как LEDE (ранее OpenWrt), но если вы хотите получить решение «под ключ», посмотрите IQrouter с сайта evenroute.com. По-видимому, он автоматически настраивает пропускную способность в течение дня, максимизируя пропускную способность и минимизируя задержку.

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

*Очень интересно. Я наблюдал это поведение с преобладанием, которое приближается к вездесущему. Любое объяснение, почему так много устройств влияет на это? У поставщиков сетевого оборудования нет стимула, чтобы это исправить? Есть ли в их глазах "причина" для такого поведения? Что-то другое? Twisty Impersonator 6 лет назад 0
Оперативная память @Twisty стала дешевой, поэтому инженеры добавили больше места в буфере кадров, чтобы исключить необходимость удаления кадров. Проблема в том, что TCP Congestion Control использует отбрасывание кадров для обнаружения перегрузки. Поэтому они случайно скрыли перегрузку от TCP, не осознавая этого. Теперь вопрос повышения осведомленности, чтобы заставить производителей промежуточных коробок принять CoDel. Алгоритм управления перегрузкой «BBR» от Google рассматривает увеличение задержки буфера (а не просто отбрасывание пакетов) как признак перегрузки, как попытку сделать конечные точки более умными, чтобы обойти эту ошибку промежуточной коробки. Spiff 6 лет назад 0
@Spiff Я не уверен, что вы правильно поняли CoDel ... Пожалуйста, взгляните на Википедию: https://en.wikipedia.org/wiki/CoDel Есть две вещи: 1) с CoDel вы исправляете очереди под вашим контролем а не ISP и 2) узкое место возникает, когда пакеты из быстрой сети перемещаются в медленную сеть, т.е. из сети ISP (быстрая) в клиентскую линию (медленную). Так что CoDel по широкополосному модему не поможет, к сожалению ... Andriy Berestovskyy 6 лет назад 0
@AndriyBerestovskyy Исследователи буферной булавы изначально разработали CoDel для потребительского оборудования, потому что это было легко и под их контролем, но они никогда не собирались останавливаться на достигнутом. Цель состоит в том, чтобы заставить всех производителей промежуточных ящиков и интернет-провайдеров везде использовать интеллектуальные очереди, такие как CoDel или PIE, включая CMTS, DSLAM, формирователи трафика и т. Д. Исследование CoDel Майка «Дейва» Тата спонсируется Comcast, гигантским кабельным интернет-провайдером в США. Требуется некоторое время, чтобы исправить все промежуточные блоки в Интернете, но процесс начался. Spiff 6 лет назад 0
@AndriyBerestovskyy Кроме того, упомянутый мною обходной путь (создание искусственного узкого места в вашей сети и запуск CoDel на нем, чтобы ECN или сбрасывание происходило до того, как на других блоках могут скопиться скопления) действительно работает в обоих направлениях. Многие люди успешно применили этот трюк. Evenroute.com даже создал коммерческий продукт вокруг этого трюка (IQrouter). Spiff 6 лет назад 0
@ В принципе искусственное узкое место - ограничение скорости вашего трафика с низким приоритетом. Так что здесь нет никакой магии ... Самый простой способ сделать это - ограничить полосу пропускания в загружаемой программе. Смотрите вкладку «Ограничитель скорости» в исходном вопросе. Andriy Berestovskyy 6 лет назад 0
@AndriyBerestovskyy Нет, исправление bufferbloat снижает задержку даже без QoS для определения приоритетов одного потока над другим. Или даже если ваш приоритетный поток был тем, который вызвал раздувание. В этом вся прелесть. Независимо от того, какой поток насыщает канал, исправление буферного потока делает их все с низкой задержкой. Spiff 6 лет назад 0
@Spiff ранее вы написали "создание искусственного узкого места в вашей сети и запуск CoDel на нем". Это «искусственное узкое место» называется «предел скорости / пропускной способности». Ты согласен? Andriy Berestovskyy 6 лет назад 0