Print

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

[myth]

In Italy cable doesn't even exist! :S

[RRM]

At least some people in Spain (of the eMuleteca HDGroup) have the same bandwith;
they uploaded to me with speeds of over 1MB / s (each!), and vice versa.
Ive also met a few very fast russians...

[btkaos]

At least some people in Spain (of the eMuleteca HDGroup) have the same bandwith;
they uploaded to me with speeds of over 1MB / s (each!), and vice versa.
Ive also met a few very fast russians...

Hey RRM, how is your problem with aMule going?

I tried to reproduce it, but unfortunately I don't have available ATM such a bandwidth. Also I tried to add debug hooks to the internal structure, but it is too messy ATM to be realiable.

[RRM]

Heeey Bill, nice to 'see' you.
Unfortunately, the crashing / freezing issue is still the same (about once a day)
, regardless of versions (currently a fresh Jaunty and 2.2.5) and configurations.

Also I tried to add debug hooks to the internal structure, but it is too messy ATM to be realiable.

Thank you for trying. You think it isnt worth a shot to try it out on my system?
Or how about a little program that restarts aMule every time it crashes?
(When aMule crashes while im at work, i cannot restart it manually,
which means no uploading at all, and thats a waste of bandwidth, no?)

[RRM]

Wow...  
By accident i found a solution for my issue with aMule crashing daily (due to overload).
Until now, i always tried to prevent overload by restricting the max number of connections,
so that i could still utilize my total upload capacity (i dont want to restrict that).
When I replaced some of my most popular files for uploading with newer versions
(containing audio in extra languages), i stopped restricting the maximum number of
connections (because there was less demand for a slot anyway).
And since i never reached the max connection limit anymore, aMule doesnt crash anymore!!!

Apparently, keeping the number of connections below a certain level is (almost) as much a strain
on the system as allowing more connections. (in as much as putting a download on pause doesnt
seem to help either; somehow its potential activity is still being processed, though not actualized)
To me this makes sense, as continuously refusing those extra slots means that they still need to
be 'processed' (as in 'analyzed' / 'counted' and 'refused'), and still are "connections" in some way.
So, when there is simply less demand for a slot, the load is smaller than when extra slots need to
be refused (on top of that same number of slots).

How to reduce the demand for slots?
Not in the "preferences" section, but by keeping all the rare files and deleting one or more
of the most popular shared file(s); as many as required to adequately reduce the demand for slots.

AMule used to crash daily (at least once a day), but since the reduction in demand for slots,
aMule does not crash anymore, despite the fact that both the average upload rate and the
number of actual slots are higher than before...  
Only because aMule no longer has to deal with any extra demand for slots...  

'The bouncher can sit on his ass now, because he no longer has to make people wait;
he just lets everybody in, so that there is never a line at the door,
whereas its always very busy but yet never too crowded inside'.

[RRM]

woohaa!!!
It really works... aMule has still not crashed
and it has been 5 days and 3.48 hours now...  
No  more glib warnings etc; nothing...

[Stu Redman]

Sorry, I'm not fully getting you. 
You have an upload bandwidth set and a slot allocation. So while there is demand, number of slots is bandwidth/slot allocation.
If there's less demand (queue empty), there are less slots and they get more bandwidth each.
So, your point is, you now have more slots with less bandwidth each and that's what prevents the crashes?

[RRM]

Well, actually, my queue is (and was) almost always empty ("clients on queue"=0);
only when someone has downloaded the 10MB, he may go into the queue
for a second, before reappearing in the list of current downloaders.
And yet, there are always plenty of downloaders that have waited several minutes or
several hours before they were allocated a slot.
So, there are no people waiting, and yet they wait for minutes / hours???

So, your point is, you now have more slots with less bandwidth each and that's what prevents the crashes?

No, they each get about the same bandwidth as before; more slots + more bandwidth.
However, they dont wait that long anymore; id say their waiting time has reduced by 50 to 75%
("waited" in my uploads list)
So, the queue that is supposed to have never been there ("clients on queue"=0)
is much smaller now (individual waiting times have reduced drastically), coz i deleted
a few popular shared files. 
What prevents the crashes, in my view, is that the system has to deal with less clients waiting.

[RRM]

You have an upload bandwidth set

I have not set a limit to that; its only limited by how much bandwidth is available
(for example: more bandwidth available in the middle of the night)

The reason why both bandwidth and slots have increased (not much, btw) is because aMule is
much more stable now; number of connections, uploads and downloads used to go up and down
like crazy all the time, because of 'small freezings' (a big freezing usually led to a crash).
So that now i can finally utilize the bandwidth available due to a lack of such 'corrections'.

[Stu Redman]

What's your setting for slot allocation? Also 0 ?

[RRM]

What's your setting for slot allocation? Also 0 ?

Ehrr, no... Thats not possible somehow.
Mine is set at 1 kB/s.

[GonoszTopi]

Thats not possible somehow.

That's intentional.

Mine is set at 1 kB/s.

If you can reliably upload at high speeds I'd suggest setting it to some higher value (10k, 100k, 1M, something). If you're uploading at 2MB/s you actually might be uploading to 2048 clients simultaneously, at 1kB/s each.

[btkaos]

Mine is set at 1 kB/s.

If you can reliably upload at high speeds I'd suggest setting it to some higher value (10k, 100k, 1M, something). If you're uploading at 2MB/s you actually might be uploading to 2048 clients simultaneously, at 1kB/s each.

Does this setting make sense when you don't have an upload limit? (like in RRM case)

Regards

[GonoszTopi]

Yes, it does. In this case the maximum number of slots is determined from the upload speed, not from the upload limit.

[RRM]

In this case the maximum number of slots is determined from the upload speed, not from the upload limit.

But it is still determined by aMule, who needs to select the candidate downloaders.
The only difference is that the downloaders are selected on different paramters. No?
When aMule has to do that selecting, my system crashes daily.
When the demand (number of candidates)  is simply reduced (by deleting popular files for uploading),
the system does not crash, even though actual number of slots and total uploading is not reduced.