trickle defaults to 10KiB/s for upload/download limits

[Fernando Miguel]

If I set trickle to limit my upload while using it to control a download, the download limit will be stuck a preset value:
~$ trickle -u 8 wget -c http://neacm.fe.up.pt/pub/ubuntu-releases/gutsy/ubuntu-7.10-desktop-i386.iso

this should just limit my upload to 8KiB/s, but what it does is to limit download rate at 10KiB/s no mater what the upload limit I set.
It could even be:
~$ trickle -u 1024 wget -c http://neacm.fe.up.pt/pub/ubuntu-releases/gutsy/ubuntu-7.10-desktop-i386.iso
It would still limit my download rate by 10KiB/s

-----------------------

New information:
trickle -s #standalone doesnt change this;
trickle -u UPSPEED -d DOWNSPEED does in fact allow bigger speeds;
trickle -u UPSPEED_BIGGER_THEN_10KiB/s works as expected

[Andrea Colangelo (warp10)]

According to man trickle, -u sets a limit for uploading -d sets for downloading. Maybe you want to use trickle -d 8?

[sveri (sssssrichter)]

I can reproduce exactly the same the behavior on my machine.
Kubuntu - Hardy with the todays update installed.

Adding the -d option works, so
trickle -u 8 -d 1000 wget -c http://neacm.fe.up.pt/pub/ubuntu-releases/gutsy/ubuntu-7.10-desktop-i386.iso
limits the download spped to 1000 K/s

[Fernando Miguel (fernandomiguel)]

Andrea I want to limit the UPLOAD bw to allow the VOIP in the company!
that why I'm "trying" to limit my upload bw usage and not the download.
Thats why I used -u parameter on trickle

[sveri (sssssrichter)]

Ok, just to clear things out.

trickle -u 8 wget -c http://neacm.fe.up.pt/pub/ubuntu-releases/gutsy/ubuntu-7.10-desktop-i386.iso

produces the same behavior, it limits the dl rate to 10 k/s, which it shouldnt do i think.
My native understanding is that -u option shouldnt touche the dl rate in any way.

[Andrea Colangelo (warp10)]

Fernando: my apologies, I misunderstood your report.
I tried it again, and I can confirm your findings under both Hardy and Gutsy. Looks like using -u alone sets the download to 10; using both -u and -d sets the download to the desired speed.
Confirming this bug.

[Fernando Miguel (fernandomiguel)]

Actually sveri, the -u SHOULD affect the download speed, because it limits the acknowledge packages.
But, of course, it should never by by a ten-fold limit.
If i just use
~$ trickle -d 800 wget -c http://neacm.fe.up.pt/pub/ubuntu-releases/gutsy/ubuntu-7.10-desktop-i386.iso
I'll get the proper download limit, and wont use more then 3KB/s of upload.
So, setting -u 8, should allow me to use all my 8mb/s (or 1024KiB/s)

[sveri (sssssrichter)]

I took a look at the trickle source.
Opening trickle.c you can see the following code:

main(int argc, char **argv)
{
 char *winsz = "200", verbosestr[16],
     *uplim = "10", *downlim = "10", *tsmooth = "3.0", *lsmooth = "20",
     *latency = "0";
.....

 while ((opt = getopt(argc, argv, "hvVsw:n:u:d:t:l:L:")) != -1)
                switch (opt) {
  case 'v':
   verbose++;
   break;
  case 'w':
   winsz = optarg;
   break;
  case 'u':
   uplim = optarg;
   break;
  case 'd':
   downlim = optarg;
   break;
  case 'V':
   errx(1, "version " VERSION);
   break;
  case 'n':
   strlcpy(sockname, optarg, sizeof(sockname));
   break;
  case 't':
   tsmooth = optarg;
   break;
  case 'l':
   lsmooth = optarg;
   break;
  case 's':
   standalone = 1;
   break;
  case 'L':
   latency = optarg;
   break;
                case 'h':
  default:
   usage();
  }
....
 setenv("TRICKLE_DOWNLOAD_LIMIT", downlim, 1);
 setenv("TRICKLE_UPLOAD_LIMIT", uplim, 1);
 setenv("TRICKLE_VERBOSE", verbosestr, 1);
 setenv("TRICKLE_WINDOW_SIZE", winsz, 1);
 setenv("TRICKLE_ARGV", argv[0], 1);
 setenv("TRICKLE_SOCKNAME", sockname, 1);
 setenv("TRICKLE_TSMOOTH", tsmooth, 1);
 setenv("TRICKLE_LSMOOTH", lsmooth, 1);
...
}
In my understanding this means that the dl rate is hardcoded, and if trickle is called without
the -d option the dl rate will remain at 10 k/s.

I dont know how to go on with this, just wanted to help a little bit :-)

[Fernando Miguel (fernandomiguel)]

well from my tests cases, even using:
trickle -d 2048 -u4 wget -c http://neacm.fe.up.pt/pub/ubuntu-releases/gutsy/ubuntu-7.10-desktop-i386.iso

will not limit the upload to 4KiB/s, so using -d just remove the hardcoded limit doesnt work.

[sveri (sssssrichter)]

Hm, ok, there must be a more severe bug inside the program.

The first thing you mentioned was the fact that
trickle -u 8 wget -c http://neacm.fe.up.pt/pub/ubuntu-releases/gutsy/ubuntu-7.10-desktop-i386.iso
downloads only with 10 K/s and this can be explained by looking in the code above.
Setting the -d xxxx option works, it your download will be as fast as you want to.

So i checked out what goes on with the upload.
I used the tool you proposed, nethogs:
trickle -u 8 -d 1000 wget -c http://neacm.fe.up.pt/pub/ubuntu-releases/gutsy/ubuntu-7.10-desktop-i386.iso

Now nethogs shows me an upload value of ca. 6 k/s with short peaks at 12 K/s measured over 1 minute

And now comes the really weired thing, exchanging the -u and the -d option, like you wrote above
i get an upload value at ca. 34 K/s with peaks at 40 K/s which is all my connection is able to transfer.

Maybe you can try exchanging the options and see if it does change anything.

[Fernando Miguel (fernandomiguel)]

On Tuesday 19 February 2008 16:35:19 sveri wrote:
> Now nethogs shows me an upload value of ca. 6 k/s with short peaks at 12 K/s measured over 1 minute

For better control over spikes, one needs to set the time parameters.

> And now comes the really weired thing, exchanging the -u and the -d option, like you wrote above i get an upload value at ca. 34 K/s with peaks at 40 K/s which is all my connection is able to transfer.
>
> Maybe you can try exchanging the options and see if it does change anything.

You mean setting first the -u and then -d?

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by...

[Isan (45702yhfksahf)]

Don't forget -s option for running trickle in standalone mode independent of trickled.

trickle -s -u 8 -d 1000 wget -c http://neacm.fe.up.pt/pub/ubuntu-releases/gutsy/ubuntu-7.10-desktop-i386.iso

[Fernando Miguel (fernandomiguel)]

On Wednesday 26 March 2008 12:45:52 Isan wrote:
> Don't forget -s option for running trickle in standalone mode independent of trickled.

I've tried in the past with -s and even with the daemon and the behavior was the same.
I'll try tomorrow again, and post back

> ** Changed in: trickle (Ubuntu)
> Assignee: (unassigned) => Isan (45702yhfksahf)
> Status: Confirmed => Invalid

Why are you marking this as invalid after more users confirm it?
If the reason is for not have used the standalone in the reported post, you should at least have marked it as incomplete.

 status new

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by...

[Fernando Miguel (fernandomiguel)]

Just tested...
it seems that using -s wont change anything.
BUT using -d parameter does affect the download speed.

So this is a bug, because not using -d, and only -u, it limits the donwload to 10KiB/s and not the maximum of the connection.

So the orginal reports is correct.

[Isan (45702yhfksahf)]

I tested -s changes something so it is again invalid, sorry.

[Johnathon (kirrus)]

From my testing, tricked will automatically go into standalone mode, if some case is met (I'm not sure what that case is). If it is already in standalone mode, then telling it to go into it doesn't matter... and I have duplicated this bug here, limiting upload ALSO appears to limit download. I do not believe that this should be invalid, but will not change it: Isan can you check again, preferably on a completely clean install (nothing but trickle added).

[Fernando Miguel (fernandomiguel)]

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)

[Isan (45702yhfksahf)]

in Hardy clean install:
 trickle -s -d 15 wget -c http://releases.ubuntu.com/releases/8.04/ubuntu-8.04-beta-alternate-i386.iso
I got 15.00K/s
 trickle -s -u 5 -d 15 wget -c http://releases.ubuntu.com/releases/8.04/ubuntu-8.04-beta-alternate-i386.iso
I got 15.00K/s
 trickle -u 5 -d 15 wget -c http://releases.ubuntu.com/releases/8.04/ubuntu-8.04-beta-alternate-i386.iso
I got 15.00K/s

[Isan (45702yhfksahf)]

But:
trickle -u 100 wget -c http://releases.ubuntu.com/releases/8.04/ubuntu-8.04-beta-alternate-i386.iso
I got 10.00K/s
trickle -u 3 wget -c http://releases.ubuntu.com/releases/8.04/ubuntu-8.04-beta-alternate-i386.iso
I got 10.00K/s

[Isan (45702yhfksahf)]

And
trickle -s -u 100 wget -c http://releases.ubuntu.com/releases/8.04/ubuntu-8.04-beta-alternate-i386.iso
I got 10.00K/s
trickle -s -u 3 wget -c http://releases.ubuntu.com/releases/8.04/ubuntu-8.04-beta-alternate-i386.iso
I got 10.00K/s

so you must specify your download speed even you are limiting upload speed too

[Fernando Miguel (fernandomiguel)]

Thanks for confirming my report so clearly.
e will have to have this fix on hardy+1, since the reps are now closed.

[Johnathon (kirrus)]

Is this still a problem for you?

[Fernando Miguel (fernandomiguel)]

Yes. i re-tested this bug this week and i can still reproduce it

[Daniel Hahler (blueyed)]

In the Debian bug report, Robert Lemmen writes:
  this is correct, trickle always limits both up and down traffic to the
  configured value or the default (which is 10k). i'll try and add an
  "unlimited" mode which would be on by default, but that might take a
  while, in the meantime i suggest that you specify a very large value for
  the other direction.

[Fernando Miguel (fernandomiguel)]

$ trickle -s -u 300 wget -c http://cdimage.ubuntu.com/daily-live/current/maverick-desktop-i386.iso
--2010-09-17 22:04:30-- http://cdimage.ubuntu.com/daily-live/current/maverick-desktop-i386.iso
Resolving cdimage.ubuntu.com... 91.189.88.39
Connecting to cdimage.ubuntu.com|91.189.88.39|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 728471552 (695M) [application/x-iso9660-image]
Saving to: `maverick-desktop-i386.iso'

 0% [ ] 81.996 8,93K/s eta 19h 41m

Maverick, not fixed

[jessesmith (jessefrgsmith)]

This is not a bug. The upstream documentation points out that if a value is not specified then trickle will default to limiting the speed to 10kB/s. This happens for either uploads or downloads, whichever value is not manually supplied. The program is working as documented and designed.

[Ken Sharp (kennybobs)]

The manual says no such thing. The Debian bug states it _will_ be added in the next release, but that was a decade ago and we've still not seen a new release.