*** 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*
@MegnaGaming you have occasional packet loss on the first hop to the router, which is a little unusual. You shouldn't see any packet loss to the router. I would suggest running an extended test to the router only. Use the routers address as the target and set the ping interval to 1 second and let that run for a day. What I would like to see is an extended run to the router without any packet loss. If the packet loss is still evident, then its time to go hunting for the cause. After that, target the CMTS, which is the IP address after the modem. From your plot, there is occasional packet loss, which appears to be minimal, is still present. Personal opinion, there is a packet loss issue with the CODA-4582. Its singular occurrences, but its still present throughout the day from what I've seen. Running an extended all day test to the CMTS will also illustrate the variance in the average ping times between the quiet early morning hours and the busier times in the evening. When you move up in time scale, up beyond 30 min with the pingplotter display, pingplotter switches to an averaged display instead of the min-max display in the 60 sec, 5 and 10 min displays. Even with the averaged display, you will probably see a large difference between the quiet and busy times of the day.
@Kdurantulla if you have gigabit service, then it should not be maxed out unless there are other issues on the go. With a good router in place, you could see much higher wifi data rates, but, that depends on both the router and device. If you look at the following chart, you can see the various connection rates that are possible with, 1 or more antenna. The number on the right side the Modulation and Coding index (QAM) is the number that you multiply the connection rate with in order to calculate the max theoretical throughput. You can see the connection rates that are possible by using a 20, 40, 80 and 160 Mhz wide channel, divided into 400 or 800 nano-second spacing between broadcasts. So, the whole point of this is to say, yes, you will see higher performance, but, the router and end device have to agree on a common connection rate. That's the difficult part in terms of buying equipment as manufacturers don't usually release that information, as in "This device supports dual antenna, VHT index #9, 160 Mhz channels, using 400 ns guard channels." Going thru the chart, that gives you a connection rate of 1733.3 Mb/s which would in theory give you a max throughput of 5/6 x 1733.3Mb/s = 1,444.4 Mb/s. In theory, faster than the gigabit service. If the device supports a connection rate which is much less than that, it won't matter if you have the fastest router in the world, the connection rate and therefore the throughput rate will be limited by the end device. You could be standing next to the router, or in the next room, running a speedtest, and it won't matter where you are because the device will be limiting the throughput.
So, a little homework is required in selecting a router for wifi data rates, and more homework is required to determine why your devices won't keep up with the router. Its all a matter of the specifications, or should I say, trying to find those specifications.
@RyzenFX what happened to your post last night? It was up for a minute or two and then it disappeared.
In theory, the 4582 should be better for UDP, however, there is a real problem when it comes to testing that theory. With TCP/IP and ICMP its possible to ping a target to get a response that can be measured throughout the day. UDP requires a co-operative target that returns a UDP response, as in a DNS server or co-operating server configured for UDP testing or possibly a data transfer or backup program that can be configured to run UDP transfers at various rates. I haven't found a Windows application that will continuously ping a DNS server for an address, where that response time can be measured and recorded for further analysis. That would be very handy for situations such as this. Same as pingplotter results, but, pure UDP in both directions.
Its possible to test for UDP throughput and from that testing I know that there are issues with UDP transfer rates for the 4582. What the 4582 should not be suffering from is the latency spikes that are evident on all of the other Hitron modems and which are easily seen for TCP/IP and ICMP tests. If you run GRC's DNS Benchmark, which is a UDP test application what you will see is that the 3552 suffers 10 to 12 % losses for cached results where the 4582 doesn't have any losses. So, one can surmise that the transfer rates or payload size that are seen in that test with the 4582 don't result in UDP losses. So, the question that requires asking is, what is the payload size for LOL and is it all UDP? Maybe with that info we can start to make a little more sense out of this. Does LOL indicate if the ping times and losses are UDP or TCP/IP. How does anyone know, without monitoring the data exchange with Wireshark, that the LOL data exchange is actually UDP?
-
496460 views
-
295 Likes
-
-
