So I use Claro Guatemala for my ISP. I pay for 10/1 service. But for the last few weeks, my internet speeds have been terrible. Most d/l speeds (actual downloads on actual files) show around 10-15 MBps.

If I do a Speedtest on a Claro server, be it in Guatemala, Honduras, or any other country with Claro, I get something like 10.5d/1u. But if I switch to ANY other server, be it in the same city or any other around the world, and my speeds show around 0.5d/1u. Same if I use SpeedOf.me, TestMy.net, etc.

Below is a copy of tracert to google.com. The second jump ALWAYS times out.}

Traza a la dirección google.com []
sobre un máximo de 30 saltos:

  1     3 ms     5 ms     3 ms
  2     *        *        *     Tiempo de espera agotado para esta solicitud.
  3    34 ms    48 ms    15 ms
  4    54 ms    49 ms    26 ms
  5    18 ms    41 ms    55 ms
  6    68 ms    32 ms    21 ms
  7    52 ms    60 ms    32 ms
  8    98 ms   181 ms    67 ms  xe-10-3-6.mia10.ip4.gtt.net []
  9   110 ms    85 ms    80 ms
 10    81 ms   115 ms    69 ms
 11    82 ms    80 ms    84 ms
 12   109 ms    72 ms    83 ms  mia07s34-in-f14.1e100.net []

Traza completa.

All my router power/noise levels have been checking out as within normal range. Ive been basically arguing with my ISP about this, as their techs are next to useless...a few have shown up, ran a speed test on their own server and said its fine, others listen to me, but they´ve all been stumped.

I tried changing my DNS on my router, but its blocked, and I cant get into it via telnet. I changed it on my laptop, but it didnt help, if it even made a difference.

What in the world could be causing this? Im fed up trying to get the techs to do this correctly, and I cant figure it out. Any help or suggestion is greatly appreciated.

  • 1
    The answer is simple, your existing tests have already proven it... You test to any server within your ISP's network and it's good, outside of their carrier network is not, therefore everything within your ISP's network is fine, their uplink to the rest of the world or an upstream carrier is the problem. Welcome to the real world, your carrier probably knows and is (hopefully) working with them to fix it, or it is farther upstream than that and there is nothing they can do. The Internet may be a "cloud" but that really means several distinct, linked networks, which do have problems sometimes. – acejavelin Apr 4 '16 at 2:55
  • This has been my assumption the entire time, and hence why I keep arguing with them about their wanting to send techs to my house. The only issue, which I probably should have mentioned, is that other people with the same ISP, including some basically right down the road, have not had the same issue I have. The only other big concern Ive had is that they are possibly throttling my connection for some reason? But I cant really prove that. – Derek Apr 4 '16 at 2:59
  • That was a pretty important piece you left out, and although it is worht investigating, it doesn't change my previous statement, although the focus could be different, you could be on an overloaded DSLAM or carrier node, or that nodes upstream link could be bad. Either way, it is likely a carrier issue. – acejavelin Apr 4 '16 at 3:03

While it is typical for your ISP to respond the best in speed tests, in your case I would suspect your ISP is doing one of two things:

  1. Cheating on the test. This involves recognizing that the traffic is a speed test and then dedicating resources to it so they rate as high as they can.

  2. Having problems handing your traffic off to other providers. The world of ISP border traffic negotiation is partially political. For example, ISPs (and network providers) generally charge each other for traffic passed from one network to another. Sometimes an ISP doesn't pass through enough traffic of another provider to get a deal where they agree to pass each others traffic for little cost. Sometimes a foreign ISP will charge excessively for the privilege. The end result is that the traffic crossing the edge is relatively expensive so either your ISP is trying to limit traffic going that way or the other ISP is intentionally limiting traffic from your ISP.

Either way, you get screwed and there's not a lot you can do about it. They won't admit it's happening and you can't prove it's happening. They can easily blame your or others' equipment and you don't really have a way to prove otherwise or do anything about it.

(Regarding the ping timeout: This is normal. tracert uses pings to do what it does. It's not required that all equipment respond to pings. Those that don't will appear like that.)

  • No, tracert doesn't use ping. Those are two different protocols. Ping sends an echo request, and it expects an echo reply, but tracert uses the IP TTL field to elicit ICMP error messages. – Ron Maupin Apr 4 '16 at 3:04
  • 1
    @RonMaupin There are several methods used, one of which uses ICMP Echo Requests, otherwise known as pings. Windows' tracert.exe uses pings. Regardless of the method, the issue is the same: Equipment is not required to respond to it. – Ouroborus Apr 4 '16 at 3:09
  • It doesn't look for echo replies, it uses the TTL and looks for error messages. – Ron Maupin Apr 4 '16 at 3:12
  • @RonMaupin "Tracert works by incrementing the TTL value by one for each ICMP Echo Request it sends, then waiting for an ICMP Time Exceeded message." as described at technet.microsoft.com/en-us/library/cc940128.aspx. An error response can be considered a kind of reply. – Ouroborus Apr 4 '16 at 3:14
  • Yes, it uses the TTL and looks for error messages, not echo replies. It also uses ICMP type 30, but a ping uses ICMP type 8. – Ron Maupin Apr 4 '16 at 3:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.