Print

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

[RRM]

No more downloaders - but still people on queue ?  

Yes, everybody that was downloading under the 1 kB/s slot allocation settings, was apparently
moved to the clients in queue when the treshold (slot allocation) became 100 kB/s.
Once i changed my settings back, they gradually all moved back from the queue to downloading.

How many downloaders were there at maximum?

Before i changed the settings (so when it was still 1 kB/s slot allocation), there were about
270 downloaders.
Right after i changed the slot allocation to 100 kB/s, that number went down, and kept on going down,
and equally fast, the number of clients in queue went up, and kept going up till all downloaders were
gone (clients in queue went from 0 to 273 eventually; downloaders went from 270 to 0)
Right now clients in queue is 0 again, and 256 downloaders.

[RRM]

According to the dictionary, allocation means:
allotment, apportioning, apportionment, assignation, parceling

So, yes, when slot allocation is set at 100 kB/s, its logical to expect that aMule will
divide the available upload bandwith, 3000 kB/s, over 30 downloaders. As in:
"the apportionment is 100 kB/s each"

However, it also means "assignation", so that the connection needs to be
100 kB/s already BEFORE you are allocated/assigned a slot. And, that, of course, never is the case
(because you use the bandwith required, which is not much for communication only).

I suspect that "slot allocation" in aMule means the latter.
Hence no more downloaders when slot allocation is set at 100 kB/s.

[Stu Redman]

Oh please...
Most of us are not native English speakers, and we don't have a dictionary or thesaurus open when we label our dialogs. Your conclusion is wrong. Nobody gets kicked for downloading too slowly, except if he drops below measurable speed or spends his time limit.

[RRM]

Okay. Im just trying to find an explanation for what happened.
So, its the former then.
But why then do also the fastest downloaders, who download way
faster than 100 kB/s get kicked off?
What happens if you, on your system set slot allocation to 100 kB/s?
(or 50 kB/s or 25 kB/s)

[RRM]

Even when i set slot allocation to only 10 kB/s,
eventually all downloaders are eliminated.
Down to 7 kB/s seems to be a safe setting; that allows
full bandwith utilization.

[Stu Redman]

Like 1k/s it will result in 250 upload slots because that's the maximum number. 

[RRM]

But why then are all downloaders eliminated
when slot allocation is set at 10 kB/s or higher???

[RRM]

And why does the "waited" time (aMule>uploads>waited)
very often include time not spend waiting but downloading?
(maximum of 3 secs in between re-allocation = "waited" for minutes/hours))

[Stu Redman]

I'm transferring now an 8GB file from my Windows client to my Linux client (in my Virtual box VM). Speed is 500-700 k/s, which is disappointing. I'll set up a transfer between two real machines for comparison.
What I noted:
- Speed is much worse with upload speed == 0 , so better set a real value
- Currently it's transferred 2.9 GB, all on the same slot.
- Current SVN will crash with memory exhaustion when it will reach 4GB, fix is on the way. Problem was introduced when we changed the upload queue so clients don't get disconnected unless necessary. Your memory crashes were there before the change was introduced IIRC, so I don't think that's the problem.
Hey, I thought this text was lost when DumbFox just crashed - but it could restore it.  

I'll run more tests.

Edit:
Hey, the Waited is screwed. I just paused/resumed my download, and on the uploading client it says "Waited 2:17 hours".

[btkaos]

Hey, the Waited is screwed. I just paused/resumed my download, and on the uploading client it says "Waited 2:17 hours".

Good job, Stu. There's clearly a bug here, let's hope it can be fixed.

BTW, what is your setup for reproducing?

[Stu Redman]

"Waited" should be fixed in 9862.
I did several slight changes/fixes in the upload so please retry SVN 9866.

Current SVN will crash with memory exhaustion when it will reach 4GB

That was overly pessimistic - the payload counter overflowed, but it still can't prepare more than asked for. Raised it to 64 bit though (it gets displayed after all).

Setup is simple. Upload limit to something sensible, NOT zero. I couldn't test slot behavior having only one downloading client. But upload speed doesn't get limited to the slot allocation speed, so much is sure. And my client gets upload tirelessly, without disconnect/requeue even.

[Stu Redman]

BTW, what is your setup for reproducing?

Well - I'd suggest a bed... 

[GonoszTopi]

ROFL

[RRM]

Wow... Impressing and interesting!  

Upload limit to something sensible, NOT zero.

Ok. I'll set upload limit to 3000 kB/s again.

As some of my upload files have become increasingly popular again,
aMule has started crashing again; i experienced 3 crashes in the last 5 days.
So, I falsely attributed the absence of crashes to setting no connection limit.
aMule simply crashes when it gets too busy, so that eliminating popular files
previously solved the issue of crashes.

my client gets upload tirelessly, without disconnect/requeue even

Yes, i regularly (continuously for a day or more) experienced that in the past,
(all my clients got upload tirelessly, without disconnect/requeue)
but this has not happened for over half a year now.
Maybe this only happens in certain conditions; for example: when the (remaining) download capacity of all
clients combined is smaller than my total upload capacity. (im just wildly speculating, of course)

I did several slight changes/fixes in the upload so please retry SVN 9866

Thank you.
Currently im using the Ubuntu 9.10 (Karmic Koala) distro's aMule 2.2.6
Can i still start using the SVN 9866?

[RRM]

Hey, the Waited is screwed. I just paused/resumed my download, and on the uploading client it says "Waited 2:17 hours".

Yes, the 2:17 is the time you previously spend downloading (at least in my case it is)