photon

По аналогии. Сделать несколько деревьев хэш-фильтров в соответствии с тем, как классы были поделены между деревьями HTB.

Не совсем понял, решает ли проблему с локами вариант с несколькими независимыми htb-деревьями поверх mq, который предложил Eric Dumazet? for ETH in eth0 do tc qdisc del dev $ETH root 2>/dev/null tc qdisc add dev $ETH root handle 100: mq for i in `seq 1 4` do tc qdisc add dev $ETH parent 100:$i handle $i htb default 1 done done

Это у меня в sc по умолчанию quantum 1500 стоит. На гигабитных каналах увеличивать не приходилось.

Это да, еще не мешало бы call graph для самого прожорливого _raw_spin_lock сделать, как показано здесь: http://www.brendangregg.com/perf.html

Лучше спросить у разработчиков в рассылке linux-netdev: http://vger.kernel.org/vger-lists.html

Не совсем понял вопрос. Можно указывать путь к конфигурационному файлу в командной строке: sc -f sc-night.conf. Т.е. если ночью у вас другие тарифы, то можно переключаться между несколькими конфигами. Также можно переопределять любые параметры конфига из командной строки: sc --<parameter>=<value>, т.к. они обрабатываются по тем же хэшам. Для парсинга используется библиотека AppConfig::File http://search.cpan.org/~abw/AppConfig-1.56/lib/AppConfig/File.pm .

Исправил в 1.5.6.

Это баг или так теперь будет во всех новых версиях?

Тег добавляет 4 байта и смещает все поля в пакете на 4, поэтому ошибки и валятся. Надо в коде поменять смещение для dst IP c 16 на 20.

Какие параметры в конфиге? Есть ли NAT и псевдоустройства?

Для снижения числа cache misses в дополнение к RPS нужно включить hardware-accelerated RFS, если сетевуха поддерживает: http://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/network-rfs.html . Но это все разрабатывалось для распределения нагрузки на прикладные сервисы, а не для NAT/shaping. Низкоуровневые манипуляции с пакетами выполняются внутри обработчиков softirq. Для производительности надо отключить iptables и использовать stateless NAT средствами iproute2. Наиболее оптимально это будет через ingress filter actions с хэш-фильтрами. Но опять же, лучше это делать на отдельной машине, чтобы не усложнять правила шейпинга.

Полисинг тоже на хэш-фильтрах сделан или нет?

1. Storage с какой-либо сетевой ФС для кластеров. Обычно юзают GFS2, но для простых задач пойдет и NFS. 2. Высокоскоростное соединение с низкими задержками (Infiniband, 10Gb Ethernet). Опять же, для пионерских задач можно взять и простой коммутатор с гигабитным Ethernet. 3. Софт. MPICH2 или Intel MPI, компиляторы и библиотеки с поддержкой MPI, Sun Grid Engine. По-хорошему, нужен Intelовский софт и библиотеки (Intel Parallel Studio Cluster Edition), потому что он оптимизирован под железо, но можно начать и с GNU. 4. Набор MPI-приложений для тестирования коммуникаций и скорости работы, например, SPEC MPI2007. Вот типичное описание пионерского кластера на свободном софте: http://help.ubuntu.com/community/MpichCluster

По идее, лучше не совмещать функции BRAS и управления трафиком на одном устройстве. Тогда не будет необходимости во всяких костылях, вроде полисинга и псевдоустройтв.

Ответил в ПМ. Насколько я знаю, одним фильтром можно полисить подсеть адресов (если используются хэш-фильтры, маска должна быть больше /24), но не список IP из произвольных подсетей. Однако, если tc уже поддерживает логические операторы из серии "match ip src 192.168.1.1 or ip src 172.16.1.1", тогда можно и списком. Надо проверить. Я бы раздал всем юзерам на upload по скорости договора, а на download будет шейпинг и деление общей полосы. Это же upload, его все равно будет мало.

Эта возможность доступна в платной версии.

Намного, т.к. хэш-фильтров нет, и каждый пакет будет проходить по куче правил iptables. В общем, не маемся херней с псевдоустройствами, а берем sc (http://sourceforge.net/projects/sc-tool/), ставим limit_method = hybrid, вешаем на внутренний интерфейс, и никаких проблем с NAT.

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

Проще всего повесить шейпер с полисером на внутренний интерфейс, где нет NAT.

Надо писать ${5}Mibit, чтобы отделить имя переменной от текста. В какой версии sc это происходит? В 1.5.0, когда я существенно обновил код, действительно были проблемы с синхронизацией, но они были исправлены в последующих версиях. Я не могу у себя воспроизвести этот баг, скорее всего он возникает из-за каких-то проблем с запросами к базе или промежуточными скриптами.

Вы пользуетесь неправильными командами. В документации и sc help есть примеры. Зачем добавлять знаки $ перед вводимыми данными? Удалять нужно по IP-адресу, а не по номеру класса: sc dbdel 176.111.x.x. Добавление адреса делается командой sc add 176.11.x.x 5Mibit. Номера классов вычисляются автоматически, т.к. есть однозначное соответствие с IP-адресами.

Если будете писать патч для этого дела, то рекомендую не просто менять 1000 на 1024, а ввести новые единицы измерения (kibit/s, Mibit/s, ...) в соответствии со стандартом IEC 80000-13 (http://en.wikipedia.org/wiki/Data_rate_units). Тогда и обратная совместимость сохранится, и есть надежда, что примут в CURRENT.

Сделал релиз 1.5.5, где немного изменился конфиг (некоторые параметры теперь сгруппированы в секции) и добавлена возможность устанавливать для шейпера default policy: block или pass.

Тема о том, что TC якобы упирается в 2 Гбит/с появляется здесь уже не впервые. В очередной раз сообщаю, что причиной этому является использование псевдоустройств (IFB, IMQ). Делайте шейпинг на реальных интерфейсах.

Что произойдет, если отключить batch-режим и включить отладку (в конфиге поставить verbose = 2 и debug = 1)? Если все выполнится без сообщений об ошибках, и фильтры так и не будут создаваться, то советую сгенерировать максимально простую последовательность команд tc, где такой баг проявляется, и создать bugreport на багтрекере ядра. Они постоянно что-то ломают в сетевой подсистеме, похожий прецедент уже был: https://bugzilla.kernel.org/show_bug.cgi?id=84661