Jump to content

Greg Hazel

Established Members
  • Posts

    725
  • Joined

  • Last visited

Everything posted by Greg Hazel

  1. 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!
  2. 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.
  3. 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.
  4. 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).
  5. 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.
  6. 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.
  7. I was referring to your red highlighting and bold formatting.
  8. 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.
  9. 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.
  10. So 17.5% is too high, but 9.5% is ok? Is 13.5% ok?
  11. Yes, those problems indicate issues with bt.tcp_rate_control, not uTP.
  12. uTP is quite stable, actually. Are you having problems? Have you tried disabling bt.tcp_rate_control?
  13. 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.
  14. nt.calc_overhead is disabled by default currently, because it needs more work. Please be patient.
  15. 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.
  16. 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.
  17. 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.
  18. "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.
  19. 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.
  20. 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.
  21. Can you post the wireshark capture that shows > 1500 byte packets? Also, is it easy to reproduce that?
  22. 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?
  23. Why not? CPU usage? Bandwidth usage? Harddrive usage? Is the file on your local harddrive?
×
×
  • Create New...