dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
10548
raghu1111
join:2009-03-05
San Jose, CA

2 edits

raghu1111

Member

Very jittery upstream (big variation in ping) San Jose, CA

I think this has been happening for couple of months. I saw this forum only recently and recent use of voip phone made it more obvious (the receiver hears extremely choppy voice during those times).

Problem :

Internet quality degrades badly, starting in the late afternoon.

Voip Quality test shows that upstream is very jittery (large variations in delays some exceeding 1 second) and quality (pauses in download and upload) is pretty bad :
Speed test statistics
---------------------
Download speed: 2590840 bps
Upload speed: 1153800 bps
Quality of service: 36 %
Download test type: socket
Upload test type: socket
Maximum download pause: 1311 ms
Average download pause: 9 ms
Minimum round trip time to server: 86 ms
Average round trip time to server: 236 ms
 
VoIP test statistics
--------------------
Jitter: you --> server: 218.2 ms
Jitter: server --> you: 0.3 ms
Packet loss: you --> server: 0.0 %
Packet loss: server --> you: 0.0 %
Packet discards: 0.0 %
Packets out of order: 0.0 %
Number of supported VoIP lines: 19
Estimated MOS score: 3.5
 

Note that there is no packet loss, but upstream ("you to server") jitter is very high, pause is pretty large.

I have started a smokeping here.
Ping varies a lot : for e.g. :
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=32 ttl=48 time=1310 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=33 ttl=48 time=314 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=34 ttl=48 time=365 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=35 ttl=48 time=2340 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=36 ttl=48 time=1347 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=37 ttl=48 time=347 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=38 ttl=48 time=117 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=39 ttl=48 time=91.2 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=40 ttl=48 time=153 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=41 ttl=48 time=126 ms
64 bytes from w2.rc.vip.re4.yahoo.com (206.190.60.37): icmp_seq=42 ttl=48 time=100 ms
 

This condition lasts quite a few hours. Next day morning, it might be fine. Cable modem signal levels are good. The location is San Jose, CA.

traceroute for google.com:
traceroute to google.com (209.85.171.100), 30 hops max, 40 byte packets
 1  DD-WRT (192.168.0.1)  0.821 ms  1.010 ms  1.227 ms
 2  * * *
 3  te-4-2-ur09.sanjose.ca.sfba.comcast.net (68.85.190.177)  340.919 ms  341.128 ms  341.372 ms
 4  te-8-3-ur04.sanjose.ca.sfba.comcast.net (68.87.226.62)  340.446 ms  340.893 ms  341.065 ms
 5  te-7-1-ur03.sanjose.ca.sfba.comcast.net (68.87.192.41)  341.874 ms  341.879 ms  341.947 ms
 6  be-40-ar01.sfsutro.ca.sfba.comcast.net (68.87.226.225)  345.094 ms  338.663 ms  338.533 ms
 7  pos-1-7-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.90.153)  338.664 ms  25.702 ms  25.581 ms
 8  xe-10-0-0.edge1.SanJose1.Level3.net (4.71.118.29)  25.225 ms  33.832 ms  34.067 ms
 9  vlan99.csw4.SanJose1.Level3.net (4.68.18.254)  37.169 ms vlan69.csw1.SanJose1.Level3.net (4.68.18.62)  33.214 ms vlan79.csw2.SanJose1.Level3.net (4.68.18.126)  33.362 ms
10  ae-91-91.ebr1.SanJose1.Level3.net (4.69.134.205)  33.460 ms  30.311 ms ae-81-81.ebr1.SanJose1.Level3.net (4.69.134.201)  30.374 ms
11  ae-3.ebr1.Seattle1.Level3.net (4.69.132.50)  52.566 ms  55.961 ms  82.418 ms
12  ae-11-51.car1.Seattle1.Level3.net (4.68.105.2)  87.182 ms  86.880 ms  78.816 ms
13  GOOGLE-INC.car1.Seattle1.Level3.net (4.79.104.74)  139.728 ms  139.732 ms  139.686 ms
14  209.85.249.34 (209.85.249.34)  114.410 ms  114.201 ms  113.796 ms
15  216.239.46.212 (216.239.46.212)  84.321 ms 209.85.250.126 (209.85.250.126)  87.518 ms 72.14.239.12 (72.14.239.12)  99.152 ms
16  64.233.174.99 (64.233.174.99)  1224.549 ms * 209.85.250.144 (209.85.250.144)  1244.293 ms
17  209.85.251.129 (209.85.251.129)  1222.193 ms 209.85.251.153 (209.85.251.153)  1239.235 ms 64.233.174.97 (64.233.174.97)  1185.383 ms
18  209.85.251.141 (209.85.251.141)  1210.019 ms 209.85.251.153 (209.85.251.153)  1211.809 ms 209.85.251.145 (209.85.251.145)  1192.693 ms
19  74.125.30.134 (74.125.30.134)  1195.332 ms 74.125.31.6 (74.125.31.6)  1182.232 ms 74.125.30.130 (74.125.30.130)  1184.221 ms
20  cg-in-f100.google.com (209.85.171.100)  1157.775 ms  240.473 ms  255.870 ms
 

What could be wrong? I think there are some real problems with the Comcast network. I have been using Comcast HSI for many years I don't think I have seen such flakiness before.

I am equally interested knowing if such problems usually get fixed for users here. How do we explain this to Comcast?

I hope a few Comcast network experts follow this forum. I can provide any more info that is needed to diagnose the problem.

btw, bandwidth tests like speedtest.net also varies a lot during those times.

tshirt
Premium Member
join:2004-07-11
Snohomish, WA

2 edits

tshirt

Premium Member

Re: Very jittery upstream (big variation in ping amd more),

There are several factors going on here.
late afternoon more kids get home from school, and people get done at work, so residential internet usage rises rapidly, congesting the local network.
Plus right now the bay area is in the process of getting/getting ready for DOCSIS3 upgrades so some of the local routes may be temporarily out of service leading to some more round about routing/ heavy congestion on the remaining routes.
a third factor in the test results may be where you are testing to
The VoIP tester is in LA, try this one instead »myvoipspeed.visualware.c ··· sjc.html

the yahoo address, even though it geo locates in Sunnyvale, appears to route thru chicago and DC and assorted other places (at least from here)

and as was recently pointed out in another thread pinging google.com gives a generic, roundabout route to a heavily overloaded inflow, where pinging www.google.com or www.l.google.com (that's a lower case L) will give a much better, more consistant results.

A forth possiblity is your connection is being effected by afternoon weather/temps, some other enviromental factor.
the best way to get help with that is to provide this info, back in this thread »Comcast High Speed Internet FAQ »How To Get Help!

Oh, BTW yes it will eventually get better, exactly when(tomorrow? next week?, next year?) only comcast knows. (and unfortunately many of the people you get to talk to on the phone either don't know or make a wild guess.)
However it nevers hurts to call and let them know, if the get enough calls from a particular area they may expedite the work as much as possible.
raghu1111
join:2009-03-05
San Jose, CA

1 edit

raghu1111

Member

Click for full size
SmokePing from 03/05 7pm till 03/06 10am PST
Thanks for the reply.

If it is congestion, many people in the area should be affected. How is Comcast getting away with it?

I hope Comcast engineers can confirm this so that we know it is a known issue will have better confidence it will be fixed. I am surprised in this day and age, an internet provider could let quality to suffer some much for so long.

The following SmokePing plot between start of the test (7pm PST) and 10pm today shows great degradation in delays.

More infor regd my setup :
Modem : SurfBoard SB5120 (I own it)
Router : Buffalo WHR-HP-G54 running latest DD-WRT
There are no firewalls involved on the computers.
The signal numbers on modem are good all through the day : (S/N : 35, power level down : -1 dBmV, up : 44 dBmV, etc)

I will try removing the wireless router. But doubt it matters.

I will post ping to www.l.google.com as you suggested during evening again.
kcbrown
join:2005-08-08
Santa Clara, CA

1 edit

kcbrown

Member

I've been experiencing the very same thing (I'm in Santa Clara).

I'd say the problem is that the local segment is oversubscribed. If you ping the default gateway assigned to you by Comcast (you may have to look at your router to find out what it is) you'll find that the latency spikes appear there. So the problem isn't with Comcast's internal network itself (e.g., between routers within their network), but instead is with the local segment itself: the IP-level connection between you and the default router. The signal (as seen by the modem) appears to be fine, so I have no reason to believe that the problem is at the link layer. Instead, this looks like an oversubscription issue.

The fact that this problem occurs only during what could be considered "peak" hours lends strong support to the oversubscription hypothesis.

I have no idea when this will likely be fixed. But it is mighty annoying, because it makes my VPN into work largely useless.

For what it's worth, my default gateway is 67.169.24.1.
kcbrown

kcbrown to raghu1111

Member

to raghu1111

Re: Very jittery upstream (big variation in ping) San Jose, CA

By the way, I keep statistics on my connection. Every 10 minutes I sample the ping round trip time, packet loss, and signal to noise ratio, and stick the results in the database. I can tell when there's a signal-level outage and can tell when there's a problem with the first hop.

My records show that there was a signal-level outage starting at 1am on Feb. 27 and lasting until 4am. At 4am, it appears service was restored.

Prior to that outage, the connection was smooth, with very little jitter: average ping times prior to the outage ranged between 10 and 30 milliseconds throughout the day and night.

After the outage, the connection has been very jittery during "peak" hours, with average ping times ranging from 15 milliseconds to 2000 milliseconds.

I can't help but think the outage was the result of them putting me onto a different virtual segment or something, one that is more heavily populated and/or much more heavily used than the one I was on.

And like I said, I am mightily annoyed.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to tshirt

MVM

to tshirt

Re: Very jittery upstream (big variation in ping amd more),

said by tshirt:

the yahoo address, even though it geo locates in Sunnyvale, appears to route thru chicago and DC and assorted other places (at least from here)
Routing is probably an artifact of tracing route to 'google.com' instead of tracing route to 'www.google.com'. Google normally takes you to a server close to the source. Using 'google.com', instead of 'www.google.com', seems to override that action.

A 'google.com' trace route takes me to the east coast:
03/06/09 12:51:23 Slow traceroute google.com
Trace google.com (74.125.67.100) ...
192.168.0.1     RTT:   0ms TTL:170 (suzuka.aosake.net ok)
68.127.107.254  RTT:  11ms TTL:170 (adsl-68-127-107-254.dsl.pltn13.pacbell.net ok)
64.164.107.2    RTT:  23ms TTL:170 (No rDNS)
151.164.93.239  RTT:  11ms TTL:170 (No rDNS)
69.220.8.33     RTT:  30ms TTL:170 (No rDNS)
72.14.198.105   RTT:  12ms TTL:170 (No rDNS)
209.85.240.114  RTT:  24ms TTL:170 (No rDNS)
209.85.243.247  RTT:  85ms TTL:170 (No rDNS)
209.85.254.247  RTT:  82ms TTL:170 (No rDNS)
209.85.255.198  RTT:  85ms TTL:170 (No rDNS)
74.125.67.100   RTT:  95ms TTL:241 (gw-in-f100.google.com ok)
 

OTOH, here is a trace to 'www.google.com':
03/06/09 12:54:19 Slow traceroute www.google.com
Trace www.google.com (209.85.171.103) ...
192.168.0.1     RTT:   0ms TTL:170 (suzuka.aosake.net ok)
68.127.107.254  RTT:  10ms TTL:170 (adsl-68-127-107-254.dsl.pltn13.pacbell.net ok)
64.164.107.129  RTT:   9ms TTL:170 (No rDNS)
151.164.241.216 RTT:   9ms TTL:170 (No rDNS)
69.220.8.33     RTT:  11ms TTL:170 (No rDNS)
72.14.197.105   RTT:  10ms TTL:170 (No rDNS)
209.85.240.114  RTT:  11ms TTL:170 (No rDNS)
216.239.49.198  RTT:  25ms TTL:170 (No rDNS)
209.85.250.144  RTT:  27ms TTL:170 (No rDNS)
64.233.174.127  RTT:  28ms TTL:170 (No rDNS)
209.85.251.125  RTT:  28ms TTL:170 (No rDNS)
74.125.31.134   RTT:  29ms TTL:170 (No rDNS)
209.85.171.103  RTT:  29ms TTL:243 (cg-in-f103.google.com ok)
 
Destination is much closer to the source.
raghu1111
join:2009-03-05
San Jose, CA

1 edit

raghu1111 to kcbrown

Member

to kcbrown
said by kcbrown:

I'd say the problem is that the local segment is oversubscribed. If you ping the default gateway assigned to you by Comcast (you may have to look at your router to find out what it is) you'll find that the latency spikes appear there.[...]
That might be the case. Does it explain why there are large spikes and variations only in upstream but not on downstream? I will try pinging the gateway.

NormanS, you are probably right. But this issue is not about google.com, but rather about large delays and fluctuations in comcast network. I think picking the best www.google.com site is secondary. Sure, I will use www next time. Do you see anything insightful in either your tracerout or mine about this this issue? Thanks.

tshirt
Premium Member
join:2004-07-11
Snohomish, WA

1 edit

tshirt to NormanS

Premium Member

to NormanS
said by NormanS:

said by tshirt:

the yahoo address, even though it geo locates in Sunnyvale, appears to route thru chicago and DC and assorted other places (at least from here)
Confused as to why you quoted and struck me on that part NormanS See Profile
I was referring to his ping to w2.rc.vip.re4.yahoo.com (206.190.60.37) which for me ends a few hops past DC
tshirt

2 edits

tshirt to raghu1111

Premium Member

to raghu1111

Re: Very jittery upstream (big variation in ping) San Jose, CA

I agree that your first hop or 2 (68.85.190.177) are could be a large part of the problem.
PINGing/tracerouting to distant points just adds more room for errors.
Try Pinging 68.85.190.177 for a few minutes to see what you get. From here I get a very consistant/stable 30-31ms about what I'd expect from seattle to San Jose.
raghu1111
join:2009-03-05
San Jose, CA

raghu1111 to kcbrown

Member

to kcbrown
said by kcbrown:

[...] After the outage, the connection has been very jittery during "peak" hours, with average ping times ranging from 15 milliseconds to 2000 milliseconds.
pretty much what I see. For Comcast, only non peak hours seems to be 1AM to 7AM!

I can't help but think the outage was the result of them putting me onto a different virtual segment or something, one that is more heavily populated and/or much more heavily used than the one I was on.
What you are guessing is that we got unlucky and got dumped into a bad pool! I must have been on that for many weeks. Some Comcast angels reading this hopefully take us out of these, if possible.

my gateway is 76.103.56.1. My ip changed last night (but no change in problems).

tshirt
Premium Member
join:2004-07-11
Snohomish, WA

1 edit

1 recommendation

tshirt

Premium Member

said by raghu1111:

my gateway is 76.103.56.1. My ip changed last night (but no change in problems).
that's actually a good sign
Here's my theory
First in order to clear a rack for the new equipment, they condense exisiting customers to a few channels/cards (hense the congestion you've seen) once clear the can replace the old equipment with new D3 and populate it, .
Now they move some/all to the new equipment (may still be congested) and redo the second rack.
Now they can go back to the lower user per card/channel scheme and still have the extra channels required for the D3 tiers.
My IP range changed when the D3 was completed but it took a week or more for speeds to settle at a consistant rate around the clock.
So you may be close to the "DONE" stage

bayareanon
@pacbell.net

bayareanon to raghu1111

Anon

to raghu1111
Call and complain every time it gets like that.

Have a tech come out and check everythign carefully.

If that doesn't fix it, call again.

That's what I had to do to FINALLY get someone from Comcast to admit the problem wasn't with my inside wiring or my modem (which I own).

5 phone calls and 2 tech visits, and as far as I know it's STILL not fixed (but they did tweak the signal levels on my modem so that when the signal levels swing wildly - as much as +/- 6dbmv on the downstream - at least it stays within spec so the modem doesn't constantly reset and/or hunt for a new channel.

Call. Complain. Rinse. Repeat.
raghu1111
join:2009-03-05
San Jose, CA

raghu1111 to tshirt

Member

to tshirt
said by tshirt:

that's actually a good sign
Here's my theory [...]
I hope you are right. The subnet hasn't changed just the last number changed by 12.

I really wish U-verse was available here.. so that Comcast has a better motivation to treat customers better (not that U-verse would be free of problems).

We understand need to do maintenance that could take multiple days, but what is annoying is the total lack of information.. if some one could (unofficially) give us some useful info from Comcast side, it would be so much better. Who knows, our theory about congestion and maintenance might not be so accurate.. plus it is surprising that it lasts so many weeks for me.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to tshirt

MVM

to tshirt

Re: Very jittery upstream (big variation in ping amd more),

Sorry. Peeked at the OP's trace; didn't think to look at the ping. Same difference, though. A trace to 'yahoo.com' takes me far:
03/07/09 02:35:51 traceroute 206.190.60.37
Trace 206.190.60.37 ...
192.168.0.1     RTT:   0ms TTL:170 (suzuka.aosake.net ok)
68.127.107.254  RTT:   9ms TTL:170 (adsl-68-127-107-254.dsl.pltn13.pacbell.net ok)
64.164.107.2    RTT:   9ms TTL:170 (No rDNS)
151.164.42.102  RTT:   9ms TTL:170 (bb2-10g2-0.pltnca.sbcglobal.net ok)
70.245.63.230   RTT:  11ms TTL:170 (ex1-p3-0.eqsjca.sbcglobal.net ok)
151.164.248.58  RTT:  10ms TTL:170 (asn10310-yahoo-10g.eqsjca.sbcglobal.net ok)
216.115.101.150 RTT:  55ms TTL:170 (as1.pat2.da3.yahoo.com ok)
216.115.101.154 RTT:  91ms TTL:170 (so-1-0-0.pat2.dcp.yahoo.com ok)
216.115.108.67  RTT:  90ms TTL:170 (ae2-p161.msr1.re1.yahoo.com ok)
216.39.49.1     RTT:  91ms TTL:170 (te-8-3.bas-a1.re4.yahoo.com ok)
206.190.60.37   RTT:  91ms TTL: 56 (w2.rc.vip.re4.yahoo.com ok)
 
A trace to 'www.yahoo.com' takes me near:
03/07/09 02:36:07 traceroute 209.131.36.158
Trace 209.131.36.158 ...
192.168.0.1     RTT:   0ms TTL:170 (suzuka.aosake.net ok)
68.127.107.254  RTT:  11ms TTL:170 (adsl-68-127-107-254.dsl.pltn13.pacbell.net ok)
76.246.22.129   RTT:   9ms TTL:170 (No rDNS)
151.164.93.237  RTT:   9ms TTL:170 (No rDNS)
70.245.63.230   RTT:  10ms TTL:170 (ex1-p3-0.eqsjca.sbcglobal.net ok)
151.164.248.58  RTT:  10ms TTL:170 (asn10310-yahoo-10g.eqsjca.sbcglobal.net ok)
216.115.107.63  RTT:  11ms TTL:170 (ae1-p161.msr1.sp1.yahoo.com ok)
209.131.32.17   RTT:  12ms TTL:170 (te-8-1.bas-a1.sp1.yahoo.com ok)
209.131.36.158  RTT:  10ms TTL: 56 (f1.www.vip.sp1.yahoo.com ok)
 

tshirt
Premium Member
join:2004-07-11
Snohomish, WA

tshirt

Premium Member

Click for full size
I think his PING was aimmed at w2.rc.vip.re4.yahoo.com (206.190.60.37) specifically
which appears to me to be very close/just outside DC (hard to decipher Yahoo hop names, but the ping is so similar, maybe somewhere in Virgina)
raghu1111
join:2009-03-05
San Jose, CA

raghu1111

Member

with all due respect, how far or near the server is totally besides the point. Please stop pointing that out. We are not complaining about ping times, we are complaining about wild variations and jitter in ping times. Note dslreport's SmokePing from CA1 and from NY look the same in "variation".. just the minimum ping is different.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA

NormanS

MVM

With all due respect. isn't it better to ping an IP address determined from an nslookup on an actual target FQDN ('www.yahoo.com'), than on the IP address of a generic domain name? Regardless of anything else you wish to discuss.
raghu1111
join:2009-03-05
San Jose, CA

raghu1111

Member

Alright, following is a ping to my gateway (close enough, i hope) taken around 1pm Satday. Notice some pings taking 1 to 2 seconds! Ping ranges from 11ms to 2347ms.

$ ping 76.103.56.1
PING 76.103.56.1 (76.103.56.1) 56(84) bytes of data.
64 bytes from 76.103.56.1: icmp_seq=1 ttl=254 time=598 ms
64 bytes from 76.103.56.1: icmp_seq=2 ttl=254 time=137 ms
64 bytes from 76.103.56.1: icmp_seq=3 ttl=254 time=44.8 ms
64 bytes from 76.103.56.1: icmp_seq=4 ttl=254 time=119 ms
64 bytes from 76.103.56.1: icmp_seq=5 ttl=254 time=39.6 ms
64 bytes from 76.103.56.1: icmp_seq=6 ttl=254 time=34.0 ms
64 bytes from 76.103.56.1: icmp_seq=7 ttl=254 time=2347 ms
64 bytes from 76.103.56.1: icmp_seq=8 ttl=254 time=1356 ms
64 bytes from 76.103.56.1: icmp_seq=9 ttl=254 time=356 ms
64 bytes from 76.103.56.1: icmp_seq=10 ttl=254 time=664 ms
64 bytes from 76.103.56.1: icmp_seq=11 ttl=254 time=11.0 ms
64 bytes from 76.103.56.1: icmp_seq=12 ttl=254 time=36.1 ms
64 bytes from 76.103.56.1: icmp_seq=13 ttl=254 time=536 ms
 
raghu1111

raghu1111

Member

I think there is something wrong with these gateway routers or other machines involved. If it is just conjestion, it seems odd that it induces only delays upstream but no packet loss in either direction. Probably some misconfiguration that makes the problem worse as the traffic increases.

EG
The wings of love
Premium Member
join:2006-11-18
Union, NJ

3 edits

EG

Premium Member

said by raghu1111:

it seems odd that it induces only delays upstream but no packet loss in either direction.
It's not really odd. The upstream channel/s is/are narrower than the downstream channel/s (not as much bandwidth capability) and are therefore easier to congest/saturate.

I'm not referring to routers here, I'm referring to the hybrid fiber coax connection between the premises and the local headend.

xxhiroshi21x
join:2009-03-02
Salisbury, MD

xxhiroshi21x to raghu1111

Member

to raghu1111

Re: Very jittery upstream (big variation in ping) San Jose, CA

If you can, go into your modem and find out the power levels (dBmV) that your modem is reporting, too high or too low a level will create an unstable connection, and cause not only your HSI to suffer, but your VOIP based phone as well.
nextisthe
join:2001-08-16
Emeryville, CA

nextisthe to raghu1111

Member

to raghu1111
Im in Oakland, CA and today was the 2nd time I had such a bad upstream connection that Internet access was useless. I have a feeling its some maintenance they are doing, but thats just a hunch. Both times it clears up EXACTLY at 8PM and the last time this happened was EXACTLY 2 weeks ago. I get massive packet loss just pinging my first hop. Its quite annoying.

EG
The wings of love
Premium Member
join:2006-11-18
Union, NJ

1 edit

EG to xxhiroshi21x

Premium Member

to xxhiroshi21x
said by xxhiroshi21x:

If you can, go into your modem and find out the power levels (dBmV) that your modem is reporting, too high or too low a level will create an unstable connection, and cause not only your HSI to suffer, but your VOIP based phone as well.
W.I.W, they already posted their modem stats..

Please review this entire thread.
eddychan
join:2002-09-25
Santa Clara, CA

1 edit

eddychan to raghu1111

Member

to raghu1111
Ok I just figured it out, I had the same exact problem with a Motorola SB5101 modem. Random ping times that ranges from 30ms to 2k ms. I played WOW, so its driving me nuts. Been happening since. Feb 26th when they upgraded to docsis 3.0.

What I figured out was there must be some sort of issues with the firmware on my modem and the upgraded network. What I did was went to:
»192.168.100.1/ (Modem configuration) Reset my modem to factory default. Then the modem downloaded a new firmware for itself and that fixed the problem.

Of course that was no help from the comcast tech support I called 3 times to try to fix the problem and to no avail. I love how they always think the problem is with your router or computer. And the fix is immediate, ping your gateway immediately after and no pings over 80ms.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

koitsu

MVM

said by eddychan:

Ok I just figured it out, I had the same exact problem with a Motorola SB5101 modem. Random ping times that ranges from 30ms to 2k ms. I played WOW, so its driving me nuts. Been happening since. Feb 26th when they upgraded to docsis 3.0.

What I figured out was there must be some sort of issues with the firmware on my modem and the upgraded network. What I did was went to:
»192.168.100.1/ (Modem configuration) Reset my modem to factory default. Then the modem downloaded a new firmware for itself and that fixed the problem.

Of course that was no help from the comcast tech support I called 3 times to try to fix the problem and to no avail. I love how they always think the problem is with your router or computer. And the fix is immediate, ping your gateway immediately after and no pings over 80ms.
The SB5101 also had a bug in older firmware versions where the modem would stop passing packets after a certain point/time. A firmware update fixed that problem.

I'd refer you to the (very long) thread of mine about it, but I can't seem to find it on the forums. Johkal See Profile was involved.
raghu1111
join:2009-03-05
San Jose, CA

raghu1111 to eddychan

Member

to eddychan
said by eddychan:

And the fix is immediate, ping your gateway immediately after and no pings over 80ms.
Thanks Eddy. I am trying out the fix. will report the status after the new firmware is running. Is there a way to confirm that new firmware is running?.

Btw, pinging the gateway ideally should not take more than a couple of milliseconds.. when you say max 80ms, is it varying from some low number (like 10ms) to 80ms?

sailorfrag
@comcast.net

sailorfrag to raghu1111

Anon

to raghu1111
I've been seeing this lately too in Mountain View CA. I've called their support people twice and they seem to not have any idea about active problems, just that it might get busy during the day.

Last night my ping times to the 3rd hop varied from 17ms to 2910ms. I was seeing speed test results 100kbps.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

2 edits

koitsu to raghu1111

MVM

to raghu1111
said by raghu1111:

said by eddychan:

And the fix is immediate, ping your gateway immediately after and no pings over 80ms.
Thanks Eddy. I am trying out the fix. will report the status after the new firmware is running. Is there a way to confirm that new firmware is running?.
Visit »192.168.100.1/, and choose the Help link on the left side. The firmware version will be shown. You will, of course, need to know what the previous version was for sake of comparison.
Btw, pinging the gateway ideally should not take more than a couple of milliseconds.. when you say max 80ms, is it varying from some low number (like 10ms) to 80ms?
Actually, "it depends" on if by gateway he means Comcast's gateway (e.g. the network router which he sends packets through upstream), or if he means his own LAN router (e.g. a Linksys WRT54G, etc.).

If he's seeing 80ms to his own LAN router, the problem is his own and has nothing to do with the SB5101.

If he's seeing flippant latency to the Comcast endpoint (gateway/network router), then this indicates either something wrong with his coax connection (check signal levels and SNR at »192.168.100.1/) or could be *completely normal*.

Network devices such as routers commonly prioritise ICMP packets last -- and in some cases, administratively drop ICMP packets while the router is under high load. Honestly "ping" is not going to suffice for troubleshooting this kind of problem. He will need to use a tool such as WinMTR or PingPlotter (recommended) which will show where the latency begins and if it trickles down through subsequent network hops.

It is 100% normal to see a traceroute that shows latency at hop #X, but then normal/acceptable latency at hop #X+1 or #X+2. You'd have to understand how tools like WinMTR and PingPlotter work to fully understand how this can happen.

Convincing Comcast that there's a problem when using these tools is fairly difficult, so consider yourself warned.

On the flip side, higher-than-normal latency to your local ISP's gateway *can* in fact indicate oversaturation on the router itself. As mentioned in the above paragraph, debugging this and convincing Comcast of it is nearly impossible -- getting in touch with the right people is very, very difficult. If you do phone something like this in, be sure to say "IP network" and not "network", otherwise the techs will think you're referring to the cable/coax network.
koitsu

koitsu to sailorfrag

MVM

to sailorfrag
out.txt
63,670 bytes
03/09 periodic mtr, hop #3
said by sailorfrag :

I've been seeing this lately too in Mountain View CA. I've called their support people twice and they seem to not have any idea about active problems, just that it might get busy during the day.

Last night my ping times to the 3rd hop varied from 17ms to 2910ms. I was seeing speed test results 100kbps.
I can't confirm any of this in my area of Mountain View. I run periodic traceroutes every minute, 24x7x365.

I've attached a .txt file of the output from my periodic traceroutes. As you can see, no loss in my area.
raghu1111
join:2009-03-05
San Jose, CA

raghu1111 to eddychan

Member

to eddychan
Thanks Eddy. Mine does not seem to have downloaded a new firmware. I have SB5120 (firmware : 2.19.0.12-SCM03-NOSH). There is no log about downloading new firmware. btw, over last day or so, the problem is less severe. will today if it gets be equally bad as last week. As the ping plot from Sat 9am till Mon 9pm Pacific shows, Satday was pretty bad, but Sunday a bit better.

Btw, I see multiple instance of the following error in log (not sure if it is related) : "DIST: Management Message with unidentified Version->4 - Discard message"