Greg Hazel

Established Members
  • Content Count

    725
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Greg Hazel

  • Rank
    BitTorrent Developer
  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. No problems here either. But
  14. 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.
  15. nt.calc_overhead is disabled by default currently, because it needs more work. Please be patient.