Do other computers fear the Chicago Machine?

April 23, 2009 5:34 PM

My DSL is slow...but only when connecting to servers outside Chicago. What gives?

I'm located in Chicago. I have a3mbps down/512kbps up plan with my DSL provider, who rides on AT&Ts lines. When I do a speedtest on a server located in Chicago (or download files from it) I get around 2.43 downstream/0.43 up. When I connect to a server anywhere else (including Milwaukee or St. Louis) my speed drops to 1.4 downstream/0.32 up. My DSL provider claims that their line tests show that everything is okay, and so does AT&T. They want to dispatch a technician, on my dime, to diagnose the problem. The rate they quoted sounds like it will add up to a few hundred dollars.

I've removed every extraneous device - I just have my main computer hardwired into the new DSL modem that my provider sent me. Because I get full speed to servers in Chicago, it doesn't sound to me (who is admittedly a n00b at networks) like it's a problem with my local circuit. Is it possible that this is a problem on my end? Is it worth it for me to fork over a few hundred dollars for the technician to tell me that the problem is upstream?

posted by burnfirewalls to computers & internet (5 comments total)

Well, whats your traceroute look like? I imagine the issue is that once you hit an edge router or whatever route your network is taking out of chicago then youre hitting some laggy lines. I'd wait this out and not pay a dime for them to look into this. Especially if theyre going to bill you two hours labor to tell you that some OC3 line out of Chicago is acting up.

That said, speed tests are unreliable and theyre always being pounded. Have you tried downloading from a site with lots of bandwidth like downloading the java SDK or SP3 from MS?
posted by damn dirty ape at 6:57 PM on April 23

Run a traceroute first, see where the problem is. Instructions. If it's not your setup, then why should you pay.
posted by gemmy at 7:24 PM on April 23

Understood. I did a tracert, but what do the three columns of numbers mean?
posted by burnfirewalls at 8:31 PM on April 23

Each number is a round trip time -- you send three probes per hop. Let's show you a real life example.

iMac: ~ -> traceroute 4.2.2.2
traceroute to 4.2.2.2 (4.2.2.2), 64 hops max, 40 byte packets
1 192.168.101.1 (192.168.101.1) 0.534 ms 0.306 ms 0.204 ms
2 er1.chi1.speakeasy.net (64.81.148.1) 15.973 ms 13.817 ms 14.736 ms
3 220.ge-0-1-0.cr2.chi1.speakeasy.net (69.17.83.153) 12.993 ms 12.666 ms 13.774 ms
4 unknown.Level3.net (166.90.208.205) 34.009 ms 63.212 ms 16.537 ms
5 vnsc-bak.sys.gtei.net (4.2.2.2) 13.454 ms 13.814 ms 13.762 ms

What traceroute does. It sends an UDP packet with a time-to-live field set. TTL decrements by one as each router forwards the packet. So, the first three probes are set with a TTL of one. They reach my router (here, 192.168.101.1) and it decrements the TTL. Since we started with one, this hits zero. TTL exceed, and the remote router sends back an ICMP TIME_EXCEED packet. Traceroute measures the time between sending the UDP packet and getting the ICMP packet back. In the first hop, this time is very short -- the distance is literally single digit feet.

Then, traceroute sends three probes with the TTL set to two. The outbound packet hits my router, which decrements TTL (to one) and sends it to the next router. This hits 64.81.148.1, and it decrements, hits zero, HEY, sends back the ICMP, and we get the time to that router. It's longer, that's my DSL hop.

What your looking for is unusually high or unusually random numbers. For example, look at hop 4. Note how the three probes have pretty divergent values. Normally, this is a bad sign, but I picked 4.2.2.2 for a reason, in this particular case, it's not*.

In general. Values under 50ms on a hop are good, under 20ms are very good. Values over 300ms are problems -- for example, most of the Europe Level 3 routers are 115ms from me. Better wires have less latency -- the DS-3 in my offices has less than 10m round trip times to Kanas City (from St. Louis), my home computer has around 15ms round trip times to Speakeasy's Chicago Pop, from Northwest Chicago (city, not suburban.)

Guess which line costs more?

Note: Not all the time is the wire -- some is the computer, which has to process the packet. Stop playing games and video while you're testing.


* The Verizon/GTIE nameserver are very trick and the upstream routers will point you at the closest one. The randomness here is figuring out which is the closest one. DO NOT ABUSE 4.2.2.2-4.2.2.6.
posted by eriko at 9:00 PM on April 23

You might try a few other ways to collect data too, burn. Run the non-mail tests from Testing Network Faults to see what kind of results you get.

What you are looking for is if a specific server on your outbound traces is slowing you down. Try a trace to several different places and see if you can spot a pattern of a specific server giving you a very high number. The continuous ping command can show you if there are any weird fluctuations in your connection that might cause you to have issues.

You can also try to look at your signal levels to see if the problem has anything to do with signal loss.

How long ago did you receive the modem? Did you pay for it outright, or rent it? Personally, in all five instances in the last eight years or so when we have had odd internet issues, it was solved by getting a new modem. YMMV, obviously.
posted by gemmy at 9:32 AM on April 24