Thanks Stephen.. but what about MY (me me me) problem which started this whole thread: www.asainc.net.au is still downloading at a measly 28 Kbytes/sec. Can you look into that one specifically for me? It’s an important client of mine… thanks! 
[ed] All my clients are important of course. (just in case any of them are reading this!)
And dude, it’s been almost a year now. 
See I called you dude, that’s how bummed out I am, man. :hippie:
Got your PM Stephen, thanks.
I did another test and there’s still a major difference, but I tried something new this time with interesting results. A single-connection download (ie. from the browser) from a site on Cluster 1, comes down at ~30 KBytes/sec, same as before, very slow. Same file from my site on Cluster 2 comes down at ~200 KB/s.
Then I decided to try a download manager with multiple connections.
Five download threads each. Cluster 1 download = ~120 KB/s, Cluster 2 = ~1000 KB/s.
Notice how the limitation seems to be per-connection, not a blanket network limitation.
Then I tried 10 threads from Cluster 1 and got ~250 KB/s (almost 10 times the ~30 KB/s per-connection limit).
So the question is, where is this per-connection speed limit coming from?
Tracert to the Cluster1 site:
[code]Tracing route to www.activeorg.com.au [204.14.106.234]
over a maximum of 30 hops:
1 2 ms <1 ms 1 ms 192.168.2.1
2 15 ms 15 ms 15 ms nexthop.wa.ii.net [203.59.14.16]
3 15 ms 15 ms 15 ms gi2-7.per-qv1-bdr1.ii.net [203.215.4.85]
4 74 ms 75 ms 74 ms gi0-15-1-0.syd-ult-core1.ii.net [203.215.20.2]
5 74 ms 75 ms 74 ms 202.139.19.33
6 230 ms 229 ms 230 ms 203.208.191.157
7 227 ms 250 ms 227 ms 208.50.13.165
8 292 ms 287 ms 288 ms INTERNAP.Tengigabitethernet2-2.ar1.MIA2.gblx.net [64.212.16.166]
9 285 ms 285 ms 285 ms border5.pc2.bbnet2.mia003.pnap.net [69.25.0.77]
10 286 ms 288 ms 287 ms webhosting-12.border5.mia003.pnap.net [216.52.162.66]
11 287 ms 287 ms 286 ms ibgp.border3.nota.mia.webhosting.net [64.71.226.34]
12 293 ms 286 ms 286 ms 64.71.225.26
13 289 ms 289 ms 289 ms 204.14.106.234
Trace complete.[/code]
Tracert to the Cluster 2 site:
[code]Tracing route to www.activeorg.net.au [64.71.229.15]
over a maximum of 30 hops:
1 1 ms 1 ms <1 ms 192.168.2.1
2 15 ms 23 ms 15 ms nexthop.wa.ii.net [203.59.14.16]
3 16 ms 15 ms 15 ms gi2-7.per-qv1-bdr2.ii.net [203.215.4.87]
4 74 ms 74 ms 75 ms gi0-15-1-1.syd-stl-core1.ii.net [203.215.20.66]
5 75 ms 74 ms 75 ms 202.139.19.37
6 225 ms 233 ms 223 ms 203.208.191.213
7 223 ms 224 ms 224 ms ge-0-0-0-0.laxow-dr1.ix.singtel.com [203.208.171.65]
8 225 ms 232 ms 225 ms 203.208.145.102
9 284 ms 283 ms 283 ms INTERNAP.Tengigabitethernet2-2.ar1.MIA2.gblx.net [64.212.16.166]
10 455 ms 454 ms 437 ms border5.pc2.bbnet2.mia003.pnap.net [69.25.0.77]
11 282 ms 282 ms 282 ms webhosting-12.border5.mia003.pnap.net [216.52.162.66]
12 282 ms 282 ms 282 ms ibgp.border3.nota.mia.webhosting.net [64.71.226.34]
13 282 ms 282 ms 282 ms 64.71.225.26
14 282 ms 282 ms 282 ms 64.71.229.15
Trace complete.[/code]
Do you see anything there that might give a hint?
There has to be some kind of network congestion on your route from Cluster 1.What you are seeing is TCP congestion control in action. One or more of the routers (enroute to your PC) is probably highly congested…
If TCP packets experience congestion anywhere on the route, it will scale back the rate of transmission, to ensure that all TCP connections intersecting at that router, have a fair share of that route’s capacity. In theory, each TCP connection is capped by the Total Capacity / Number of connections at a congested node… A download accelerator (with 3 or 4 simultaneous connections) will give you a larger share of bandwidth on that route, but the performance of each connection is still limited by that congested node.
I can assure you, that the congestion is not taking place inside our network, or to our immediate ISPs. And because its not taking place within our immediate network, there is very little we can do but complain to our ISP (which often has little effect)
Thanks for the explanation Yash! That makes sense and would explain the per-connection limit.
I’ve since noticed that single-connection d/l speed from cluster 1 seems to be slowly improving over time, so perhaps the congestion issue is being addressed somewhere. It can be anything from 60 to 200 Mbytes/sec now, so the max is much faster, but can’t really see a pattern in the variations.
My Verizon DSL here seems to be throttled in the daytime, its been recently upgraded to 3mb, but downloading from our servers or elsewhere from about 7am to 10am maxes 200kb/s, then the same from 3pm to 7pm, after that it gets better and I can get about 350kb/s.
I don’t know if it is network congestion (certainly possible) or intentional throttling. I can’t see any packets coming my side limiting the speeds to the modem or anything, but it could be happening on their gear in the office.
Annoying but not the end of the world.
hmm more than just annoying though, when the max speed of images and PDFs from a client’s web site is down to 50kB/s. I’ve had the Cluster 2 account for a while now, which performed better than C1 initially, but can’t see much overall difference at the moment since the C1 rates improved.