Ещё раз про ограничение скорости

>до перезагрузки или как?

до перезагрузки

>И будет ли при этом пинг быстрее, чем без ограничений?

... ну быстрее он имхо не станет, но и медленее тоже: это cbq шэйпит искуственными задержками, вроде...

> 60Mbit

у тебя 60 мегабит? офигеть...

> latency 50ms

вот это дело как раз надо тьюнить

>burst 7000

не столь актуально

ЗЫ я слабо в tc шарю :)

Читай: http://gazette.linux.ru.net/rus/articles/taleLinuxTC.html

>... ну быстрее он имхо не станет, но и медленее тоже: это cbq шэйпит искуственными задержками, вроде...

Ну а мне надо, чтобы во время закачки или скачки можно было браузить без задержек в несколько секунд. Поэтому хочу скорость ограничить процентов на 5-10 ниже максимума. Поэтому пинг должен быть не дольше 100 мс (без закачек/скачек или когда закачка/скачка не занимает весь канал пинг именно такой, во время закачки/скачки он несколько секунд).

>у тебя 60 мегабит? офигеть...

Это цитата, у меня почти мегабит.

вроде как sfq очередь делит так чтобы всем досталось. tc qdisc add dev eth0 root sfq

>Поэтому хочу скорость ограничить процентов на 5-10 ниже максимума.

>Поэтому пинг должен быть не дольше 100 мс

не вижу связи...

ну так сделай по доке иерархию классов: вэбу большой приоритет, остальному - всё, что останенся.

Token Bucket Filter

Token Bucket Filter (TBF) простая дисциплина очереди, которая передает поступающие пакеты со скоростью не превышающей административно заданный порог, но с возможностью превышающих его коротких всплесков.

TBF очень точная дисциплина, при этом она не создает серьезных нагрузок на сеть и процессор. Если вам нужно просто ограничить скорость на интерфейсе, то это первый кандидат на использование.

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

Каждый прибывающий токен сопоставляеться с одним пакетом данных из очереди после чего удаляется. Связав этот алгоритм с двумя потоками -- токенов и данных, получим три возможных ситуации:

Данные прибывают со скоростью равной скорости входящих токенов. В этом случае каждый пакет имеет соответствующий токен и проходит очередь без задержки.

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

Данные прибывают быстрее, чем токены. Это означает, что в буфере скоро не останеться токенов, что заставит дисциплину приостановить передачу данных. Эта ситуация называется "превышением". Если пакеты продолжают поступать, они начинают уничтожаться.

Последняя ситуация очень важна, поскольку позволяет административно ограничивать доступную полосу пропускания.

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

Учтите, что в реальной реализации дисциплины, токены соответствуют байтам, а не пакетам.

Stochastic Fairness Queueing.

Stochastic Fairness Queueing (SFQ) -- простая реализация семейства алгоритмов справедливой очередизации. Она не так точна, как другие дисциплины, но требует меньше рассчетов, и при этом поровну распределяет доступную полосу пропускания между сеансами.

Ключевым понятием в SFQ является диалог (или поток), который приблизительно соответствует сеансу TCP или потоку UDP. Трафик делится на достаточное количество очередей типа FIFO, по одной на каждый диалог. После этого, все очереди обрабатываются в циклическом порядке, тем самым обеспечивая каждому сеансу равные шансы на передачу данных.

Благодаря этому достигается очень ровное поведение, которое не позволяет какому-либо диалогу подавлять остальные. SFQ называется "стохастической", т.к. на самом деле для каждого сеанса очередь не формируется, а трафик делится на ограниченое количество очередей на основе хеш-алгоритма.

Из-за использования хеша, несколько сессий могут попасть в одну и ту же очередь, что уменьшает шансы на передачу каждого сеанса. Для того, чтобы эта проблема не ощущалась, SFQ часто меняет алгоритм хеширования, поэтому, если сессии и попадут в одну очередь, длиться это будет лишь несколько секунд.

Стоит заметить, что SFQ эффективен только если исходящий интерфейс полностью загружен! В противном случае очередь будет отсутствовать и, следовательно, никакого положительного эффекта наблюдаться не будет. Позже мы рассмотрим варианты комбинирования SFQ с другими дисциплинами для достижения наилучшего результата.

В частности, применение SFQ на ethernet интерфейсе к которому подключен кабельный модем или DSL маршрутизатор совершенно бессмыслено без органичения полосы пропускания!

Какие типы дисциплин нужно использовать.

Обобщая вышесказанное: мы рассмотрели простые дисциплины очередей, которые управляют трафиком переупорядочиванием, задержкой или уничтожением пакетов.

Следующие советы могут помочь при выборе типа применяемой дисциплины. Здесь также упоминаются некоторые дисциплины, описываемые в главе 14.

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

Если ваш канал полностью загружен и при этом вы не желаете допустить доминирование какого-либо сеанса, используйте SFQ.

Если вы хотите управлять скоротью магистральных каналов и хорошо понимаете как это делается, используйте Random Early Drop (описывается в главе 14).

Для управления скоростью входящего трафика, который не пересылается, используйте ограничитель (Ingress Policer).

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

Если вам не нужно ограничивать полосу пропускания, но вы хотите видеть, справляется ли ваш интерфейс с нагрузкой, используйте очередь pfifo (не pfifo_fast). У нее нет внутренних полос, но она ведет учет использования очереди.

Наконец, вы можете использовать "человеческий" фактор. Использование технологических решений не всегда приводит к желаемым результатам. Пользователи враждебно относятся к техническим ограничениям. Доброе слово тоже может помочь в правильном распределении пропускной способности!

и нафига флудить?

>ну так сделай по доке иерархию классов: вэбу большой приоритет, остальному - всё, что останенся.

А чем веб отличается от скачки по HTTP?

Пробовал sudo tc qdisc add dev eth0 root sfq - не влияет, пинги как были около тысячи, так и есть, и при скачке, и при закачке. sudo tc qdisc replace dev eth0 root tbf rate 400Kbit latency 50ms burst 7000 помогает при закачке (пинг держится около сотни), а что делать при скачке?

>А чем веб отличается от скачки по HTTP

хех... вот оно оказывается как... я должен угадывать, чем ты качаешь...

можно через иптейблз метить нужные пакеты от нужных команд