cancel
Showing results for 
Search instead for 
Did you mean: 

FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

RogersMargaret
Community Manager (Retired)
Community Manager (Retired)

Hello Community,

 

We are currently offering our users an exclusive opportunity to participate in an upcoming trial of the new firmware for our Rocket Wi-Fi Modem (CGN3ACR, CGN3AMR and CGN3ACSMR) and Rocket Gigabit Wi-Fi Modem (CGN3552 and CODA-4582). For details of this program, please see this thread.

 

This thread will be used for feedback regarding the firmware.  We've invited @RogersSergio@RogersSyd & @RogersBob from our Networking team to participate in this thread.  Your feedback is very valuable and will be used to enhance the firmware before it is released publicly.

 

Thank you for your continued feedback and support.

4,921 REPLIES 4,921

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial


@Nadernt wrote:

@RogersDave

 

I think my modem tried to download the new firmware you may have pushed to it, but "Disruption during SW download - Power Failure" ended up happening and after 3 or so reboots by itself it hasn't updated. I'm on the .28T2 firmware since I factory reset to avoid the reboots. If you can maybe push the .33T3 firmware to me I'd appreciate it. 

 

These were the event logs I got:

1111/09/2017 18:41:0769010900errorDisruption during SW download - Power Failure
1211/09/2017 18:41:0769010100noticeSW Download INIT - Via NMS
1311/09/2017 18:42:0869011100noticeSW download Successful - Via NMS

 

I tried rebooting to see if it would load it but it hasn't. 


I'm trying to do it but I'm having issues. Your modem has the software loaded in the alternate software bank, I just need to figure out how to make it load it....

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

Nadernt
I plan to stick around

Thank you for the quick response. Appreciate it.

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

@RogersDave, what's the root cause or trigger for the reboots.  Understanding that a second design or coding error has been found, what's the trigger?  Is it a signal condition, or caused by a certain traffic type for example?  Beyond updating a modem to .33T3, what should users be looking for in terms of signal levels and/or network configuration and traffic type in order to possibly avoid this.  Personally speaking I don't think I've seen any reboots other than those that I initiate myself.  I suspect that our household is pretty typical, gaming, netflix, youtube videos, web cruising, the occasional VPN, etc, etc. 

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

All I was told is that they found a memory leak in some software module (unspecified) in the gateway function.

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

arnym21
I plan to stick around

@RogersDave

 

May I ask some relevant Qs given you're a well qualified network architect?

 

For example, I see the trend at Rogers to cup even further upload speeds on new Gigabit subs. Hence the question, when this modem FW and Rogers infrastructure will be ready to face Bell challenge with near symmetrical speeds in both directions? What exactly prevents it from happening now, and why the upload speed targets are degrading instead of improving overtime?

 

Another question: I see in some areas Rogers contractors are digging the ground presumably running fibre to street taps. What kind of equipment is replaced or upgraded by doing this, how it will affect local area network capacity, and will CODA modem and its FW be able to coupe with upgraded upload speeds?

 

Yet one more question: why upload speeds seems to have more constrains and limitations in DOCSIS3.0 and 3.1 compare to download speeds? Is that purely a restrictive measure to prevent users uploading content, or its rather driven by limitations of the signal transmission method? How upload signal is different from download signal in that sense?

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

Nadernt
I plan to stick around

@RogersDave

 

Did you figure out how to load the firmware? Is there anything I need to do on this end?

Thanks.

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial


@arnym21 wrote:

@RogersDave

 

May I ask some relevant Qs given you're a well qualified network architect?

 

For example, I see the trend at Rogers to cup even further upload speeds on new Gigabit subs. Hence the question, when this modem FW and Rogers infrastructure will be ready to face Bell challenge with near symmetrical speeds in both directions? What exactly prevents it from happening now, and why the upload speed targets are degrading instead of improving overtime?

DOCSIS networks are very dynamic in nature and are constantly evolving. What happens is that upload speed is very limited compared to download speed (more details in question 3 below).

 

In order to offer symmetrical speed, we need a technology called full duplex DOCSIS. This is great in theory but requires massive change to our infrastructure, going from an active/passive technology to a fully passive network with fibres much deeper into the network so that only splitter are  used instead of a combination of amplifiers/splitters.

 

When it comes to degrading speed, yes usage always increases in every area of the network and this over time degrades speeds. This is continuously monitored and segmentation activities are triggered. Sometimes, we see unforecasted jumps in usage (usage increases faster than our capacity to segment). Problem is that people complain publicly when their speed goes down but rarely that it suddenly improved back... Some segmentation activities are fairly quick (if we already have fibre) or can take months if we need construction permits and digging to lay down new fibres.

 

 

Another question: I see in some areas Rogers contractors are digging the ground presumably running fibre to street taps. What kind of equipment is replaced or upgraded by doing this, how it will affect local area network capacity, and will CODA modem and its FW be able to coupe with upgraded upload speeds?

There could be multiple reasons for this but it is likely a segmentation activity. In a hybrid fibre-coax network (HFC), you have a fibre going from the headend all the way to the node (point where optical signals are converted to coax). A segmentation activity means that we take 1 node (with X number of houses connected to it) and split it in 2 (with X/2 houses connected to it). This effectively doubles the capacity available at each house. 

 

Yet one more question: why upload speeds seems to have more constrains and limitations in DOCSIS3.0 and 3.1 compare to download speeds? Is that purely a restrictive measure to prevent users uploading content, or its rather driven by limitations of the signal transmission method? How upload signal is different from download signal in that sense?


 A lot of this is historical. DOCSIS uses cable as a transmission medium and cable was originaly for TV services. Everything is therefore based on TV channels. The old channel "2" is located at 59 MHz and each channel is separated by 6 MHz from that point onward. I won't go in the details of what happened to channel 1, that's another story...

 

Now when bi-directionnal services were introduced, engineers needed "clean" spectrum for these low power devices (modems) that would not be impacted by TV services, especially broadcast TV services and the lower part of the spectrum (below 42 MHz) was selected. All amplifiers on the network are based on this and amplify signal above 42MHz in the downstream direction while signal below 42MHz are amplified in the upstream direction.

 

That leaves room for about 4 channels for upstream traffic while we support more than 50 channels of downstream capacity in most areas. The lowest channel of all is very "dirty" and subject to a lot of interference so it is not used (different story with DOCSIS 3.1 in the upstream).

 

There are enchancements possible to this configuration called the mid-split where we could move the upstream/downstream limit at 85 MHz which would provide a lot more uplink capacity. This however requires a change to all amplifiers so again takes time and planning. We might see this in the coming year, area by area, as required based on usage/congestion levels.

 

*** This is a very simplified view of all the considerations in the planning and engineering of an HFC network ***

 

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

When will upload 3.1 be available ?

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial


@lethalsniper wrote:
When will upload 3.1 be available ?

I can't tell exactly. This is very "bleeding edge". There are efforts underway but issued delayed the project. Given that we normally don't make major changes on our networks starting in mid-November until the new year, I would say Q1 next year.

 

--Dave

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

JohnBeaudin
I'm a senior contributor

Q1 next year would be awesome. 

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

Nadernt
I plan to stick around

Ok, successfully on .33T3. I'll post updates if I have issues with it. Thanks.

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

arnym21
I plan to stick around

@RogersDave

 

Thanks for the highlight on the infrastructure constrains. Given this, introduction of 3.1 upload speeds will be probably very segmented network wise, and available only in very limited areas initially? Is CODA FW ready to support them?

 

Another issue I wanted to ask about is based on watching modem signal levels on all channels. For example, looking at my signals, why on most channels they are pretty consistent in +6 to 8 range, but on a few channels they are dropped to 0.1 to 1? While its all within the tolerance range, I still wonder why signal levels vary by channel, and such variations pattern is pretty persistent over time? In that regard, what "channel" term means, since in my understanding all my modem channels are coming through the same single wire across the network - or not? Are they subjected to different noise levels depending on frequency, and that causes signal drops on some channels?

 

Another question is based on this thread reports. Many trial participants would benefit, if you explain what records in the modem log signify "modem reboot" event, which is caused by a bug rather than a "feature" like config update? How frequent are config pushes or requests from the modem, if not caused by manual reboots? And each config reset is followed by modem reboot? Or wise versa, config requests are caused by any modem reboots, and that's why we see the 90000000 warning?

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial


@arnym21 wrote:

Thanks for the highlight on the infrastructure constrains. Given this, introduction of 3.1 upload speeds will be probably very segmented network wise, and available only in very limited areas initially? Is CODA FW ready to support them?

 Once everything is in place (software version on CMTS for example), enabling D3.1 uplink is fairly simple and I expect it will be quick across the network. It does not mean however that 100% of the modems will be able to lock on this channel on the low part of the spectrum, more susceptible to noise.

 

The current CODA firmware is ready for that yes.

Another issue I wanted to ask about is based on watching modem signal levels on all channels. For example, looking at my signals, why on most channels they are pretty consistent in +6 to 8 range, but on a few channels they are dropped to 0.1 to 1? While its all within the tolerance range, I still wonder why signal levels vary by channel, and such variations pattern is pretty persistent over time? In that regard, what "channel" term means, since in my understanding all my modem channels are coming through the same single wire across the network - or not? Are they subjected to different noise levels depending on frequency, and that causes signal drops on some channels?

 The ultimate goal would be for all modems to have a perfect flat line where all channels are operating right at 0 dBm but that is not possible. A coaxial cable has inherent loss which means that houses located closer to the node will have higher power than houses located further down the line. Therefore, in order to get everybody within the specified range, the transmitter can send signal at +10 so that along the way it goes down to -10 (again this is a simplified view).

 

To make things more complicated, the loss in a coaxial cable is not the same at all frequencies. At higher frequencies, the losses are higher which means it is normal for you signal level at higher frequencies to be lower.

 

Amplifiers along the line have settings which allow our maintenance teams to adjust the gain (how much it should amplify the signal) and the slope (factor to amplify higher frequencies more than lower frequencies).

 

It would technically be possible to adjust all these amplifiers gains and slope to make sure your house gets a perfect 0 dBm signal along the entire frequency band but then perhaps 10 houses down the street, the signal would be off for certain frequencies. Ultimately the goal is to give a signal within the limits for everybody but that yields to strange signal variations on the various channels.

 

Another question is based on this thread reports. Many trial participants would benefit, if you explain what records in the modem log signify "modem reboot" event, which is caused by a bug rather than a "feature" like config update? How frequent are config pushes or requests from the modem, if not caused by manual reboots? And each config reset is followed by modem reboot? Or wise versa, config requests are caused by any modem reboots, and that's why we see the 90000000 warning?


 

This is very hard to explain but configuration changes that would require a reboot are performed at night only (midnight-6AM typically) with some rare exceptions. These activities are also infrequent unless your area is being upgraded in which case, there could be a few reboots over the course of a few days. A reboot daily or a few times a day is not normal and is likely an issue with the firmware or an indication of very poor signal level (device will reboot if it looses connectivity with our network).

 

An example of an exception is if you call customer service to change your speed tier, our system will force a reboot so that your modem redownloads the configuration with the new speed.

 

One additional word of caution. The log message "MIMO event..." is typically displayed when the modem boots but not always. The only sure way to confirm if a modem has rebooted is to look at the uptime.

 

--Dave

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

I have received a new software version for CGN3 "AC" devices (CGN3ACR, CGN3AMR, CGN3AMF, CGN3ACSMR and CGNM3552). This version is 4.5.8.35T2 and fixes some management functions on the modem but nothing customer visible.

 

I will be loading this version on firmware trial participants modems however, the version displayed in the GUI will remain as 4.5.8.35 (the T2 is not displayed).

 

--Dave

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

Square
I'm a reliable contributor

@RogersDave wrote:

I have received a new software version for CGN3 "AC" devices (CGN3ACR, CGN3AMR, CGN3AMF, CGN3ACSMR and CGNM3552). This version is 4.5.8.35T2 and fixes some management functions on the modem but nothing customer visible.

 

I will be loading this version on firmware trial participants modems however, the version displayed in the GUI will remain as 4.5.8.35 (the T2 is not displayed).

 

--Dave


Were we not suppose to get a .36 update that I read about in a post from October?

 

Thank you.

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial


@Square wrote:

Were we not suppose to get a .36 update that I read about in a post from October?

 

Thank you.


 Yes you are right, that was the plan.

 

Rogers and Hitron are sometime working in parallel universes 🙂 Releases .34, .35 and .36 are not perfectly linear but instead different streams with multiple fixes being ported across all releases. It is not perfect but 35T2 gives you better features/stability than 36 right now which is why it is the version I'm deploying.

 

Once I receive 36T2 (I assume that will be the name), I'll push that version.

 

--Dave

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

Square
I'm a reliable contributor

Ok, thank you.  My original .35 was working Great, was just curious about that post. 🙂

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

tester2013
I plan to stick around
Software Version 2.0.10.33T3
LAN Up Time 001 days 10h:43m:26s

 

18 11/09/2017 13:05:26 69010100 notice SW Download INIT - Via NMS
19 11/09/2017 13:05:56 69011100 notice SW download Successful - Via NMS
20 11/09/2017 13:08:34 90000000 warning MIMO Event MIMO: Stored MIMO=1 post cfg file MIMO=-1;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.1;
 
Has anyone noticed that there are no error messages after the update (33T3?). I used to get a lot of them but so far it looks good!

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

Robleh
I plan to stick around

did you request 33t3?

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial


@Robleh wrote:

did you request 33t3?


I have been pushing firmware 2.0.10.33T3 to all CODA modems and firmware 4.5.8.35T2 to all CGN3 "AC" modems over the last couple of days. I should be done with the CODAs this morning and I expect to be done with the CGN3 "AC" at the beginning of next week.

--Dave

Re: FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

Triple_Helix
I plan to stick around

@RogersDave wrote:

@Robleh wrote:

did you request 33t3?


I have been pushing firmware 2.0.10.33T3 to all CODA modems and firmware 4.5.8.35T2 to all CGN3 "AC" modems over the last couple of days. I should be done with the CODAs this morning and I expect to be done with the CGN3 "AC" at the beginning of next week.

--Dave


Hi @RogersDave so far so good but will need a few more days to see if the Random reboots stop

 

I use Wired, 5G and 2.4G wireless through different devices. And I did a manual reboot after I found that I had the new firmware and Thanks!

 

Hardware Version	2A
Software Version	2.0.10.33T3

LAN Up Time 000 days 11h:11m:25s
WAN Up Time 000 days 11h:09m:32s

  

 

Daniel Smiley Wink