tc, приоритеты

Имхо никак.
Если зарезать входящий трафик еще можно, через жуткие костыли типа IMQ, то приоретизировать имхо нереально.
Рулит трафиком тот, у кого собираются очереди пакетов. А очереди пакетов собираются всегда на выходе. Правда, костылевый IMQ позволяет создать очереди на входе, но вам это не поможет.
После того, как входящий трафик уже забил вам канал, вы ничего не можете сделать.

Возможные варианты:
1. (Правильный, но сложный.) Выставлять нужным соединениям TOS Minimize-Delay, а всем остальным — Maximize-Throughput, и договориться с провом, чтобы он приоретизировал трафик согласно этим меткам (собственно, договориться с провом и есть сложность).
2. (Простой метод кувалды.) Тупо зарезать внутренним юзерам скорость, оставив n% от канала. n определяется исходя из потребностей внешних клиентов.

подскажите пожалуйста пример по сценарию 2 для входящего трафика (пусть например 2 мегабита канал, из них скажем по 900 кбит на веб и 900 кбит на фтп отдать. при чём, если никто не затребовал этих ресурсов, то что бы канал не простаивал, т.е. скажем пусть качалки жрут тогда - так можно ? ) сорри за глупые вопросы, lartc перечитал, но сейчас нет времени на метод проб и ошибок. через недельку обязательно углублюсь. н6о сейчас нужно так.

Хм. Родилась идейка. Суть такова:
1. Сделать два класса в tc, причем у одного зафиксировать потолок жестко где-то на одну четверть канала, а у второго — на полный канал.
2. Добавить фильтр, заворачивающий в ограниченный класс трафик с определенной меткой.
3. При помощи iptables RATEEST оценивать скорость трафика на внешние сервисы.
4. Если эта скорость превысить определенный предел (проверка через iptables rateest), начать маркировать выбранной меткой трафик внутренних пользователей.

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

Пример для tc приводить не буду, так как разбираюсь в нем плоховато и боюсь ошибиться, а с rateest и так все понятно.

спасибо. явно не kiss, боюсь не смогу заредизить быстро, но вот когдла буду через недельку курить tc - будет интересно. эх, проблемно всё (((

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

Мое предложение, конечно, является костылем. Идея основана на _косвенной_ возможности влиять на входящий трафик, урезая исходящий (направленный к внутренним пользователям). Такой механизм все равно не обеспечивает эффективной обратной связи. Но (имхо) это все, что можно сделать.

И не парьтесь по поводу кривокостыльности. Ваша задача сродни задаче создания сверхсветового звездолета или машины времени — ее решению препятствует фундаментальный закон бытия (непрерывность времени). Можно лишь попытаться обойти ее, но не решить.

ни слова о времени - Вы рушите мои мечты о мирах Уельса )))) ок. спасибо.