dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
22
share rss forum feed

stardust3

join:2012-09-08
united state
reply to monicakm

Re: Gen4/Changes Coming After Jan 1

Just a followup on my previous post. No I do not know anything in regards to gen4 at the 1st of the year.
The repair order I went on this morning that was to replace the radio for slow speeds was interesting. First thing I did before replacing anything was to run some speed tests & check signal. Sqf was 161 on beam 40, bypassed switch & router using laptop with win 7/google chrome straight to modem. 2 speed tests before replacing anything were 15222/860 & 15112/990. I was shocked to say the least, internet was responsive, browsing was quick, & a youtube video played flawless. I went ahead & replaced the radio per work order even though there probably wasn't a thing wrong with it. Repeated the process again, sqf was the same, speed test were a little different this time. 12560/1065 & 12129/794, not a 100% sure the modem was finished updating while running the 2nd test. Either way ovt passed with flying colors & all the #'s looked good. I did not get a chance to run any speed tests through his network, his daughter or daughter in law was there to let me in & spoke with customer on phone to inform him of what I found/didn't find.
Don't know if it was the time of day, something in his network, or what but everything at that point in time seemed to be good.
Had a gen4 upgrade real recently that would not sync to this router no matter what I did. Even though it worked perfectly on the previous 9000 system. Fortunately the lady had a brand new llinksys in the box, hooked it up & it worked flawless.
I'm clueless what is causing these speed issues. I hope it can get resolved. A little more forth coming from hughes would be nice even if they don't know the answer.

TexasRebel

join:2011-05-29
Edgewood, TX
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?