[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new WRR sched, updated TBF and "real" ingres implementation





On Mon, 7 Aug 2000, Devik wrote:

> ugh I read the paragraph above several times and I think there
> is principial error in it.

I was basically explaining why it was important to know how long the
hardware would take to transmit the packet (perhaps this is a Linux
limitation; it's a general purpose OS)

> When packet P1 of size PS1 is sent at time 0, it completes transmision
> over the wire at time HT1. Then there will be (even zero) pause, say WT1.
> Transmision rate of link is then P1/(HT1+WT1). Estimators in CBQ
> measures just this rate.

agreed (btw, you mean PS1/(HT1+WT1)). 

> When you go thru 100Mb eth or 56k modem there will differ only
> HT1/WT1 ratio. But rate doesn't depend on the ratio, only on the
> sum.
> I can't believe that data rate should depend on HW bandwidth - it
> would affect only upper limit of the rate, wouldn't it ?

This is nice to say but hard to do;-> How do you know what HT1 is?

> > > you are right but estimation is based on allocated rate, not on HW rate.
> > > The hw rate is used here only for undertime correction.
> > 
> > Hmmm.. are you sure about this? double check what L2T() macro does;
> 
> Yes I'm sure ;-}:
> #define L2T(cl,len)
> ((cl)->R_tab->data[(len)>>(cl)->R_tab->rate.cell_log])
> 
> so it "computes" transmision time of packet size "len" at given
> "cl"'s rate. cl->R_tab is classe's allocated rate. In source code
> there are only two points where L2T(&q->link, len) is used
> (q->link->R_tab is HW bandwidth.
> 

You are right. (TCA_CBQ_RATE is used both by the class and qdisc)

> > I think if you can solve the problem of having clear knowledge of when
> > the packet has left the NIC/driver, i will be more convinced ;->
> 
> As I stated above you don't need to know NIC's service time,
> you need to know packet_len/total_packet_transm_time and you
> know it.
> 

And i still think there is something wrong with your strategy.

total_packet_transm_time has 2 time factors which are hidden: These are
the interpacket gap and the h/ware transmission time. In order to
shape/leak at a certain allocated rate you need to account for
both.
The h/ware transmission time becomes less important as you go to higher
speeds (but significant as you move to lower speeds). The interpacket gap
could be zero as you stated (in order to meet this shaping requirement).

> I have some results but not in good form. But is seems
> that each class which is underlimit delays packet at most
> 1ms (486DX2/66), bounded classes are throttled exactly
> to specified ratio and delay with 5kbps flow and 500B packets
> is 45ms avg (using DROP overlimit action).

What are the similar numbers with the current estimator? 1 ms for
underlimit sounds like too much.

> Extra bw is divided correctly (given well formed weights).
> Now I plan massive code cleanup, testing and documentation...
> 

Good. Like i said in my earlier mail; just make sure there is a selectable
alterntive for the old estimator.

> > PS:- Can i con you into implementing a scheduler? I have lots of
> > suggestions for things that would be nice to have ;->
> 
> pls I found "con" in dict but there is too many translations.
> Can you explain what the word means ?
> 

con in this case translated as "to trick or convince"; i.e can i convince 
you to write a new scheduler or something else ;-> You seem to be a very
capable guy and we need the manpower if we can get it ;-> Instead of you
trying to tune existing things, i think your skills could be more usefull
to add new things (eg think of W2FQ for one or HPFSC; it would be useful
to have them around. I have been meaning to implement one of them but too
occupied at the moment).

cheers,
jamal