[DON'T USE] Mini-guide to help all of you with your speed problems...

Errm...so what could it be? I'm clueless...

so am I... But I'm on the other torrent where you are seeding as well. the problem is that my average d/l speed is 1.4kB/s and I'm hardly downloading anything from you, even though the E flag is on.

Exactly. And I'm not even maxed out, there's at least 8~9 kB/s more I can pump out to you...I don't know why your/my client isn't aggressive enough. :/

I'm guessing here, but maybe my ISP detects BT traffic on my port, since I'm set to Enabled and not to Enabled always.

It might be that my ISP is shaping all traffic on that port.

But I'm just guessing here.... Maybe you or Firon can confirm.

well, I tried to set my client to Forced, and unchecked incoming legacy, and I'm still getting only around 1.5kB/s from you. Is your BW still free now? because if it is, then either my ISP overcomes µtorrent's encryption, or the client is not aggressive enough.

I think that Firon and Ludde should know about this.

1c3d0g, could you let them in on our little "experiment" here?

Edit: I don't know what I'm talking about here really, but is it possible that I am set to Force, don't allow incoming legacy, and that my ISP detects DHT/Pex traffic and thus manages to throttle BT traffic?

well, I tried to set my client to Forced, and unchecked incoming legacy, and I'm still getting only around 1.5kB/s from you. Is your BW still free now? because if it is, then either my ISP overcomes µtorrent's encryption, or the client is not aggressive enough.

1.) My bandwidth is still free. Indeed, I should be upping much more data to you than I'm doing right now. B.t.w., Build 421 is out.

I think that Firon and Ludde should know about this.

2.) So do I.

1c3d0g, could you let them in on our little "experiment" here?

3.) Sure, why not? I'm all for making µTorrent better...let's test the Encryption to hell and back.

Edit: I don't know what I'm talking about here really, but is it possible that I am set to Force, don't allow incoming legacy, and that my ISP detects DHT/Pex traffic and thus manages to throttle BT traffic?

4.) Interesting question. Well I don't know much about that either, so I guess Firon/DWKnight/Ludde will have to give us an explanation... :|

yeah, those three proved that they can solve any mystery...

Edit: thanks for the head up. just upgraded to b421.

Edit2: now that I am set to Forced, my upload is also free, and still I'm connected to two Az 2307 on a torrent I'm seeding, the E flag is on, but I'm uploading to them at a total speed that is under 1kB/s

Some ISP's are using draconian methods to prevent people from using BitTorrent, like throttling down all ports other than 80, 21 etc (even when those ports aren't used for P2P traffic - they just slow them down regardless). Perhaps your ISP is using these same tactics? If so, you may have to change your port to one of the common ones, unfortunately... :/

I'll try changing to port 21 now, and see what happens...

Edit: no, it's not going well with port 21 as well. I think we need some expert advice here...

Firon / Ludde / DWKnight / anyone?

Edit2: I went back to Enabled, allow. Now I am at least able to seed, but still the d/l is at a grinding halt.

Icedog, consider adding this to your mini guide.

There is a close relationship between all these parameters below:

Upload capacity in kBytes/s

Upload slots

Global max connections

Connections per torrent

peer.disconnect_inactive true/false

peer.disconnect_inactive_interval 300 seconds minimum

Optimistic unchoke interval, 10 seconds minimum and up to 30 seconds

Basic functions and concepts to keep in mind for the rest to make any sense:

Client prefers to upload to peers that let it download.

Client prefers to maintain current fast TFT connections active.

A new connection has 3 times the chance of being optimistically unchoked over current connections.

There is a minimum speed threshold before it becomes very inefficient to transmit data over a single connection, it's about 1kBytes/s.

A connection is a link between two peers. An active connection is a connection that actively uploads or downloads. An upload slot is a connection that actively uploads.

All parameters except the optimistic unchoke interval can be set by the user. Since we can't configure the optimistic unchoke interval or even disable this function because it's an essential part of BitTorrent, it becomes the determining factor for every other parameter.

The only situation where the optimistic unchoke function is not considered is when there are equal or less peers than upload slots. Since all peers are assigned upload slots, there will not be an optimistic unchoke. This is an exception and does not apply to what follows below.

Before we begin, I will change the way you think.

The BitTorrent concept is a unique one that forces us to reconsider our perspective on the way we download content. We used to think that all we needed to know was how fast we could download from one source. With BitTorrent, this is no longer true. It used to be that the only thing we thought of was "how much can I take?". With BitTorrent, this is no longer true. Because of the unique method BitTorrent uses to download content, the only question that we must ask ourselves is:

How much do I give?

There are a few questions you must answer before you can determine what value to set for all the relevant parameters:

1. How much total upload bandwidth do I give?

2. How much upload bandwidth per upload slot do I give?

3. How much upload bandwidth per connection over time do/can I give?

4. Do I want to play nice?

We'll answer question #4 first. If you don't want to play nice, I don't care and neither do you. If you do want to play nice, keep reading and consider the following suggestions carefully. Consider that I run one torrent at a time so these suggestions assume you'll do that as well. Adjust as necessary if you run more than one torrent at a time, there's a note about that at the end of this article.

First, I'll show you what I do and you can then come back to this example once you have grasped the concepts:

My connection: cable ~10Mbit/900kbit (changed my modem, used to be ~6.5Mbit/900kbit)

Upload limit for download mode: 80kBytes/s

Upload limit for seeding mode: 100kBytes/s

Upload slots: 10 (both download and seeding mode)

Global max connections: equal or higher than connections per torrent

Connections per torrent: 50 (20 for seeding mode)

peer.disconnect_inactive true

peer.disconnect_inactive_interval 600 (10 minutes)

Optimistic unchoke interval, 10 seconds minimum and up to 30 seconds. I can't change that but I write it anyway because it's an essential part of BitTorrent and it rules over other functions.

We begin.

Fundamental principle: If you can't activate a connection after you've established it before the peer.disconnect_inactive_interval is reached, this connection becomes in fact useless. It's a waste of time and resource. I will not consider if or when another peer activates the connection on his end.

Fundamental principle: The more you spread your upload bandwidth, the slower the torrent becomes. Conversely, the less you spread your upload bandwidth, the faster the torrent becomes.

Fundamental principle: Your upload bandwidth is spread over all connections, not just upload slots. It's divided this way because of the optimistic unchoke function that activates one connection every 10 seconds minimum and chokes one active upload slot to maintain the same number of upload slots. It's a rolling spread over many connections. The equation is simple: speed / connections. Further down I give an example of what I do, I usually give 1.6kBytes/s per connection over time. I suggest you consider giving a minimum of 1kBytes/s per connection over time even if you can make more connections based on peer.disconnect_inactive_interval. You will find that making only 30 connections for a 30kBytes/s upload speed will still net you good download speeds, probably even saturate your connection.

I'll assume you have determined your total upload speed limit using Icedog's mini guide. I'll assume that you give 5kBytes/s per upload slot and that you know how many upload slots to set based on that and your total upload speed limit. At the end of this article, there's a special note for very fast connections.

peer.disconnect_inactive true/false

peer.disconnect_inactive_interval 300 seconds minimum

The two parameters above tell me two things: I can terminate inactive connections or not and I have a minimum amount of time to wait before I do terminate inactive connections. I will only assume that you will terminate inactive connections because I don't think you want to wait forever. Neither do I want to wait on you forever. I'll assume that 300 seconds is too short and you set it to 600 seconds.

Optimistic unchoke interval, 10 seconds minimum and up to 30 seconds

This function tells me many things: It takes a minimum of 10 seconds to activate one connection. Combined with peer.disconnect_inactive_interval, we can then calculate the maximum number of connections we can make before the interval runs out and we start terminating inactive connections uselessly.

Upload slots

Since upload slots are connections to which we upload actively, we can disregard them when considering how many connections we can make based on the two functions: peer.disconnect_inactive_interval/optimistic unchoke interval.

This is the equation I use to determine the absolute maximum number of connections I can make before I start making useless connections:

(peer.disconnect_inactive_interval / 10) + upload slots = global max connections.

peer.disconnect_inactive_interval: is the total amount of time before a connection is terminated in seconds.

/ 10: because the optimistic unchoke interval runs at an absolute minimum of 10 seconds.

+ upload slots: because I don't count active connections.

global max connections: because there is only one global upload bandwidth to spread: Mine.

(600 / 10) + 10 = 70 global max connections.

In the equation above, I can spread 80kBytes/s over 10 upload slots over 70 connections in 10 minutes. I give 80kBytes/s / 10 upload slots = 8kBytes per upload slot. I would be spreading my upload over 70 connections in 10 minutes but I usually make only 50 connections so I give on average 80kByte/s / 50 connections = 1.6kBytes/s per connection over time (over 400 seconds in fact).

Still, I can make 70 connections before I start making useless connections that I can never activate in time. Go back to what I actually do at the beginning of this article, use the equation above for your connection and compare your result to mine. Check uTorrent's parameters, especially peer.disconnect_inactive_interval to get a good idea of how nice you actually play.

For example, if you make 100 connections, 5 upload slots with a 300 seconds interval for peer.disconnect_inactive_interval, you are not playing nice at all:

(300 / 10) + 5 = 35 global max connections.

100 - 35 = 65 useless connections.

You might answer: Yes but I spread my upload only over 5 upload slots so I give 5kByte/s per upload slot. To which I reply: Yes but what about the 65 connections you never upload to because you disconnect them after 5 minutes? Consider that a new connection has 3 times the chance of being optimistically unchoked over current connections and you can imagine how much of a problem it is to make too many connections. Not only will you spread your upload too thin over too many connections but you'll be spending a great part of your time unchoking new connections because you'll be spending a great part of your time terminating inactive connections and making new ones.

(peer.disconnect_inactive_interval / 10) + upload slots = global max connections.

Using that equation, figure out how many connections you can make before you start making useless connections. Regardless of your upload bandwidth capacity, you'll notice that there is very little difference in max connections between you and me. This is due to the fact that the peer.disconnect_inactive_interval rules you the same way it rules me and the fact that the minimum optimistic unchoke interval is the same for all of us, 10s and the fact that the majority of us have only a limited amount of upload bandwidth to spread over a limited number of upload slots. Where there might be a big difference is if you choose to limit the number of connections by giving a minimum of 1kByte/s per connection over time as I suggested. In my case I could make 70 connections and still meet that 1kB/s quota but if you can only upload at 30kBytes/s, you'd make only 30 connections even if you could make more based on peer.disconnect_inactive_interval.

Going back to the beginning of this article, I wrote: Because of the unique method BitTorrent uses to download content, the only question that we must ask ourselves is:

How much do I give?

Ask yourselves another question at this point, even more important than the first:

How effectively do I give it?

This article allows you to answer that.

A special note on making more connections to connect to more seeds to get more speed. I can make an argument against it and I will.

Since a seed has the complete file, I don't need to upload to it. Since I only consider peer.disconnect_inactive_interval for me towards peers, not for peers towards me and I don't need to upload to seeds, I could increase the number of connections. Here's an example using the same equation with my own setting for upload slots but including 15 seeds as connections I don't need to activate:

(peer.disconnect_inactive_interval / 10) + upload slots + seeds = global max connections.

(600 / 10) + 10 + 15 = 85 connections before I start making useless connections.

In the example above, I don't count upload slots because they are active and I don't count seeds because I don't need to upload to them. I'd be connected to 70 peers and 15 seeds and I'd still be able to activate 60 connections in 600 seconds. I'm still playing nice. I said I can make an argument against that and I will, well here it is:

Go back to the beginning of this article and re-read this part:

Client prefers to upload to peers that let it download.

Client prefers to maintain current fast TFT connections active.

Now re-read this part:

Fundamental principle: The more you spread your upload bandwidth, the slower the torrent becomes. Conversely, the less you spread your upload bandwidth, the faster the torrent becomes.

Now consider that I reduce the number of connections per torrent to 20 as well as increase my upload limit to 100kBytes/s when I seed. That's only me and I do that to reach my share ratio more quickly but I'm sure there are many more that do just that for the same reason.

Now consider that over time, the number of seeds will increase and the number of peers will decrease naturally because that's what happens: Peers become seeds. I don't consider hit 'n runs, as I said, if you don't want to play nice, I dont' care and neither do you. I don't care because there's nothing I can do about it, they don't care because they know I can't do anything about it.

Here's my argument against making more connections to get more speed from seeds: Using this article as a guide, making just enough connections to play nice and maintaining this same number of connections to the end will naturally allow the torrent to pick up a lot of speed over time because your upload, and mine, will be spread over fewer connections to peers as time goes by. Since the number of seeds increases as a result of peers becoming seeds, you'll also get more speed from them as time goes by. Because you keep the same number of upload slots, you still get the same speed that you got from the same 5 peers (or 10 in my case) that let you download because you uploaded to them.

When I play nice you get more speed. When you play nice I get more speed.

How much do I give?

How effectively do I give it?

A note on running multiple torrents.

Consider that your upload bandwidth is spread globally. Consider that the optimistic unchoke function acts on a per torrent basis: It will unchoke one connection every 10 seconds on each torrent you run. You will find that you can still make many more connections globally while reducing the number of upload slots per torrent to maintain a good speed per upload slot while still activating all the connections on each torrent before the peer.disconnect_inactive_interval is reached.

If you do run multiple torrents, simply reduce the number of upload slots per torrent to maintain a good speed per upload slot and use the same equation per torrent. An example using my own settings if I were to run two torrents:

80kBytes/s / 10 upload slots

10 upload slots / 2 torrents = 5 upload slots per torrent

(600 / 10) + 5 = 65 connections per torrent * 2 torrents = 130 global max connections

The above is what I could do but I still make only 40-50 connections per torrent when I do run multiple torrents. I make even fewer connections when I seed so that's not a problem.

A special note for very fast connections, 10Mbit/10Mbit and the like.

If you have a very fast upload capacity, consider giving much more than 5kBytes per upload slot, 10-25kBytes/s. Be careful if you still configure uTorrent to give 5kBytes per upload slot. If you set many upload slots like 50 or 100, observe uTorrent's behavior and see if you give less than 1kBytes/s to many upload slots. If that is the case, reduce the number of upload slots to a reasonable number so that you can give all upload slots at least 5kBytes/s. This may happen because some of us can take all you can give on just one of your upload slots and other peers could be neglected because of that. Bear in mind that some peers just can't take more than a few kB/s anyway so check what those connections give you in return, it's a good indicator of what's happening with a particular peer. If you find that you don't get the same speed that you give globally (share ratio is out of whack), simply limit your upload speed to the download speed you get (and adjust upload slots accordingly) until the torrent picks up speed if you want to maintain a fair share ratio. When you start to seed, do like I do with max connections but simply uncap your upload for my benefit, thank you

For those who have doubts that this guide can result in getting more download speed, consider that when I make only 20 connections, I can get 100kBytes/s download speed just fine. 40 connections can get me anywhere between 175kBytes/s and 700kBytes/s. 100 connections can saturate my connection: 1100kBytes/s (~10Mbit).

Now go play nice.

ML

Martin Levac: nice post, but do you want me to post all that? It's a bit too long and confusing...no offense - maybe it's just me. Can I get like a "crunched" version of the above, with only the most essential points?

Icedog, you don't have to copy and paste the text, just link back to this page. You're not the first who think it's confusing so it might just be me. I think it has to do with how people think about downloading content, it's a little difficult to grasp the BitTorrent concept firmly and it is difficult for me to put it into words in a concise manner.

Imagine a world where BitTorrent does not exist and your upload capacity is almost completely irrelevant. In that world, the big selling point was download speed. Upload speed was never talked about because it just wasn't important to you and me. ISPs were competing on a download speed basis: I'm the fastest ISP around the block, buy me. When ADSL and cable internet access was developed, it fit right in with this download speed mania because it relies on existing technology that has serious drawbacks with regards to upload capacity. Some types of cable access even had a telephone link for upload and there are still such services being offered and deployed today. That world existed just a few years ago before Brahm got an idea about BitTorrent. In that world, all we needed to think about was how fast to get and where to get it from. ISPs are still competing this way today even as BitTorrent is quickly becoming the single most important cause of internet traffic throughout the world.

Because of BitTorrent's unique way of downloading content, the old way of thinking no longer applies. File serving websites such as filefront, downloads.com or 3dgamers (3dgamers already offers every file on their server as a torrent) will catch on to the idea because of the tremendous potential savings in bandwidth consumption. Bandwidth costs money. Users are already catching on. ISPs will catch on eventually: They have no choice but to supply the demand or lose business to competitors that will supply the demand. As the file serving websites move more and more towards a BitTorrent approach because we as users move more and more towards the same thing, they will require less bandwidth and will buy less as a result while we will want more. ISPs who used to sell that bandwidth to those websites will find themselves having too much upload bandwidth to sell to too few websites and simultaneously having an increased demand for that same bandwidth from users like you and me.

Take my connection for example. I have cable ~10Mbit/900kbit. I have the fastest internet access service available in Monreal. I'm not kidding when I say I can get 1100kBytes/s download speed. My upload capacity still sucks comparatively. What I have: ~10Mbit/900kbit. What I want: 10Mbit/10Mbit. Because I can download at ~10Mbit, I'm frustrated when I "only" get 300kByte/s download speed from a torrent when in fact I should consider myself lucky to get double my upload speed.

Combine the old way of thinking with the fact that most users on high speed connections have either ADSL or cable with fat download pipes and comparatively tiny upload pipes and the fact that we want our money's worth of download speed whatever the price and you get the idea of why we only think about how to get more speed from a torrent when in fact we should be thinking about how to give more speed to a torrent. Now combine the old way of thinking and the behavior that it tends to produce in each of us and you get an idea of why a torrent is so slow.

What if your connection was synchronous at 2Mbit, 5Mbit or even 10Mbit up and down, would you still cap your upload at 30kBytes/s and make a buttload of connections and uploat slots to try to get more download speed? Would you still act like a leech (I don't mean you personally, Icedog, I mean anybody) without regards for how much you give? Of course not and neither would I, with BitTorrent you'd soon realize that the more you give, the more you get. More importantly, the more efficiently you give what you do give, the more you get. In a case where you had a synchronous 2Mbit-5Mbit-10Mbit connection, you'd have the upload bandwidth and you'd use it if only because you'd get more download speed in return.

With BitTorrent's unique way of downloading content, I can't in good conscience expect or demand that I get more download speed than upload speed. In all fairness, I can only ask to get exactly what I give. In my case, it's 80kBytes/s. Anything more is a bonus. If I had a 10Mbit/10Mbit connection, I would ask 1000kBytes/s because that's what I would give and I would make sure that I did get equal download speed by spreading my upload speed over many upload slots in a TFT manner.

If I had a 10Mbit/10Mbit connection and only got 200-300kBytes/s from the peers I uploaded to, I'd count how many upload slots I have, check that they all uploaded back to me, figure out the average download speed I got from each upload slot that does upload back to me and increase upload slots to get more TFT going on with more peers to increase my download speed. Remember the saying "what you see is what you get"? Well, with BitTorrent "what you give is what you get". In a case where I did have a 10Mbit/10Mbit connection, it would be just as fair to ask for as much as I give as fast as I give it. Tit for tat.

Such as it is, I don't have a 10Mbit/10Mbit connection. I can only give a measly 80kBytes/s over 10 upload slots. I can't do more than that but I do it efficiently. I spread it over few connections and I still get exactly what I give. Nevetheless, I still get much more download speed than 80kBytes/s with only 40 connections on a single torrent. I'd get even more download speed if I could upload faster.

Here's the crunched version:

The single most important aspect of BitTorrent is your (mine and everybody else's for that matter) capacity to upload and to upload effectively and efficiently. It's not how much you can get, it's how much you can give and how well you give it.

ML

HEY U... MR. ,... 1-c-3-d-0-g ..........--------------> U Rock man!!!

I do? Oh well, if you say so...what exactly did I do to rock though?

Martin Levac: sorry I couldn't get to ya sooner Mister. Will post that crunched text in the mini-guide in just a bit.

1c3d0g... first my friend... you made reading your speed guide fun.. with all your metaphors and humorious comments.. second good buddy.. after following your instructions.. i am downloading at 50 - 60 kbps ... um make that 80 and rising.

That's good to know...enjoy µTorrent!

P.S. I saw this on Digg, thanks!

Holy crap I was wondering why the forum was so slow earlier... we have to stop making the front page, otherwise I'm going to die from waiting for pages to load xD

we keep getting digged, and our server sucks...

I've been searching this forum and following the posts for the last 3 weeks, tweaked my setting accordingly, but it's still not working for me, so I'm turning to you guys for help.

Here are my vitals:

Intel Celeron 1.7, 768 RAM

XP Pro SP2

uTorrent 1.41 BETA (Build 424)

Zone Alarm 6.0.631.003

Spy Sweeper 4.53. (Build 560)

(other prog. running: Maxthon Browser, WaetherBug, ATIevxx)

Optonline cable modem, 10mb down, up ?

Speed test:

Download Speed: 6994 kbps (874.3 KB/sec transfer rate), I get at times 9500+

Upload Speed: 135 kbps (16.9 KB/sec transfer rate)

verified Disk set to DMA

patched TCPIP.sys (all open)

used TCP/IP Optimizer

uTorrent settings: (what I've tried in these 3 weeks)

Port: 56930

uPnP mapping: enabled (tried not enabled as well)

Add to win firewall exception: enabled, (even though I disabled win firewall)

Global max. upload: 30KB/s (tried 0-20 as well)

max download: 0

Encryption: Outgoing: disabled (left as default)

Allow incoming legacy connections: enabled

Global max # connections: 800

Max. # connected peer per torrent: 125-200 (depending on many ppl. I connected to on the torrent)

# upload slots: 4-10 (depending on many ppl. I connected to on the torrent)

Max # active: 5-10

DHT, Scraping, Peer exchange: enabled (tried not enabled as well)

Advanced:

gui.compat_diropen: false

net.bind_ip:

net.Outgoing_ip

net.low_cpu: false

net.max_halfopen: *64 (tried variations of 8-50)

iplifter.enable: true

dht.rate: -1

webui.pass:

queue.dont_count_slow_dl: true

queue.dont_count_slow_ul: true

queue.prio_no_seeds: true

bit.scrape_stopped: false

bt.compact_alocation: false

bt.enable_tracker: false

bt.multiscrape: true

bt.send_have_to_seed: true

bt.set_socklbuf: false

bt.connect_speed: 20

bt.prio_first_last_piece: false

bt.convert_to_fast_pct: 66

peer.lazy_bitfield: *true (tried with false as well)

peer.resolve_country: false

peer.disconnect_inactive: true

peer.disconnect_inactive_interval: *600 (tried 300 as well)

diskio.flush_files: true

diskio.sparse_files: false

diskio.write_queue_size: -1

diskio.use_partfile: true

diskio.coalesce_wrires: false

diskio.read_cache_size: 0

My story:

I switched from ABC (when their updated ver. froze my downloads). uTorrent was great for the first week or so, giving me my ususal great speeds of 100-400KB/s, all depending of course on the popularity of the torrent.

The slowdown began afterwards, speeds of 5-10KB/s, but I blamed it on the torrent (4.35gb) with not that many peers (25), who probably arent uploading as much. My other downloads were also slow, but also not that many peers, giving me a global dl of 35-50KB/s, and ul of 100-150KB/s, which kinda rules out ISP throttling since the uploads were at full speed.

After about a week of that (with some of the old torrents, some new) those numbers dropped as well. I currently have 7 dl and 2 ul (seeding) at dl 5-14KB/s, ul 10-20KB/s (my ul is almost always double my dl). What is really crazy is that on one torrent (7.7GB) I am connected to has 1(19) seeds 149-168(2468) peers, and I am dl 0.1KB/s - 10KB/s max., my ul are 6kb/s - 15KB/s. I've tried it with only 2 torrents downloading, with only 4 upload slots, 125 connections (added more for the big torrent), with no difference.

I tried the oo torrent and reached 1MB/s! (never had such fast speeds on a torrent before). So I am not being throttled, something seems to be royally messed up. I don't know what. I haven't done anything to windows or run some programs, (nothing that I can remember), it just happened suddenly and gradually.

(I don't know if this is related or not, when running uTorent my browser (IE/Maxthon) slows to a crawl, even though it takes Mem Usage only 4-9k. When I pause it, the browser goes back to normal. Although it is paused I am still downloading and uploading at a few k, it never comes to a complete stop. Just figured I'd mention it in case there is a connection. I know this goes in another section, and will post this particular issue there).

Help me out please!

You really should've posted in a new thread for this... but whatever.

1) Your speed tests appear to be shaky... try running the speed test again without ANYTHING using your connection other than the webpage (no downloads, nothing)

2) Your maximum number of connections is way too high. Stick to the settings recommended by the Speed Guide (after you retest)

3) How many simultaneous half-open connections did you patch TCPIP.SYS to?

4) Make sure you've configured ZoneAlarm properly... are you using the free one or a paid one?

5) Did you forward your ports? Are you getting some kind of error in the taskbar?

6) What's your ISP, and what router and modem do you have?

1) Your speed tests appear to be shaky... try running the speed test again without ANYTHING using your connection other than the webpage (no downloads, nothing)

http://www.speakeasy.net/speedtest/

Download Speed: 7125 kbps (890.6 KB/sec transfer rate)

Upload Speed: 136 kbps (17 KB/sec transfer rate)

I do get higher as I've previously posted, probably more ppl. surfing now.

2) Your maximum number of connections is way too high. Stick to the settings recommended by the Speed Guide (after you retest)

I played with those setting from low to high with no change in results.

3) How many simultaneous half-open connections did you patch TCPIP.SYS to?

to the max. 65k+ (don't remember exact number)

4) Make sure you've configured ZoneAlarm properly... are you using the free one or a paid one?

a dowload with serial. I'm not sure what you mean by configuring properly. It's set to allow. Please guide me about other options.

5) Did you forward your ports? Are you getting some kind of error in the taskbar?

Network OK, no errors. I didn't forward port, didn't think I had to since I don't have a router only a modem. Please guide me on how to if I'm wrong.

6) What's your ISP, and what router and modem do you have?

Optonline, Motorola SB5100 SURFboard cable modem.

3) Lower the max. You'll honestly never need that much. 100 is good enough... That shouldn't make a difference, but this is just for security reasons ;P

4) Configuring ZoneAlarm 6.x

Erf you don't need to forward ports if you're only using a router. Try disabling DHT and seeing if it helps.

3) Lower the max. You'll honestly never need that much. 100 is good enough... That shouldn't make a difference, but this is just for security reasons.

been reading about that in posts, will leave it at max until I get the speed going properly.

4) Configuring ZoneAlarm 6.x

Done, followed all the instructions. Same lousy speeds, no changes there. The only difference that all torrents are downloading only have a -on them (offline, timed out), i'll wait and see if it resolves. If not I'll try tweaking the range of ports in ZL, for the moment it's only set to one port.

Erf you don't need to forward ports if you're only using a router. Try disabling DHT and seeing if it helps.

done that. no difference.

http://www.utorrent.com/faq.php#What_does_the_no_entry_symbol_mean_on_the_torrent_status_icons.3F

if you aren't connecting to the tracker have you tried signing out of the tracker sites You use manually, clearing your cookies, and then re-sign in to trackers? I know that doing that sometimes sounds entirely too easy yet if your connection (cable, I use the same model modem) changes your address (most drop about every 24 hours )The trackers are looking for the old address and Your'e probably close but not quite, and if that does work for you.......make it report to tracker your current address and I'd bet things will at least be reporting to tracker correctly. Good Luck I know it can seem frustraiting at times yet 99.999 times out of 100 it is something so simple you wish you could kick yourself....been there done that MORE THAN ONCE!