[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new WRR sched, updated TBF and "real" ingres implementation
On Wed, 26 Jul 2000, Devik wrote:
> Yes I know. But I've seen several posts where people had various
> problems with setting CBQ. I have the same problems, I can't
Yes, CBQ is not exactly the most friendly to set accurately.
> make CBQ work correctly on the wireless link. I tried to set
> link's bandwidth to 2Mbit but flow rates was now as I set them.
> One of classes was 50kbit (bounded) bit sometimes it was 40kbit
> and sometimes 60 (!).
This is due to several factors, mostly the shaping effect on TCP i would
think; of course the CBQ parameter setting has a part to play in all this.
I think the CBQ parameter setting really needs to be well documented.
You also have to recall that CBQ is an approximation (to compenstate for
efficient implementation)-- an app can achieve a very high percentage
of its target rate (90%?)
> May be it is due to fack that our wireless link has varying
> bw and CBQ code uses it to compute both time of packet's right
> edge and integrated time.
I dont understand why you think sampling at the right edge is a problem.
> After a week of hacking I gave it up and wrote WRR sched.
> My impl. of WRR qdisc also uses DRR internaly - maybe I should
> rename the qdisc to DRR ..
> Jamal, by the way, do you know why the CBQ uses right packet edges
> to compute idle value ? It would be much simpler and more exact
> to use left edges. Is there any reason for using right edges ?
Yes it does use the right edges. I think as long as you are consistent,
it shouldnt matter whether you use left or right edges; i may be missing
something you are trying to point to.
> And second question regarding CBQ, why does exists offtime there ?
> Offtime is constant, would not be better to make class sleep for
> interval given by undertime ?
You can achieve this by setting minburst to 0 in your tc CBQ settings (in
which case the offtime would become 0). offtime defaults to 1 avg packet
time at the specified serialization rate. This is generally used as the
"minimum packet times" allowed for recovering class to to wait before
being able to send more traffic.
I have never experimented with this; so i dont know what the effect
is. Maybe you could post some results?