*** This post was last edited May 2, 2017 ***
Good morning Community,
As I mentioned in a post two days ago, we have received the next firmware 2.0.10.20 from Hitron. We are currently running initial testing on this version and will push it out to participants in the firmware trial program as soon as it passes initial testing.
However, while running these tests, we discovered abnormal behavior with ICMP and are awaiting feedback from Hitron today to asses how this will be addressed. As soon as I this is confirmed, I’ll update the change log with the correct version information and start pushing it out.
In parallel, we are still working on the following high priority items. In some cases below, I requested affected customers to reach out to me via private message. If you do so, please include your modem MAC address in the subject line (even if we exchange messages daily) as there are a lot of you reaching out to me daily 🙂
UDP Packet Loss
The investigation for what has been reported as UDP packet loss is still ongoing. We have deployed a probe at one fellow forum member on both a CODA-4582 and a CGNM-3552 to collect additional data. We are actively working with Hitron and Intel on the results observed.
Based on what we know so far, in most instances UDP packet loss is coupled with higher uplink usage in the area. Although the impact is noticeable in specific logs (League of Legends), the root cause for the perceivable impact (while playing) is likely related to bufferbloat (see next issue).
Bufferbloat
When comparing the performance of a CODA-4582 to a CGNM-3552 in the same network conditions, the CODA-4582 consistently reports higher bufferbloat when tested on DSLReports.
Update April 12: The solution for this problem will come in two folds. It will require a change in software which will possibly be included in 2.0.10.27 but more likely in 2.0.10.28 and a change in network configuration.
The network configuration change is not compatible with the current firmware so this change will only come after a vast majority of the modems are running the new code. We are however looking at a way to make the change only for specific modems to support testing in the community.
Update April 22: This problem seems resolved in firmware 2.0.10.27
5 GHz WiFi Low range for channels 36 to 48
Lower WiFi channels on the modem have a much smaller range. This is due in part to the limit imposed by Industry Canada to maximum transmit power.
Furthermore, the current automatic channel selection (auto mode) tends to select the lower channels when in similar load conditions.
Workaround: manually select higher channels (149-153-157-161)
Update April 22: The channel selection algorithm has been improved in firmware 2.0.10.27
Loss of OFDM Channel Lock
Under some RF conditions, the modem fails to lock properly on the OFDM channel. This typically result in variable performance.
Update April 12: This problem is resolved in 2.0.10.26T2
List of connected device does not get fully populated
This is a known issue that has been tracked since firmware 2.0.10.13. We are making improvements at every firmware but it is not a perfect system.
The situation is worst after a reboot or firmware upgrade as the list gets reset and must be repopulated as devices renew their DHCP lease.
NAT Loopback not working for wired clients
When setting up port forwarding to an internal server, it is possible for a client on WiFi to reach the server using the external IP/port. If the client is on a wired interface, it doesn't work.
Update April 12: This problem is resolved in 2.0.10.26T2 (not confirmed)
LAN Counters not working
Some customers reported that LAN counters (especially in bridge mode) are reporting inaccurate values.
This problem has been reported to Hitron for investigation.
Unexpected modem reboot
Some customers reported their modem reboots unexpectedly. We have also seen this behavior in our lab.
Update April 12: This problem is resolved in 2.0.10.26T2
Missing SC-QAM Channels
After a reboot, some modems are missing SC-QAM channels. A fix has been implemented in 2.0.10.26T2 to address this behavior but it has not corrected all scenarios.
Investigation continues with Hitron.
WiFi Survey
The WiFi Survey functionality in firmware 2.0.10.26T2 (and possibly before) reports incorrect SSID names.
Guest Network
When connecting to the Guest Network, an error message is displayed "only allow DHCP client to use this wireless". This has been reported in firmware 2.0.10.26T2.
Update April 22: This issue has been resolved in firmware 2.0.10.27
Update May 2: It seems this issue is not fully resolved and still experienced by some users
Future Planned Improvements
The following are items that we are working on in parallel of the above.
- Improvement in WiFi speeds
- Improvement in latency / bufferbloat
Dave
*Edited Labels*
@stoneball the Broadcast Maintenance and No Ranging Response alerts are listed as critical as the modem has not received a maintance period from the Cable Modem Termination System (CMTS) which includes Sync timing, but, in reality, the modem logs the alert and carries on, requesting another Maintenance period a short time later. So, nothing to be really concerned with unless they accompany other alerts which indicate a more serious problem such as an MDD loss or timeout or a SYNC loss. Here's a link for the MIMO alert:
https://www.speedguide.net/faq/what-does-the-mimo-event-mimo-log-message-mean-393
The MDD (Mac Domain Descriptor) contains various pieces of data for the modem to use to reestablish synchronization with the CMTS should it become necessary. I've seen MDD loss alerts where nothing has happened, and MDD loss alerts where the modem has rebooted. Usually there is more than one alert in that case.
Just to check the signal levels on the modem, can you log into the modem, navigate to the STATUS .... DOCSIS WAN tab and copy the lower table, which contain the signal levels and signal to noise ratios. Paste that into a post. The copy and paste process will paste in the text contents of the table.
It looks like you're using wifi for your device. Can you have a look at the following post and then have a look at your wifi environment to see who else you're competing with. Please change the wifi settings in the modem if necessary and reboot the modem when you're complete with the changes.
http://communityforums.rogers.com/t5/Internet/slow-wifi/m-p/399949#M47222
Try the following. Load Acrylic on a laptop, as indicated in the post, and then stand next to the thermostat to see what the modem signal level and signal to noise ratios look like. Ideally the signal level would be around -35 dBmW and ideally the next modem/router signal level on the same channel and adjacent channel would be around -75 dBmW. As you reduce the separation between your network signal level and the same and near channel signal level, you will see increasing difficulties in running your network. So, just about the only thing to do at this point is to ensure that the wifi settings are optimized in the modem/router, the best operating channel is selected and failing that, possibly moving the modem/router.
Please give this a go and let us know what you've found as you look at this issue.
@stoneball your downstream DOCSIS 3.0 signal levels aren't too bad. They show the usual high frequency roll off but, that's not a concern at this point. The signal to noise ratios are ok, with a slight roll off at the top end. The upstream levels are slightly low. Typically with this modem we see somewhere in the 30 to 32 dBmV range. The Cable Modem Termination System (CMTS) which the modem connects to, actually controls the upstream power level, so, if the CMTS wanted a higher output level from the modem, it would simply command the modem to do so. Having said that, it would be worth a call to tech support to ask the CSR what the signal levels and signal to noise ratios are for the upstream signals that arrive at the CMTS. The CMTS does not feed that back to the modem, so a phone call is necessary to determine those numbers. If I remember this correctly, I believe the optimum upstream levels are 0 dBmV with a minimum 27 dB signal to noise ratio. You can ask the CSR what the actual numbers are and whether or not their in spec.
The OFDM (DOCSIS 3.1) signal level may or may not be correct. That data in the OFDM block isn't displayed properly. If you call tech support, ask the CSR to run a signal check on the modem and ask if the modem's receive power level for the OFDM channel is within spec.
There's nothing that jumps out as being a problem, however, as I indicated the upstream DOCSIS 3.0 levels are slightly low. That may or may not be an issue. If the CMTS is happy, ok, it is what it is.
Fwiw your modem is using DOCSIS 3.1 on the downstream side and DOCSIS 3.0 on the upstream side, so, the upper DOCSIS 3.0 data in the table isn't much value. Interesting to look at, but, the only value of real interest is port ID #8. The OFDM channel is probably running just below or just above that channel and both Port ID #8 and the ODFM channel power levels are high. That should be ok at this point.
So, you could call tech support to:
1. Run a signal check
2. Confirm what the modem's OFDM (DOCSIS 3.1) receive power level actually is, and whether or not its in spec
3. Confirm what the upstream signal levels and signal to noise ratios are when they arrive at the CMTS and whether or not their in spec
Are you running any other Rogers services and if so, are you seeing any issues with those services?
Next up: looking at your wifi environment to see what networks your neighbours are running and determine if any of those networks are causing problems for your network.
1. Are your speedtest results observed via ethernet or wifi? You should use the www.speedtest.net Toronto Rogers server as the first choice, Montreal Rogers server as second choice. The Toronto Rogers server is a 10 Gb/s server, not sure about the Montreal server, but, from Ottawa, they are basically equal except for a lower latency from Montreal. The Toronto server definitely has the horsepower to run gigabit tests.
2. There isn't anything unusual about your signal levels, at least nothing stands out as being a real issue. The upstream DOCSIS 3.0 levels are a little higher than normal for a modem that is running DOCSIS 3.1 on the downstream side. Normally we've been seeing somewhere in the 30 to 32 dBmV range, but, yours aren't too far from that and are definitely in spec. What you could do is call tech support and ask the CSR to run a signal check to determine if the DOCSIS 3.1 OFDM levels are within spec or not.
3. Have you ever inquired with tech support about the modem provisioning, as in what speeds it's set for, for both downstream and upstream? That's another question to ask, just in case its been set to the wrong values.
4. There are a subset of customers who are seeing slower than expected downstream rates with this modem. That is most likely due to some issue with the DOCSIS 3.1 processing by the modem. I've never received a satisfactory answer as to why that is, so this is a definite possibility. You might be one of those customers.
5. Are you running the speedtest on a desktop or laptop?
- last edited on by
RogersZia
Same issue here....Previously had speeds around 1 gbps and occasionally higher. Now cannot reach even 400 mbps. Was rolled-back to 34T6 about 5 days ago....which previously was good, but now no different. Did reboot...but still no improvement in speed. Something is definitely awry here..... Rogers took a while to improve the 4582 and finally deliver 1gb speeds for almost a year .....but now, we're back to the same poor results we used to get in the early days of this program. Common Rogers get back in the game and get this fixed ASAP....you cannot expect us to pay for 1Gb service and deliver naught.
The Celeron 2961Y is probably as low as you want to go for Gigabit service. That processor runs at 1.1 Ghz. Depending on what functions you have enabled for CentOS 7 to run as a router, something in the order of a 2 Ghz or above processor would probably be preferable. Just depends on the router functions. The best that you'll see on a speedtest is somewhere around 950 to 960 Mb/s on the download side and 33 Mb/s on the upload side. Too bad Rogers cut the upload rates down from 50 Mb/s. They're going to have to do much better to close the gap with Bell's symmetrical download/upload rates over fibre.
Yup, over 5K posts. Where does the time go when you're having fun ?
Your router is rather interesting to say the least. First time that I've seen that come up in the forum.
Fwiw, don't know if you've seen this, here's a link to Intel's processor search page configured for AES-NI processors. Looks like the newer Celeron processors are AES-NI capable, and can run at speeds including 2.9 Ghz depending on which processor you're looking at.
https://ark.intel.com/Search/FeatureFilter?productType=processors&AESTech=true
Also fwiw, looks like the next version of pfSense will require an AES-NI capable processor. I'm thinking about going that route one of these days.
-
475782 views
-
295 Likes
-
-
