One salient point here: - are you using qdisc on the same box as the DCCP sender? I had to shift qdisc onto another box as the point that qdisc intercepts is not necessarily where you think. In my research I ended up using three boxes - a sender, a traffic shaper and a receiver. I also had to create two subnets and have the traffic shaper route also as otherwise the boxes were smart enough to work out they were on the same Ethernet segment. I can supply some scripts etc if you want to look at mine... Regards Ian -- twitter imcdnzl web http://www.next-genit.co.uk On 26 August 2010 17:11, Eugen Dedu <Eugen.Dedu@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 26/08/10 13:08, gerrit@xxxxxxxxxxxxxx wrote: >>> >>> Let's say that qdisc on the sender allows 2Mb/s to get out. A sender >>> application sends a file at 3Mb/s to DCCP. Currently, DCCP "eats" it >>> completely, i.e. at 3Mb/s. However, about 1Mb/s is "eaten" (lost) >>> locally because of qdisc, and only 2Mb/s are sent to the network. DCCP >>> indeed sees that some packets are lost (the ones lost locally), that is >>> why it computes a rate ("computed transmit rate") of 2Mb/s indeed (we >>> printed it to the screen in our tests). The problem is that DCCP "eats" >>> 3Mb/s instead of eating 2Mb/s. >> >> Up to here I agree; but there is nothing wrong here. DCCP would even >> "eat" 10Gbps if it were given large enough buffers. It is not a bug >> since the actuator for the sending rate is the output, not the input. >> -- To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
