[sisyphus] Re: [Comm] Advanced Routing & QoS

[aen]

Андрей, Вы, видимо, забыли отправить это письмо и в Sisyphus.
Andrey Orlov wrote:

>On 2002 December 02 Monday 20:08, you wrote:
>  
>
>>Для начала, извините за крос-постинг. Я предполагаю, данная тема
>>интересует многих.
>>    
>>
>
>Довольно-таки. Что касается статьи то у меня особых замечаний нет, хотя я бы
>расширил пункты 7,8 (оформив их как некий cookbook, хорошим (но недостаточным) приближением 
>может быть Advanced Router HOWTO), кроме того должен заметить - ссылка в п.8 на man 8 tc
>немножко лукавая : man 8 tc во всех пунтктах посвященный фильтрам, ссылается на
>man 8 tc-filters, который похоже еще не написали : во всяком случае в дистрибутиве
>его не имеет места (сейчас тяжело посмотреть, но кажется в sysiphus тоже). Да и остальная
>часть man tc,  больше похожа на сумму из tc <....> help. Использоваение же самого man 8 tc для 
>понимания работы упомянутых u32 & fw - невозможно  (в версии из ALM2.0 man tc|grep -iE "u32|fw" - пусто). 
>
>Тем не менее, статья особых нареканий не вызывает, а вот вопрос по поводу ip/tc у 
>меня есть : последние две недели я вожусь с настройками посредством tc и у меня 
>возникает странное ощущение того, что этот код крайне плохо отлажен (или крайне 
>плохо собран в нашем случае, я использую ALM2.0 со всеми апдейтами). Я не настолько 
>хорошо в этом разбираюсь, что бы сразу начинать  тыкать пальцем в ошибки в коде - я 
>собственно tc раньше и не трогал, но мне хотелось бы понять текущий статус этого кода:
>нечто отлаженное,  часто используемое и надежно работающие
>или некий код, 80% декларированного функционала  которого никто никогда не использовал. 
>По ощущениям (еще раз - это именно ощущения, на полуинтуитивном уровне) я склоняюсь ко 
>второму варианту, так как те особенности работы, которые я наблюдаю могут быть результатом:
>
>1. Использования неинициализированой памяти (в модулях ядра, похоже);
>
>2. Неосвобождения памяти (опять же в модулях ядра);
>
>3. Отсутствия проверок граничных условий;
>
>4. Отсутствия проверок допустимости параметров;
>
>5. Отсутствия проверок переполнения и т.п.
>
>Про нереализованность некоторых обещанных фичей я лучше промолчу - так как если
>насчет этих пяти пунктов я могу более-менее аргументировано рассуждать, то неработоспособность
>некоторых решений - может быть (и скорее всего есть) моей ошибкой (хотя работа с доками в 
>данном случае больше напоминает "шаг в сторону - контрольный выстрел в голову").
>
>Эти пять пунктов я заметил при использовании tbf, prio, u32  в меньшей степени - cbq 
>(kernel24-up-2.4.18-alt6master, AFAIR).
>Подробнее я рассказывать не буду - так как в данный момент интересует не помощь в 
>решении конкретных проблем, а понимание текущего статуса этого кода, особенно статус 
>этого кода в рамках AltLinux (так как менять дистрибутив в обозримом будущем я не намерен), 
>чбы решить для себя что делать дальше:
>
>1. Поискать другое решение (в случае если этот код вообще никто не поддерживает и это лишь
>забавный реликт, оставшийся от ядер 2.2.*);
>
>2. Повнимательней почитать доки, пересобрать ядро, поставить какие-л. апдейты
>и т.п. (если этот код отлаженный, проверенный,  всеми используется, имеет 
>сплоченную команду поддержки);
>
>3. В том или ином виде присоеденится к его поддержке (вряд ли как писатель кода - но по крайней
>мере отследить баги и написать баг-репорты  с точным описанием глюков - если код перспективный
>но у команды разработчиков не хватает рук, времени, тестовой базы и т.п.); 
>
>Буду благодарен если ктонть мне это прояснит.
>
>  
>