Xfinity plant
Xfinity globe
Community Forum

Recurring T3 timeouts since 08/14

Contributor

Recurring T3 timeouts since 08/14

Since yesterday (08/14) at approximately 12:07 PDT, I began seeing packet loss ranging from 5 to 25% (I run periodic traceroutes that last 40 seconds, every minute).  Upon checking my cable modem (SB6121) logs, I found incrementing events of this type:

 

Aug 14 2012 13:19:51 3-Critical R02.0 No Ranging Response received - T3 time-out;CM-MAC=cc:7d:37:98:ae:0b;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

The timestamp would increment/change, and would match up with the packet loss seen exactly.  My SNR and power levels look fantastic, barring a single downstream channel (channel 8) that does have SNR that fluctuates quite a bit (36dB to 31d:

Aug 14 14:40:44        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 14 14:40:44    Boot Version: PSPU-Boot(25CLK) 1.0.12.
Aug 14 14:40:44    Modem Uptime: 0 days 0h:10m:54s
Aug 14 14:40:44  Down Channel  2: 717000000 Hz,   1 dBmV power, 36 dB SNR, mods: QAM256
Aug 14 14:40:44  Down Channel  3: 723000000 Hz,   0 dBmV power, 36 dB SNR, mods: QAM256
Aug 14 14:40:44  Down Channel  5: 735000000 Hz,   1 dBmV power, 36 dB SNR, mods: QAM256
Aug 14 14:40:44  Down Channel  8: 753000000 Hz,   0 dBmV power, 35 dB SNR, mods: QAM256
Aug 14 14:40:44    Up Channel  9:  23700000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 14 14:40:44    Up Channel  7:  35400000 Hz,  48 dBmV power, 2.560 Msym/sec, mods: [3] QPSK [2] 16QAM, status: Success
Aug 14 14:40:44    Up Channel  8:  30600000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 14 14:40:44 Stats Channel  2: 27264375 unerrored, 29 correctable, 699 uncorrectable
Aug 14 14:40:44 Stats Channel  3: 27264382 unerrored, 60 correctable, 662 uncorrectable
Aug 14 14:40:44 Stats Channel  5: 27264390 unerrored, 18 correctable, 700 uncorrectable
Aug 14 14:40:44 Stats Channel  8: 27264395 unerrored, 48 correctable, 663 uncorrectable
Aug 14 14:40:44 --

 

I tried resetting to factory defaults my cable modem + rebooting it (as you can see from the uptime entry above), but the issue didn't go away.  I called Comcast to have them check upstream SNR, and the CSR said everything looked good ("only going up and down about 0.5").  I asked the CSR to "make note of the issue" and told her that I'd call back the next day if it didn't resolve itself.

 

That same day, the issue went away around 17:26 PDT.  No more packet loss, no more T3 errors.  I figured "ah, people got home from work, I bet they started calling in and someone went out and did something".  Everything worked fantastic throughout the night / very early hours of the morning.

 

Then today (08/15), starting at 12:24 PDT, the issue began happening again.  T3 errors are back, packet loss is back.  SNR and power levels look the same as yesterday.  I've checked my equipment (loose coax, etc.) but have found nothing.

 

Current levels (also shows the problem with downstream channel 8):

 

Aug 15 15:00:04        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 15 15:00:04    Boot Version: PSPU-Boot(25CLK) 1.0.12.
Aug 15 15:00:04    Modem Uptime: 0 days 16h:20m:36s
Aug 15 15:00:04  Down Channel  2: 717000000 Hz,   1 dBmV power, 36 dB SNR, mods: QAM256
Aug 15 15:00:04  Down Channel  4: 729000000 Hz,   1 dBmV power, 36 dB SNR, mods: QAM256
Aug 15 15:00:04  Down Channel  5: 735000000 Hz,   1 dBmV power, 36 dB SNR, mods: QAM256
Aug 15 15:00:04  Down Channel  8: 753000000 Hz,   0 dBmV power, 32 dB SNR, mods: QAM256
Aug 15 15:00:04    Up Channel  9:  23700000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 15 15:00:04    Up Channel  7:  35400000 Hz,  48 dBmV power, 2.560 Msym/sec, mods: [3] QPSK [2] 16QAM, status: Success
Aug 15 15:00:04    Up Channel  8:  30600000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 15 15:00:04 Stats Channel  2: 2671707089 unerrored, 1600 correctable, 713 uncorrectable
Aug 15 15:00:04 Stats Channel  4: 2671707314 unerrored, 1571 correctable, 536 uncorrectable
Aug 15 15:00:04 Stats Channel  5: 2671707393 unerrored, 1492 correctable, 536 uncorrectable
Aug 15 15:00:04 Stats Channel  8: 2671707580 unerrored, 1222 correctable, 623 uncorrectable
Aug 15 15:00:04 --

And most recent cable modem log entry (note that the cable modems have no concept of DST, so since we're in PDT, you have to add an hour to the time shown):

Aug 15 2012 13:28:15 3-Critical R02.0 No Ranging Response received - T3 time-out;CM-MAC=cc:7d:37:98:ae:0b;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;


And packet loss that correlates with that time perfectly:

=== Wed Aug 15 14:27:00 PDT 2012  (1345066020)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   2.2
  2.|-- 67.180.84.1                2.5%    40    39  20.7  28.6  16.5  95.9
  3.|-- 68.85.191.249              2.5%    40    39   9.3   9.7   8.7  11.2
  4.|-- 69.139.198.90              2.5%    40    39  17.1  17.2  11.3  23.6
  5.|-- 68.86.91.45                0.0%    40    40  12.2  19.6  12.2  37.9
  6.|-- 4.71.118.49                0.0%    40    40  12.2  15.2  11.2  66.6
  7.|-- 4.69.152.190               0.0%    40    40  11.8  15.8  11.3  26.9
  8.|-- 4.69.153.9                 0.0%    40    40  13.0  12.9  10.8  28.5
  9.|-- 4.69.132.10                0.0%    40    40  21.2  21.4  18.9  36.4
 10.|-- 4.69.137.34                0.0%    40    40  28.5  23.6  19.1  54.3
 11.|-- 4.69.137.1                 2.5%    40    39  19.3  20.3  19.2  22.1
 12.|-- 4.69.133.205               0.0%    40    40  22.5  53.2  21.9 223.0
 13.|-- 4.53.121.58                0.0%    40    40  24.7  44.1  23.5 194.8
 14.|-- 216.98.153.78              0.0%    40    40  25.7  25.7  23.3  41.1
 15.|-- 209.126.140.25             0.0%    40    40  25.1  26.0  23.8  40.9
=== END

=== Wed Aug 15 14:28:00 PDT 2012  (1345066080)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.4   0.3   0.2   0.4
  2.|-- 67.180.84.1                2.5%    40    39  24.4 190.9  15.3 1345.5
  3.|-- 68.85.191.249              2.5%    40    39   9.8 186.7   8.1 2050.1
  4.|-- 69.139.198.90              7.5%    40    37  19.0 160.3  10.6 1986.6
  5.|-- 68.86.91.45               10.0%    40    36  14.4 156.1  11.9 1154.8
  6.|-- 4.71.118.49                2.5%    40    39  26.9 254.5  10.8 2094.8
  7.|-- 4.69.152.190              12.5%    40    35  12.0 139.4  11.1 1780.7
  8.|-- 4.69.153.9                 7.5%    40    37  11.6 224.5  11.0 1959.8
  9.|-- 4.69.132.10                0.0%    40    40  21.1 276.5  18.9 1898.7
 10.|-- 4.69.137.34               10.0%    40    36  21.1 187.9  18.8 1831.7
 11.|-- 4.69.137.1                 0.0%    40    40  21.1 287.4  19.2 1763.8
 12.|-- 4.69.133.205              10.0%    40    36  23.6 221.5  21.7 1706.9
 13.|-- 4.53.121.58                5.0%    40    38  23.8 205.1  23.6 1631.9
 14.|-- 216.98.153.78             12.5%    40    35  23.7 181.3  23.4 1563.9
 15.|-- 209.126.140.25             2.5%    40    39  26.3 193.1  24.2 1496.2
=== END

=== Wed Aug 15 14:29:00 PDT 2012  (1345066140)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.4   0.3   0.2   0.4
  2.|-- 67.180.84.1                0.0%    40    40 558.0  79.9  10.2 1563.6
  3.|-- 68.85.191.249              0.0%    40    40 476.6  58.9   8.1 1496.5
  4.|-- 69.139.198.90              0.0%    40    40 418.6  64.2  10.2 1437.8
  5.|-- 68.86.91.45                0.0%    40    40 351.7  60.8  12.9 1371.6
  6.|-- 4.71.118.49                2.5%    40    39 275.5  58.0  11.4 1295.4
  7.|-- 4.69.152.190               2.5%    40    39 207.5 110.3  11.7 2246.1
  8.|-- 4.69.153.9                 0.0%    40    40 139.5  98.6  11.0 2179.1
  9.|-- 4.69.132.10                2.5%    40    39  79.0  49.4  18.8 1098.8
 10.|-- 4.69.137.34                2.5%    40    39  34.8  50.8  19.1 1031.0
 11.|-- 4.69.137.1                 0.0%    40    40  19.8  93.6  19.5 1982.8
 12.|-- 4.69.133.205               0.0%    40    40  26.4 119.5  21.9 1947.7
 13.|-- 4.53.121.58                0.0%    40    40  25.2 113.2  23.6 1851.0
 14.|-- 216.98.153.78              0.0%    40    40  27.6  87.4  23.3 1783.1
 15.|-- 209.126.140.25             0.0%    40    40  25.4  84.1  23.5 1715.4
=== END

Sadly the traceroutes aren't completely indicative of how the problem manifests itself.  Visiting websites/etc. during these brief spurts of interruptions results in nothing but stalls (like I said: packet loss :-) ).  So it's not purely an ICMP reporting problem.  In fact, the reason I noticed the issue at all was because of the stalls.

 

I've posted about this on the Comcast Direct forum (private) over on DSLR/BBR, as well as in the Comcast HSI forum (public) on DSLR/BBR: http://www.dslreports.com/forum/r27425364-Connectivity-SF-Bay-Area-anyone-having-T3-timeout-problems...

 

Anyone have any tips or things I should have looked at?  The fact it seems to start around certain hours and (at least yesterday) end at certain hours is really bizarre, but the T3 timeouts are obviously the cause of the loss I see.  Some reference material for that claim:

 

http://www.dslreports.com/faq/13055

http://www.dslreports.com/faq/16404

http://www.dslreports.com/faq/8560

 

Thanks.

New Poster

Re: Recurring T3 timeouts since 08/14

I am also facing the same issue. Lot of interruptions every 3 or 4 minutes. I live in NJ. Do not know what to do?

 

Wed Aug 15 17:26:58 2012       Critical (3)      16 consecutive T3 timeouts while trying to range on upstream channel 2;CM-MAC=cc:7d:37:1c:9a:22;CMTS-MAC=00:01:5c:24:52:d2;CM-QOS=1.1;CM-VER=3.0;


 Wed Aug 15 17:26:58 2012       Critical (3)      Unicast Maintenance Ranging attempted - No response - Retries exhausted;CM-MAC=cc:7d:37:1c:9a:22;CMTS-MAC=00:01:5c:24:52:d2;CM-QOS=1.1;CM-VER=3.0;


 Wed Aug 15 17:26:58 2012       Critical (3)      Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=cc:7d:37:1c:9a:22;CMTS-MAC=00:01:5c:24:52:d2;CM-QOS=1.1;CM-VER=3.0;

Contributor

Re: Recurring T3 timeouts since 08/14

I'm pretty sure your issue is not the same as mine, jebastine.  I'm not seeing any Unicast Maintenance messages, only T3 timeouts.  Plus you're literally across the country (Jersey vs. California).  I'd recommend you start a separate thread for your issue.

Expert

Re: Recurring T3 timeouts since 08/14

Typically when you see a lot of T3 errors you are either looking at a bad modem or upstream noise. Considering the many complaints about potential firmware issues, it might be prudent to swap the modem. You can always rent one from Comcast for a month. Otherwise you need a skilled tech to check for upstream noise. Since it appears to be an intermittent problem, it can be tough to track down and repair.

Contributor

Re: Recurring T3 timeouts since 08/14

Replacement modem will be here on Friday so I can reprovision when it arrives.

 

That said, two questions:

1. Wouldn't a bad or faulty modem result in this behaviour happening constantly?  Why would it simply go away for 19 hours (17:26 PDT to 12:24 PDT the following), then come back?

 

2. You mention "firmware issues" -- the firmware I'm running is, obviously, pushed to me by Comcast.  So I'm not sure how I would have "firmware issues" given that I have zero control over the firmware.  (Meaning: I imagine if this was a "firmware problem" it would be affecting everyone in my general geographic area and not just me).  Can you expand a bit on what you mean by this?

Expert

Re: Recurring T3 timeouts since 08/14

A bad modem can be working intermittently, but I agree it sounds like something else.

 

You can see a long post here about the firmware problems: http://forums.comcast.com/t5/Connectivity-and-Modem-Help/Having-issues-with-your-Motorola-SB6121-Ple...

Contributor

Re: Recurring T3 timeouts since 08/14

Wasn't aware of that thread -- thank you.  Wow, that's... yeah.  I would hope Comcast would be rolling back (or rolling forward, if there's a fix/etc.) the 1.0.6.6 firmware update given this craziness.  Although I will admit that I've been using 1.0.6.6 since 07/29 (verification) without issues until yesterday.

 

I've put in an additional order for a Zoom 5341J which should also arrive on Friday, in case this somehow does turn out to be a firmware problem with the SB6121.  (So yes, I have two different cable modems arriving on Friday -- always good to have spares anyway!)

Contributor

Re: Recurring T3 timeouts since 08/14

Follow-up: issue completely disappeared as of 17:53 PDT. I've done nothing to my equipment (no reboots/resets, nothing). SNR and power look the same (including that one downstream channel which has a highly fluctuating SNR).  Haven't seen a T3 timeout since 17:52 PDT, when before I was seeing them every 3-4 minutes.

Expert

Re: Recurring T3 timeouts since 08/14

Humm well, keep us posted pls!

Contributor

Re: Recurring T3 timeouts since 08/14

Issue started again today at 11:51 PDT.  Up until then, everything was crystal clear + perfect.  T3 errors have returned, as has packet loss.  Like the previous two times: SNR and power levels look fine, barring that one onery downstream channel.  :-)

 

Also got my replacement SB6121 today (the Zoom I also bought arrived tomorrow).

 

I guess it's time to go try reprovisioning...

Contributor

Re: Recurring T3 timeouts since 08/14

Well that was fun.  (Okay not really, but I did manage to get through it w/out having to call anyone ;-) )

 

After reprovisioning on the new model (and I added some code to my stats polling script to pick up H/W version number), this is what I'm with:

 

Aug 16 14:48:06        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 16 14:48:06    Boot Version: PSPU-Boot(25CLK) 1.0.12.
Aug 16 14:48:06     H/W Version: 5.0
Aug 16 14:48:06    Modem Uptime: 0 days 0h:4m:44s
Aug 16 14:48:06  Down Channel  2: 717000000 Hz,   0 dBmV power, 37 dB SNR, mods: QAM256
Aug 16 14:48:06  Down Channel  3: 723000000 Hz,   0 dBmV power, 36 dB SNR, mods: QAM256
Aug 16 14:48:06  Down Channel  5: 735000000 Hz,   0 dBmV power, 37 dB SNR, mods: QAM256
Aug 16 14:48:06  Down Channel  6: 741000000 Hz,   0 dBmV power, 37 dB SNR, mods: QAM256
Aug 16 14:48:06    Up Channel  8:  30600000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 16 14:48:06    Up Channel  7:  35400000 Hz,  48 dBmV power, 2.560 Msym/sec, mods: [3] QPSK [2] 16QAM, status: Success
Aug 16 14:48:06    Up Channel  9:  23700000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 16 14:48:06 Stats Channel  2: 10381569 unerrored, 43 correctable, 704 uncorrectable
Aug 16 14:48:06 Stats Channel  3: 10381781 unerrored, 1 correctable, 517 uncorrectable
Aug 16 14:48:06 Stats Channel  5: 10381663 unerrored, 14 correctable, 641 uncorrectable
Aug 16 14:48:06 Stats Channel  6: 10381663 unerrored, 48 correctable, 607 uncorrectable
Aug 16 14:48:06 --

The important thing to note here is the difference in channel numbers/frequencies.  Note that downstream channel 8, for whatever reason, the modem didn't choose to use.  (Cable techs would know how this negotiation works, but I don't.  I'm just a simple IP network guy!  :-) )

 

T3 timeouts?  Yeah, I got one during the last reboot/reconfig of the modem:

 

Aug 16 2012 13:44:21 3-Critical R02.0 No Ranging Response received - T3 time-out;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

(I'll also point out, just for those who may be skeptical and think I may not have swapped my modem with a new one: note the CM-MAC shown above and compare it to my previous posts.  This is a new/different modem!)


As for downstream channel 8, there was a point earlier during the end stages of the reprovisioning where it did pick up that channel.  Note the slightly lower SNR too, just like on the previous modem:

 

Aug 16 14:43:07        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 16 14:43:07    Boot Version: PSPU-Boot(25CLK) 1.0.12.
Aug 16 14:43:07     H/W Version: 5.0
Aug 16 14:43:07    Modem Uptime: 0 days 0h:5m:35s
Aug 16 14:43:07  Down Channel  3: 723000000 Hz,   1 dBmV power, 37 dB SNR, mods: QAM256
Aug 16 14:43:07  Down Channel  5: 735000000 Hz,   1 dBmV power, 36 dB SNR, mods: QAM256
Aug 16 14:43:07  Down Channel  6: 741000000 Hz,   1 dBmV power, 37 dB SNR, mods: QAM256
Aug 16 14:43:07  Down Channel  8: 753000000 Hz,   1 dBmV power, 34 dB SNR, mods: QAM256
Aug 16 14:43:07    Up Channel  8:  30600000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 16 14:43:07    Up Channel  7:  35400000 Hz,  48 dBmV power, 2.560 Msym/sec, mods: [3] QPSK [2] 16QAM, status: Success
Aug 16 14:43:07    Up Channel  9:  23700000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: T4 TimeOut
Aug 16 14:43:07 Stats Channel  3: 12832264 unerrored, 48 correctable, 567 uncorrectable
Aug 16 14:43:07 Stats Channel  5: 12832302 unerrored, 6 correctable, 556 uncorrectable
Aug 16 14:43:07 Stats Channel  6: 12832184 unerrored, 22 correctable, 679 uncorrectable
Aug 16 14:43:07 Stats Channel  8: 12832304 unerrored, 7 correctable, 557 uncorrectable
Aug 16 14:43:07 --

But during this phase I didn't have Internet access (due to the walled garden) so I didn't have a way to determine packet loss / etc..

 

So far (and I'll follow up in about an hour or so), I haven't seen any packet loss or oddities.  So I'm left wondering if that wonky downstream channel truly is causing some oddity -- maybe its tickling some firmware bug?  Seems weird, since it should be upstream SNR that would cause the modem to have T3 errors.

 

Time to let things sit for a while and see how it holds up.

Contributor

Re: Recurring T3 timeouts since 08/14

Most areas added 4 more downstream carries( frequencies) hence the 8. Used to have just 4.

 

Here in my part of colorado our downstream carries for internet are between 543 mhz and 561 mhz.

 

The SNR for those should always be 35+. The 36,37,38 in your posts looks normal. the 34, 32, etc looks bad.

 

One of yours (753mhz) is low .. the modem will not always lock on to the same 4... it will change... when it

jumps to 753mhz it seems like you are having your issue. You need a tech to turn the job over to the line tech and check that amp feeding your area. They can check the channels indvidually on their meter and see the signal issues on just that freq, it could be more then one freq with that issue that your modem doesnt show. Show the tech what you see, he can check also on his meter so he can let the correct people know.

Contributor

Re: Recurring T3 timeouts since 08/14

Just to add.

 

Here we had 2 carriers(frequencies) have low SNR(< 32) and the other 2 were normal(>36).

It caused very bad connection issues and low speeds on speedtest.comcast.net(was getting less the 1 mbps when it would load).  

 

After tech came out and the low downstream snr was fixed our speeds went back to normal(>20mbps).

 

The problem reocurred once a few months later and the SNR dropped on the same 2 carriers.

 

Now obviously this is just a guess in terms to your issue and the amp on the street was our issue but the SNR on all internet frequencies should be close to same. 32 is obsolutely odd and when you posted your problem again, you were on 753mhz with SNR 34 while the others were higher.

Contributor

Re: Recurring T3 timeouts since 08/14

hyatis, thank you for this insight.  This is exactly the sort of thing I was looking for / needing to know, especially the part about what I need to request from Comcast.

 

It's also really great to know that a single frequency/carrier having sub-par SNR can affect overall behaviour of the modem and probably cause what I'm seeing.  I'm thinking that replacing the cable modem didn't really have any effect -- I just happened to be lucky (in the sense that presently 753MHz isn't being used) during the last frequency/carrier negotiation/lock.

 

I will contact Comcast tomorrow and schedule to have a tech come out.  I'm sure if I ask for a line tech from the get-go I'll be told no, and will have to "convince" the normal field tech of the problem + get him to approve getting a line tech out to find out what's going on.  I imagine he can examine the SNR of all the frequencies to find out where problems start and can work with it from there.

 

Again, thank you for the information -- this is a tremendous help.

Contributor

Re: Recurring T3 timeouts since 08/14

Yea there is not direct to line techs.

 

Just show the tech what you showed us and he should be able to use his meter and double check those frequencies individually and see the downsteam SNR issue. Make sure he checks 753 mhz, his default channel maybe on of the others and sometimes the tech doesnt check all the frequencies, just the common one.

Contributor

Re: Recurring T3 timeouts since 08/14

Scheduled a standard technician to come out on 08/20 @ 1400-1600 PT to look at all of the data I have + this thread (printed it out for him + highlighted useful sections) and hopefully get him to send a line tech out.

 

I still don't have an explanation for why the problem only happens between the hours of roughly 1200-1800 PT.  I'll have to make sure the line tech comes out during those hours otherwise they won't see the problem.

 

I find the fact that it only happens during certain times of the day to be the weirdest of all.  I guess for techs here it probably isn't that weird...

 

For now I'm using downstream channels between 717MHz and 741MHz so my connection is stable/usable; I'll just keep an eye on it (resets/etc. could renegotiate those).

 

I'll post an update after Monday's tech visit.  Again, thank you everyone.

 

 

Expert

Re: Recurring T3 timeouts since 08/14

Perhaps it is a return path contention / capacity / congestion issue ? ATDMA is wonderful but it is still not a miracle if the upstream port on the CMTS has over utilization.

Contributor

Re: Recurring T3 timeouts since 08/14

I've been up since around 7am this morning; Internet has been fine.  Then suddenly 10 minutes ago (10:50 PDT), guess what started happening?

=== Fri Aug 17 10:52:00 PDT 2012  (1345225920)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   0.4
  2.|-- 67.180.84.1                5.0%    40    38  26.0  75.5  10.8 1588.8
  3.|-- 68.85.191.249              5.0%    40    38  10.4  66.9   8.4 1504.4
  4.|-- 69.139.198.90              5.0%    40    38  19.9 116.0  10.2 2196.2
  5.|-- 68.86.91.45                2.5%    40    39  22.8 144.8  13.9 2127.1
  6.|-- 4.71.118.49                5.0%    40    38  12.8 105.8  11.0 2053.1
  7.|-- 4.69.152.190               5.0%    40    38  11.7  99.8  11.2 1984.2
  8.|-- 4.69.153.9                 5.0%    40    38  12.7  47.1  11.2 1167.0
  9.|-- 4.69.132.10                2.5%    40    39  19.8  71.2  19.0 1108.2
 10.|-- 4.69.137.34                2.5%    40    39  20.7  94.1  18.8 1788.3
 11.|-- 4.69.137.1                 2.5%    40    39  21.3  62.4  18.9 971.2
 12.|-- 4.69.133.205              10.0%    40    36 196.1  29.7  21.8 196.1
 13.|-- 4.53.121.58                2.5%    40    39  23.7 125.2  23.6 1589.1
 14.|-- 216.98.153.78              5.0%    40    38  25.5 111.2  23.6 1792.6
 15.|-- 209.126.140.25             0.0%    40    40  25.6 130.7  23.7 1724.7
=== END

And its getting worse:

 

=== Fri Aug 17 10:57:00 PDT 2012  (1345226220)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   0.5
  2.|-- 67.180.84.1               25.0%    40    30 160.6 548.9  11.6 2049.9
  3.|-- 68.85.191.249             20.0%    40    32  79.3 552.0   8.4 1981.0
  4.|-- 69.139.198.90             17.5%    40    33  22.3 526.2  12.0 1918.1
  5.|-- 68.86.91.45               27.5%    40    29 969.6 489.7  13.1 1860.0
  6.|-- 4.71.118.49               20.0%    40    32  11.4 556.6  11.4 2054.9
  7.|-- 4.69.152.190              27.5%    40    29 836.4 653.5  11.7 2052.7
  8.|-- 4.69.153.9                32.5%    40    27 1780. 688.1  12.1 1983.7
  9.|-- 4.69.132.10               30.0%    40    28 769.0 718.2  19.0 1923.7
 10.|-- 4.69.137.34               17.5%    40    33 644.7 750.6  19.6 1839.4
 11.|-- 4.69.137.1                30.0%    40    28 565.4 716.6  18.7 1788.9
 12.|-- 4.69.133.205              17.5%    40    33 1519. 759.6  22.1 1995.7
 13.|-- 4.53.121.58               22.5%    40    31 433.8 675.3  23.6 1929.0
 14.|-- 216.98.153.78             35.0%    40    26 365.8 595.1  24.2 1862.0
 15.|-- 209.126.140.25            40.0%    40    24 297.9 628.9  24.3 2201.2
=== END

=== Fri Aug 17 10:58:00 PDT 2012  (1345226280)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   0.4
  2.|-- 67.180.84.1               12.5%    40    35 434.7 133.7  12.4 2193.1
  3.|-- 68.85.191.249             10.0%    40    36 351.2 100.4   8.3 1370.2
  4.|-- 69.139.198.90             15.0%    40    34 1049. 107.6  12.3 2058.1
  5.|-- 68.86.91.45               12.5%    40    35 976.9 140.1  12.4 1996.0
  6.|-- 4.71.118.49               10.0%    40    36 150.0  84.1  11.1 1169.8
  7.|-- 4.69.152.190               7.5%    40    37  82.1 179.8  11.2 2121.8
  8.|-- 4.69.153.9                10.0%    40    36  14.1 118.8  11.1 2052.8
  9.|-- 4.69.132.10                7.5%    40    37 973.8 142.6  19.0 1727.8
 10.|-- 4.69.137.34               12.5%    40    35  20.2  88.9  19.4 1664.7
 11.|-- 4.69.137.1                10.0%    40    36  19.2 131.3  19.2 1856.8
 12.|-- 4.69.133.205               2.5%    40    39  22.5 210.6  21.7 1927.4
 13.|-- 4.53.121.58               12.5%    40    35 705.6  99.0  23.2 1459.8
 14.|-- 216.98.153.78             12.5%    40    35 637.7  91.1  23.3 1391.9
 15.|-- 209.126.140.25            10.0%    40    36 569.8 159.2  23.6 1724.9
=== END

I immediately thought: "the modem is using 753MHz again".  Guess what -- it isn't.

 

Aug 17 11:03:05        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 17 11:03:05    Boot Version: PSPU-Boot(25CLK) 1.0.12.
Aug 17 11:03:05     H/W Version: 5.0
Aug 17 11:03:05    Modem Uptime: 0 days 16h:21m:37s
Aug 17 11:03:05  Down Channel  2: 717000000 Hz,   1 dBmV power, 37 dB SNR, mods: QAM256
Aug 17 11:03:05  Down Channel  4: 729000000 Hz,   1 dBmV power, 37 dB SNR, mods: QAM256
Aug 17 11:03:05  Down Channel  5: 735000000 Hz,   1 dBmV power, 37 dB SNR, mods: QAM256
Aug 17 11:03:05  Down Channel  6: 741000000 Hz,   0 dBmV power, 37 dB SNR, mods: QAM256
Aug 17 11:03:05    Up Channel  8:  30600000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 17 11:03:05    Up Channel  7:  35400000 Hz,  48 dBmV power, 2.560 Msym/sec, mods: [3] QPSK [2] 16QAM, status: Success
Aug 17 11:03:05    Up Channel  9:  23700000 Hz,  46 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 17 11:03:05 Stats Channel  2: 2676066027 unerrored, 1527 correctable, 583 uncorrectable
Aug 17 11:03:05 Stats Channel  4: 2675350538 unerrored, 1420 correctable, 475 uncorrectable
Aug 17 11:03:05 Stats Channel  5: 2675350764 unerrored, 1285 correctable, 542 uncorrectable
Aug 17 11:03:05 Stats Channel  6: 2675350380 unerrored, 1053 correctable, 1317 uncorrectable
Aug 17 11:03:05 --

 

But guess what I'm seeing in my SB6121 log?  Yup, that's right, T3 timeouts, and they again correlate directly with when this issue started (remember SB6121 log timestamps do not support DST, so you have to add an hour to them):

Aug 17 2012 10:01:45 3-Critical R02.0

No Ranging Response received - T3 time-out;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

I'm starting to think EG's theory is probably the case here, but I have absolutely no way to diagnose this kind of problem, nor do I know how to bring this kind of issue to Comcast's attention.

Contributor

Re: Recurring T3 timeouts since 08/14

Quick follow-up: issue which began about ~20 minutes ago has since subsided.  T3 timeouts have also stopped.  Last T3 timeout = 11:08 PDT, last time packet loss was seen = 11:08 PDT.  Signals are still excellent (no SNR issues like last time).

 

I'm left wondering if later today I'll start to see the issue.  Man, the fact this only happens during certain timeframes makes it so utterly bizarre...

 

Maybe I'll flip my sleep schedule around and be awake only at night so I can use my connection reliably, haha.  :-)

Contributor

Re: Recurring T3 timeouts since 08/14

Issue has again recurred starting at 12:35 PDT.  T3 timeouts and packet loss being seen once more.

Contributor

Re: Recurring T3 timeouts since 08/14

13:28 PDT -- cable modem just suddenly rebooted on its own.  Looks to me like someone at Comcast did it (note the "reboot via SNMP" log message):

Aug 17 2012 12:29:47 3-Critical R04.0 Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Aug 17 2012 12:29:17 3-Critical R05.0 Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Aug 17 2012 12:28:58 5-Warning U103.0 Initializing Channel Timeout Expires - Time the CM can perform initial ranging on all upstream channels in the TCS has expired;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Aug 17 2012 12:28:58 5-Warning U102.0 TCS Partial Service;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Aug 17 2012 12:28:54 3-Critical R02.0 No Ranging Response received - T3 time-out;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Aug 17 2012 12:27:57 6-Notice I401.0 TLV-11 - unrecognized OID;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Aug 17 2012 12:27:57 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Jan 01 1970 00:00:42 3-Critical R02.0 No Ranging Response received - T3 time-out;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Jan 01 1970 00:00:13 6-Notice N/A Cable Modem Reboot from SNMP ;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0;

 

And now i'm again using downstream channel 8 (753MHz), which is the carrier which has the wonky SNR problem.  And actually, it looks like 747MHz might also have a problem, hard to say.

 

Aug 17 13:31:54        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)

Aug 17 13:31:54    Boot Version: PSPU-Boot(25CLK) 1.0.12.
Aug 17 13:31:54     H/W Version: 5.0
Aug 17 13:31:54    Modem Uptime: 0 days 0h:4m:51s
Aug 17 13:31:54  Down Channel  3: 723000000 Hz,   1 dBmV power, 37 dB SNR, mods: QAM256
Aug 17 13:31:54  Down Channel  5: 735000000 Hz,   2 dBmV power, 36 dB SNR, mods: QAM256
Aug 17 13:31:54  Down Channel  7: 747000000 Hz,   1 dBmV power, 35 dB SNR, mods: QAM256
Aug 17 13:31:54  Down Channel  8: 753000000 Hz,   1 dBmV power, 35 dB SNR, mods: QAM256
Aug 17 13:31:54    Up Channel  8:  30600000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 17 13:31:54    Up Channel  7:  35400000 Hz,  48 dBmV power, 2.560 Msym/sec, mods: [3] QPSK [2] 16QAM, status: Success
Aug 17 13:31:54    Up Channel  9:  23700000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: T4 TimeOut
Aug 17 13:31:54 Stats Channel  3: 10777400 unerrored, 48 correctable, 607 uncorrectable
Aug 17 13:31:54 Stats Channel  5: 10777405 unerrored, 14 correctable, 637 uncorrectable
Aug 17 13:31:54 Stats Channel  7: 10777320 unerrored, 15 correctable, 727 uncorrectable
Aug 17 13:31:54 Stats Channel  8: 10777388 unerrored, 34 correctable, 639 uncorrectable
Aug 17 13:31:54 --

Contributor

Re: Recurring T3 timeouts since 08/14

Also, the "T4 Timeout" on upstream channel 9 (23.7MHz) is also compounded by a known firmware bug in 1.0.6.6 (the "Cable Modem Status: Offline" bug, even though service is working).  For me, these two things go hand in hand, and only started happening with 1.0.6.6.  They don't have anything to do with the problem I've been reporting, TMK.

Contributor

Re: Recurring T3 timeouts since 08/14

Reset modem to factory defaults + rebooted.  Came back up fine (sadly again using channel 8 / 753MHz), but now the modem shows status is online and no T4 timeout on upstream channel 9.

 

One thing in my log since resetting that I haven't ever seen before is below:

Aug 17 2012 12:39:39 5-Warning U103.0 Initializing Channel Timeout Expires - Time the CM can perform initial ranging on all upstream channels in the TCS has expired;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Aug 17 2012 12:39:39 5-Warning U102.0 TCS Partial Service;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Then a few minutes later this arrived:

Aug 17 2012 12:42:09 3-Critical R04.0 Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=94:cc:b9:1b:1d:19;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

...and I'm again seeing T4 timeout on upstream channel 9 (23.7MHz).

 

Then while all of this was going on (I'm not kidding, seriously, all this BS happened simultaneously), the Zoom modem arrived, so I'm going to call Comcast and talk to someone about provisioning that instead.  Maybe all of this insanity is just some horrible firmware bug, since I don't understand how there could be a line problem with 753MHz *and* 23.7MHz, since they're no where near one another frequency-wise.

 

Also, this forum has some serious problems with font selection.  I love how I'm having to battle it just to write something coherent.  Grumble. 

Contributor

Re: Recurring T3 timeouts since 08/14

After much hemming and hawing, plus having to write a new stats polling script, I'm on the Zoom 5341J.

 

One major downside to the Zoom modems is that there is no error/status log, so I can't even see if I have T3 errors occurring.  That does not make me happy.

 

But the problem still exists, even with the Zoom modem:

 

=== Fri Aug 17 15:21:00 PDT 2012  (1345242060)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.2   0.3   0.2   0.4
  2.|-- 67.180.84.1               10.0%    40    36  19.2 186.3  14.5 1722.9
  3.|-- 68.85.191.249             27.5%    40    29   9.3  85.8   7.5 1505.6
  4.|-- 69.139.198.90             17.5%    40    33  17.5 136.6  10.3 1177.4
  5.|-- 68.86.91.45               20.0%    40    32  18.1 236.9  11.7 2139.3
  6.|-- 4.71.118.49               25.0%    40    30  11.5 169.8   8.1 2059.4
  7.|-- 4.69.152.190              17.5%    40    33  15.2 252.9  10.7 1991.6
  8.|-- 4.69.153.9                12.5%    40    35  12.6 282.1  10.5 2188.4
  9.|-- 4.69.132.10               20.0%    40    32  19.1 221.0  15.8 2128.2
 10.|-- 4.69.137.34               18.4%    38    31  20.6 176.5  17.5 1795.2
 11.|-- 4.69.137.1                15.8%    38    32  18.8 198.8  15.4 1992.3
 12.|-- 4.69.133.205              21.1%    38    30  22.8 173.9  18.5 1828.9
 13.|-- 4.53.121.58               26.3%    38    28  22.6 163.3  22.5 1860.6
 14.|-- 216.98.153.78             18.4%    38    31  24.2 160.7  19.9 1792.7
 15.|-- 209.126.140.25            18.4%    38    31  24.5  98.3  20.9 1460.7
=== END

Now take a look at this. The SNR for 747MHz and 753MHz is actually quite bad (they fluctuate a lot, up and down almost 9dB at times), so I'm inclined to think the problem starts around 747MHz but not as low as 741MHz:


Aug 17 15:37:27      Modem Model: Zoom 5341J
Aug 17 15:37:27 Software Version: 5.5.4.9J
Aug 17 15:37:27 Hardware Version: A0
Aug 17 15:37:27     Modem Uptime: 0 days 01h:20m:01s
Aug 17 15:37:27  Down Channel  8: 753000000 Hz,  0.4 dB power,  36.5 dB SNR, status: Locked, 2143 corr, 0 uncorr
Aug 17 15:37:27  Down Channel  1: 705000000 Hz,  0.8 dB power,  39.8 dB SNR, status: Locked, 115 corr, 0 uncorr
Aug 17 15:37:27  Down Channel  2: 717000000 Hz,  1.2 dB power,  39.9 dB SNR, status: Locked, 120 corr, 0 uncorr
Aug 17 15:37:27  Down Channel  3: 723000000 Hz,  0.9 dB power,  39.8 dB SNR, status: Locked, 116 corr, 0 uncorr
Aug 17 15:37:27  Down Channel  4: 729000000 Hz,  1.0 dB power,  39.9 dB SNR, status: Locked, 103 corr, 0 uncorr
Aug 17 15:37:27  Down Channel  5: 735000000 Hz,  0.9 dB power,  39.6 dB SNR, status: Locked, 79 corr, 0 uncorr
Aug 17 15:37:27  Down Channel  6: 741000000 Hz,  0.8 dB power,  39.5 dB SNR, status: Locked, 75 corr, 0 uncorr
Aug 17 15:37:27  Down Channel  7: 747000000 Hz,  0.8 dB power,  33.5 dB SNR, status: Locked, 78 corr, 0 uncorr
Aug 17 15:37:27    Up Channel  8:  30600000 Hz, 46.8 dB power,  5120 Ksym/sec, status: Locked, ATDMA
Aug 17 15:37:27    Up Channel  7:  35400000 Hz, 48.0 dB power,  2560 Ksym/sec, status: Locked, TDMA
Aug 17 15:37:27    Up Channel  9:  23700000 Hz, 46.3 dB power,  5120 Ksym/sec, status: Locked, ATDMA
Aug 17 15:37:27    Up Channel  0:         0 Hz,  0.0 dB power,     0 Ksym/sec, status: Not Locked, Unknown
Aug 17 15:37:27 --

I have a feeling the Comcast CSRs are probably going to be very annoyed with me if I call them back up and say "so, uh, care to put me back on my SB6121?"  They're going to think I'm crazy switching cable modems back and forth like this.

 

I would love to let the Zoom sit in use until Monday when the tech comes out, but again, lack of error log means all I can go off of are periodic traceroutes/packet loss indications, and using packet loss as an indication of a cable network problem never flies with any ISP.

 

Contributor

Re: Recurring T3 timeouts since 08/14


koitsu wrote:

One major downside to the Zoom modems is that there is no error/status log, so I can't even see if I have T3 errors occurring.  That does not make me happy.


Strike that -- Googling shows there's a hidden error log page, as long as you know the URL...

 

http://192.168.100.1/RgEventLog.asp

 

And I don't see any T3 timeouts there, but I also don't know how big the log region is (meaning after so many log entries they may just simply stop logging -- lots of embedded products act this way).

 

I'll clear the log + reset to factory defaults + reboot and then let things sit and see what comes in after that.

 

I think at ths point, though, I've done everything I can to prove that this is some kind of "cable problem" and not an issue with my equipment.  I'm going on 4 days now of this nonsense, so I'm hoping I get some kind of service credit.

 

Contributor

Re: Recurring T3 timeouts since 08/14

Here's a link to a screenshot from the Zoom.  I've highlighted in red the 747MHz and 753MHz channels -- look at their SNR.

 

http://jdc.koitsu.org/lj/bad_snr.png

 

The error log, however, shows no T3 timeouts or anything indicative of a problem, so I would say that the Zoom is probably "less sensitive" than the Motorola when it comes to deciding when to log an error.

 

Expert

Re: Recurring T3 timeouts since 08/14


koitsu wrote:

 

One major downside to the Zoom modems is that there is no error/status log, so I can't even see if I have T3 errors occurring.  That does not make me happy.

 


Use this addy for the error log;

 

http://192.168.100.1/RgEventLog.asp

 

Be advised that before the last firmware push this used to work on the first try with the factory firmware. If you have the newest firmware you will need to login two times consecutively for the tab to appear. I find that a desktop shortcut for that link works best. Log in once using the "admin & password" entries, close the window and then immediately log back in. Any joy ?

 

[Edit]

 

Didn't see your last two posts before I posted.

Expert

Re: Recurring T3 timeouts since 08/14


koitsu wrote:

Here's a link to a screenshot from the Zoom.  I've highlighted in red the 747MHz and 753MHz channels -- look at their SNR.

 

http://jdc.koitsu.org/lj/bad_snr.png

 

 

Yep. It sure does look like those two downstreams are a bit borked.

 

The error log, however, shows no T3 timeouts or anything indicative of a problem, so I would say that the Zoom is probably "less sensitive" than the Motorola when it comes to deciding when to log an error.

 

In my experience, back to the SB4100, the Surfboards have typically been hypochondriacs for reporting T-3's.

 


 

Contributor

Re: Recurring T3 timeouts since 08/14

Thanks for the log URL -- yeah, found it.  :-)  Hehehe...

 

I think the Motorolas are just more sensitive to their timeouts when talking to the CMTS.  And admittedly the firmwares (on all models) are spotty sometimes, no argument from me on that.

 

Since this issue tends to disappear on its own after 1800 PDT, I'll just deal with this until Monday when the tech comes out.

 

In the meantime, the only thing I can think of is to ask my neighbours (in my building) if they'd mind visiting http://192.168.100.1/ on their own Comcast connections.  I know one for sure has a Motorola modem (not sure what model), and I'm wondering if they're seeing the same problems on the same frequencies I am.

 

I should note I do not have cable TV service or anything else on my coax (in my home nor all the way out to the drop point where the cable comes off the pole), so if someone is injecting noise onto the cable network segment (is that possible?) I imagine it'd be affecting more people than just me.

 

It still bothers the heck out of me that this thing comes and goes during fairly specific hours of the day.

Expert

Re: Recurring T3 timeouts since 08/14


koitsu wrote:

 

I should note I do not have cable TV service or anything else on my coax (in my home nor all the way out to the drop point where the cable comes off the pole), so if someone is injecting noise onto the cable network segment (is that possible?) I imagine it'd be affecting more people than just me.

 


It's more than "possible" and happens all the time !! And yes, it will affect close by neighbors, and if it is strong enough it could take out an entire node.

 

Good luck with it !

Contributor

Re: Recurring T3 timeouts since 08/14

Strange things afoot today.  It's remarkable how all this stuff happens simultaneously.

 

1. This morning I decided to revert back to my original SB6121 (not the replacement I got, but the very original) since in this thread it was confirmed that my original SB6121 was fine (the replacement saw the same problem, and a Zoom 5341J also saw the problem).  So the issue is definitely not with the modem(s).

 

The reprov. worked fine and signal levels looked about the same as before.  753MHz got chosen so I was like "feh, I bet the problem starts again" (more on that in a moment).

 

2. Early this afternoon I caught a Comcast guy working in the apartment next to mine.  I figured "oh boy, someone else was seeing the same problem!" -- nope.  He was doing a brand new install for cable TV.  He was completely uninterested in my situation/predicament (I imagine because he had to focus on the install) so I left him alone.

 

He did however have to open the security box where the coax from Comcast comes in before branching out to our apartments.  I was pretty appalled -- and actually so was he (quote: "I've seen worse, but this is absolutely a complete mess").  I used the opportunity (asking first of course) to take some photos of the box because I couldn't for the life of me figure out whose apartment got what coax.

 

There are an insane amount of splitters and filters (I think they're filters) involved.  From looking at the photos, I count 5 splitters, and 2 filters (one which doesn't appear to do anything).  This is excluding the (count 'em) 6 filters/whatever laying at the bottom of the box covered in grime/dust.  And of course the labels for which apartment uses what coax are spotty.  Comcast guy was in agreement with me that many of them seemed suspect.

 

I'm still going over the photos to try and "map out" the coax to/from my apartment.  I have a single coax line in my flat -- one and only one.  So there really shouldn't be any splitters involved for my connection unless someone put one on to try and "level out" signal levels.

 

I'll put the photos up online for folks to look at, and I'll try to outline which coax is involved for my flat.  Messy messy messy.  Good thing there's only 6 apartments.

 

3. The Comcast guy completed the installation for the neighbours and left.  Sadly he closed/locked the box, but that's normal (for obvious reasons, duh).  However:

4. Once I got back my flat, I found that between 12:30 and 13:00 PDT the cable modem rebooted citing complete signal loss.  Around this time was when the Comcast guy was finishing things up.  Whether or not he had anything to do with it is unknown, but I'm doubting it.

 

After the modem rebooted, my signal levels are worse in almost every regard:

* Downstream: 747MHz and 753MHz were not chosen -- currently only using 705 / 717 / 735 / 741MHz.

* Downstream: power level fluctuates between -1 to -3 dB for all frequencies (that's 1-3dB lower than before)

* Downstream: SNR is generally stable at 36-37dB for all frequencies

* Upstream: power level is 50-51dB across all frequencies (that's 3-4dB higher than before)

 

Here they are before the reboot:

Aug 18 12:40:00        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 18 12:40:00    Boot Version: PSPU-Boot(25CLK) 1.0.12.
Aug 18 12:40:00     H/W Version: 5.0
Aug 18 12:40:00    Modem Uptime: 0 days 1h:29m:47s
Aug 18 12:40:00  Down Channel  2: 717000000 Hz,   0 dBmV power, 36 dB SNR, mods: QAM256
Aug 18 12:40:00  Down Channel  1: 705000000 Hz,   0 dBmV power, 37 dB SNR, mods: QAM256
Aug 18 12:40:00  Down Channel  7: 747000000 Hz,   0 dBmV power, 36 dB SNR, mods: QAM256
Aug 18 12:40:00  Down Channel  8: 753000000 Hz,   0 dBmV power, 35 dB SNR, mods: QAM256
Aug 18 12:40:00    Up Channel  9:  23700000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 18 12:40:00    Up Channel  7:  35400000 Hz,  48 dBmV power, 2.560 Msym/sec, mods: [3] QPSK [2] 16QAM, status: Success
Aug 18 12:40:00    Up Channel  8:  30600000 Hz,  47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 18 12:40:00 Stats Channel  2: 243643672 unerrored, 181 correctable, 639 uncorrectable
Aug 18 12:40:00 Stats Channel  1: 243643706 unerrored, 153 correctable, 637 uncorrectable
Aug 18 12:40:00 Stats Channel  7: 243643716 unerrored, 139 correctable, 641 uncorrectable
Aug 18 12:40:00 Stats Channel  8: 243643667 unerrored, 132 correctable, 703 uncorrectable

And here they are after:

 

Aug 18 13:00:00        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 18 13:00:00    Boot Version: PSPU-Boot(25CLK) 1.0.12.
Aug 18 13:00:00     H/W Version: 5.0
Aug 18 13:00:00    Modem Uptime: 0 days 0h:5m:12s
Aug 18 13:00:00  Down Channel  2: 717000000 Hz,  -2 dBmV power, 36 dB SNR, mods: QAM256
Aug 18 13:00:00  Down Channel  1: 705000000 Hz,  -2 dBmV power, 36 dB SNR, mods: QAM256
Aug 18 13:00:00  Down Channel  4: 729000000 Hz,  -3 dBmV power, 36 dB SNR, mods: QAM256
Aug 18 13:00:00  Down Channel  5: 735000000 Hz,  -3 dBmV power, 36 dB SNR, mods: QAM256
Aug 18 13:00:00    Up Channel  9:  23700000 Hz,  50 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 18 13:00:00    Up Channel  7:  35400000 Hz,  51 dBmV power, 2.560 Msym/sec, mods: [3] QPSK [2] 16QAM, status: Success
Aug 18 13:00:00    Up Channel  8:  30600000 Hz,  50 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 18 13:00:00 Stats Channel  2: 12471915 unerrored, 31 correctable, 667 uncorrectable
Aug 18 13:00:00 Stats Channel  1: 12471917 unerrored, 36 correctable, 665 uncorrectable
Aug 18 13:00:00 Stats Channel  4: 12471926 unerrored, 57 correctable, 634 uncorrectable
Aug 18 13:00:00 Stats Channel  5: 12471923 unerrored, 31 correctable, 666 uncorrectable

So, yeah, I'm not sure what to make of this situation.

 

I'm starting to wonder if that storage box with the mess of coax in it may be to blame.  I know for a fact my flat and the one next door used to be one big apartment and the landlord came in + dropped a wall.  So I suppose it's possible that my neighbours getting cable TV / etc. could affect my line depending on how everything is wired.

 

Expert

Re: Recurring T3 timeouts since 08/14

Post the pictures!

Contributor

Re: Recurring T3 timeouts since 08/14

Okay, pictures are up.  I kept the originals so they're pretty big but you can read the signal levels on the splitters in some cases.

 

http://jdc.koitsu.org/lj/666hope/

 

map.jpg is my horrible attempt at figuring out what wire goes from what to where, based purely on the photos.  I didn't have enough time in person to try and map it out by hand + on paper.

 

My apartment is #5 and I have only one coax jack, though my gut feeling is that someone has actually run two coax wires to here and one's hiding under the floorboards.

 

The folks next door who were having a Comcast install done today are in apartment #6.  The Comcast installer had to run brand new coax to where their living room is, outside their apartment, and I have no idea where it goes.

 

Apartments #5 and #6, many years ago, used to be one big apartment (which has always made me suspect of the wiring).  Apartment #3 I only mention because I believe one of the wires is labelled #3 and both the Comcast guy and myself today suspect it's actually used by #5.

 

The box is in a really uncomfortable location so getting photos is sometimes difficult:

 

The folks in #6 are incredibly nice (husband is a Eng/Jap translator who works with engineers, and I happen to be an engineer ), so I imagine they'd let me use a toner to try and figure out what coax goes where if needed, but again, the box is now locked so I can't get in there.  Maybe Monday the Comcast guy can do it.

 

What a mess!!!

Contributor

Re: Recurring T3 timeouts since 08/14

I had the wonderful pleasure of spending the past 3-4 hours with the folks in the apartment next to mine.  They have Comcast internet and TV service, and use an SB6121 + DOCSIS 3.0 plan.  They were having problems getting their WiFi router working with their Macs so I helped solved that (their router was just flat out busted -- I gave them a spare Netgear 3500Lv2 I had and they're thrilled).

 

Then I asked them politely "hey, do you mind if I check out your cable connection, given the problems I've been having with mine?"  "Oh sure go ahead"

 

Surprise surprise: they too see the exact same problem with crummy SNR at 747MHz and 753MHz (fluctuates just like mine), they see packet loss the same way I do, and they see T3 timeouts just like I do.  Their signal levels (in general) are about the same as mine (their upstream power is ~2-3dB better than mine).

 

They also added: "if when Comcast comes out on Monday insists the issue is only with you, we'll be home, so just come over and show them ours doing the same thing".  :-)  THAT made me very very happy.

 

So this is definitely NOT a problem with my coax, and not a problem with my equipment -- it is something that is affecting multiple people in my immediate area.

 

I imagine the tech on Monday is going to have a field day with this one.  I dunno how techs track down equipment that is injecting noise at frequencies in/on a node, but kudos to that kind of forensic work.

 

P.S. -- It's now 19:58 PDT and I'm still seeing packet loss/issues.  So I'm starting to really, truly wonder if the issue is actually with an oversaturated/oversubscribed CMTS like EG stated earlier.  If it is, I imagine the more new customers they put on it the worst its going to get.

Expert

Re: Recurring T3 timeouts since 08/14


koitsu wrote:
So I'm starting to really, truly wonder if the issue is actually with an oversaturated/oversubscribed CMTS like EG stated earlier.  If it is, I imagine the more new customers they put on it the worst its going to get.

FWIW, It wouldn't be an entire "CMTS" but it could be a single CMTS port (less likely) or your neigborhood node / segment (more likely).

Contributor

Re: Recurring T3 timeouts since 08/14

Thank you for the clarification EG -- yep, as you can see, this "cable stuff" is something I am not completely familiar with.  I'd kill for an actual topology diagram combined with what terminology usually refers to (in the diagram itself).  :-)

Expert

Re: Recurring T3 timeouts since 08/14

There is nothing wrong with that cables in that security box. The junk in the bottom of the box shold be cleaned out and some more weather seals should be applied, but all in all it looks pretty good.

Contributor

Re: Recurring T3 timeouts since 08/14

Ah okay, to me it looks like a rat's nest, and I'm not even sure why (for example) my apartment would be on a splitter as well as the one next door to me.  I imagined we all would have separate coax lines, not "splitter madness" like this.

 

THe two that concerned me: there's also some kind of filter (not sure -- it's a gigantic silver cylinder, on the cable to the right of the one I labelled yellow / apt #5) on one of the connections.  Not sure whose it is or if it's "the main".  It's bigger than the rest of the filters in that box, so I wasn't sure what it was for.

 

The other which concerns me is visible in IMG_0843.JPG but is hard to see.  It's off to the left side, at the Regal-brand splitter in the back.  There is an IN line that comes in, and one coax that comes out of the splitter -- which has physically been cut.  It's literally just dangling there.

 

I dunno if either of these could be a problem (for me) because like I said, I didn't have time to map out all the wires and which went to what.  I guess on Monday I can watch the Comcast tech go through it.  :-)

 

Also just a timestamp footnote: packet loss / T3 timeouts continue, this time with even stranger timeframes.  Things did not subside until almost 20:30 PDT last night, and ran clean until 08:00 PDT this morning.  Since then, packet loss / T3 timeouts.  I also checked my neighbour's cable modem -- they're seeing the same.

 

Contributor

Re: Recurring T3 timeouts since 08/14

Updated information:


1. T3 issue I've described is actually getting worse.  My cable modem logs show T3 timeouts going all the way up to 01:40 PDT (that's 1:40am), so the timeframe seems to be somewhat variable now.  That's frustrating -- I hope it happens when the Comcast tech is here in a few hours.

 

2. More interestingly: my cable modem, the last time I reset it (21 hours ago), has not been using anything above 741MHz (highest carrier freq. on downstream is 741MHz right now).  Yet it still shows packet loss / T3 timeouts.

 

3. I visited two of my neighbours apartments and checked out their cable modems (logs or signal stats) as well.  Both of those people are seeing the same problem -- T3 timeouts in their cable modem logs, and for those which have DOCSIS 3.0 + have 747MHz or higher in use, SNR that drops horribly.  I asked the tenants if they were experiencing anything like web pages which would stall/stop for 4-5 seconds or time out reandomly; "yeah!  It got really bad starting last week I think".  So that makes a total of -- count 'em -- 4 people (of 6) in this building who are seeing the same problem I am and have stats to prove it.

 

4. Since that Comcast installers' work yesterday in the apartment next door to mine, my signal stats have diminished.  My downstream power is acceptable (going from -1 to 0dB (previously it was 0-2d), but my upstream has gone from an average of 46-48dB to 50-52dB.  I don't know how his work could have affected my connection, but I guess I can ask the tech today how that could happen.

 

So given the above information, I'm starting to think there's two problems going on:

i. A definite issue with something injecting noise into the freq. range ~747MHz and above.  Line tech / etc. should be able to figure this one out I hope.

 

ii. Even if a modem isn't using a carrier of 747MHz or above, packet loss / T3 timeouts are still seen.  This could indicate what EG was talking about earlier -- possibly a CMTS port is overloaded/overtaxed or something more nefarious is going on.  In this case, I really have not the slightest idea how to get Comcast to investigate this, as any techs they send out into the field won't have a way to diagnose this (AFAIK, at least not with a 30-minute visit).

 

From what I remember techs have told me in the past, they have to file some report and "once there are enough status/quality reports filed, network technicians take a look".  Yeah well, I think this is one situation where someone needs to take a look without requiring a boatload of reports.  I just don't know who I can talk to to get this looked at.  ComcastSteve has been extremely busy recently so I don't know how to get a low-level engineer to look at the CMTS to look for any issues...  Smiley Sad  But it's obvious this issue is affecting multiple people at this point, so I imagine it's probably affecting everyone on this node by now, just that everyone in my area is so used to this kind of service that nobody calls it in.

 

Contributor

Re: Recurring T3 timeouts since 08/14

Ahh, here we go, finally starting again... :-)

 

=== Mon Aug 20 10:01:00 PDT 2012  (1345482060)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.2   0.3   0.2   0.4
  2.|-- 67.180.84.1                2.5%    40    39  17.4 151.3  13.3 1893.2
  3.|-- 68.85.191.249              7.5%    40    37   9.6 125.1   8.5 1779.1
  4.|-- 69.139.198.90              2.5%    40    39  20.2 156.3  11.4 1715.6
  5.|-- 68.86.91.45                2.5%    40    39  22.3 202.7  12.5 2208.2
  6.|-- 4.71.118.49               10.0%    40    36  11.5  82.4  11.2 1577.6
  7.|-- 4.69.152.190              10.0%    40    36  20.4 130.9  11.3 2120.4
  8.|-- 4.69.153.9                 5.0%    40    38  14.9 115.1  11.3 1450.7
  9.|-- 4.69.132.10                5.0%    40    38  21.2 144.7  19.4 1991.8
 10.|-- 4.69.137.34               10.0%    40    36  31.9  69.2  19.3 1313.4
 11.|-- 4.69.137.1                 5.0%    40    38  19.6 100.3  19.2 1246.6
 12.|-- 4.69.133.205              10.0%    40    36  23.1  85.7  21.8 1180.2
 13.|-- 4.53.121.58                2.5%    40    39  24.4 213.1  23.2 2134.2
 14.|-- 216.98.153.78              2.5%    40    39  25.5 175.0  23.1 2066.3
 15.|-- 209.126.140.25            10.0%    40    36  26.0  67.3  23.8 979.2
=== END

And stats (nothing above 741MHz in use):

Aug 20 10:05:00    Device Model: Motorola SB6121 (hardware version 5.0)
Aug 20 10:05:00        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 20 10:05:00       Boot Code: PSPU-Boot(25CLK) 1.0.12
Aug 20 10:05:00    Modem Uptime: 0 days 22h:22m:24s
Aug 20 10:05:00 Down Channel  3: 723000000 Hz,  -1 dBmV power, 36 dB SNR, mod: QAM256, corr: 2472, uncorr: 692
Aug 20 10:05:00 Down Channel  2: 717000000 Hz,   0 dBmV power, 36 dB SNR, mod: QAM256, corr: 2230, uncorr: 599
Aug 20 10:05:00 Down Channel  4: 729000000 Hz,   0 dBmV power, 36 dB SNR, mod: QAM256, corr: 2186, uncorr: 692
Aug 20 10:05:00 Down Channel  6: 741000000 Hz,  -1 dBmV power, 36 dB SNR, mod: QAM256, corr: 1758, uncorr: 694
Aug 20 10:05:00   Up Channel  8:  30600000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 20 10:05:00   Up Channel  7:  35400000 Hz,  51 dBmV power, 2.560 Msym/sec, status: Success
Aug 20 10:05:00   Up Channel  9:  23700000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success

Now if this will just continue 'til 2-4pm when the tech gets here... :-)

 

Contributor

Re: Recurring T3 timeouts since 08/14

Sadly, 12:48 PDT, I haven't seen any T3 timeouts or packet loss.

 

A little bit ago I reset my cable modem (factory refaults + reboot) and it picked up carrier/freq 753MHz -- but SNR there now looks normal (36dB, power level -2 d and never drops to crummy values like before.

 

Frustrating, because the tech is scheduled to be here within the next 1.5 hours, and naturally if the issue isn't happening any longer he's going to go "shrug, there's no issue" and leave.

 

I would love to say "problem solved!" except like my previous post shows, the T3 timeout issue was happening at late hours of the night, and I wasn't even using 747/753MHz at that time.  I guess all I can do is hope that the issue happens before he gets here so he can try to figure it out.  My gut feeling says that later tonight I'll start seeing the issue again, and thus it'll become a challenge to get a tech out here while the issue is happening.  Frustrating as heck!


Maybe while he's here I'll ask him to show me how the coax distribution is done here, so at least his time isn't completely wasted.  I'm also a little concerned about my upstream levels (given that one has to assume there will be 2-3dB fluctuations, that would possibly put me up into the 54dB range, which means drop-outs are likely).

 

Current stats, just for the record.

 

Aug 20 14:43:01    Device Model: Motorola SB6121 (hardware version 5.0)
Aug 20 14:43:01        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 20 14:43:01       Boot Code: PSPU-Boot(25CLK) 1.0.12
Aug 20 14:43:01    Modem Uptime: 0 days 0h:19m:43s
Aug 20 14:43:01 Down Channel  2: 717000000 Hz,  -1 dBmV power, 36 dB SNR, mod: QAM256, corr: 71, uncorr: 562
Aug 20 14:43:01 Down Channel  5: 735000000 Hz,  -1 dBmV power, 36 dB SNR, mod: QAM256, corr: 45, uncorr: 681
Aug 20 14:43:01 Down Channel  6: 741000000 Hz,  -2 dBmV power, 36 dB SNR, mod: QAM256, corr: 37, uncorr: 589
Aug 20 14:43:01 Down Channel  8: 753000000 Hz,  -2 dBmV power, 36 dB SNR, mod: QAM256, corr: 34, uncorr: 681
Aug 20 14:43:01   Up Channel  8:  30600000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 20 14:43:01   Up Channel  7:  35400000 Hz,  51 dBmV power, 2.560 Msym/sec, status: Success
Aug 20 14:43:01   Up Channel  9:  23700000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 20 14:43:01 --

Contributor

Re: Recurring T3 timeouts since 08/14

Tech just left.  The guy was absolutely awesome (if he ever read the forums: Sam, you're rad).  He's also worked this building before, so he knew of its setup.  Here are the details:

 

Before he got here, he looked at my cable modem remotely (from his truck) to see what things looked like.  Everything looked normal -- which is the same thing I posted about earlier too.  Problem mysteriously disappeared.

 

When he arrived I explained all the craziness.  He explained to me that the fact that I had switched modems out multiple times, even though it was a good troubleshooting approach, completely destroyed his ability to see old statistics for the line.  So all he could see from his stuff was going back about a day.  Thus, PROTIP: for issues like this, it actually may be best to NOT swap out the modem and instead let things sit until a tech can come out.  Otherwise, they lose visibility into signal statistics and so on which can be super helpful.

 

The next thing he did was disconnect the line from my modem and put a terminator on it.  Then we went out to the cable box (the one in the photos) and took a look at things.

 

I asked how exactly the coax got distributed.  It turns out Comcast, for whatever reason, for a 6-building apartment only chose to run one coax line (but keep reading -- the tech found something totally awesome).  So what happens is that that single line has to be split repeatedly to make it to all the apartments.  We mapped out where my line was / etc. -- simply put it goes like this:

Comcast drop
  |
  +--> 2-way splitter (3.5 / 3.5)
        |
        +---> 2-way splitter (7.5 / 7.5)
        |      |
        |      +---> Apartment #5 (me)
        |      +---> Apartment #6 (my neighbours)
        |
        +---> 3-way splitter (3.5 / 7.5 / 7.5, or maybe 3.5 / 5 / 5)
               |
               +---> other apartments

Tech did a reading between the box and my apartment, and said everything there was absolutely perfect -- he did a bunch of frequency tests with his tester (pretty neat, LCD display + suped up cable modem), as well as looked for things like BERs (a term I do know since I'm familiar with frame and SONET :-)) -- everything was clean.  So we confirmed the problem was not with the coax between my apartment and the coax box outside.  This was also backed by the fact that other tenants saw the same problem I did, but he wanted to rule out any possibility of it being a building wiring issue.  Cool.

 

He then disconnected the Comcast drop/main (taking everyone here offline, but that was okay, nobody home but me), and then took readings from that + took notes on a piece of paper.  He checked all the frequencies and said that he didn't see any anomalies / issues (I pressed him to make sure to check **ALL** the frequencies, not just the "common ones", and he seemed a bit annoyed at this but did it -- and I did see 753MHz fly by, so he wasn't pulling my leg).  I managed to take a quick snapshot of that paper before he took it, so I think techs here might find it useful or can explain what exactly these mean (since the numbers are significantly different than what I see on my modem -- he did explain why to me, but it was a bit over my head):

 

http://jdc.koitsu.org/lj/666hope/20120820_signals.jpg

He said the readings from the Comcast drop looked "hot".  He then examined the Comcast drop coax end, and found that the white + copper area of the end had been pushed in somehow -- meaning it wasn't flush.  I forget the term he used for it (maybe "pushedback?"), but anyway, he said this could absolutely attribute to noise / a problem.  So he clipped the end off + put a new high-quality end on and hooked us back up.

 

At this point, since we were talking about all sorts of stuff, we started talking about other options for how to solve this problem generally.  He followed the Comcast drop which went up to the pole and kept following it.

 

It went to some kind of box (he called it a "hub") that contained "4 ports".  The box was labelled something like "SSP-3N" or "SSN-3P", I forget.  As he began looking at it, he called someone (presumably his boss) and asked about the possibility of having Comcast run us another line, since then we could split 2 lines across 6 apartments.  Whoever he talked to said "it was unlikely that networking would do anything about it, especially given that the main line was running hot and looked good".

 

Suddenly he spotted two things:

1. What looked like a 2nd coax/copper run which went down a little ways and then over to the top of our apartment building -- and was just spooled up in a coil sitting atop the building.  This interested him greatly (and me too), since it meant possibly we had 2 drops that could be used!  However, upon getting on the roof + testing it, it was disconnected/not live.  :-( :-(

 

2. A yellow "Comcast" tag on one of the other ports/lines (not to our building, but to someone elses) coming off that "hub".  I'm nearsighted so I couldn't tell, but once I got binoculars and he got up on a ladder to look at it, he said it was going to another building, and that his group, "at the request of networking", would put these on lines to indicate that there was noise coming on the line at some point (which can affect an entire node).  I asked him if it looked like the tag was new or old, and he said "it's very, very new".  He added that "he did not see a filter on that line", meaning whoever the tech was that put it on there may have solved the noise issue in some other way.

 

Based on #2, the tech concluded that it was very possible someone on Sunday MAY have come out and done something to fix the wonky SNR we were seeing for 747/753MHz.

 

We went back in my flat and reconnected my modem to look at stats.  These are my stats:

 

Aug 20 17:16:18    Device Model: Motorola SB6121 (hardware version 5.0)
Aug 20 17:16:18        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 20 17:16:18       Boot Code: PSPU-Boot(25CLK) 1.0.12
Aug 20 17:16:18    Modem Uptime: 0 days 0h:42m:26s
Aug 20 17:16:18 Down Channel  2: 717000000 Hz,  -2 dBmV power, 36 dB SNR, mod: QAM256, corr: 100, uncorr: 602
Aug 20 17:16:18 Down Channel  1: 705000000 Hz,  -2 dBmV power, 36 dB SNR, mod: QAM256, corr: 84, uncorr: 697
Aug 20 17:16:18 Down Channel  4: 729000000 Hz,  -3 dBmV power, 37 dB SNR, mod: QAM256, corr: 87, uncorr: 692
Aug 20 17:16:18 Down Channel  8: 753000000 Hz,  -3 dBmV power, 35 dB SNR, mod: QAM256, corr: 86, uncorr: 663
Aug 20 17:16:18   Up Channel  8:  30600000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 20 17:16:18   Up Channel  7:  35400000 Hz,  51 dBmV power, 2.560 Msym/sec, status: Success
Aug 20 17:16:18   Up Channel  9:  23700000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 20 17:16:18 --

So, amusingly, my downstream power is now worse than it was before, hahaha.  Well, it's still well within the allowed range (-8 to +8), so I'm not worried.

 

However: he and I were both a little worried about the upstream power.  He said that as long as it stays consistently at 49/50/51 not to worry too much, but if it starts to get higher absolutely there's risk of trouble.  His impression is that the issue is that there's just too many splitters going on for a building with 6 apartments, and it would be really good to get that 2nd coax line (the one just laying on the roof doing nothing) put in use since it would help things overall.

 

His impression is that possibly someone at the headend found something wrong and fixed it, and/OR that the tech that came out and put that yellow tag on someone elses line may have addressed something in the process.  Hard to say.

 

I asked him how we could go about doing that (I added "if it involves money I am happy to pay for the time"), since my opinion is that since there's already a 2nd line we should make use of it.  He agreed, but explained to me the politics of the whole field tech vs. network tech ordeal -- and this isn't the first time I've heard this.  Apparently the majority of the time -- but not always -- when a tech like him asks networking to enable a port or turn up a 2nd line like this, if the existing line is already "within specification", they just flat out say no.  However, he said there's been a couple cases in recent days where his boss said "nah networking isn't going to do squat", but he called them anyway and the network tech said "sure thing" and 30 minutes later the network tech had gone out + done it.  So it seems to be a toss-up as to whether or not you get a good network tech or a lazy/bad one.

 

He left me his phone number + hours + days he worked and stated, quote: "the next time you see that packet loss problem, and ESPECIALLY that drop in SNR, call me immediately and I can look at it remotely from my truck.  If it happens again, we have a couple options".  He was super friendly and educated me a lot about cable in general, plus how all the stuff gets run + etc..  Very very cool.  He also seemed quite happy with the fact that I keep a very close eye on my equipment + track problems like this, since most customers are just "the Internet is down" and troubleshooting it all is a lot easier when you have someone who is knowledgeable (I'm a UNIX SA + NA for IP stuff, not cable :-) ) and who's willing to help out and provide insights.

 

Overall the experience i had was fantastic, but the result when he left was the same as before he arrived: things are working, but still kinda "ehhhhhhhh".  So all I can do now is wait and see if the SNR problem + packet loss problem comes back, and if so, give him a ring immediately and then get that ball rolling.  I would call that excellent service (honestly, no sarcasm).  It made me really happy to get a good field tech who was willing to share knowledge and I almost felt like I was working *with* him.  Very cool.

 

I'll post here if things recur.

 

EDIT: I do plan on talking to my neighbours over the next few days + checking our their cable modems to see what their stats look like now vs. what they looked like before he swapped out the main drop coax end connector.  I now can see how the gal downstairs from me has an upstream power of 52dB though -- she's at the end of 4 splitters!  Ouch.

Contributor

Re: Recurring T3 timeouts since 08/14


koitsu wrote:
It went to some kind of box (he called it a "hub") that contained "4 ports".  The box was labelled something like "SSP-3N" or "SSN-3P", I forget.

Took a photo of said box.  It's way up there and my cheap digital camera doesn't have good zoom (I turn off digital zoom since it sucks), so it's hard to read, but: it says SSP-3N for certain:

 

http://jdc.koitsu.org/lj/666hope/20120820_hub.jpg

 

I know it's a bit blurry, but of 8 shots thats the best one.  Had to do some contrast/brightness adjustment to get the letters more readable too.

Contributor

Re: Recurring T3 timeouts since 08/14

 

Things were smooth-sailing until  this morning when reviewing my traceroutes + cable modem log, I saw this:

Aug 21 2012 03:35:00 3-Critical T05.0 SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=cc:7d:37:98:ae:0b;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Aug 21 2012 03:34:44 3-Critical R04.0 Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=cc:7d:37:98:ae:0b;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Aug 21 2012 03:34:37 3-Critical T05.0 SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=cc:7d:37:98:ae:0b;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

And this is what my cable modem reported during that timeframe -- note the upstream carrier statuses, and the downstream uncorrected frames count:

Aug 21 04:30:00    Device Model: Motorola SB6121 (hardware version 5.0)
Aug 21 04:30:00        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 21 04:30:00       Boot Code: PSPU-Boot(25CLK) 1.0.12
Aug 21 04:30:00    Modem Uptime: 0 days 11h:56m:8s
Aug 21 04:30:00 Down Channel  2: 717000000 Hz,  -1 dBmV power, 37 dB SNR, mod: QAM256, corr: 1204, uncorr: 602
Aug 21 04:30:00 Down Channel  1: 705000000 Hz,  -1 dBmV power, 37 dB SNR, mod: QAM256, corr: 1121, uncorr: 697
Aug 21 04:30:00 Down Channel  4: 729000000 Hz,  -1 dBmV power, 37 dB SNR, mod: QAM256, corr: 1168, uncorr: 692
Aug 21 04:30:00 Down Channel  8: 753000000 Hz,  -1 dBmV power, 36 dB SNR, mod: QAM256, corr: 850, uncorr: 663
Aug 21 04:30:00   Up Channel  8:  30600000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 21 04:30:00   Up Channel  7:  35400000 Hz,  50 dBmV power, 2.560 Msym/sec, status: Success
Aug 21 04:30:00   Up Channel  9:  23700000 Hz,  49 dBmV power, 5.120 Msym/sec, status: Success
Aug 21 04:30:00 --
Aug 21 04:35:00    Device Model: Motorola SB6121 (hardware version 5.0)
Aug 21 04:35:00        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 21 04:35:00       Boot Code: PSPU-Boot(25CLK) 1.0.12
Aug 21 04:35:00    Modem Uptime: 0 days 12h:1m:7s
Aug 21 04:35:00 Down Channel  2: 717000000 Hz,   0 dBmV power, 19 dB SNR, mod: QAM256, corr: 1245, uncorr: 2517
Aug 21 04:35:00 Down Channel  1: 705000000 Hz,   0 dBmV power, 19 dB SNR, mod: QAM256, corr: 1138, uncorr: 2543
Aug 21 04:35:00 Down Channel  4: 729000000 Hz,   0 dBmV power, 19 dB SNR, mod: QAM256, corr: 1288, uncorr: 2436
Aug 21 04:35:00 Down Channel  8: 753000000 Hz,   0 dBmV power, 19 dB SNR, mod: QAM256, corr: 869, uncorr: 2414
Aug 21 04:35:00   Up Channel  8:  30600000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 21 04:35:00   Up Channel  7:  35400000 Hz,  50 dBmV power, 2.560 Msym/sec, status: T4 TimeOut
Aug 21 04:35:00   Up Channel  9:  23700000 Hz,  49 dBmV power, 5.120 Msym/sec, status: T4 TimeOut
Aug 21 04:35:00 --
Aug 21 04:40:00    Device Model: Motorola SB6121 (hardware version 5.0)
Aug 21 04:40:00        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 21 04:40:00       Boot Code: PSPU-Boot(25CLK) 1.0.12
Aug 21 04:40:00    Modem Uptime: 0 days 12h:6m:8s
Aug 21 04:40:00 Down Channel  2: 717000000 Hz,   0 dBmV power, 37 dB SNR, mod: QAM256, corr: 1822, uncorr: 6873
Aug 21 04:40:00 Down Channel  1: 705000000 Hz,   0 dBmV power, 37 dB SNR, mod: QAM256, corr: 1864, uncorr: 6646
Aug 21 04:40:00 Down Channel  4: 729000000 Hz,  -1 dBmV power, 37 dB SNR, mod: QAM256, corr: 1803, uncorr: 6942
Aug 21 04:40:00 Down Channel  8: 753000000 Hz,  -1 dBmV power, 36 dB SNR, mod: QAM256, corr: 1198, uncorr: 6793
Aug 21 04:40:00   Up Channel  8:  30600000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 21 04:40:00   Up Channel  7:  35400000 Hz,  50 dBmV power, 2.560 Msym/sec, status: Success
Aug 21 04:40:00   Up Channel  9:  23700000 Hz,  49 dBmV power, 5.120 Msym/sec, status: Success
Aug 21 04:40:00 --

Note that this happened at 4:34 PDT in the morning -- so this would very likely be Comcast doing CMTS maintenance.

 

But then later, at 8:42 PDT:

Aug 21 2012 07:42:57 3-Critical R02.0 No Ranging Response received - T3 time-out;CM-MAC=cc:7d:37:98:ae:0b;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

So I reviewed my traceroutes, and it looks like something went crazy around 8:14 PDT until 08:32 PDT:

 

=== Tue Aug 21 08:14:00 PDT 2012  (1345562040)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   0.4
  2.|-- 67.180.84.1                5.0%    40    38  27.8 184.8   9.9 1710.4
  3.|-- 68.85.191.249              7.5%    40    37   9.0 135.2   8.3 1641.2
  4.|-- 69.139.198.90              2.5%    40    39  20.1 190.7  10.6 2061.4
  5.|-- 68.86.91.45                7.5%    40    37  18.4 122.5  12.0 1444.0
  6.|-- 4.71.118.49               12.5%    40    35  15.7  90.9  11.0 1374.5
  7.|-- 4.69.152.190               2.5%    40    39  13.4 191.9  11.2 1916.2
  8.|-- 4.69.153.9                 2.5%    40    39  12.5 215.0  11.4 1847.2
  9.|-- 4.69.132.10               10.0%    40    36  19.4 158.3  18.7 1719.4
 10.|-- 4.69.137.34                7.5%    40    37  19.8 181.7  19.0 1719.0
 11.|-- 4.69.137.1                10.0%    40    36  19.6 158.2  18.7 1652.1
 12.|-- 4.69.133.205              12.5%    40    35  23.4 242.7  21.8 2066.3
 13.|-- 4.53.121.58                7.5%    40    37  25.5 165.4  23.5 1929.7
 14.|-- 216.98.153.78              7.5%    40    37  26.0 171.4  23.8 1930.5
 15.|-- 209.126.140.25             2.5%    40    39  24.7 196.8  24.1 1862.7
=== END

=== Tue Aug 21 08:15:00 PDT 2012  (1345562100)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   0.4
  2.|-- 67.180.84.1               10.0%    40    36  43.0 266.1   9.3 2133.2
  3.|-- 68.85.191.249             12.5%    40    35   9.7 145.9   8.1 2049.4
  4.|-- 69.139.198.90             10.0%    40    36  16.9 143.7  12.0 2055.8
  5.|-- 68.86.91.45               10.0%    40    36  15.3 172.1  13.2 1919.3
  6.|-- 4.71.118.49                7.5%    40    37  11.8 159.8  11.4 1780.8
  7.|-- 4.69.152.190               7.5%    40    37  11.7 126.0  11.2 1445.7
  8.|-- 4.69.153.9                10.0%    40    36  12.1 144.9  11.0 1713.6
  9.|-- 4.69.132.10               12.5%    40    35  21.8  94.9  19.1 1312.7
 10.|-- 4.69.137.34                0.0%    40    40  19.3 216.5  19.2 1653.4
 11.|-- 4.69.137.1                10.0%    40    36  19.5 164.1  19.0 1584.4
 12.|-- 4.69.133.205              12.5%    40    35  21.9 165.9  21.9 1451.2
 13.|-- 4.53.121.58                7.5%    40    37  24.8 126.0  23.4 1452.4
 14.|-- 216.98.153.78             15.0%    40    34  23.6 166.9  23.2 1997.8
 15.|-- 209.126.140.25            12.5%    40    35  25.9 106.9  23.9 2269.4
=== END

 

=== Tue Aug 21 08:16:00 PDT 2012  (1345562160)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   0.4
  2.|-- 67.180.84.1                0.0%    40    40  28.5  58.5  10.1 1145.9
  3.|-- 68.85.191.249              0.0%    40    40   8.7   9.6   8.1  11.1
  4.|-- 69.139.198.90              0.0%    40    40  22.2  17.0  10.4  23.4
  5.|-- 68.86.91.45                0.0%    40    40  16.8  19.1  12.6  25.0
  6.|-- 4.71.118.49                0.0%    40    40  12.0  13.9  11.1  46.3
  7.|-- 4.69.152.190               0.0%    40    40  12.2  16.2  11.0  38.8
  8.|-- 4.69.153.9                 0.0%    40    40  11.6  12.6  11.2  27.9
  9.|-- 4.69.132.10                0.0%    40    40  20.2  20.5  18.9  22.3
 10.|-- 4.69.137.34                0.0%    40    40  26.9  23.7  19.3  32.7
 11.|-- 4.69.137.1                 0.0%    40    40  20.9  20.9  18.9  35.7
 12.|-- 4.69.133.205               0.0%    40    40  24.6  54.7  21.9 213.6
 13.|-- 4.53.121.58                0.0%    40    40  24.6  27.2  23.2  93.0
 14.|-- 216.98.153.78              0.0%    40    40  24.7  25.7  23.6  41.2
 15.|-- 209.126.140.25             0.0%    40    40  24.3  25.7  24.0  41.4
=== END

=== Tue Aug 21 08:17:00 PDT 2012  (1345562220)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   0.4
  2.|-- 67.180.84.1                0.0%    40    40  27.2  81.4  10.1 1711.4
  3.|-- 68.85.191.249              0.0%    40    40  14.4  66.7   8.4 1642.5
  4.|-- 69.139.198.90              2.5%    40    39  18.2  70.5  10.8 1588.0
  5.|-- 68.86.91.45                0.0%    40    40  14.1  67.9  12.8 1512.6
  6.|-- 4.71.118.49                0.0%    40    40  11.5  62.2  11.3 1441.4
  7.|-- 4.69.152.190               0.0%    40    40  13.4  58.5  11.1 1374.5
  8.|-- 4.69.153.9                 2.5%    40    39  11.4  19.6  11.3 287.6
  9.|-- 4.69.132.10                2.5%    40    39  20.8  26.2  19.0 226.2
 10.|-- 4.69.137.34                0.0%    40    40  21.2  55.4  19.3 1177.1
 11.|-- 4.69.137.1                 0.0%    40    40  19.7  49.2  18.9 1110.1
 12.|-- 4.69.133.205               0.0%    40    40  60.0  64.8  21.7 1045.0
 13.|-- 4.53.121.58                2.5%    40    39  24.0  49.2  23.3 978.0
 14.|-- 216.98.153.78              0.0%    40    40  24.6  95.4  23.4 1929.8
 15.|-- 209.126.140.25             0.0%    40    40  25.8  91.6  23.4 1862.8
=== END

=== Tue Aug 21 08:18:00 PDT 2012  (1345562280)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.4   0.3   0.2   0.4
  2.|-- 67.180.84.1                7.5%    40    37  28.1 196.0  10.9 1779.3
  3.|-- 68.85.191.249              0.0%    40    40  10.2 239.6   8.2 2118.0
  4.|-- 69.139.198.90              5.0%    40    38  14.5 208.7  10.4 2058.2
  5.|-- 68.86.91.45                5.0%    40    38  12.0 173.3  12.0 1993.5
  6.|-- 4.71.118.49                5.0%    40    38  11.5 141.1  11.0 1916.5
  7.|-- 4.69.152.190               7.5%    40    37  17.3 193.0  11.0 1853.2
  8.|-- 4.69.153.9                10.0%    40    36  13.0 162.4  10.9 2120.2
  9.|-- 4.69.132.10                2.5%    40    39  20.1 225.7  18.9 2060.3
 10.|-- 4.69.137.34                7.5%    40    37  20.8 179.2  19.1 1927.4
 11.|-- 4.69.137.1                15.0%    40    34  19.6 105.0  19.0 1177.3
 12.|-- 4.69.133.205              12.5%    40    35  93.9 134.3  21.9 1859.0
 13.|-- 4.53.121.58                5.0%    40    38  25.0 258.6  23.4 2065.2
 14.|-- 216.98.153.78              5.0%    40    38  24.5 225.9  23.4 1997.2
 15.|-- 209.126.140.25             5.0%    40    38  25.0 240.1  23.9 1930.3
=== END

=== Tue Aug 21 08:19:00 PDT 2012  (1345562340)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   0.4
  2.|-- 67.180.84.1               12.5%    40    35  26.2 126.4   9.8 1439.7
  3.|-- 68.85.191.249              5.0%    40    38   8.7 207.7   8.4 2291.1
  4.|-- 69.139.198.90              7.5%    40    37  11.5 157.8  11.5 2230.5
  5.|-- 68.86.91.45                5.0%    40    38  21.1 167.9  12.8 1520.6
  6.|-- 4.71.118.49                5.0%    40    38  12.0 224.3  11.1 2091.3
  7.|-- 4.69.152.190               5.0%    40    38  12.0 218.2  10.9 2022.2
  8.|-- 4.69.153.9                 7.5%    40    37  13.1 237.1  10.9 2053.6
  9.|-- 4.69.132.10                2.5%    40    39  20.4 242.6  18.9 1994.2
 10.|-- 4.69.137.34               12.5%    40    35  27.6 102.9  19.4 1184.7
 11.|-- 4.69.137.1                12.5%    40    35  20.9 176.0  19.0 2128.7
 12.|-- 4.69.133.205              10.0%    40    36  21.6 202.9  21.6 2063.6
 13.|-- 4.53.121.58                7.5%    40    37  24.6 200.8  23.1 1997.6
 14.|-- 216.98.153.78              7.5%    40    37  23.9 192.4  23.4 1929.7
 15.|-- 209.126.140.25             2.5%    40    39  25.1 226.5  24.3 1861.8
=== END

...and so on...

 

The latter looks exactly like what I've been seeing + complaining about + trying to get fixed.  I guess I'll give the tech a call and let him know what I saw this morning.

 

Contributor

Re: Recurring T3 timeouts since 08/14

Spoke to the tech -- he looked in his system (presumably at the CMTS side of things?) and confirmed T3 timeouts during the timeframe I specified, as well as some T3 timeouts late last night (on then night of the 20th).  The latter timeouts I did not see, which is interesting.

 

He said he's going to talk to his lead about this, since he's starting to feel that this is a problem for network, but that he might bring his lead out here to check things out and see for himself + make a decision.  He definitely agrees there's a problem that needs further investigating and wants to get it solved sooner than later since if it's a network or node issue it's something that needs to get addressed ASAP.

Contributor

Re: Recurring T3 timeouts since 08/14


koitsu wrote:

koitsu wrote:
It went to some kind of box (he called it a "hub") that contained "4 ports".  The box was labelled something like "SSP-3N" or "SSN-3P", I forget.

Took a photo of said box.  It's way up there and my cheap digital camera doesn't have good zoom (I turn off digital zoom since it sucks), so it's hard to read, but: it says SSP-3N for certain:

 

http://jdc.koitsu.org/lj/666hope/20120820_hub.jpg

 

I know it's a bit blurry, but of 8 shots thats the best one.  Had to do some contrast/brightness adjustment to get the letters more readable too.


The "Tap" is the 4 port box. it has a value on it and that helps determine signal and return transmits.

 

The SSP-3N is a 2 way splitter for hardline. thats probably why he called his supervisor and asked about another line being ran. He was asking for hardline and tap to be installed in the box instead of RG-6 drops and splitters. It was hard to tell from your pic but the bottom right side is probably terminated.There are several places like this in my area for various reasons.

 

In terms of the picture with the notes he took.

 

He was checking his common frequencies( like i knew he would)

 

He checked 2 ( a low freq 55.25), a mid (58 429 mhz) and a high(113 729 mhz) which 113(729mhz) according to your posted logs is probably the default docsis channel that their meters are set up to test. Here our default is 79(555mhz).

 

He was +15 on the downstream(RX) with 39?(looks like SNR) and 38 transmit.

 

38+ all your splitter values is how you get to 50.

 

15 - all your splitter values + some cable loss is how you get 0 to -3 dbmv downstream signal.

 

To me the Amp needs to be checked, its a network issue. I've seen this same exact issue in one area around me like i said

 

I'm curious if it affects speeds. run speedtest.comcast.net  pick same sever and compare when good and bad. When the modem in my area jumped on the 2 low SNR freq the speeds dropped to around 1 mbps and it was hard to surf. We only had 4 downstream docsis freq at the time, we recently added 4 more so the modem couldnt jump back to 4 good ones like it can for you.

Contributor

Re: Recurring T3 timeouts since 08/14

Yeah, he said he'll get back to me either today or tomorrow morning and further discuss things with me and his supervisor.

 

I decided to take a look at the SNR for carrier frequency 753MHz (since that's currently what I'm using), parsing my monitoring logs for the cable modem.  Sorry for the "complex-looking" UNIX + awk stuff, but:

 

$ cat /var/log/captures/sb612x.log | awk '/753000000/ { print $12 " " $13 " " $14 }' | sort | uniq -c
   1 19 dB SNR,
   1 31 dB SNR,
   1 32 dB SNR,
   3 33 dB SNR,
   8 34 dB SNR,
  44 35 dB SNR,
 149 36 dB SNR,
   1 37 dB SNR,

The number on the left indicates how many times in my logs I've seen the that level of SNR, specific to 753MHz.  This covers time frame 08/21 00:00 until right now.

 

The 19dB drop shown was during 04:35 this morning when I lost sync + someone probably doing something at the headend.  So I'm ignoring that one for now.

 

As you can see, the average SNR is 35-36dB, except there are definite times where it drops all the way down to 31dB.  So the noise problem is still there it seems.

 

Come to think of it, when I asked him to explicitly scan 747MHz and 753MHz given the horrible SNR I'd seen historically, he actually made a "grunting" noise (I interpreted this to mean "I can't be bothered").  I think that's probably an indication he'd rather have a line/network tech do it.  I did watch the scanning and I swore I saw frequencies above 741MHz, and he assured me that "if anything was out of spec the unit would emit a beep" (there was no beeping).  But of course if the range isn't going up that high, then of course it's not going to find a problem.

 

On the bright side, last T3 timeout I saw was at 08:40-something this morning -- so I haven't seen any all day, and generally speaking the Internet (today) has been mostly okay (barring previous post/incident).

Regular Contributor

Re: Recurring T3 timeouts since 08/14

koitsu - you need to give us an update! It's been 2 1/2 days with no new installment in your saga. Have your connectivity issues been resolved?

Contributor

Re: Recurring T3 timeouts since 08/14

Sorry to not follow up publicly, I've been discussing the matter privately with someone who contacted me via these forums.  :-)

 

Short version: problem is still happening actively.  Going on 11 days now.  I still see T3 timeouts and packet loss intermittently.

 

A network/line tech came out on Wednesday (he wasn't officially on schedule to investigate this, was doing it as a nicety) to check out my cable box + run some tests (from the main drop/in line) + examine hubs/taps and so on.  He was able to confirm, from looking at the SNR of my neighbour's flat, that there is a noise problem of some kind, but he hasn't narrowed its location down yet.

 

He was under the impression the line amp feeding our building was coming from the succeeding block (e.g. the 700-block of Hope Street) since that's what their map/documentation said, but upon visual inspection determined that that isn't the case (instead being fed from somewhere on the preceding block, e.g. possibly 500-block of Hope Street).  He said he would register for a block of official time in the system + start trying to figure out what was going on.

 

We did figure out why my upstream power level went from 46-47 to 50-51 after Saturday when that Comcast installer came out to install apt 6 -- that installer ran brand new coax from apt 6 to the cable box and proceeded to install a 3.5/3.5 splitter.  It's the splitter shown on the far left.  (So that splitter handles apt 5 (me) and apt 6).

 

So the last contact I've had with anyone from Comcast officially was Wednesday.  I am currently under the assumption that people are trying to figure it out.  :-)

 

In the interim, I modified my modem polling script to write to a CSV file, and then fed that into dygraphs, so that I could graph the SNR of all my downstream channels.  I also increased my polling interval to every 2 minutes and the graph is thus real-time.  I do all of this on my own LAN, but I periodically (manually!) upload the results to my own website where people can see what's going on too:

http://jdc.koitsu.org/snrgraph/

 

The graph is zoomable (drag/select), and to get back to the zoomed out view double-click on the graph.  You can enable/disable visualisation of any of my other frequencies using the checkboxes at the bottom.  Sorry for not having data between the mid-16th to the mid-20th; my own problems/complexities (and changing cable modems more than a few times) made getting this difficult.

 

The "drop out" (drop to 0) on the 22nd was when the network tech came out and tested the main Comcast drop/in out at the cable box.

 

Based on the graph, the issue appears to have began roughly August 12th (Sunday) and has gotten progressively worse since then.

 

But more importantly, the graph also shows just how intermittent the issue is -- meaning a single tech visit may or may not turn up anything because the SNR drop might only last a few minutes.  But during some hours of the day (and it varies as you can see!), the drops repeatedly happen, over the course of many hours.

 

My stats script shows the below (look at the number of corrected frames on 753MHz):

Aug 24 10:17:52    Device Model: Motorola SB6121 (hardware version 5.0)
Aug 24 10:17:52        Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 24 10:17:52       Boot Code: PSPU-Boot(25CLK) 1.0.12
Aug 24 10:17:52    Modem Uptime: 1 days 21h:45m:19s
Aug 24 10:17:52    Modem Status: Operational
Aug 24 10:17:52 Down Channel  2: 717000000 Hz,   0 dBmV power, 36 dB SNR, mod: QAM256, corr: 4652, uncorr: 619
Aug 24 10:17:52 Down Channel  4: 729000000 Hz,   0 dBmV power, 36 dB SNR, mod: QAM256, corr: 4464, uncorr: 540
Aug 24 10:17:52 Down Channel  6: 741000000 Hz,  -1 dBmV power, 37 dB SNR, mod: QAM256, corr: 3455, uncorr: 509
Aug 24 10:17:52 Down Channel  8: 753000000 Hz,  -1 dBmV power, 36 dB SNR, mod: QAM256, corr: 43866, uncorr: 485
Aug 24 10:17:52   Up Channel  8:  30600000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 24 10:17:52   Up Channel  7:  35400000 Hz,  51 dBmV power, 2.560 Msym/sec, status: Success
Aug 24 10:17:52   Up Channel  9:  23700000 Hz,  50 dBmV power, 5.120 Msym/sec, status: Success
Aug 24 10:17:52 --

 

And the last packet loss event was a few minutes ago:

 

=== Fri Aug 24 10:13:00 PDT 2012  (1345828380)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.4   0.3   0.2   0.4
  2.|-- 67.180.84.1                0.0%    40    40  13.0  82.7  10.6 1710.7
  3.|-- 68.85.191.249              2.5%    40    39  10.2  51.5   8.2 1641.8
  4.|-- 69.139.198.90              5.0%    40    38  34.5  17.5  10.7  34.5
  5.|-- 68.86.91.45                5.0%    40    38  15.5  17.9  12.3  26.1
  6.|-- 4.71.118.49                0.0%    40    40  12.0  65.3  11.3 1469.3
  7.|-- 4.69.152.190               7.5%    40    37  13.2  16.6  11.1  35.0
  8.|-- 4.69.153.9                 0.0%    40    40  12.5  51.5  11.1 1304.4
  9.|-- 4.69.132.10                2.5%    40    39  21.7  26.0  18.5 225.9
 10.|-- 4.69.137.34                0.0%    40    40  19.8  56.2  19.8 1176.7
 11.|-- 4.69.137.1                 2.5%    40    39  19.7  50.8  19.0 1109.7
 12.|-- 4.69.133.205               5.0%    40    38  23.4  23.9  21.8  46.9
 13.|-- 4.53.121.58                0.0%    40    40  25.3 114.2  23.2 1996.5
 14.|-- 216.98.153.78              5.0%    40    38  27.7  25.7  23.8  40.9
 15.|-- 209.126.140.25             0.0%    40    40  24.7  91.7  23.8 1861.7
=== END

=== Fri Aug 24 10:14:00 PDT 2012  (1345828440)
HOST: icarus.home.lan             Loss%   Snt   Rcv  Last   Avg  Best  Wrst
  1.|-- 192.168.1.1                0.0%    40    40   0.3   0.3   0.2   0.4
  2.|-- 67.180.84.1                5.0%    40    38  19.7  83.0  10.4 1643.8
  3.|-- 68.85.191.249              5.0%    40    38   9.8  68.9   8.5 1574.7
  4.|-- 69.139.198.90              5.0%    40    38  18.0  61.5  11.6 1100.2
  5.|-- 68.86.91.45                7.5%    40    37  19.6  31.2  12.9 428.3
  6.|-- 4.71.118.49                2.5%    40    39  30.6  87.2  11.3 1373.2
  7.|-- 4.69.152.190               5.0%    40    38  12.7  46.7  11.3 901.3
  8.|-- 4.69.153.9                 5.0%    40    38  12.2  87.8  11.0 1847.2
  9.|-- 4.69.132.10                2.5%    40    39  20.3 144.6  19.1 2197.3
 10.|-- 4.69.137.34                7.5%    40    37  19.7  89.1  19.1 1719.7
 11.|-- 4.69.137.1                 0.0%    40    40  20.9 153.6  19.3 2062.3
 12.|-- 4.69.133.205               2.5%    40    39  23.9 121.6  22.0 1996.3
 13.|-- 4.53.121.58                7.5%    40    37  24.5  54.9  23.2 910.7
 14.|-- 216.98.153.78              5.0%    40    38  23.8 110.7  23.3 1862.6
 15.|-- 209.126.140.25             5.0%    40    38  24.4  91.3  23.5 1794.8
=== END

And the cable modem log entry matches up almost perfectly (remember cable modem log doesn't support DST, so add an hour):

 

Aug 24 2012 09:17:55 3-Critical R02.0 No Ranging Response received - T3 time-out;CM-MAC=cc:7d:37:98:ae:0b;CMTS-MAC=00:01:5c:32:6e:44;CM-QOS=1.1;CM-VER=3.0;

 

Contributor

Re: Recurring T3 timeouts since 08/14

Today has been particularly bad.  In fact, the graph is pretty indicative of it too.  SNR has been between 29-34 pretty much most of the afternoon.  And like expected, I've seen packet loss all day, mostly non-stop, with very small intervals (maybe 3-4 minutes at most) where things were clean/good.  Some friends linked me some Youtube and Niconicodouga videos earlier which I couldn't even watch because they'd just stall or whatever.

 

And yes I know video sites aren't the best thing to test with, but they're something that has constant network traffic flowing, so they often make for good tests of this sort.  Speedtests and so on aren't necessarily helpful because they don't indicate error conditions, just overall throughput -- plus given the duration of the incidents it's very likely a speedtest will finish before the next T3 timeout thus "everything looks fine".  I'm not gonna sit around all day running speedtests constantly, haha.  :-)

 

So yeah, if anyone from Comcast (aside from the folks I've already talked to I guess?) has some way to poke engineers/etc. about this, I will be happy to work with whomever to figure this out.  Very frustrating.  And just a footnote reminder: my neighbour has the same experience (T3 timeouts, packet loss, low SNR) so it's not specific to my stuff.