comcast business service

rwebb at ropeguru.com rwebb at ropeguru.com
Fri Feb 21 12:12:00 UTC 2014


Biggest unknown at this point is your upstream SNR. If there is noise 
ingress somewhere in the plant, then your upstream could be having all 
kinds of issues.


Robert

On Fri, 21 Feb 2014 05:23:07 -0500
  shawn wilson <ag4ve.us at gmail.com> wrote:
> Works:
> 
> Downstream Channel
> Downstream Frequency525000000 Hz561000000 Hz567000000 Hz573000000 
>Hz579000000 Hz
> Lock StatusLockedLockedLockedLockedLocked
> Modulation256 QAM256 QAM256 QAM256 QAM256 QAM
> Symbol Rate5.360537 Msym/sec5.360537 Msym/sec5.360537 
>Msym/sec5.360537
> Msym/sec5.360537 Msym/sec
> Downstream Power 2.2 dBmV 3.8 dBmV 3.0 dBmV 2.9 dBmV 2.9 dBmV
> SNR41.2 dBmV40.8 dBmV40.5 dBmV40.9 dBmV41.0 dBmV
> Upstream Channel
> Upstream Frequency36000000 Hz29400000 Hz22800000 Hz0 Hz
> Lock StatusLockedLockedLockedNot Locked
> ModulationATDMAATDMAATDMAUnknown
> Symbol Rate5120 sym/sec5120 sym/sec5120 sym/sec0 sym/sec
> Upstream Power46.2 dBmV46.2 dBmV46.2 dBmV0 dBmV
> 
> --- 8.8.8.8 ping statistics ---
> 10 packets transmitted, 10 received, 0% packet loss, time 9013ms
> rtt min/avg/max/mdev = 23.066/27.049/35.627/4.825 ms
> 
> Not working:
> 
> Downstream Channel
> Downstream Frequency525000000 Hz561000000 Hz567000000 Hz573000000 
>Hz579000000 Hz
> Lock StatusLockedLockedLockedLockedLocked
> Modulation256 QAM256 QAM256 QAM256 QAM256 QAM
> Symbol Rate5.360537 Msym/sec5.360537 Msym/sec5.360537 
>Msym/sec5.360537
> Msym/sec5.360537 Msym/sec
> Downstream Power 2.2 dBmV 3.8 dBmV 2.9 dBmV 2.8 dBmV 2.9 dBmV
> SNR41.4 dBmV40.8 dBmV40.4 dBmV41.0 dBmV41.3 dBmV
> Upstream Channel
> Upstream Frequency36000000 Hz29400000 Hz22800000 Hz0 Hz
> Lock StatusLockedLockedLockedNot Locked
> ModulationATDMAATDMAATDMAUnknown
> Symbol Rate5120 sym/sec5120 sym/sec5120 sym/sec0 sym/sec
> Upstream Power46.5 dBmV46.5 dBmV46.5 dBmV0 dBmV
> 
> --- 8.8.8.8 ping statistics ---
> 233 packets transmitted, 232 received, 0% packet loss, time 232884ms
> rtt min/avg/max/mdev = 23.431/1918.702/8758.161/2017.033 ms, pipe 9
> 
> I'm not seeing any big difference in SNR (and only slight 
>differences
> in upstream power) and everything else seems to be the same. Though,
> since db is logarithmic, .3 might be enough to matter?
> 
> On Thu, Feb 20, 2014 at 4:14 PM, Dan Shoop <shoop at iwiring.net> 
>wrote:
>>
>> On Feb 20, 2014, at 4:08 AM, shawn wilson <ag4ve.us at gmail.com> 
>>wrote:
>>
>>> A while ago I got Comcast's business service. Semi-idle connections
>>> are get dropped (I haven't really diagnosed this - I just no that it
>>> isn't the client or server but some network in between). However the
>>> second and most obvious issue is that intermittently, the service 
>>>will
>>> grind to a halt:
>>> --- 8.8.8.8 ping statistics ---
>>> 37 packets transmitted, 34 received, 8% packet loss, time 36263ms
>>> rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe 
>>>15
>>>
>>> After a modem reboot, it goes normal:
>>> --- 8.8.8.8 ping statistics ---
>>> 4 packets transmitted, 4 received, 0% packet loss, time 3003ms
>>> rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms
>>>
>>> This seems to happen about once or twice a day. I can't attribute it
>>> to any type of traffic or number of connections. All of the rest of
>>> the network equipment is the same and the behavior persists when a
>>> computer is plugged directly into the modem. I called Comcast and 
>>>they
>>> said they didn't see anything even when I was experiencing 
>>>ridiculous
>>> ping times. I tend to think it's an issue with the 'modem' but I'm 
>>>not
>>> sure what the issue might be or how to reproduce it when asked to if 
>>>I
>>> tell them to look at it.
>>
>> I’ve seen this happen before with various cable ISPs. I’d concur 
>>with the poster suggesting intermittent noise on the cable segment as 
>>a likely culprit. Also if you have a cable modem that binds multiple 
>>channels for higher bandwidth this can also be problematic, 
>>especially with the noise. Signals will look good to the NOC but it’s 
>>not the signal “level" that’s the issue it’s the signal to noise 
>>level. Noise has to be measured locally and techs don’t always check 
>>SNL.
>>
>> Also check to see if the packets aren’t actually being dropped but 
>>just taking longer than ping is looking for. Also check for out of 
>>sequence packets returned. These can indicate flapping of a bonded 
>>circuit or the bonded circuit experiencing noise. Try seeing if you 
>>disconnect everything and get a straight run to the demarc, with a 
>>know and tested out good cable, if the problem doesn’t ever occur. 
>>This could indicate noise on the cable in your premise. But I’ve 
>>experienced this same problem with noise coming through the demarc. 
>>I’ve also seen levels too hot beyond the demarc causing similar 
>>problems too.
>>
>> HTH.
>>
>>
>> -d
>>
>> -----
>>
>> Dan Shoop
>> shoop at iwiring.net
>> 1-646-402-5293 (GoogleVoice)
>>
>>
>>
>>
> 





More information about the NANOG mailing list