On 19 03 2003 15:06, Nickola Kolev wrote: > Boyan wrote: > > > > V momenta polzvame chisto htb s okolo 520 klasa (v ednata posoka, i > > oshte tolkova v drugata) za ogranichenie i balansirane na trafik ot > > internet/peering kym vseki otdelen kabelen user i obratno. I obshti > > limiti za nqkoi grupi clasove. > > > > Moga da kaja che raboti vpechatlqvashto (v sravnenie s drugite resheniq > > pod linux, koito si imaha syotvetnite problemi). > > > Da, i az polzvam htb - naistina raboti vpechatlqvashto. Imam okolo 1500 > klasa, koito garantirat min skorost kakto po grupi, taka i na otdelni > useri.
> > s HTB-to s mnogoto klasove i filtri imahme efekta che kernela se > > panirashe. zaobikolihme go kato postavihme 100ms sleep mejdu operaciite. > > predpolagame che e nqkakyv locking problem v kernela. Na predishnata > > (po-slaba) mashina imah efekta che ako pusna tc utilkata i gledam > > ogromniq i izhod prez less kernela neminuemo zabivashe sled izvestno > > vreme (naj-veroqtno poradi tova che drugo tc se puska ot vreme na vreme > > da sybira statistiki w rrd-ta) > > > Interesno, edinstveniq pyt, kogato uspqh da dokaram mashina s htb do kernel > panic beshe, kogato rychkah, deto ne trqbvashe. A imenno, vyv versiq 2.0 > na htb imashe ogranichenie za dylbochina na clasovete v ierarhiqta 4 (ili > 8, ne pomnq veche). Ta pipah kakvoto pipah, i mashinata experience-vashe > seriozni, hard lockups. ;))) Само предложения без никакви идеи за заяждане или да поправям който и да било. hard lockups тук е употребено като забивка или kernel hang. Това може да е в разултат от corrupted data structures в ядрото в резултат на това, че повече от един kernel thread манипулират (read/write) конкурентно дадени shared data structures. За това си има примитиви за заключване на подобни shared data structures. Да, Linux ядрото разполага с advanced locking primitives (не за забиване на ядрото [hard lockpus], а за заключване [locking] на дадени полета от дадена ядрена нишка за read/write, така че другите ядрени нишки да не пишат там докато някой чете или четат от там докато някой пише и други случаи;-)... Без да имам претенцийте да разбирам от qdisciplines и kernel source ми се струва че именно user space tc провокира ядрена нишка или нишки коя(и)то не взаимодействат _конкурентно_ in safest way possible приемайки от user space, tc команди "четейки от" или "пишейки в" в kernel space (или по-точно някъде в kernel-data, дадени shared data structures) и плювайки обратно към user space т.е. към tc... Моля не ме обвинявайте в flames, а след като имате опит с htb & others докладвайте вашите hard lockups/hang cases на автора на HTB , заедно с скриптовете които ползвате... Тази защита от user space в добавяне на интервал от нялколко милисекунди е workaround, но не и за kernel-a... и за това трябва да се погледне и фиксне той... Предполагам, че иде реч за тривиално (за автора) доизглаждане на кода в ядрото който поема и праща от и към user/kernel space. Мисля, че просто не оставих шанс на средностатистическия потребител да не разбере какво имам предвид. Бтв, трябва да се прави сериозна разлика между flamewar и аргументирана дискусия или поставяне на диагнози било то и ядрени , e.g. kernel's ...;-)... I'm just a Doc. -- printk(KERN_EMERG "Peace. No flames.", panic_timeout); mdelay(panic_timeout*1000); machine_restart(NULL); ============================================================================ 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 ============================================================================
