dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
22
share rss forum feed

TexasRebel

join:2011-05-29
Edgewood, TX
reply to stardust3

Re: Gen4/Changes Coming After Jan 1

this is why the speeds are crap on HNG4.. Their connection to the internet is crap, meaning they either don't have the bandwidth to handle all the traffic or they have serious flaws in their traffic shaping software or whatever it is.

Everywhere you see timeouts, means it's dropping packets because the bandwidth isn't there or it a software problem..

C:\Windows\system32>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms DD-WRT [192.168.1.251]
2 1 ms 1 ms 1 ms 100.75.75.25
3 651 ms 639 ms 669 ms dpc6935160130.direcpc.com [69.35.160.130]
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 1440 ms 629 ms 664 ms 67.131.14.218
8 1400 ms 659 ms 680 ms 66.249.94.212
9 655 ms 639 ms 611 ms 66.249.94.199
10 723 ms 698 ms 708 ms 216.239.46.208
11 674 ms 1131 ms 697 ms 216.239.48.165
12 * * * Request timed out.
13 748 ms 639 ms 669 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.


dbirdman
Premium,MVM
join:2003-07-07
usa
kudos:5
said by TexasRebel:

Everywhere you see timeouts, means it's dropping packets because the bandwidth isn't there or it a software problem..

No. It COULD meant that, but rarely does on a ping or tracert.

What it USUALLY means is a router that is setup to not respond to ICMP requests. Not at all uncommon on some networks.

If the final IP in a tracert does not accept ICMP, then the trace never completes. for intermediates, you just get a timeout and it moves on.

An example of a site that won't accept? Try tracing or pinging www.microsoft.com
--
Motosat self-pointing dishes: .74 meter G74 on 127W, SL-5 HD DirecTV|Hughes HN7000S|Verizon UMW190 Air Card|1990 Blue Bird Wanderlodge Bus "Blue Thunder"|Author of hnFAP-Alert, PC-OPI and DSSatTool

TexasRebel

join:2011-05-29
Edgewood, TX
no, it's definitely a bandwidth issue or a software issue on the ground. here's a tracert I did earlier this morning around 6:30am.

I understand about some routers not responding to iCMP pings. But these packet losses are happening during peak times, which it seems for HNG4 it's 9AM-2AM, a 16 hour window.

much different outcome at around 6:30AM.

C:\Windows\system32>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms DD-WRT [192.168.1.251]
2 1 ms 1 ms 1 ms 100.75.0.201
3 650 ms 1539 ms 689 ms dpc6935160130.direcpc.com [69.35.160.130]
4 613 ms 649 ms 618 ms dpc6935164017.direcpc.com [69.35.164.17]
5 661 ms 649 ms 649 ms tuk-edge-11.inet.qwest.net [63.235.80.137]
6 1094 ms 770 ms 748 ms sea-edge-12.inet.qwest.net [67.14.41.62]
7 622 ms 679 ms 649 ms 67.131.14.218
8 701 ms 661 ms 659 ms 66.249.94.214
9 1696 ms 859 ms 639 ms 66.249.94.197
10 1288 ms 629 ms 689 ms 216.239.46.200
11 619 ms 644 ms 654 ms 216.239.48.165
12 * * * Request timed out.
13 655 ms 659 ms 639 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.


dbirdman
Premium,MVM
join:2003-07-07
usa
kudos:5
OK, since the missing hops are mostly outside the Hughes network it probably just is a true timeout. Have your tried opening up the tracert timeout window?