2 edits |
Very jittery upstream (big variation in ping) San Jose, CAI 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
2009-Mar-6 9:04 am
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.htmlthe 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. |
|
1 edit |
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 |
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 |
to raghu1111
Re: Very jittery upstream (big variation in ping) San Jose, CABy 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. |
|
NormanSI 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
|
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. |
|
1 edit |
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 |
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 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 |
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. |
|
|
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
2009-Mar-6 7:14 pm
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 to raghu1111
Anon
2009-Mar-6 7:36 pm
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. |
|
|
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. |
|
NormanSI 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
|
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
2009-Mar-7 6:21 am
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) |
|
|
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. |
|
NormanSI gave her time to steal my mind away MVM join:2001-02-14 San Jose, CA |
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. |
|
|
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 |
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. |
|
EGThe wings of love Premium Member join:2006-11-18 Union, NJ 3 edits |
EG
Premium Member
2009-Mar-7 7:48 pm
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. |
|
|
to raghu1111
Re: Very jittery upstream (big variation in ping) San Jose, CAIf 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. |
|
|
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. |
|
EGThe wings of love Premium Member join:2006-11-18 Union, NJ 1 edit |
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. |
|
1 edit |
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
2009-Mar-9 11:37 am
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 was involved. |
|
|
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 to raghu1111
Anon
2009-Mar-9 12:40 pm
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 |
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 |
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. |
|
|
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" |
|