У меня был интересный опыт работы в сети раньше. До того, как я переехал, у меня было соединение VDSL с восходящей линией связи 3 Мб. (Скорость вниз была около 30 Мб, но в данный момент это не актуально). Всякий раз, когда я насыщал восходящую линию связи (резервное копирование CrashPlan), я мог видеть замедление общей задержки и скорости отклика, но я все еще мог использовать Интернет без каких-либо серьезных проблем.
Теперь я переехал в другое место, где я получаю только нормальный ADSL +. Скорость составляет 10 МБ нисходящей линии связи с 1 МБ восходящей линии связи. Проблема, однако, в том, что всякий раз, когда я насыщаю восходящую линию связи, почти все останавливается - время пинга возрастает до десятков секунд, и общее впечатление довольно плохое. Даже если я использую только 50% скорости загрузки, задержка возрастает до 500-800 мс.
Сначала я связывал эту проблему с ухудшением качества соединения - однако теперь я думаю, что это проблема конфигурации / сети со стороны моего провайдера и не имеет никакого отношения к качеству меди, идущей мне на пути. Что еще больше подтвердило это убеждение, так это то, что у моего друга есть связь с похожими параметрами (другая область, но схожее расстояние до обмена), и он может с радостью насытить загрузку, не ставя под угрозу общую связь!
Итак, в чем может быть проблема? Это знаменитая проблема с Bufferbloat ? Если так, есть ли способ смягчить это? Техническая поддержка просто говорит мне, чтобы я не использовал загрузку слишком часто для обеспечения возможности подключения ... что является слабым в моей книге.
Я также изучал некоторые из томатных прошивок роутера, какой-нибудь совет по этому поводу ? Я перепробовал все возможные настройки QoS, чтобы предоставить программному обеспечению для резервного копирования более низкий приоритет, но это только частично решает проблему.
Итак, подведем итог - вы думаете, что это буферная шлюза, и если да, то как это исправить? (кроме смены провайдеров)
Это, вероятно, буферная шлюза. Помидор не имеет исправлений для этого.
Попробуйте openwrt, dd-wrt или систему qos cerowrt, все они теперь используют fq_codel.
Я отмечаю, что некоторые формы DSL используют инкапсуляцию ATM, точная компенсация которой была нарушена до самого недавнего времени (исправлено в linux 3.10.12 или более поздней версии, текущая головка барьерного выключателя openwrt, головка cerowrt)
Способ устранения «переполнения буфера» состоит в том, чтобы полностью отключить буфер вашего провайдера, ограничив входящую и исходящую пропускную способность только их соответствующими ограничениями. Таким образом, буфер на стороне вашего интернет-провайдера никогда не будет использован, и вы почувствуете улучшение задержки при небольшой стоимости пропускной способности.
tcэто инструмент Linux / DD-WRT / Tomato для этого. Существует сценарий под названием «Wondershaper», который реализует это на ПК, возможно, вы могли бы адаптировать его для Tomato.
There's no reason using 50% upload and 0% download should cause significant ping increases. Something else is going on here. I don't know if that's what bufferbloat is. I suspect it's just a physical issue with your modem or line. Badly congested connections should still be able to maintain pings under 1 second. I would troubleshoot with the ISP and/or check out modem stats if your modem supports it (your ISP can check if your modem doesn't). I'm guessing the the signal to noise ratio is below 6 on the upload or the attenuation is too high (greater than 55db)
Lack of bandwidth management doesn't help either (but should never cause things to be as bad as you describe) You should implement a QoS Solution; the only thing that works properly for aDSL connections is one with the TC-ATM patch. I would recommend Tomato Toastman or Shibby, recent versions. My "mini-guide" to configure this is here: http://www.dslreports.com/forum/r28371690-Cable-Help-Configuring-Tomato-QoS- . The only difference with your setup is you put the "settings for DSL modems only" to something like 32-bytes instead of "none".
Bufferbloat test: http://netalyzr.icsi.berkeley.edu/