Назад | Перейти на главную страницу

как настроить параметр скорости tc для оптимальной производительности с htb / sfq?

Я новичок в использовании 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, потому что интерфейс в моем случае также несет гигабитный сетевой трафик.