![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
petropavelМеня довольно долго удивляла такая вещь, что на одной и той же машинке (домашняя машинка у меня в dual-boot, так что действительно на одной и той же) совершенно по-разному ведёт себя Firefox (имеется в виду - Firefox в Windows и Firefox в Linux).
В Windows - работает совершенно замечательно (правда, Google Chrome летает намного быстрее, но и Firefox не вызывает раздражения скоростью реакции).
В Linux (Ubuntu, 8.04 и 8.10) - не знаю, даже, как сказать... В общем, "тупит".
Я долго не мог для себя сформулировать, что именно я подразумеваю под словом "тупит", возможно, это даже несколько не связанных между собой аспектов сложились в моём восприятии. Но вот одну из частностей я прочувствовал, когда запустил на загрузку несколько подкастов, и попытался, пока они качаются, параллельно "побродить" по интернету.
Получилось то, что называется congestion, причём в полный рост. Закачка так прочно "забивала" канал, что открытие странички на LiveJournal можно было ждать и по 20, и по 30 минут, и не дождаться в итоге.
Причём, что особенно противно, под Windows компьютер использует ровно тот же ADSL-канал.
Попытался понять, могу ли я что-либо предпринять на этот счёт. Вспомнил, что мне знакомы слова traffic shaping, QoS, CBQ, Linux Advanced Routing Guide, но не более, чем просто знакомы, и попытка почитать об этом немножко в субботу вечером особых знаний мне отнюдь не прибавит. Почитав, получил некое смутное представление о сути проблемы, и решил поискать, возможно, готовые решения.
В репозитории Убунты обнаружил скрипт WonderShaper, который конфигурирует сетевую подсистему немного более хитрым способом, чем она сконфигурирована по умолчанию, в результате чего Линукс чуть-чуть "придерживает" скорость сетевого соединения для обычных видов трафика, используя сэкономленный "чуть-чуть" для того, чтобы пропихивать "вне очереди" трафик интерактивный.
Запускается это чудо примерно так: sudo /usr/sbin/wondershaper eth0 скорость_входящая скорость_исходящая
где скорость_входящая и скорость_исходящая - скорость в килобитах в секунду, цифрами.
вспомнив, что входящая скорость линка у меня 128 кбит/с, а исходящая - не знаю, сколько, но в кратное двойке число раз меньше :-), попробовал урезать входящую скорость до 110.
Результат оказался более чем удовлетворительный. Действительно, стало возможно "бродить" по интернету, при активных "длинных" загрузках. Ну, и субъективное ощущения "торможения" Firefox-а, если и не исчезло совсем, то перестало так раздражать. Как-то стало оно всё "отзывчивей", что ли.
Посоветовался с оказавшимся в аське в столь неурочное время знакомым программистом. Он подтвердил мои мысли, что курить надо вещи, подобные Linux Advanced Routing & Traffic Control HOWTO, но без хорошей теоретической подготовки результат такого курения неочевиден, и что в Windows некое своё понимание QoS, которое не торчит наружу из-под капота всеми рычагами, но в каких-то средневероятных случаях использования оно просто работает :-)
Так что, когда вы встретите в очередной пропагандистской статье про достоинства линукса, что он позволяет вам выжать 100% из вашего сетевого соединения (в отличие от, где для работы QoS резервируется, якобы, 30% от доступной полосы), то это не враки - действительно, "позволяет". Но это отнюдь не значит, что всё будет гладко работать "из коробки", а придётся нехило почитать, чтобы таки суметь эти 100% использовать :-)
Надо будет ещё попробовать, как ведёт себя система без traffic shaper-а, но, например, закачки делать чем-нибудь вроде kget-а, который умеет самостоятельно ограничивать скорость закачки.
UPD. http://support.microsoft.com/kb/316666 - по-русски, статья для чайников - что это вообще такое (QoS в Windows)
http://blogs.msdn.com/wndp/archive/category/10409.aspx - ряд обсуждений относительно Traffic Control, Windows Core Networking
В Windows - работает совершенно замечательно (правда, Google Chrome летает намного быстрее, но и Firefox не вызывает раздражения скоростью реакции).
В Linux (Ubuntu, 8.04 и 8.10) - не знаю, даже, как сказать... В общем, "тупит".
Я долго не мог для себя сформулировать, что именно я подразумеваю под словом "тупит", возможно, это даже несколько не связанных между собой аспектов сложились в моём восприятии. Но вот одну из частностей я прочувствовал, когда запустил на загрузку несколько подкастов, и попытался, пока они качаются, параллельно "побродить" по интернету.
Получилось то, что называется congestion, причём в полный рост. Закачка так прочно "забивала" канал, что открытие странички на LiveJournal можно было ждать и по 20, и по 30 минут, и не дождаться в итоге.
Причём, что особенно противно, под Windows компьютер использует ровно тот же ADSL-канал.
Попытался понять, могу ли я что-либо предпринять на этот счёт. Вспомнил, что мне знакомы слова traffic shaping, QoS, CBQ, Linux Advanced Routing Guide, но не более, чем просто знакомы, и попытка почитать об этом немножко в субботу вечером особых знаний мне отнюдь не прибавит. Почитав, получил некое смутное представление о сути проблемы, и решил поискать, возможно, готовые решения.
В репозитории Убунты обнаружил скрипт WonderShaper, который конфигурирует сетевую подсистему немного более хитрым способом, чем она сконфигурирована по умолчанию, в результате чего Линукс чуть-чуть "придерживает" скорость сетевого соединения для обычных видов трафика, используя сэкономленный "чуть-чуть" для того, чтобы пропихивать "вне очереди" трафик интерактивный.
Запускается это чудо примерно так: sudo /usr/sbin/wondershaper eth0 скорость_входящая скорость_исходящая
где скорость_входящая и скорость_исходящая - скорость в килобитах в секунду, цифрами.
вспомнив, что входящая скорость линка у меня 128 кбит/с, а исходящая - не знаю, сколько, но в кратное двойке число раз меньше :-), попробовал урезать входящую скорость до 110.
Результат оказался более чем удовлетворительный. Действительно, стало возможно "бродить" по интернету, при активных "длинных" загрузках. Ну, и субъективное ощущения "торможения" Firefox-а, если и не исчезло совсем, то перестало так раздражать. Как-то стало оно всё "отзывчивей", что ли.
Посоветовался с оказавшимся в аське в столь неурочное время знакомым программистом. Он подтвердил мои мысли, что курить надо вещи, подобные Linux Advanced Routing & Traffic Control HOWTO, но без хорошей теоретической подготовки результат такого курения неочевиден, и что в Windows некое своё понимание QoS, которое не торчит наружу из-под капота всеми рычагами, но в каких-то средневероятных случаях использования оно просто работает :-)
Так что, когда вы встретите в очередной пропагандистской статье про достоинства линукса, что он позволяет вам выжать 100% из вашего сетевого соединения (в отличие от, где для работы QoS резервируется, якобы, 30% от доступной полосы), то это не враки - действительно, "позволяет". Но это отнюдь не значит, что всё будет гладко работать "из коробки", а придётся нехило почитать, чтобы таки суметь эти 100% использовать :-)
Надо будет ещё попробовать, как ведёт себя система без traffic shaper-а, но, например, закачки делать чем-нибудь вроде kget-а, который умеет самостоятельно ограничивать скорость закачки.
UPD. http://support.microsoft.com/kb/316666 - по-русски, статья для чайников - что это вообще такое (QoS в Windows)
http://blogs.msdn.com/wndp/archive/category/10409.aspx - ряд обсуждений относительно Traffic Control, Windows Core Networking
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2008-11-17 06:43 am (UTC)no subject
Date: 2008-11-17 07:22 am (UTC)А упомянутый выще скрипт всего-навсего делает вместо одной очереди, имеющейся в системе изначально, четыре разных очереди. Грубо говоря, основная очередь, очередь тех, которые в первую очередь, очередь тех, которые без очереди :-) (Как в поликлинике).
соответственно, как-то распределяет сетевые пакеты между этими очередями, по своим понятиям.
И, что самое удивительное, эта поликлиника приносит вполне осязаемый эффект в конечном итоге! :-)
no subject
Date: 2008-11-17 07:28 am (UTC)no subject
Date: 2008-11-17 07:56 am (UTC)no subject
Date: 2009-01-23 12:54 pm (UTC)"Плохо" касается доступа к нижегородским сайтам (входящим в кольцо IX-NN).
данный шейпер настраивает недра ( :-) ) линукса вне зависимости от диапазонов IP-адресов, куда мы хотим пойти, в результате нижегородское кольцо тоже оказывается "зарезанным" по скорости, на общих основаниях. А нижегородское кольцо у нас имеет гораздо большую скорость, чем внешка. Для обычной веб-странички это не очень заметно, а вот "качание" файлов страдает сразу.