Jump to content

speed crashes on server... way 2 fix?


mishkin

Recommended Posts

like subject says speed often crashes on server when loading with rdp or even when brining up a ftp window etc... seems like it's not keeping the stuff cached or is getting wrote outa cache after closing rdp... cause if you keep it current / check back often it never happens

but yeah any little thing will set the down and upload to under 100KB/s from 5-10MB/s and then it willl slowly climb back and sometimes you need to pause them for a few secconds and resume for it to climb back...

pretty annoying...

Oh on a unreleated note, nice job with that disabling windows cache in 1.8 I love it!!

Link to comment
Share on other sites

This happens with multiple different servers at different datacenters... it's like a fact of high speed torrenting... just about anything that requires the tinyest bit of loading will cause speeds to crash

I wonder if you had a small drive for all programs and os and then anther drive(s) for the data files of torrents if loading things would cause crashes....

like loading firefox or flashfxp will cause speed crashes

Link to comment
Share on other sites

I went :P because as I try to ... keep OT commenting to a minimum here, heh... I envy you guys who have troubles at such fast speeds. I wish i had the $ or connections to try it. I do know that in 1.8 the developers were approached by a kind person willing to help with hardware resources to test such instances. I do not know if they made any changes to underlying code due to this testing however.

We're talking ~ 50% load on a GigE connection right? I know there have been threads since GigE premiered about speeds > 100Mbit speeds causing crashes due to the overload on the CPU.

Link to comment
Share on other sites

Well, if you're downloading at 5MiB/s, you're going to fill your cache VERY quickly, and naturally, µTorrent's going to have to contrinue writing out to disk quickly as well. If it needs to do that, and other applications use the disk simultaneously, it's likely going to hit some disk overload (as jewelisheaven pointed out earlier). The question is, do you see a "disk overloaded" message in the µTorrent status bar? What are your disk cache settings like?

Link to comment
Share on other sites

okay clarification:

1- I"m not talking utorrent crash, but a sudden drop in speeds which is slowly recovered from or a "speed crash"

2- I have the windows cache disabled and am running utorrent 1.8 so there is no disk overload

Also on windows it's almost impossible to max the up and down at once... but on linux servers it's easy

atm I have 3 torrent severs I"m using... 4TB us server, 2TB amsterdam, and a unmetered 40-60Mbit amsterdam :)

Link to comment
Share on other sites

... Even though your hosts may not mangle your connections, it doesn't mean the connected peers' ISPs dont. :/

If uT can sustain the down/up-load try limiting your connections more... On 40Mbit, DAYYUM, ok that translates to 50 peers running 100 KiBps, hmm. I don't know honestly if and it doesn't appear that there is any indication of more testing on fast servers is wanted/available. Since 1.8 is currently in feature-freeze I think the devs are trying to iron out existing bugs...

Regarding this speed-drop: is it rhythmic and repetitive? Does it happen on all torrents connected to all peers? Does it happen say between your two hosts in amsterdam? Trying to find out the CAUSE would definitely elucidate some sort of solution. I know this is echoed many times, but often one simply cannot eliminate the bottlenecks. It takes investigation to find WHICH is at fault though. Since you're running 1.8 it's safe to rule out Windows caching... so what happens with internal cacheing, if you change to the speed tab and switch to disk statistics mode do you see a correlation of the speed drops to a flush of the uT cache? What's your current cache setting? Does it still happen when increasing the cache size... and in correlation with data flushing to disk? It could also be due as i said to the peers losing connection... and this is harder to diagnose. The only way I know of is to wireshark or use other capturing methods to pinpoint what EXACTLY happens on the wire at the timecode you're looking for when speeds crash.

Per usual, I'm only giving out ideas. ;) I hope they help you.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...