Outline · [ Standard ] · Linear+ Could something be blocking the network??

The last week, I've been experiencing problems with my Mule....

Up until about 1 week ago, my Mule could run 2-4 days before it had to be restarted, but now it useually only runs for half an hour..

After this time, the CPU use increase to approx 50% (since it's a dual-CPU machine, this means that it uses almost 100% of one of the CPUs), up/download COMPLETELY stops, and eMule almost stops to respond (it does NOT go Not Responding in the title-line).. Overlaopping windows are not removed until maybe 1 minut has passed, and I have to wait a LONG time, when clicking inside eMule..

This has been "normal behaviour" after 2-4 days, but now it happens after 10-60 minutes...

I've decreased the number of downloads (it's down to 8 now), connections, max sources, but NOTHING has helped...

I've checked for virus, and found nothing...

Any suggestions??

I doubt that this has something to do with the network.

Do you run any software firewall, packet filters... ?

(somehow I get the impression that you have a pretty weird system, since zz´s upload system doesn´t work for you either )

I've been looking at the ZZupload... It seems to be active the first few minutes....

But no... I've even tried connecting to the internet without any kind of firewall etc...

Just to point it out...



This is what my upload queue looks like efter 6½ minutes...

Not much ZZUpload about that..

That's the kind of speed distribution I'd expect with ZZUpload. There's a well-known issue with the averaged upload speed display not matching the displayed speeds. Also, the top downloader might not be capable of receiving at the ~14kB/s that you'd expect if you allow ~20kB/s upload. I'm not sure ZZUpload is smart enough to redistribute the unused bandwidth amongst the others in the queue.

Lots clients are limiting there download speeds or cant achieve top download speeds. A normal client will attempt to slow down your downloads if you dont check the "unlimited downloads" checkbox.

ZZUL will send the data as fast as it can to the main slots (2 at the moment in your case), then it will send data to the next trickle slot until there is a certain amount of bandwidth left. The rest of the bandwidth will be then filled with trickle slots running at about 0.5k/sec. If one of the n clients starts to download faster this will take bandwidth away from the other clients/trickle slots will be moved back to the head of your queue. Clients Can move in both directions between main slots to trickle slots and both directions between trickleslots and the top of the queue.

In sysonpsis when a client enters your upload queue, he will start slowly and perhaps be stopped a few times, then his speed will start to increase until it is in the top trickle slot and his speed will be increased (but not to its maximum). Finally the client makes it to a main slot and will download as fast as it can, until it has transfered a complete part or there was a disconnection problem.

This post has been edited by moosetea: Nov 12 2003, 16:32

check if your internal memory is running like it should, these sudden problems are among the ones I have had with bad ram.. OR delete the known.met, then it has to rehash... because sometimes a file just wont hash with the current known.met..

My memory is fine... Using 216 MB of 512 installed..

My memory is fine... Using 216 MB of 512 installed..

I meant it could be broken, sounds strange but it's possible.. it usually shows in crashing programs or strangely running programs, strange problems and the likes.. not really a stopping machine as you would expect.

unless u've got ECC-ram, then u definately got it crash

had a friends machine in for a service checkup and springclean once .. The damn thing would under NO circumstances boot propper... Then I pulled out som Ram modules and the MoFo worked again..

Damaged Ram is a strange and silent bug in your system.

JB