Greg Hazel
-
Posts
725 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by Greg Hazel
-
-
- Fix: try to improve new upload choker
So, I guess that means - tried and failed...
Not so! We have seen many cases in which is was improved. Perhaps it needs to be improved further, but the recent changes did work.
-
Can you please fix this release so that the sent packet size will not change when net.utp_dynamic_packet_size = false and there is a set upload speed limit (as I see was the intention) ?
thanks
The behavior you are observing is a side-effect of limiting your rate when the underlying connection is very fast. This is not a bug with net.utp_dynamic_packet_size but an effect of our Nagle implementation: http://en.wikipedia.org/wiki/Nagle's_algorithm
This is *not* uTP "changing" the packet size. The same occurs with TCP if you have only written a small amount of data and the Nagle time limit (200ms on Windows) is exceeded. So if you're sending at <=7.5kB/s with TCP you will see less than full sized packets, (or higher if you have tuned Nagle like some articles tell you to http://smallvoid.com/article/winnt-nagle-algorithm.html ). You're sending (according to what you told me) at 20kB/s, which is not far off. Our Nagle target is different, because if uTP waited 200ms before sending an incomplete packet (including an ACK for data from the other direction) it would have not be able to react to delay on the order of 100ms, which is the latency target.
-
http://lh6.ggpht.com/_6IoA7yojDSI/S6s_yDiOIsI/AAAAAAAAASk/mOtEY2SaEIU/BEP22_bug.png
As you can see, I'm still having this bug with BEP22... It does not request PTR record and uses my NETBIOS name (Eliotbook) in SRV request instead...
Client was started with only one trackerless Torrent active...
What do you get when you run "nslookup" on your public IP? Are there any other peers on the local network or the same machine? Getting the NETBIOS name implies either uTorrent is not aware of the public IP (and is aware of a LAN IP), or reverse DNS for your public IP is somehow mis-configured (possibly on a local DNS server).
-
How is it possible to see the X flag [peer was included in peer lists obtained through Peer Exchange (PEX)] on a private torrent where Peer Exchange is "not allowed" ?
http://img534.imageshack.us/img534/4026/93222930.th.png
EDIT: None of the connected IPs for that torrent are IPv6 addresses.
Despite what Switeck claims, there is not a bug with IPv6.
What's going on here is peers communicate to each other what their IPv4 and IPv6 addresses are when they connect. This allows peers to try to reconnect to each other using a different protocol if for some reason the connection fails (i.e. is RST by some malicious third-party...)
uTorrent refers to the "source" of these addresses as PEX, even though they did not come from the PEX message itself, but from a peer about itself directly.
-
bt.tcp_rate_control was our attempt to slow down TCP based on the information we can learn from uTP connections. Where this fails is when the speed of uTP connections is tiny compared to the speed of the TCP connections we're limiting - in your case, the TCP connection is an ISP-level seed box, so there's no way normal uTP connections to other peers could go as fast.
We're working on improvements to this.
-
I was referring to your red highlighting and bold formatting.
-
The benefit is that you no longer need to set and upload rate limit in order to keep from overloading your internet connection. Anyone on the network can check email, browse the web, do whatever, and uTP will transfer as fast as possible without getting in the way.
-
You're mixing a few concepts. uTP was designed for minimizing congestion, while still maximizing throughput. It does add some overhead, which we'll work to reduce. The effective rate of throughput minus overhead (sometimes called "goodput") is slightly reduced as a result, but this is a small price to pay for a more responsive network.
We're working on lowering the overhead, but outside of rafi's scary-looking graphs, you shouldn't have any serious problems with it.
-
So 17.5% is too high, but 9.5% is ok? Is 13.5% ok?
-
Yes, those problems indicate issues with bt.tcp_rate_control, not uTP.
-
So the best of 2.0 is only udp tracker, I think utp is much more to fix. Look like stable utp will be 2.5.
Thank you.
uTP is quite stable, actually.
Are you having problems? Have you tried disabling bt.tcp_rate_control?
-
No problems here either. But
I think 2.0 is good manage but not good bandwidth. -
Could everyone with bandwidth problems try setting bt.tcp_rate_control to false and let us know if that helps? If not, you can set it back to true.
-
possibly wrong uTP overhead calculation (bt.transp_disposition = 10) :
(from IRC: <alus> _rafi_: that seems to be an overhead difference )
also - you should explain "0" value in the help file, since it's set to that by disabling "traffic management "
nt.calc_overhead is disabled by default currently, because it needs more work. Please be patient.
-
I believe that finding one's own public IP is a simple task by one of the many services available that uT can simply use (whatismyip etc) , at least optionally.
There's no benefit to this. Either you can successfully connect to yourself and the ban occurs, or you can not and uT slows down how often it retries, and attempts other peers instead. Either way the traffic is not going across the internet, so there is no interesting wasted bandwidth. Consider the alternative of refusing to connect to a peer who is also behind your public IP.
-
well, you are welcome, then, to review the capture+screenshot+log , and find out why there are still UDP messages there in-spite of the auto-ban.
I'm not saying the uTP issue is related to the previous poster, or even that it's uT related. It might be just bad luck not seeing multiple concurrent 2.0 peers actively uploaded-to. As I said, it can very well be my ISP... or not...
Just an observation FYI/review.
(capture is filtered by own IP)
I don't see a mention of the ban in your uT log. I also don't see a problem here. Wireshark says 192.168.2.3 is trying to communicate with 89.139.178.214 and it is not responding. So, it if can't connect to get the ID, it can't know that it is itself.
-
@Greg: "connecting to itself" ? why should it even try ? better keep it's own IP out of the peers list... if there are a quite a few torrents trying AND RE-TRYING to connect to themselves - it sounds like waist of bandwidth and might cause router issues/loops...
Regarding the other issue, I was trying to set transp_disposition to 10 or 26 (uTP) while having ONLY seeding tasks. I see some difficulty maintaining uTP connections for uploading. It feels like peers keep disconnecting before gaining speed.
I guess it can be caused by local issues, like my ISP messing up with them...
uTorrent is not always aware of it's own IP. Once it connects to itself and discovers it, it does ban that IP to prevent future re-connections. This works unless the router already has a bug where it rewrites looped packets. In either case it's rarely a waste of bandwidth since the packets never make it to the internet, and the attempt is too infrequent for it to be significant on a LAN.
Your uTP issues are unrelated to the post I commented on.
-
Oh my gosh - you released it without fixing the problem the two 2.0 versions (exact build) can't connect to each other ("UNKNOWN" torrent bug).
See here:
http://www.mediafire.com/?ynhumzyebhk
On the right side you can see the incomming connection in the Logger tab.
This one is also reproducable in my testenvironment (I have 12 test PCs under my controll).
"Incoming connection for a.b.c.d:p for torrent 'UNKNOWN'" is a bug, but only in the log message. It says "UNKNOWN" because it can not possible know which torrent the incoming connection is for yet. So, it's completely harmless. What you see there is one uTorrent client connecting to itself, seeing its own ID and disconnecting. Also completely harmless.
The only thing which is concerning to me are the log lines that say "Disconnect: Invalid header". Can you tell me more about 10.0.2.2:12345? The machine on the right seems to be 10.0.2.15, with one client running on 23224. What IP and port is the other client on? Is it on the same machine? What is 10.0.2.2 then?
If they are different machines, please disable encryption and capture the traffic with Wireshark and post it somewhere for us to look at.
-
The source is a bit of a misnomer. What this probably means is that you connected to a peer over their IPv4 address and in the handshake they told you their IPv6 address. For some reason the IPv4 connection was lost, but later uT was able to connect to their IPv6 address.
Nothing to worry about.
-
well, what about the opposite symptom - of only using small packets ... am I mistaken here as well ? ... or there is a logical explanation to this ?
uTP uses variable packet sizes. At low speeds the packet size is small, so that we have finer grain control over how much data is in transit (often only 1 packet). When there are more packets in flight at once, we increase the packet size to reduce overhead without losing much granularity.
-
its easy to reproduce, you just have to be stiff enough to write frame.len instead of ip.len. Sorry was looking at wrong number. biggest packets were 1492 (ppoe safe)
Haha, ok then
-
-My MTU is 1500, but somehow uTorrent kept trying to send 1506 bytes UDP packets. Most of those packets went to one specific peer. By most I mean my Utorrent send 500 1506 bytes UDP packets to one peer, 7 1506 bytes UDP packets to other and 3 to third one.
There were only 2 (two) packets in 1400-1500 range during that time. Im using wireshark filters for this :
udp && (ip.src== my.ip.is.here) && (frame.len > 1400) && (frame.len <1500)
Can you post the wireshark capture that shows > 1500 byte packets? Also, is it easy to reproduce that?
-
Secondly I, like others, see a definite loss of available bandwidth when using other programs requiring internet data.
Does that mean that other applications have less bandwidth available to them when uTorrent is running, or uTorrent has less bandwidth available when other programs are running?
-
first beta in a while that has given me issues.. this version seems to affect performance majorly.. can't barely watch a video with MPC.
Why not? CPU usage? Bandwidth usage? Harddrive usage? Is the file on your local harddrive?
µTorrent 2.2 released
in Announcements
Posted
For people experiencing choker problems. If you have time, you could generate a log to assist me in debugging that. That would be very helpful!
Enabling logging is a bit involved:
- Exit uTorrent
- Open settings.dat with Bencode Editor (
http://forum.utorrent.com/viewtopic.php?id=31306 )
- Delete the .fileguard key (while you're at it msg Firon and tell him to remove the .fileguard feature entirely)
- Add (or edit) the logger_mask key (make sure it's an "integer" type)
and set it to -1
- Save and exit Bencode Editor
- Run: uTorrent.exe /LOGFILE output.log
- Reproduce your speed problems
- Exit uTorrent
- Email / private message output.log to me ( do not post it online! )
Quite involved. If you need help with any of the steps above, don't hesitate to ask.
Thanks in advance for your help!