Quote:
Originally posted by JSA Matt
They are having some problems, takes almost a full minute to load their page on a T1 :helpme :helpme :helpme
Code:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.111.1 - 0 | 11 | 11 | 0 | 8 | 47 | 0 |
| tns-137-gw-algx.tns.net - 0 | 11 | 11 | 0 | 7 | 47 | 0 |
| tns-136-gw-algx.tns.net - 0 | 11 | 11 | 0 | 35 | 156 | 15 |
| tns-143-gw-algx.tns.net - 0 | 11 | 11 | 0 | 5 | 16 | 0 |
| 165.117.188.1 - 0 | 11 | 11 | 0 | 4 | 16 | 0 |
| lax10-core2-so-0-2-0-0.atlas.algx.net - 0 | 11 | 11 | 0 | 8 | 16 | 15 |
| lax10-core1-so-0-1-0-0.atlas.algx.net - 0 | 11 | 11 | 0 | 8 | 16 | 16 |
| sfo10-core2-so-0-2-0-0.atlas.algx.net - 0 | 11 | 11 | 15 | 19 | 32 | 15 |
| sjc3-core5-pos5-0.atlas.algx.net - 0 | 11 | 11 | 15 | 18 | 31 | 31 |
| sjc3-core1-pos6-0.atlas.algx.net - 0 | 11 | 11 | 15 | 24 | 32 | 15 |
| sjc3-core10-pos7-0.atlas.algx.net - 0 | 10 | 10 | 15 | 25 | 32 | 15 |
| unknown.Level3.net - 0 | 10 | 10 | 15 | 21 | 31 | 15 |
| so-6-0-0.gar1.SanJose1.Level3.net - 0 | 10 | 10 | 15 | 26 | 47 | 31 |
| ge-0-3-0.bbr1.SanJose1.Level3.net - 0 | 10 | 10 | 15 | 26 | 32 | 15 |
| so-1-2-0.bbr2.NewYork1.Level3.net - 0 | 10 | 10 | 93 | 98 | 110 | 109 |
| ge-5-0-0.gar1.NewYork1.Level3.net - 0 | 10 | 10 | 93 | 93 | 94 | 94 |
| 65.59.192.22 - 0 | 10 | 10 | 93 | 96 | 110 | 94 |
| CE-9E-4.nycmny25b.isprime.com - 0 | 10 | 10 | 93 | 101 | 141 | 93 |
| 66.230.129.74 - 0 | 10 | 10 | 93 | 104 | 125 | 109 |
|
This thread is filled with misconceptions.
Looking at that traceroute, you'll see some jitter starting at hop 2, and larger jitter at hop 3.
Hop 3's jitter looks like an overloaded route processor, which is separate from the forwarding engine on many popular routers today, which is why the jitter looks more like the jitter started at hop 2, from 4 on.
Hop 2's jitter is a cause of issues internal to tns's network, if it's a problem, that's up to your determination, you're their customer. Some people find jitter to be a big problem (large downloads, streams, voip), and others don't.
It looks like your claim that "ISPrime is having problems" is because we are more L3 hops, and higher latency from you. Anyone who has any understanding in networking and physics, would be aware of the speed of light issues inherent to long-distance communication. You are in California, Jupiter is in California, ISPrime is in NYC. Of course it will take longer to go California <-> NYC than California <-> California. And regarding higher number of hops, You'll see that there are 3 more hops on algx's network (which ultimately, your are a customer of algx). If you reached us tns -> algx -> aleron -> isprime it would likely be 2 hops less, and that route is possible as we do have aleron transit, however we prefer to optimize our flow of traffic over the closest exit to the destination network as possible, and for the return path, Level3 peers with ALGX in NYC, and allows us to reach them that way, and for the traffic going the other way, this also appears to be the ideal path.
And, the fact that aleron has less hops showing up in a traceroute than Level3 is inconsequential as well. Aleron runs MPLS through their network, which is basically a series of tunnels to make it APPEAR that parts of their network are directly connected, when in fact, they aren't. All this does is hide hops in a traceroute, you still pass over the same number of devices. Additionally, the number of devices you pass over is meaningless. What has meaning is: are any of the links between point "A" and point "B" saturated? How far off course do your packets go, meaning, for example. NYC <-> NYC, do you travel to Virginia?
All in all, none of these traceroutes posted show anything other than jitter inherrent to ALGX's network (who you buy from), and the speed of light taking longer for your packets to go a longer distance. If you do a traceroute from NYC to both destinations, you'll find that we are closer than Jupiter. Does that mean anything? Unless most of your surfers are in California, no it doesn't.
NYC has lower latency to eastern US, and western europe, as Transoceanic fiber paths terminate here (Gx's AC-1, Level3's Yellow, TAT-14). California has lower latency to western US and East-Asian (Japan of particular concern). If you make more money from west-us and japan, california may be "better" for you, if you make more money from east-us and western europe (UK, Germany, France, Italy, etc.), NYC may be "better" for you. While traditionally japanese networks have better connectivity to the west coast, we still do have direct connectivity to asian networks, for example, Japan Telecom, KDDI and China Telecom (HINet).
On top of all of that, even if "you" have a problem with slow download speeds, keep in mind economics. You are buying from ALGX, who has been in bankruptcy for quite some time, and was recently bought out by qwest. ALGX has had saturated peers for a long time now. There's nothing anyone can do about it other than ALGX, so in this case, ALGX may have a saturated connection that affects ISPrime, but not Jupiter. considering ALGX is largely a dead network with almost no customers, this is more of ALGX's problem than anyone else's (and, effects any algx customer going over that particular peer, which in this case, would be level3, which is the largest tier1 network in terms of route-miles today). As ALGX was recently bought out by Qwest, it's only a matter of time until the networks are integrated, so you should have better connectivity to us, as we have multiple non-saturated ways to reach Qwest in NYC (and in fact, Qwest has a POP 2 doors down from ours).
Consider running a test from a network that is known to not be maxing out peers due to economic conditions (Qwest, Level3, Sprint, AOL/Roadrunner come to mind). Consider speed of light. Consider where your important customers are, and how they relate to your host topology wise. Additionally, none of this thread touches on Support, Uptime, and many other variables that are probably much more important to a "Quality" host.
Merry Christmas!
