@Nadernt wrote:
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:
11 11/09/2017 18:41:07 69010900 error Disruption during SW download - Power Failure 12 11/09/2017 18:41:07 69010100 notice SW Download INIT - Via NMS 13 11/09/2017 18:42:08 69011100 notice SW 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....
@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.
All I was told is that they found a memory leak in some software module (unspecified) in the gateway function.
@arnym21 wrote:
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 ***
@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
@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
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
@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
@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
@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 
-
936243 views
-
669 Likes
-
-
