Archived

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

Firon

µTorrent 1.9 alpha 15380

Recommended Posts

Will uTorrent 1.9 support DEP (Data Execution Prevention) and "Excepcion Handling Protection" security features (Windows XP SP2 / Windows Vista / Windows 7)?

Next eMule (dunno if i can say this here, sorry ...) version will support both security features.

Share this post


Link to post
Share on other sites
Stan: If your firewall is eating all your CPU, then your firewall has a bug.

Earlier builds had a CPU usage problem where utorrent.exe itself ate all the CPU, though.

Nope Firon, I have tried with serveral firewalls (Outpost, Comodo, Windows Firewall, Zonealarm, etc) and I have this CPU usage when the connection is between uTP. Nothing happend when the connection is TCP. I have a p4 at 1.7GHz and the CPU is almost 100% all the time when is connected to a uTP swarm, doesnt matters which firewall is.

Share this post


Link to post
Share on other sites

uTorrent 1.9 alpha 14470 is working good here. No high cpu, no high memory, same speed as 1.8.2 but not hogging my internet connection...

and the best of all ... is working in Windows 7.

Good job utorrent developers :)

Share this post


Link to post
Share on other sites

I've been using 1.9 with exclusivly uTP for a while now. *Helps beat name withheld's throttling* I have not seen too many problems with net.calc_overhead on, the only weird this is I have my upload throttled to 28 kB/sec but the client maxes out at 25.9/26 kB/sec although my little bandwidth meter shows its at 28 - 30. It seems the client is throttling it properly but not displaying the correct value? IF you'd like more information I will be happy to provide it for you.

I'm not sure of this but does anyone know if Linksys routers (WRT54GS) have troubles with UDP traffic? It seems that every so often it has trouble with it, but it wasn't there when I was using 1.8.1.

Also, question, what is Hole Punching and what is it used for?

Share this post


Link to post
Share on other sites

Ok I've got some bit of detail since my last post.

(I'm talking about uploading..)

It seems when I make a new connection to someone the speed bursts to 300kB/sec or higher.

Then over the next 5-30 seconds it slows down to a crippled speed.

Then after roughly 30 seconds it shoots back to 300kB/sec+ again. And then dropping again. This process repeats itself...

I've noted that build 13911 works better than 14470 though. As in I'm getting higher and a bit more stable upload speeds that the newer build. But the same effect still resides.

Share this post


Link to post
Share on other sites

works great, except for the fact that even when i create a torrent, the upload speed is 30, but down speed is something around 5.

since the torrent has been created by me, i already have the whole file, so i don't get why it says something is being downloaded. in the speed tab, too there is a green line below the red one, so that still shows something is being downloaded.

great job with utp, though! ;)

Share this post


Link to post
Share on other sites

Probably protocol overhead. uTP indeed seems to generate a bit more overhead than plain old TCP -- the devs are aware, and are (AFAIK) working on it.

Share this post


Link to post
Share on other sites
calc_overhead=off will 'adjust' this... it probably shows net data, w/o the overhead

Your saying to turn it off? I have it on so it calculates the protocol overhead, but it seems to be missing some?

Without it, the throttling doesn't work well and my upload is killed (maxed) which takes down every Internet related activity and slows the downloads to a crawl. :(

Share this post


Link to post
Share on other sites

No I don't say to turn it off. leave it on, it's doing it's job. I say that they chose to display only the data (w/o overhead). that's all... and trying to turn it off and look at the speed graph should show that.

Share this post


Link to post
Share on other sites

rafi:

"BTW - why don't you just tell us, how may torrents are you running concurrently ? and what's you max # of connections setup ? let me guess, you have 400 active torrents , and 350 max global connections ... "

I told. In the other thread @ first post... I would seed about 950 torrents. The setup in 1.9 was the same as in older clients; acitve torrents: 250, active seed: 140, with this the client downloaded only forced, but seeded every torrent. And this was a good setup for me. In 1.9 uTs it downloaded and seeded only forced ones (with same settings!). I changed these numbers to ~2000 each, and it didn't solved my problem.

Is it clear now? I can't tell you this better even if I die with it. :D :/

Share this post


Link to post
Share on other sites

@hunt3r: I have DEP on the whole time and don't have any problems. Most things work fine with it now.

Share this post


Link to post
Share on other sites

@Neronut: Holepunching is the feature where a non-NATed peer can introduce two NATed peers to each other, via PEX, and act a rendezvous server to make the NATed peer connect directly to each other. This only works with uTP, because doing holepunching with UDP is much simpler than with TCP. This feature might speed up swarms with lots of NATed peers.

Share this post


Link to post
Share on other sites

@ arvid: Would it be possible to do for one (A) to do holepunching without a thirdparty , by spoofing the IP of a thirdparty © that you know most likely already have an established connection to the party you wish to contact (B) , and sending them a packet containing your real IP ?

F.x say we know B probably has a hole through his NAT to talk with his DNS server or the tracker or any other IP we know or can guesstimate B is talking to.

A (sends packet using C's spoofed IP containing real IP as payload) -> A's NAT (opens hole to B) -> B's NAT (through open hole for C) -> B (recognises special packet containing request to contact A)

B -> B's NAT (opens hole to A) -> A's NAT (through previously opened hole) -> A

Share this post


Link to post
Share on other sites

I'm using the current Alpha 14470 and when I go to open it today it is having some issues. First it slows Explorer down to a crawl and when trying to use the Task Manager to crash it no luck, it freezes and then when it comes back the CPU usage slowly goes up to 100% then it finally kills it. Even just clicking on it takes Explorer for a ride.

I'm using Vista SP1 2 GB RAM - if that helps

Odd - I think maybe rebooting will help - will update.

Edit: I decided to leave it and Explorer completely froze and then µTorrent started up - with Explorer still frozen, the after a bit more it came back to life. Weird.

Share this post


Link to post
Share on other sites

I had such symptoms too (explorer freezing, using Maxthon, with IE engine, XP SP2, Kerio) . It sometimes unfreezes after a minute or so, some other times - not (or I don't have enough patience to wait). No idea if it's uT related.

Share this post


Link to post
Share on other sites

bug report: i'm using build 14470, and upon seeding, the download speed is still averaging a few kB/s. on the speed tab, download speed shows up too, but on the general tab, it shows that something is being downloaded, but that nothing has actually been downloaded (see image below).

proofjr5.jpg

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.