Jump to content

rafi

Established Members
  • Posts

    8,960
  • Joined

  • Last visited

  • Days Won

    148

Everything posted by rafi

  1. As I remember, with calc_overhead = true, uT is showing the actual-net data traffic rate. The limits you set - do include the overhead. Any external tool that you use to measure the traffic, will show the total traffic, that equals to those limits you've set, and NOT to the actual rate uT displays. edit: As far as I can see - in this version the actual (external) rate measurement exceeds the limit we set in uT (at least for upload) . This should be investigated. ( Measured with - http://www.softpedia.com/get/Network-Tools/Bandwidth-Tools/NetMeter.shtml )
  2. "poor" ? it's ~5-10% less in average and reaches close to the max in peeks.... Increasing of the # of upload slots per torrent might smooth it...
  3. "added on" time for RSS downloads does not show the local time (that the torrent was started) but the time it was originally added to the RSS feed. I think it should have been like a regular torrent - show the time you added it as a DL tasks. Wasn't it like that on previous releases ?
  4. try unchecking pref->bittorrent->enable-local-peer-discovery
  5. I just noticed that on tabs like the peers, trackers, files - right-click BELLOW the items' list - still pops up with the menu, unlike the behavior in the main view (no menu pops up unless you are selecting/ON an item). Shouldn't it behave the same ?
  6. check if your net.calc_overhead is set to - "true"
  7. more or less data - you mean inside a single packet ?
  8. ping times? really ? how ? Here we have the following : * average ping time to most peers - 100-200 msec (overseas, in a good day...) * when the ISP is overloaded internationally - it can easily reach 300-400 * to local pears (<3-5% of the total ) have ~20-50 msec I expect that in the US - you will have ~50/50% peers with ~50/100 msec. How will the uTP behave in both cases ?
  9. TCP (5) vs uTP (255) . UL seems to behave better in TCP as well as the DL speed ... (10(40)/25(120) peers torrent) http://img239.imageshack.us/my.php?image=62357186wb7.jpg
  10. look at the first post : Preferences > Advanced, set bt.transp_disposition - 5 though I doubt it will behave exactly the same...
  11. well I guess I remembered wrong, I thought it was a bug. Anyway - the idea was to make it "standard" like in M$ explorer - showing the file name when deleting a single file OR a more general message "are you sure you want to delete those X torrents?". So dialog size shouldn't be a problem.
  12. Just noticed that in the "remove and delete" confirmation dialog - the name of the torrent(s) be deleted - is not listed . Wasn't it there a version ago ? ... maybe not. Well it should be - so people will be aware of what exactly they are going to delete...
  13. A note to the new icons re-appeared in the RSS release list - I would add another one - reflecting the release as a "favorite" (one of the filter's results). It used to be in the RSS down-loader which we 'borrowed' the icons from... ( I forget it's name... )
  14. looks like implementation of #2 in my 'todo list' here - http://forum.utorrent.com/viewtopic.php?pid=352646#p352646. It's enabled in RSS downloads that have the torrent source URL attached in them. I think there is a typo in the change log - not mentioning RSS in this feature. looks like they are progressing nicely in this todo list ... edit: maybe uT can reflect that fact of DL being a result of an RSS feed-link/url by special icons - such as the completed, paused, downloading, uploading - all marked with some orange/white arc at one of the corners.
  15. Oh... k , though it looks like the selection is gone in the cat list....
  16. what about this bug I've reported with the RSS releases view being cleared up when DLing some releases ? ... rss1.swf - 1.17MB
  17. Just an impression I'm getting from the latest releases - I have a feeling that finding & keeping good peers also in cases of poor p/s ratio is faster here, and speed is also building up nice and fast (I not using PEX...). Still, I need to get some more experience with it but it looks/feels much improved and stable. Any to my favorite feature - RSS - it was great to see progress in this last build. Keep up the good work Richard ! and be brave and do the #18 item in my list here ... http://forum.utorrent.com/viewtopic.php?pid=352646#p352646 that is turning greener and greener ! Have a marry Christmas / Hanuka all !
  18. 200/20KB or 300/30 are typical connections where I live. PEX is now on by default, I think. That's why I suggested the possibility to have a setup/limit for the # of peers for PEX (maybe in the same menu we have the 'enable' for it today). It's better then disabling it altogether. I would also make it so it is auto-set in the 'speed guide' menu where you define your upload. A proper value would probably be around 50 for every 20K upload (and maybe default to 100) . Staggering was also considered as a solution but it seems not to work very well, maybe since the peers' list is changing and it's not so practical/easy to keep track. Though, this # can also be used for Staggering ... Edit: Another user option can be to auto-activate PEX ONLY in torrents that connects with below a user defined # of peers or below some global total # of connected peers.
  19. I'm not saying it's not accurate, just that it has some error... like a + instead of a - ... just kidding... the bottom line - it's overshooting the limit . Just set to a low limit (~12K) use netmeter and see for yourself. how about the user max PEXed peers setup ? can you add it in ? look at the 3rd graph here: http://forum.utorrent.com/viewtopic.php?pid=383827#p383827 edit: the problem can be unrelated directly to the UDP OH , but to the way it's taken into account in comparing to the speed-graph/limit
  20. Since TCP is now partly replaced with UDP - overhead might even be reduced, and the overhead calculation/reduction should easily account for more peers. As I see it there are two things to try an do (to adjust the overshoot): A. Find the problem in the math/calculation of overhead for UDP peers B. Attend to the PEX issue - by simply give an advanced control-setup to the MAX # of PEX peers the user like to involve. Since we can eliminate PEX altogether (as I do now...) I don't see any harm in this.
  21. 250 is not many, and it should handle them well. PEXing is the issue...
  22. demo of the issue with RSS releases view disapearing when you click download and then loosing focus on "all feeds" ... : http://www.mediafire.com/?mkmdnryzwwg
  23. hmm... I'll need to re-install it. I'll try here you go (capture + screen shot): http://www.zshare.net/download/53075624ce6b22ca/ Edit: .. and my conclusions: w/o PEX: * with "5" - TCP only - it behaves well. under the UL limit and does not exceed the limit much also on netmeter (~1K) http://img523.imageshack.us/my.php?image=tcp20081221220136hi3.jpg * with "10" - uTP only - speed oscillate a bit more around the limit, and gets 2-4K more on netmeter (@130K DL). Some math adjustments - might help. http://img49.imageshack.us/my.php?image=utp20081221220610ao0.jpg putting PEX on: in my case of low UL in my connection (22K) - it definitely kills the speed (@ 250 peers) when peeking the netmeter UL to this limit and cutting off the DL speed. http://img244.imageshack.us/my.php?image=pexutp20081221221913od9.jpg FYI
  24. Still, a problem with the Upload limiter. it seems it is unstable , and deviates much from the set value. In my case - I set it to 12K (out of the poor 22K I have...). With two torrents and about 250 connected peers , I measure it externally, it's low values starting at about 15-16K and it deviates from time to time to 19-22K . It seems it's not flat/stable enough and can sill slow down the other Internet activities. Also The overhear can be tuned a bit higher.
×
×
  • Create New...