Comment 16 for bug 193195

Let me try to get the ideas strait.

There are two optional parameters that I/we are using here to formulate this bug report.
* 1st -d rate Limit the download bandwidth consumption to rate KB/s;
* 2nd -u rate Limit the upload bandwidth consumption to rate KiB/s;

I guess everyone with some network experience knows that if the upload speed is artificially reduce, the download speed WILL be affected, correct?
There is a approximated value of 1 for each 80/100 bytes reason. So to achieve 1024KiB/s (8000 kb[its]/s) of bandwidth one needs something close to 10/13KiB/s (80/104 kb/s) of upload bandwidth.

Now if we all are talking the same language, I'll get back to this bug.

I repeat, in my case I used to need to set a limit on my upload bandwidth when doing downloads, due to our VoIP system.
So, when I would use the network I would launch that specific program with trickle (in this example wget). I would then pass the -u (upload throttle) to trickle so that it would only allow a maximum of 8 KiB/s (64kb/s) of our 400kb/s (notice the kilobits, the uplink speed from our ADSL).

BUT as the original OP (me) post, that would lock trickle on 10 KiB/s on the download speed, when it should in fact be much higher (around 400/600 KiB/S).
Then, with extra comments on this ticket, we found out that trickle code would AUTO set that 10KiB/s limit if not used the -d (download throttle). That doesnt make much sense, and so it is a BUG.
I know i could have just used the -d parameter, but that wasnt what I was doing, and the program should allow users to use it as they see fit.

In the meantime I've discovered wondershapper that does exactly what I want, but doenst allow me to select the network, as I would do with trickle (by app) or trickled (daemon by protocol, on .conf)