Dotaz: Podivny problem s HTB

[b42]

Zdravim,

mam trosku podivny problem s htb: Mam nasledujici konfiguraci: dvoujadrovy athlon, dve intel sitovky e1000 - na eth1 je pripojena lan, eth1 vede k isp a ma verejnou ip a tudiz NAT. Na obou rozhranich je prakticky stejne nakonfigurovane htb, rozdil je jen v hodnotach "rychlosti" a v tom jak jsou pakety klasifikovany - na eth1 podle cilove ip pomoci tc filter, na eth0 uz to nejde, protoze se do tc subsystemu paket dostane az za natem, takze se jeste predtim kazdemu paketu pomoci iptables targetu IPMARK zkopiruje zdrojova ip do marku a podle nej se pak urci do jake tridy patri. Kazda ip ma svou vlastni tridu, pro kazdou ip se spousti neco takoveho:

tc class add dev eth0 parent 1:0011 classid 1:00ab htb rate 96kbit ceil 1000kbit prio 1 quantum 1500                                                                    
tc qdisc add dev eth0 parent 1:00ab handle 00ab: esfq perturb 5 hash src                                                                                                
tc class add dev eth1 parent 1:0011 classid 1:00ab htb rate 96kbit ceil 2000kbit prio 1 quantum 1500                                                                    
tc qdisc add dev eth1 parent 1:00ab handle 00ab: esfq perturb 5 hash dst                                                                                                
tc filter add dev eth0 protocol ip prio 5 parent 1:0 u32 ht 800:0: match mark 0x0a9ad002 0xffffffff flowid 1:00ab                                                       
tc filter add dev eth1 protocol ip prio 5 parent 1:0 u32 ht 2:02: match ip dst 10.154.208.2 flowid 1:00ab

Pred par dny jsem si vsiml ze shapovani na eth0 prestalo fungovat. Je pravdepodobne ze se to stalo priblizne v dobe kdy se na tom stroji menilo jadro, ktere oproti predchozimu podporuje SMP, ma zvysenou hodnotu HZ z 250 na 1000 a kvuli SMP je taktez zmenen zdroj casovacich dat pro qos subsystem z CPU na gettimeofday(). Nicmene nejsem si 100% jisty zda problem vznikl vymenou jadra.

Shapovani na eth1 funguje normalne a to i presto ze jediny rozdil mezi konfiguraci htb na eth0 a eth1 jsou ty konkretni hodnoty a mechanismus filtru, ktery zjevne funguje, nebot pocitadla bytu/paketu u jednotlivych trid se zvysuji.

Tohle je vypis jedne tridy z "tc -s class ls dev eth0":

class htb 1:ab parent 1:11 leaf ab: prio 1 rate 97000bit ceil 1000Kbit burst 1611b cburst 1725b                                                                         
Sent 184781922 bytes 122597 pkt (dropped 0, overlimits 0 requeues 0)                                                                                                    
rate 2465Kbit 203pps backlog 0b 7p requeues 0                                                                                                                           
lended: 96087 borrowed: 26507 giants: 0                                                                                                                                 
tokens: -238223 ctokens: -19556          

Prijde mi divne ze hodnota "rate" (ta spodni) je vyssi nez hodnota "ceil" - nemuze to byt chyba v jadre nebo v iproute2, nebo jen spatne chapu vyznam techto hodnot?

Nenapada nekoho kde by mohl byt problem? Budu vdecny za kazde nasmerovani;)

Odpovědi

[b42]

Dnes jsem prekompiloval ono jadro s jedinou zmenou a to HZ=1000 na HZ=250 a opet to dela to co by to delat melo. Byla chyba mezi zidli a klavesnici nebo se muze jednat o bug v jadre?

[b42]

Hmm, tak ne, udelal jsem rychly a spatny usudek, zase to jede uplne stejne spatne jako predtim. Zkusil jsem to jeste prekompilovat s HZ=100 ale stale to same, takze problem bude nekde jinde. Dalsim podezrelym jsou e1000 ovladace, je tam pomerne historicka verze vzhledem k tomu ze je tam 2.6.16 jadro. Zkusim tam jako modul dat ty ze sf.net, sice me nenapada jak by to mohlo souviset, ale taky me nenapada co jineho zkusit. Dalsi na rade asi bude zkusit jadro bez SMP.

[xxl]

"rate 97000bit" není větší než "ceil 1000Kbit". Je jenom uvedena v jiných jednotkách.

[xxl]

Aha, tak vy jste to myslel jinak. Tak to nevím. Ta rychlost může přelézt ceil, ale jenom krátkodobě, než se naplní burst. HZ se kdysi doporučovalo zvýšit právě kvůli tomu, aby počítání rychlosti bylo přesnější. Ale na dvoujádrovém procesoru to může být jinak. Zkuste napsat přímo Devikovi.

[b42]

Takze problem je zda se docasne vyresen. Spolu s SMP jadrem jsem pridal do init skriptu neco takoveho: echo 2 > /proc/irq/10/smp_affinity, cimz jsem docilil toho, ze jedna sitovka je obsluhovana jednim jadrem a druha tim druhym. Kdyz jsem zkusil povesit obe IRQ sitovek zpet na prvni jadro, vyse popsane problemy ustaly.

Zajimalo by me, proc se to deje. Dvoujadro je celkem k nicemu, kdyz musi byt obe sitovky obsluhovany prvnim jadrem.

Tohle by mohlo byt podstatne: jadro je 2.6.16.27, ovladac e1000 je nejnovejsi stable verze se sourceforge.net, tedy 7.5.5.1-NAPI.