On 18 03 2003 17:47, Nickola Kolev wrote:
> Viktor wrote:
>
> [ cut ]
>
> > zdravo,
> > na tozi adres, http://sp9wun.republika.pl/linux/shaperd_cbq_en.html, e
> > spomenato za bugfix:
> >
> > 03.02.2003 - Version 2.00beta44.
> > o Probably fixed bug kernel: HTB: quantum of class XXXXX is small.
> > Consider r2q change
>
> [ cut ]
>
> Не, това няма съвсем, ама съвсем нищо общо. Първо, този сайт е посветен на
> неизвестен досега за мен проект, основан ВЪРХУ htb (и май cbq)
> поддръжката в ядрото. Второ, категорично твърдя, че съобщенията в логовете
> от този вид не са резултат от бъг в ядрото. Да не говорим, че става въпрос
> за оправен бъг в shaperd, а не в кода на sch_htb. Прочети по-предния ми
> пост.
Никола, HTB все още не е част от stock 2.4 kernel-a. Съдейки по това което
казва и Антон Тодоров за включения дебъг и мятането на някакви вътрешни
състояния на ядторо в лог-а си мисля че бъдещия net/sched/sch_htb.c който
требе да влиза в stock е още експериментален и за това седи отвън като пач.
На практика човек може да позаключи следното:
гледайки небрежно sch_cbq.c има бая locking дори май и при приемането на
новите стойности пращани към ядрото от user space с утилката tc (хвала набате
Алексей, тука ;-)... Май на ядрото пачнато с external htb patch му идва криво
ако му наблъскаш пресетвайки безспир или без междинно изчакване с tc разните
му стойности. Слагайки изкуствено един безкрайно малък sleep интервал явно
предотвратява това омазване на kernel-data-та, което иначе самото пачнато
ядро би трябвало да си извършва lock-вайки дадените dataполета в своя
kernel-data space (locking protects data not code ;-). Мисля, че има бая
резон в тези слова. Между другото поизрай си да пресетваш без изчакващ
интервал няколко нови htb стойности с tc ... ще е интересно да види резултата
и при теб... Освен това има иедна зависимост и тя е архитектурнозависима, see
NOTES на man tc-htb:
Due to Unix timing constraints, the maximum ceil rate is not infinite and may
in fact be quite low. On Intel, there are 100 timer events per second, the
maximum rate is that rate at which 'burst' bytes are sent each timer tick.
From this, the mininum burst size for a specified rate can be calculated.
For i386, a 10mbit rate requires a 12 kilobyte burst as 100*12kb*8 equals
10mbit.
Поиграй си и с тези стойности, задавайки некоректни значения (гледам че svetla
подава еднакви стойности за тях, напр. rate 100Mbit ceil 100Mbit) да видиш
дали htb patch kernel-a е error tolerant .... Идея нямампростое интересно да
тестиш как е положението ;-)
--
printk("Greets, fr33zb1\n");
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================
