pokesphIt Is Almost Fast Premium Member join:2001-06-25 Sacramento, CA |
to travelguy
Re: [Connectivity] New SB6120/6121 Firmware Releasednothing over here either.. still on Firmware Name: SB612X-1.0.3.3-SCM00-NOSH |
|
Asus RT-AC68 Ubiquiti NSM5
|
to DisturbedDan
said by DisturbedDan:Is 1.0.6.6 the new firmware for sb6121? As has been posted 1068 is currently being tested by a limited number of subscribers. It addresses some of the channel bonding issues introduced in 1066, which was widely deployed a few months ago. |
|
|
to travelguy
Ah.... my fault. I didn't read something fully. |
|
koitsu MVM join:2002-07-16 Mountain View, CA |
to Mike Wolf
I'm currently helping Comcast test 1.0.6.8. I imagine it may be deployed in the field to very, very small/specific areas, otherwise if outside those areas it has to be done manually/on a per-customer basis. |
|
|
What makes you think that ? |
|
koitsu MVM join:2002-07-16 Mountain View, CA Humax BGW320-500
|
koitsu
MVM
2012-Sep-25 3:24 pm
Because the user mentioned here is not in the same area I am, and it's fairly likely this user did not go to Comcast and ask to test a new firmware version. So there must be small "test regions" in the field. |
|
|
|
to pokesph
said by pokesph:nothing over here either.. still on Firmware Name: SB612X-1.0.3.3-SCM00-NOSH Have you rebooted your modem recently? |
|
|
If you are currently on 1033, I wouldn't do anything to try to get 1066. For that matter, Comcast may have suspended deployment of 1066, but I still wouldn't force a reboot. |
|
|
There is no proof that the firmware update actually caused problems. I still wonder how many started having problems because they didn't start bonding upstream until after the firmware update and the reboot that requires. Just because Comcast started offering upstream bonding doesn't mean the modem will automatically start using it. You have to reboot it to get enable it. |
|
Asus RT-AC68 Ubiquiti NSM5
|
True. However, I know in my case I was seeing 50/5 with bonded down/up channels on 1033. When 1066 was pushed, I dropped to 20/1.5. Still seeing bonded down channels, but only a single uplink channel. 1088 restored the downlink speed back to 50, and I'm seeing 2 functional uplink channels, but uplink speed is stuck on 1.5. |
|
|
Was going to get one of these modems today.
Should I get a zoom instead?
My old 5120 always been reliable but firmware never updated either as far as I know. |
|
|
I'd go with the Zoom. |
|
tshirt Premium Member join:2004-07-11 Snohomish, WA |
to travelguy
I have a Moto6120 and I'm happy with it. BUT based on the current Zoom "J" price, IF I was buying today, I'd seriously try to find one (I prefer local shopping whenever possible) nearby. You can always rent for a few months to see what happens, or buy now a replace it next year, if something better shows up. |
|
Asus RT-AC68 Ubiquiti NSM5
|
to ExoticFish
I would as well, if only because the Zoom is reported to have the ability to bond more uplink channels than the Motos do, if and when Comcast ever chooses to take advantage of that. That said, it's not clear if the recent problem reports are due to the Moto firmware, changes on the CMTS side or some combination of things. There was a least one report that a Zoom buyer didn't see any change and ended returning the modem. |
|
|
I seen the 8 channel vs 4 channels. Seems that would be more reliable if and when my neighbors leave uverse.
Thanks. |
|
|
Actually the Motorola SB 6140 is a 8 down 4 up modem just like the Zoom. I have had that modem for about 6 weeks with no problems at all. |
|
koitsu MVM join:2002-07-16 Mountain View, CA Humax BGW320-500
|
to IndyGamer
The Zoom 5341J on Comcast (at least in my area) does bond to 8 downstream frequencies/channels. Comcast only offers 8 downstream frequencies (705/717/723/729/735/741/747/753MHz) in my area. More bonded channels does not mean more reliability. I'm happy to refer you to an issue in my area which is affecting 747 and 753MHz caused by 4G/LTE cellular tower interference -- avoiding use of those frequencies is the only workaround at this time. Now try to imagine what my experience would be like if I had a Zoom 5341J -- and here's evidence I've actually used one -- I'd be forced to use 747 and 753MHz, which would mean roughly 1/4 (technically 2/8) DOCSIS frames coming down the wire would result in the need for retransmission, which means delays + packet loss. More bonded channels != more reliability. More bonded channels == more load distribution across multiple frequencies, vs. just banging on one single frequency, and eventually more bandwidth (not throughput/speed, but bandwidth). That's it. I feel sorry for anyone who uses the entire downstream spectrum in their area and has SNR issues on specific frequencies -- there's absolutely nothing the customer can do in the meantime but suffer. |
|
|
Sorry, That should be 6141 not 6140. |
|
1 recommendation |
to travelguy
Could have been an issue on Comcast's CMTS end that got messed up somehow and got straigtened out during a maintenance cycle. Phantom glitches. |
|
|
It is something of concern that there's a T4 that stays on top of the log and keeps changing its time on a refresh of the log page? Seems to update the time mark every 30 seconds. Don't remember if I was seeing that before 1.0.6.6 showed up. |
|
koitsu MVM join:2002-07-16 Mountain View, CA Humax BGW320-500
|
koitsu
MVM
2012-Sep-27 1:23 pm
said by catnapped:It is something of concern that there's a T4 that stays on top of the log and keeps changing its time on a refresh of the log page? Seems to update the time mark every 30 seconds. Don't remember if I was seeing that before 1.0.6.6 showed up. Repeated issues of the exact same type/error simply update the timestamp of the top row log entry, rather than continually prepend additional rows. What you describe indicates continual T4 timeouts, not occasional. Occasional T4 timeouts are acceptable. Constant, non-stop T4s are not. What you describe is indicative of a different problem and is not firmware related. Please start another thread or engage folks in the Comcast Direct forum for assistance; something at the head-end needs to be investigated. |
|
|
to catnapped
said by catnapped:It is something of concern that there's a T4 that stays on top of the log and keeps changing its time on a refresh of the log page? Seems to update the time mark every 30 seconds. Don't remember if I was seeing that before 1.0.6.6 showed up. If you look at your signals, one of your upstream channels is probably listed as 'T4 Timeout'. That means it cannot connect on that one. Sometimes, rebooting will get it to connect. If you signals are marginal, it may occur again. |
|
tshirt Premium Member join:2004-07-11 Snohomish, WA |
to catnapped
T4's are often associated with upstream noise, so you could call in and ask what your upstream SNR is like. |
|
|
One of the interesting things is that, when people have posted issues on 3-channel upstream bonding with a T4'd channel, it's always the middle channel, even if it's not the middle frequency. |
|
koitsu MVM join:2002-07-16 Mountain View, CA Humax BGW320-500
|
koitsu
MVM
2012-Sep-27 7:27 pm
said by andyross:One of the interesting things is that, when people have posted issues on 3-channel upstream bonding with a T4'd channel, it's always the middle channel, even if it's not the middle frequency. I cannot confirm this. Proof from my cable modem polling script logs, with firmware 1.0.6.6, are below. Apologies for the syntax changes in the log too (I removed the modulation type sometime in late August to make things easier to read): Sep 09 08:56:00 Up Channel 9: 23700000 Hz, 51 dBmV power, 5.120 Msym/sec, status: T4 TimeOut
Sep 09 08:58:00 Up Channel 9: 23700000 Hz, 51 dBmV power, 5.120 Msym/sec, status: T4 TimeOut
Aug 22 12:20:01 Up Channel 8: 30600000 Hz, 50 dBmV power, 5.120 Msym/sec, status: T4 TimeOut
Aug 22 12:20:01 Up Channel 9: 23700000 Hz, 50 dBmV power, 5.120 Msym/sec, status: T4 TimeOut
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 17 13:30:00 Up Channel 9: 23700000 Hz, 47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: T4 TimeOut
Aug 17 13:50:00 Up Channel 9: 23700000 Hz, 47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: T4 TimeOut
Let's pick August 17th as a test subject: Aug 17 13:30:00 Firmware: SB_KOMODO-1.0.6.6-SCM00-NOSH (Apr 17 2012 15:09:37)
Aug 17 13:30:00 Boot Version: PSPU-Boot(25CLK) 1.0.12.
Aug 17 13:30:00 H/W Version: 5.0
Aug 17 13:30:00 Modem Uptime: 0 days 0h:2m:57s
Aug 17 13:30:00 Down Channel 3: 723000000 Hz, 1 dBmV power, 37 dB SNR, mods: QAM256
Aug 17 13:30:00 Down Channel 5: 735000000 Hz, 2 dBmV power, 36 dB SNR, mods: QAM256
Aug 17 13:30:00 Down Channel 7: 747000000 Hz, 1 dBmV power, 35 dB SNR, mods: QAM256
Aug 17 13:30:00 Down Channel 8: 753000000 Hz, 1 dBmV power, 35 dB SNR, mods: QAM256
Aug 17 13:30:00 Up Channel 8: 30600000 Hz, 47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: Success
Aug 17 13:30:00 Up Channel 7: 35400000 Hz, 48 dBmV power, 2.560 Msym/sec, mods: [3] QPSK [2] 16QAM, status: Success
Aug 17 13:30:00 Up Channel 9: 23700000 Hz, 47 dBmV power, 5.120 Msym/sec, mods: [3] QPSK [3] 64QAM, status: T4 TimeOut
Aug 17 13:30:00 Stats Channel 3: 5604427 unerrored, 44 correctable, 607 uncorrectable
Aug 17 13:30:00 Stats Channel 5: 5604430 unerrored, 11 correctable, 637 uncorrectable
Aug 17 13:30:00 Stats Channel 7: 5604344 unerrored, 13 correctable, 727 uncorrectable
Aug 17 13:30:00 Stats Channel 8: 5604424 unerrored, 21 correctable, 639 uncorrectable
The order you see these channels in is the order they're shown in the actual "Signal" web page interface (from left to right). |
|
Thordrune Premium Member join:2005-08-03 Lakeport, CA |
to koitsu
I guess I've been lucky so far, my 6120 has been flawless with both 1.0.3.3 and 1.0.6.6. Hopefully 1.0.6.8 resolves the issues other people are having, I can imagine how frustrating it is . Ah, very interesting discovery. I was tracking that thread earlier but hadn't read the last couple weeks of posts. That reminds me of an issue I had earlier this month while staying in Las Vegas for a week. My phone was on LTE most of the time (voice calls made it hand off to HSPA). Any time the phone was on LTE, it caused interference on certain TV channels (starting at 6 and roughly every 5-6 thereafter). Having the phone idle on the desk a few feet away caused occasional stuttering/tiling whenever it chirped at the tower, while doing a speedtest killed it completely. Even standing in the far corner of the bathroom (~18 ft, one wall) caused it to drop out. The last night I was there, I ended up testing every single channel, writing down which ones were fine and which ones had issues, and reported it to the hotel service desk when I checked out. Hopefully they do something about it. I have no idea if the interference spread to adjacent rooms. Verizon just turned on LTE service in my town, but our system here is on 549-597 MHz, so we should be spared of similar problems. |
|
|
to andyross
said by andyross:If you look at your signals, one of your upstream channels is probably listed as 'T4 Timeout'. That means it cannot connect on that one. Sometimes, rebooting will get it to connect. If you signals are marginal, it may occur again. Yep...middle channel/middle (upload) frequency that had the T4. Rebooted and got rid of it, but we'll see how long it lasts.... |
|
catnapped |
to travelguy
Guess that answers my question...T4 is back again on one of the upload channels (aaaargh). Levels on my end seem to be ok (at least from other posts I'd seen), so I wonder if there's something with the number that has to be read from their end that's telling. |
|
Asus RT-AC68 Ubiquiti NSM5
|
Yes. The upstream power level you see is really an indirect look at what is going on. The key parameter for the upstream connection is the signal to noise ratio at the CMTS. The upstream power level you see on the modem signal page is the signal, but it's at the modem, not the CMTS, and you can't see any noise levels. |
|
|
to ExoticFish
Of course, you would say that wouldn't you. |
|