Jump to content

kurahashi

Established Members
  • Posts

    386
  • Joined

  • Last visited

Posts posted by kurahashi

  1. I was keeping an eye on uTorrent yesterday, and now I'm almost 100% sure: it's a bug related to uTP.

    When in seeding mode (let me remind, I'm using unlimited upload rate, no auto) with no active uTP connection everything works just fine...

    ...but when uTP connection becomes active (upload begins) then suddenly all other (TCP ones) are capped to the actual speed of that uTP connection.

    So if the uTP connection transfer manages to get 2kB/s only, all others are getting 2kB/s max (per TCP connection) - no wonder my upload can't be used fully then.

    If uTP connection dies (or become inactive) then limits on TCP connections are lifted and transfer is ok again.

  2. Having 100 or more connections per torrent didn't prevent 1.8.2 from working correctly (BTW I'm not connected through any router, only direct fast ethernet uplink)

    And when I download (not only seed as in the example above) the number of connections is more or less the same, yet somehow it doesn't choke upload then. You can see part of the correct download/upload graph here http://h.imagehost.org/view/0239/30sec on the left. Actually upload wavers twice there (when first two files finished downloading and went into seeding mode), still it come back correctly, but when third file also finished download and there was nothing more to do except seeding them - problems with upload began.

  3. After upgrading to 1.8.3 I have the feeling that something is not working exactly as it should:

    30sec.jpg

    5sec.jpg

    1sec.jpg

    This happened few times actually... the problems with utilizing whole available seem to appear in seeding mode only.

    The speed settings are pretty much defaults for my upload (2Mbit), except one thing - I'm using unlimited global upload rate (zero) with automatic turned off (just in case: yes, my ISP does the queuing thank you, and yes, I have a good reason to keep my upload unlimited instead restrain it"properly" at ca 180kB/s)

    Anyway, I didn't have such problems at 1.8.2.

    Any ideas?

  4. i guess my ISP isnt smart enough to filter my p2p traffic now.

    ...what is most probably temporary, but enjoy it while you can :)

    Hm, in fact it's not so stupid - as providers usually don't bother with new encryption/protocols in alphas/betas so... dear devs, just take your time with 1.9 development :)

  5. @moogly - have tried it already, no result

    I'd like to add that I was using (and testing) all the 1.8 betas and auto-updating was working fine

    I can suspect the problem is connected with the fact that I still use 12616 build, while Ultima have 12639 one.

    But if that is the case, why my utorrent never updated to 12639?

    Enough is enough, I'm downloading 1.8.2 manually. I'm hoping only there won't be any problems with auto-uptade later again.

  6. I don't see it worthwhile to go to any great trouble to find local peers or same ISP peers (which often aren't really "local" topology-wise)

    Being one of the user of such (i.e giving extra local transfers) ISP I can only confirm that.

    My ISP and many other local ISP's are connected here to the MAN backbone, having total thousands of users and "free" (unlimited) transfers between them but it's impossible to discover and categorize them as "local" automatically - because all the "local" IPs do not belong to the same IP (sub)ranges, they do not belong to the same name (sub)domains neither.

    If there is something could be done, then it's implementing manual possibility of adding IP ranges utorrent should classify as "local" - that is trying to connect them as first and making the upload to them unlimited (most prefferably in similar way as we can declare banned IP ranges today). Of course where we get these ranges from is another problem, but that's something user would have to worry about. True, ISPs do not publicize their IP ranges (or "free" transfer ranges) even if they exist but is there any reason to do so today? It may change however if utorrent adds such support of local peers list.

  7. Can anybody tell me, why we are still keeping this xx/number formula, which is absolutely not understandable for the noobs anyway? Everybody forgot their posts with plea for help with their speed, where one after another were happily selecting their download speed (not paying any attention for some kind of "stupid xx" before)?

    I suggest changing it for (for example):

    dial 56kbit

    64kbit upload

    96kbit upload

    128kbit upload

    192kbit upload

    etc.

    where word "upload" should be bolded, red coloured and with font 150% (at least) size larger than the rest. Or maybe we should even consider whole "upload, NOT DOWNLOAD!" sentence. Ah, and why it's written 1mbit, but 64k? Bit suffix should be added everywhere, it's not only a consequence matter, it does give some extra chance for newbies not to confuse bits with bytes.

  8. Well as far as I know (and someone please correct me if I'm wrong) if the people in your LAN all have public IPs utorrent won't recognise them as local using that method

    Why? The difference between LAN and WAN is not about the IPs hosts are using (private or public) but the media they are connected. In my case (of this 'outer' LAN) all hosts are connected by fast ethernet and switch, the direct transfers between us reach 100Mbit/s, therefore it's LAN. Doesn't matter they have public IPs.

    And your router will probably NOT send the Multicast packets over its WAN ethernet port (which is what you use to connect to the rest of your LAN).

    To be precise, my router is a linux machine with two ethernet cards aboard. But I agree, it will not route over the multicast packets...unless I reconfigure its routing policies. But how? And is it possible, anyway? I admit, I never had anything to do with multicast earlier so I'm kinda newb here. Going reading about multicast - thank you very much for great advice, almost as good as saying to someone who don't understand how to setup correct port forwarding "go learn about TCP/IP protocol" :(

    You'd need a feature that has been talked about in various topics but afaik never requested in the Feature Request forum that allows you to manually define a certain public IP range as local

    Yes, this would be certainly helpful, but I think I saw it already requested and rejected.

  9. @ultima - maybe I didn't make myself clear enough.

    Once again - I'm in LAN. Every user of it got one public IP. Me too. But my public IP is used by my router, which is doing NAT for my own, personal mini-network using private addressing space.

    So, do you want to tell me utorrent will be smart enough to find and categorize all users of my real 'outer' LAN as local, or only it will do it in my small private 'inner' LAN area?

    Because personaly I suspect the latter - unless I don't reconfigure my router (which is doing the NAT). But to reconfigure it, I need to know exactly what to do.

  10. Not our fault. It joins the multicast network and does a broadcast to find peers. If your router prevents it from going far, that's your issue.

    Fair enough, but I'll ask once again: please give us the detailed specs of this :(

    I am in LAN but have a router at home, I have and an access to it, and I can configure it, but don't have a slightest idea WHAT'S NEED TO BE DONE :(

  11. I have a little question. How does local peer discovery work on uTorrent? I'm behind router with ip 192.168.*.* but router itself is connected to LAN with ip's from 10.120.*.*

    Will uTorrent find peers from LAN(10.120.*.* ones)?

    Most probably not. I have similar configuration, but since I've got an access to the first router I'd love to know all the local peer discovery specs and what new NAT rules to add which would allow local peer protocol to work in my outer LAN network.

  12. I have a question about local peer discovery. Can I have its specification? My connection is NATed on the linux based machine and I'd like to know what should I add to my iptables rules to allow local peer discovery to work outside the NAT.

  13. @Ryan Norton

    Thanks for the help with the registry mess. I'm ashamed I didn't check it by myself, my only defense is the fact the same thing happened with some earlier beta, but it was gone with the next release so I thought it would be the same this time... ehm, nevermind.

    Nevertheless, the second problem (incorrect µ symbol in the utorrent's name in peers tab) remains.

    I'm using windows 2000 pro, with japanese fonts installed and set as default in my regional settings. And yes, if I set english localization as default, everything is fine. Unfortunately this is not an option for me.

    Well, it's not a big deal after all, because it does not affect functionality of the software, but still it would be nice to see some µTorrent peers instead of an "oTorrent" ones (オTorrent) :) ...especially remembering the 1.6 was working perfectly fine in this matter.

×
×
  • Create New...