Jump to content

Ichpuchtli

Established Members
  • Posts

    43
  • Joined

  • Last visited

Everything posted by Ichpuchtli

  1. I'm tired. 2.1 crashes. 2.0 very unstable. 2.1 and 2.0 not allowed at private trackers, 1.8.5 has many bugs related to connections (I cannot connect to anyone after some time, 0 kB speed for awhile and then returns...) not solved for almost a month!!!! OK, uTP is wonderful, a light in the dark, it's like God's blessing.... but only when it works.... so.. if not works well it's hell. I give up. No more try-outs, no more try-to-see-if-it-works, try this and try that... Last 6 months was wasted. IN VAIN. and I repeat: IN VAIN. 1.9.15380a was promissing... but better not talk about, at this point. BACK TO 1.6 (great sw!) and I have tools to be safe (against it's supposedly holes) Besides, if I became unhappy with it, you're not the only one client... and sure (I'm blood-crying at this point) not the best one nowadays. WHY? WHY you let the game? Cancel my login, cancel my account, whatever. I'm tired of you. As I was once with AZ. Identical. Typical. Waiting and waiting for a never coming solution. And seeing new projects being started, one after another, without concrete results (no final version fully working, flawness). It was good as it lasts. Life goes on. By-by.
  2. Don't know about possibility or complexity, even if this is the right place, but I'd love to have a "swarm speed" column. Even with estimated average values. Or, something like. Specially when not using DHT (more difficult, huh!) It could be of some help to many ppl who insist having "bad" settings (they will have a good parameter to compare what's going out there to what's happening locally) DNA = kid from uT + BitTorrent marriage? I have many already... hopefully an option function, FGS!
  3. ahh.. you did understood what I said about developing and "taking care" of 4... Your good temper is what makes me staying with you, and loving you more and more. Seriously, I have kids, twins, and I know the trouble.... (hehehehe..) Was just a thought... 16977 is working wonderful here, u/l and d/l flawlessly until now (ok - it's soon, just to let you know). edit: here, few hours working, 16977 is (easy) the best of 4. -----> THANK YOU!
  4. WOW! Isn't 4 brands too much? 1.8.4 (official stable - still) = ok 1.8.5 = seems 1.8.4 will not be updated anymore..., so, why not make 1.8.5 official stable, even if takes a little more time?
  5. Next new moon at 05:32 UTC october 18. 16835 very unstable for now.
  6. 16666 is "sending" packets with 1506 bytes (cable, 1500 MTU), second to WireShark when seeding/uploading via uTP (just 1 connection/peer at 0,2 - 5kB/s) But when connected to another distant peer, sends packets from 120 to 300 bytes max only (uTP). Is this expected? [WinXP-Pro-SP3, Cable PPPoA 4Mbit/600kbit, SBV5120 modem, RTL8139/810x nic)
  7. 16625 d/l... let's give another try. THANK YOU!
  8. @ Rafi: Your MS link is correct. Default value is 2 and is not shown. To change it you have to create one (DWORD), on that key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Interface GUID>] IF it doesn't work, see http://support.microsoft.com/kb/815230/ b/c you have to do some update. I have XP-PRO-SP3 working here. BTW, I don't know if it's necessary but I have the same string on [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] ok?
  9. v16222 I hope people at uT have received these reports (uT hung): I don't know what happened, possibly I was far from my pc at that time (I don't remember). ------------------------------------------------------------------------------------------------------------------------------------- edit: I tried setting "TcpAckFrequency" = 1 at XP registry and it did helped A LOT. Now, I'm uploading at "flat" top speed regardless peers latencies (50-300ms) with very much less retransmitted packets. With this setting, 16222 is working a way better (as far as I'm testing I can say = brilliant!) -------------------------------------------------------------------------------------------------------------------------------------
  10. Got a little better upload speed with target_delay at 400 (average peers ping-time = 300ms) but couldn't achieve the same when uploading to low-latency peers (30-80ms). Strange. Both graphs are like a roller-coaster. The same with 1.8.4.16150. With 1.9.0.15380 was FLAT at top speed.
  11. 16222 working well, but... some feedback: This is after a few hours uploading. The only torrent active is uploading to 2 peers, 01 TCP with 85% speed, and 01 uTP. Both have a HIGH LATENCY of 450-550ms (ping) and goes to the same country. Speed is like the graph, very inconstant. My settings are VERY conservative, 6 connections per torrent, 24 max total connections, 2 upload slots, 3 active torrents max, 5 conn/sec, 5 max half-open, at an 640kbit/sec upload link (Cable-ADSL-PPPoA), bt.tcp_rate_control is false, net.calc_overhead is false, bt.transp_disposition is 15. I did also noticed that retransmitted TCP packes are higher than previous uT version, actually reach 6% while v16126 was 1% max (netstat-s) in same 01:30h time period, with same conditions. Well, this is what can say at the moment.
  12. About a new setting, please, can someone tell me wich clients (family) are able to accept the new uTP header (bt.transp = 31) nowadays? Only 1622? Worth a try, or is it too soon? Thanks. edit: sorry, forgot to say: 1622 is working very well here...
  13. D/L 16222 now. Let's see how it goes! Thank's
  14. About the problems with posting in the forum: I noticed that incoming ICMP FRAGMENTATION NEEDED (type 3 code 4) needs to be allowed at the firewall. This ICMP code is usually blocked due to security reasons. I have had the same problem (looong time to get a blank page after "submit") and I've just allowed my firewall to accept that ICMP code only from IP 72.20.52.46 (uT Forum) and the issue was gone. I hope this helps you.
  15. It's greatful seeing a good discussion! Rafi and Switeck both have very good points. I don't know who is right or who is wrong, IF ANY. Fact is: v2 has "a new approach" and, right now, this have to be tried and learned by those users with one eye on the future. I myself have been got mistaken sometimes, both at my own PC as others for whom I give some care. After some trial and error I did achive the point, for all. And differs from one user (connection) to another. Dev's are doing a great job, and v2 is a great work, with extreme knowledge built-in. So, to start working with the V2, only vaguely remember the principle of operation of previous versions .. and give a chance to learn it all over again.... I'm sure you'll be very happy after all.
  16. @ unforgiven sh: yes, I tried. I read/apply all of that. In fact, some are more conservative than that. Thanks.
  17. v2.0.16126: I have more than 140 torrents 100% completed from a private tracker for seed. When I start uT, it scrapes a lot of them very quickly (ok). Then it starts seeding 3 torrents. Most of the times, these initial seeding are torrents without any peers, and uT don't upload nothing. Then, after some time, it starts seeding more torrents, but again, most of the time are torrents without any peer. And this procedure repeats for a long time until all torrents stays in seeding mode (~1h). The result is: for those torrents with some peers it stays in "queued seed" for a looong time. BTW, I have: queue.prio_no_seeds = true queue.use_seed_peer_ratio = true queue.slow_ul_threshold = 3072 queue.slow_dl_thredshold = 20480 Maximum number of active torrents (u/l or d/l) = 3 (64KB max upload, 600kbit/sec u/l link) Questions: 1) Is there a way to change this order, for start seeding those torrents with peers more quickly? 2) Is there a way to start seeding all torrents with 0 peers more quickly? (I don't think that increasing the "max number of active torrents" is a good idea. I want to preserve good speed for those torrents in upload state. I found 3 as a good number). Thanks.
  18. v2.0.16126: Configs second to (my) previous post #102 above. More than 12h non-stop on a private tracker and I noticed: 1) Less uTP connections than previous v15380, 2) Better speed via TCP than v15380, worse for uTP, usually I get HIGH LATENCY from my ISP (~230ms to Europe, ~350ms to Russia, ~160ms to USA "ping-time"). BUT I may be wrong on 1) and 2) b/c it was only eye-checked from time to time (any chance to separately graph/log uTP and TCP transfers on future versions?) 3) Good stability in transfers - no more roller-coaster (at least for uploading). Much less retransmitted packets than v15380 (checked with WS). 4) CPU, RAM and Disk supposedly under very good conditions. 10h upload graph & statistics (private tracker on all torrents): Process Explorer after more than 12h non-stop:
  19. b16126: Serious improvements, huh! CONGRATULATIONS! Now it's working fine. Those 404's are gone for good. Good speeds and under limits (with: bt.transp 15 + net.calc_over FALSE + bt.tcp_rate_control FALSE) - will test others configs later. Seeding +140, upload limited to 3 with 3 up slots each, max conn = 32, max conn per torrent =8, Max up 65KBytes/sec, Max down 450KBytes/sec, ADSL-Cable-PPPoA-4Mbit/sec d/l - 600kbit/sec u/l. WinXP-PRO-SP3 up to date, Sempron 3000+, 1GB RAM. Very low CPU (0 to 3%, 9% peak), RAM under same good usage. :cool: THANK YOU!
  20. Thanks: bobince, hugootto, bt22 Nice explanations and good recommendations!
  21. Switeck and arvid => THANKS for all explanations given. Is there a "workaround" for those 404 (while we don't get the new ver)? I really want to continue testing, but... Back to 15380 now. Sorry.
  22. - HTTP 404 error when d/l new torrents from private tracker and no-go for them. (didn't try on public ones) - Seeding previously completed torrents in older version are OK til now. Few questions: 1) Logger stats "*** Starting Diagnostic thread ***" when uT is opened. Should exist a log for "Finnished Diagnostic thread"? 2) What Options-->Preferences-->Advanced-->"allow_pairing" stands for? 3) Options-->Preferences-->BitTorrent-->"Enable bandwidth management" bypasses "bt.transp_disposition"? Enabling is the same as "bt.transp_disposition = 15"? THANKS.
  23. v2.0.0.16081 Beta: Can't install/upgrade from v1.9.15380. Installer (both normal and uncompressed) crashes everytime I try. WinXP-PRO-SP3-BR updated, dump files: http://www.mediafire.com/?idtlrjjlzjm http://www.mediafire.com/?jrfgdwuzudj http://www.mediafire.com/?c2wmyme0umm Edit: Managed. Installer needs connection to internet (DNS and TCP). Communication allowed, installer goes OK. I think that installer must run flawlessly even without internet access. (Many ppl installs everything with all internet access blocked, for "general" security reasons)
  24. Installer worked fine in one slimmed W7-64 ("running as" adm). Just tried once, in this specific tweaked system.
  25. Hi; Just curious about the "full" "bt.transp_disposition" field (bin value): if 255 (dec) = both TCP and uTP, incoming + outgoing (future-proof setting, always will mean this) ->this means 8 bits, 4 already well known (Incoming/Outgoing/TCP/uTP). What about the other 4? What they are for (even if not yet implemented)? Can we "play" with?
×
×
  • Create New...