Re: PF+PRIQ

[Cizek.Milan]

>  tohle je moje QoS v ramci LAN a funguje docela dobre. Kdy to srovnam s 
>  tim Tvym, tak tobe tam chybi direktiva "quick", protoze jinak bere PF 
>  pouze posledni pravidlo ktere vyhovuje. Kdyz tam das quick, tak PF bere 
>  okamzite to pravidlo ktere vyhovuje...

Ahoj, diky, zkusim s s tim pohrat. V tve ukazce je pro mne take dalsi inspirace...

>  Jeste poznamka k te rychlosti wi - mas tam 5 - podle mych mereni je 
>  realna rychlost wi v jednom smeru cca 4Mbit. Kdyz povolis na obou 
>  koncich spoje plnou rychlost a obe strany by opravdu zacaly naplno 
>  posilat, tak ten spoj stejne zahltis a QoS bude k nicemu. Ja to mam 
>  nastaveny na 2Mbit na kazde strane - je to sice pomalejsi, ale nikdy se 
>  to jeste nerozhodilo. Prip. me napada, ze by se to dalo udelat 
>  asymetricky, tj. na jeden konec 3Mbit a na druhej 1Mbit.

Ryhlost je treba teprve postupne vychytat. Stejme me zajima jedna vec, a to proc PRIQ musi byt vazano na celkovy bandwidth. Vzdyt by to preci krasne mohlo fungovat i bez toho, proste podle plnosti front jednoduchym algoritmem uprednostnovat to ci ono. Myslim ze z principu by to melo byt mozne, nekde jsem to dokonce cetl (link bohuzel nemuzu dohledat)...

8.3. Handling a link with a variable (or unknown) bandwidth
In theory, the PRIO scheduler is an ideal match for links with variable bandwidth, because it is a work-conserving qdisc (which means that it provides no shaping). In the case of a link with an unknown or fluctuating bandwidth, the PRIO scheduler simply prefers to dequeue any available packet in the highest priority band first, then falling to the lower priority queues. 

Milan