Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Stu Redman]

What is the number of download slots you are getting? And what speed does each of them have?

[RRM]

Right now thats 244 slots
Their download speed varies greatly; currently from 0 to 150 kbps
It seems to me that the slow downloaders are about
equally represented as the fast downloaders
Sometimes there is somebody who downloads very fast (like 300 kbps to 2 MBps)

[RRM]

Its hard to keep track of individual speeds
as it changes constantly

[Stu Redman]

With slot allocation still at 1k/s ?

[RRM]

yes, because aMule doesnt crash anymore.

[RRM]

So, how about that queue that is not supposed to be there? (queue=0)
Some downloaders waited for hours (aMule>Uploads>Waited)
How is that possible?

[Stu Redman]

I'll have to review the code when I have time for it. You are running a very strange configuration, mind.
My guess is you are allocating unlimited slots, but allocation actually fails because you run out of TCP sockets.
Try to limit upload bandwidth at something matching your bandwidth (with a reserve), and slot allocation so you get, say, 20 upload slots. Let's see what happens then.

[RRM]

This is weird... I just noticed that right now everybody waited for either
1 or 2 seconds. And there is always 1 client waiting in queue,
except when someone gets to the max 10MB, then its temporary (1 or 2 secs)
2 or even 3 clients waiting in queue, and then 1 again.
So, where before it was always 0, with 1 or 2 max temporary (1 or 2 secs)
its now always 1, with 2 or 3 max temporary (1 or 2 secs).
The difference: the maximum waiting time is now 2 secs (instead of hours)

Let me check whether this will last.
After that i will do what you told me.

[RRM]

Coming home from work, the queue is empty again (clients in queue=o)
and yet the waiting time is still 1 to 2 secs.
So, my hypothesis for this is:
It took some time before the "queue that isnt supposed to be there" (the TCP sockets-queue?)
had dissolved, which seems logical to me, because even when you start
letting everybody in (with limited demand), it will take some time
before there is no (TCP sockets-)queue anymore...

But then again... why did aMule constantly list 1 client in queue this morning?
Does it still make sense to try this?

Try to limit upload bandwidth at something matching your bandwidth  (with a reserve)
, and slot allocation so you get, say, 20 upload slots. Let's see what happens then.

[Stu Redman]

Definitely.

[RRM]

OK, i changed my settings:
Max. upload bandtwith: 3000 kbps
max. connections: 20

What happens next (right away) is REALLY weird.
- I suddenly notice downloaders that 'have waited' many hours (even 20 hours!). Most 'have waited' 20 to 45 minutes.
- Clients in queue remains 0, even though that the number of connections decreases gradually (due to new settings)
- The faster clients immediately get re-allocated a new slot once they've downloaded their 10MB
(even though they 'dont have credit') and yet their 'waiting time' has increased by a minute or 2!!!
This is no incident, it happens with almost every 'immediately re-allocated client', though not all... (some go from minutes to 2 secs)
So, now we know how they get that 'waiting time' (while downloading!!!)
....
- In the end (when total clients is actually 20), continuously the same fast downloaders get re-allocated immediately,
as if no other downloaders exist ... (clients in queue is still 0!!!)

Not weird:
- The download speed per client went up drastically (total bandtwith utilized remained the same)
...
....
Going back to my normal setting (no upload limit, no connections limit)
I notice a downloader that has 'waited for 2 days and 2 hours').

[RRM]

One day later.
Settings: no limits.
Clients in queue is still 0, but 'waiting times' are also mostly still
minutes to hours. About 1/3 has a waiting time of 1 to 3 secs.

All downloaders get slot re-allocation, but:
For some, their 'waiting time' is (upon reallocation) reduced to 1 to 3 secs.
For most, their 'waiting time' is increased with the time that they just spend downloading.

[Stu Redman]

Maybe I didn't make myself clear...
Leave your "max simultaneous connections" at what they were (500 - or what did you have there?).
Limit your upload to 3000 kB/s if your connection can handle it. (And please notice - kB stands for kilobyte,  kb for kilobit.)
Set your Slot Allocation to 150 kB/s which will result in 20 upload slots.

I'd like to see if aMule performs well with sensible settings.

[RRM]

Thank you. Sorry, i misunderstood.
New settings:
max connections: 2000
upload limit: 3000 kB/s
Slot allocation: 100 kB/s - I tried 150 kB/s, but aMule changes that to 100 kB/s

The number of clients in queue almost immediately goes up (from 0)
to 20, 30, 50 etc.
However, the total upload speed goes drastically down as well.
Somehow, everybody seems to get eliminated step by step,
as the average upload speed doesnt go up; even down...
The latter is because the fastest downloaders (over 100 kB/s) get eliminated first,
as they are done the soonest with their 10MB, and nobody gets reallocated.

Ultimately, they are all gone...
No more downloaders...
So, im changing back my settings, naturally.

I always though that slot allocation means that this is the miminum download speed
for potential downloaders. And nobody starts downloading at a speed of 100 kB/s,
so that naturally, nobody can get over that threshold.
right?

[Stu Redman]

No more downloaders - but still people on queue ? 
How many downloaders were there at maximum?