tulient Posted February 26, 2006 Report Posted February 26, 2006 Just recently I am having this issue where the computer running torrents slows network speed on that computer only to an inusable rate. However, torrent speeds are not effected at all. I am trying to figure out what is causing this, and it may or may not be utorrent, however the only thing this computer does is download torrents. This can be fixed by restarting of course, but that is not a good solution. I was using 1.4.2 beta 428 when I noticed this first, and went back to 1.4. The issue was still occuring so I just went back to 1.2 which I have been using without problem for ages. I will post tomorrow to see whether using the different version changed anything, as it takes around 8 hours for the slowdown to be noticable. If this doesnt change anything I suppose the next step would be to see if I get a slowdown with no torrenting.. but I doubt that would be the case. This is a newly formatted machine and I dont load it up with useless crap. If it is, then obviously the problem is with the computer (which has recently undergone some hardware changes).
Firon Posted February 26, 2006 Report Posted February 26, 2006 Have you patched TCPIP.sys?If you have patched it to 100, and haven't altered net.max_halfopen, try turning off DHT in beta 428.What router/modem do you have?
tulient Posted February 26, 2006 Author Report Posted February 26, 2006 As I expected, going back to utorrent 1.2 has solved my problem. I am using a DI-542 router and a WebSTAR DPC2100 modem. I must say that hardware is not the issue as I have been able to torrent for months at a time with no issues. I have never patched TCPIP.sys and unless versions after 1.2 have some radical change in the connection process, I shouldnt have to.Some notes...Stopping torrents and closing utorrent had no effect on fixing the slowdown issue. This either means that the number of connections are not the issue or that the connections are not closed upon stopping and terminating utorrent. I did not flush the tcpip stack however..unless that is done along repairing the connection which I did try. No effect. By the way, the slowdown concerns network use only. The computer is smooth as can be as long as the command is not network related.I am not sure how windows handles the connections, but even local network traffic with the computer was grinded to a minimum when this issue occurred. However, I am currently running xp pro with no service pack so the limited connection issue with tcpip is not the problem as the connections are not limited in that version.Because changing to version 1.2 fixed the problem, the only thing I can reasonably conclude is that the newer version is the source. The only thing I am unsure about is the fact that nothing is fixed by stopping the torrents and closing utorrent does nothing to fix the problem.
tulient Posted February 26, 2006 Author Report Posted February 26, 2006 I will try it, but you know.. disabling a well used feature is not a solution.
Firon Posted February 26, 2006 Report Posted February 26, 2006 Didn't 1.2 not have DHT? That really just might be the reason why.edit: hmm, no, it had it. Just try the TCPIP.sys patch and use beta 428, without turning off DHT. See if it helps.
1c3d0g Posted February 26, 2006 Report Posted February 26, 2006 That's because your modem/router probably can't handle DHT, that's why Firon asked you to turn it off. In short, it's not a µTorrent problem but a problem with your equipment...as it obviously works fine here without having to turn off DHT. :/
tulient Posted February 26, 2006 Author Report Posted February 26, 2006 Looks pretty clear that i see a 'enable dht' option in version 1.2. Besides, I have used DHT before with utorrent and other clients, with no issues.Edit : There is no reason to apply the TCPIP patch if you dont have sp2, so theres no reason for me to do it. Only SP2 limits the number of outgoing connection attempts...
Ultima Posted February 26, 2006 Report Posted February 26, 2006 It may be a well-used feature, but if it kills your connection, it's not such a good feature for you, when ALL your connection becomes useless, right? It's better to disable it if it's causing you problems. I disabled mine for the very same reason, and my net connection's flying even while I use µTorrent.DHT is more useful when you're on a dying torrent, so unless you download a lot of those, then you'll be fine without DHT. Even then, you can temporarily enable DHT, get some peers into µTorrent's peer cache, and then disable DHT. That's what I do, and it works just fine ;P
Firon Posted February 26, 2006 Report Posted February 26, 2006 Oh, and when you switch to beta 428 and run the patch and reboot, try clearing your settings.Go to %AppData%\uTorrent and delete settings.dat and settings.dat.old (with µTorrent closed)
tulient Posted February 26, 2006 Author Report Posted February 26, 2006 Version 1.2 has dht. My client at version 1.2 has dht enabled. My client at version 1.2 works.DHT is not the issue.My client at version 1.4 does not.Windows XP Pro SP2 limits the number of outgoing connection attempts. The TCPIP.sys patch unlimits the number of outgoing connection attempts.My operating system is not Windows Xp Pro sp2.My operating system does not need the patch.The number of connection attempts are not the issue.I installed 1.4.2 beta 428 after a complete format. My client at version 1.4.2 beta 428 did not work.
Firon Posted February 26, 2006 Report Posted February 26, 2006 And what happens if you turn off DHT on beta 428?
tulient Posted February 26, 2006 Author Report Posted February 26, 2006 This i am waiting on, as I have to let it go for a while before I can see a change.
tulient Posted February 28, 2006 Author Report Posted February 28, 2006 Well turning DHT off did nothing for me. I decided to swap network cards and that resolved the issue for all versions and all settings. However, I still am not sure why (using the old card) that version 1.2 works fine and later versions do not. Oh well.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.