Harold
-
Posts
137 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by Harold
-
-
When I updated to 18069 a couple of random torrents that were stopped/finished were suddenly started without my consent, what is that all about?
-
Uhm... you called?
-
µT rules!
-
bt.tcp_rate_control seems to be a little extreme in its throttling (at default utp_target_delay of 100)
-
Normally strange speed problems don't happen to me, but my download speed isn't going above 200KB/s either (out of 2500KB/s max)
It wasn't a bad swarm - I got 1200KB/s when I downloaded it with Azureus to see the difference and I'm sure I would have gotten a speed like that with 1.8.2 if I hadn't been too lazy to download it.
By the way, setting all files to Do not download helped to get the speed up, specially upload (obviously you'd have to toggle it all the time or else the download will never finish)
That's strange but it had it really big effect..
-
Well I was still on the old 1.8.3 for a while - managed to get it up to 675MB without noticing
But then I accidentally looked at taskmanager for something else, and, well, updated µTorrent
-
Hey you guys forgot this one:
- Feature: statistics screen splits uTP and TCP connections
-
Well the pieces distribution in the swarm was "normal" - there were no sequential downloaders or people who were skipping files (single file torrent so..). The pieces availability thing looked quite even (no big parts that were obviously darker or lighter than others)
The behaviour: pieces were grouped together rather than evenly spread out. I mean, the average length of a downloaded (or 'not-downloaded', which followed the same strange pattern) 'part' (say, 5 to 20 pieces) was bigger than what would be statistically expected for the # of completed pieces.
A bit like this (attempt at ASCII drawing):
|_||||____|||___|_|||||_|||___|||||_____|||
-
Could just my imagination, but it seemed like piece selection has become slightly less random..
Less spread-out
It wasn't due to the pieces distribution in the swarm, it was fine.
So far it only happened on 2 downloads and somehow I doubt something like the random number generator would be changed unannounced and for seemingly no reason.
-
Many thanks, gritzko
It doesn't say very much, but it's something
But, seeing as the actual protocol seems to be secret (and rather hard to reverse-engineer, I don't expect to pull that off before the RFC is released, unless it really takes half a year or something), is there any idea when it might be ready? Of course I'm not expecting any promisses, but it'd be nice to have some kind of idea as to when it might be ready..
-
So is there any chance that 'interested parties' will be shown how the uTP protocol works before it's a full-blown IETF standard?
-
Could I have a link to the uTP specifications?
-
hunt3r: you could do that, the error is quite harmless if you're not using NAT though
-
If it's not local, then you have no reason to use UPnP
If it's not local, then there is no NAT, so no need to map any ports either
-
hunt3r, is that a question? Why did you X-out your local IP address?
In any case, it looks like your router does not support UPnP or it's disabled in its settings.
-
That would be a very good way to prevent the testers from finding bugs specific to private trackers (though that's probably rare)
-
> - Change: remove "Download Limited" behaviour
Why?
-
While I understand that it's bad to manually update trackers, you can not even do it with trackers that are offline(timed out) which I feel the urge to do when the tracker just Has to be online (but for some reason was late with its reply?)
(this is not a feature request, nor a question, it's merely a statement, confusing eh?)
µTorrent 2.0.2 released
in Announcements
Posted
It seems like uploading speeds are fluctuating more than they used to (µTP enabled)