Я новичок в использовании tc / htb, и я только что скопировал / вставил скрипт в ...
http://lartc.org/howto/lartc.cookbook.ultimate-tc.html
... для работы на шлюзе офиса. Причина в том, чтобы предотвратить слишком медленные соединения SSH и просмотр веб-страниц при больших загрузках, выгрузках, p2p и видео. Сеть выглядит так:
LAN -> (eth0) шлюз linux (eth1) -> модем DSL
Шлюз также выполняет NAT для клиентов LAN.
В верхней части скрипта вы устанавливаете скорость восходящего и нисходящего каналов (в килобитах) и устройство. Наш ADSL составляет 1,5 м DL / 256k UL. Итак, я установил следующие значения:
DOWNLINK=1000
UPLINK=220
DEV=eth1
Все, что я знаю наверняка, это то, что эти значения должны быть «несколько» меньше, чем полная пропускная способность DSL, но я не знаю, как рассчитать оптимальное значение. Я предполагаю, что если значение слишком низкое, я буду чрезмерно ограничивать общую пропускную способность, а если она слишком высока, я собираюсь предотвратить правильную организацию очереди.
У меня вопрос: какие инструменты, практические правила или вычисления я использую для поиска оптимальных значений параметра скорости?
На прошлой неделе я реализовал tc, используя тот же скрипт в качестве основы.
(некоторые из этих советов относятся к этому сценарию)
Во-первых, он говорит, что он установлен на 90 для его повышения скорости линии до 128. У меня повышение скорости составляет 320, что в 2,5 раза больше, поэтому я начал с 90 * 2,5 = 225. Я закончил с 240 или 260, я думаю , но работает неплохо.
Одна вещь, которую я не учел, может быть проблемой и для вас, так это то, что ограничения скрипта основаны на $ DEV, но у моей машины был только один интерфейс, поэтому он также ограничивал сетевой трафик. Чтобы исправить это, я остановил пул 26 (самый медленный) как универсальный класс по умолчанию (удалите слово «default») и поставил последнее правило, что все исходящие сообщения, которые не относятся к месту назначения моей локальной подсети, должны быть классом 26.
В моем случае я также удалил все строки кода, ограничивающие скорость нисходящего потока, потому что единственный большой нисходящий поток, который я делаю, - это торренты, и он так или иначе ограничен в клиентском приложении. Это делает весь сценарий более понятным, и в моем случае все еще отлично работает. Кроме того, на самой веб-странице говорится, что вы можете реально ограничить скорость загрузки с какой-либо реальной уверенностью.
В моем случае загрузка 75% моей пропускной способности снизила бы мою скорость загрузки до доли от ее полной скорости, и такие вещи, как удаленный ssh in, были бы непригодны для использования. Теперь все исправлено, и я очень доволен этим.
Надеюсь, это поможет.
edit: О, и я также удалил строку mtu 1000, потому что интерфейс в моем случае также несет гигабитный сетевой трафик.