I jumped on the CODA train immediately too, but I am anxiously awaiting the new gateway as well. Its kind of fun testing this stuff out.
Any update on this?
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).
I'm having packet loss while playing league of legends at night. I'm on the CODA-4582 and .27 firmware on a wired connection.
Just finished reading the last 4 pages of this thread (sorry, I was pulled in other situations and couldn’t spend as much time as I wanted on the forums).
I’ll try to address the concerns raised (or at least explain why).
Automatic downgrade on factory reset
I understand that this is inconvenient for beta tester and wish I could move out of there. It will happen but we need more time. A bit of history, at Rogers we never really used the automatic update on boot feature. We always manually controlled firmware versions on modem which allowed me for example to push a beta firmware and it would stick.
On the CODA, the initial firmware that we received on brand new modems from the factory was far from perfect. To provide an acceptable customer experience, we had to enable automatic update on boot because otherwise a customer would stay on a very old firmware for up to 72 hours before our systems would pick it up. This also helped customers with specific issues on the more recent firmwares as a reboot would get them to a newer firmware addressing their problem immediately. It was also necessary so that IPv6 could be enabled on that modem (IPv6 is a global setting per modem type but old firmware didn’t support it well).
This is great for all CODA customers but affects the trial users (on factory reset, the modem picks up the configuration that says for a new modem, update to version X immediately). Unfortunately, we have 0.2% of the CODA-4582 users who are beta firmware participants so that decision had to be made for the greater population.
We are currently working on replacing our firmware management system (discussing with potential vendors) and once we have the new system in place, we will be able to manage this better.
Packet loss on / around CMTS
I will need to investigate further on this one. However, firmware 220.127.116.11 is an Intel SDK change so it might have to go back to Intel. I’ve seen some private messages on the topic and will look into them when I have a little free time. It is however a cosmetic issue (the end destination doesn’t report packet loss) so although annoying, it is lower priority for me at the moment. I will however focus on the IPv6 packet loss issue more carefully to understand if there is any impact.
Packet Loss on UDP and impact of VPN
Although I haven’t looked in detail at the neighborhood where this has been reported recently, it is usually tied with very high usage in the uplink direction. We have seen a dramatic increase of usage in the uplink in multiple areas and we need to increase the capacity. This can be in some cases a quick process (cabling reconfiguration) or a very lengthy process (construction permit, digging, new equipment installation).
Nonetheless, there is a lot of effort put into this right now where we are increase the capacity in multiple nodes of our network on a daily basis. We are also building a better mathematical model to predict areas where customers are impacted or are likely to be impacted based on live data from the network. This will help us schedule capacity augmentations sooner.
The problem with UDP is that there is no protection at all for these packets. In case of congestions, if the packets are dropped they won’t be retransmitted. When using a VPN from your home network to an endpoint on the Internet, all UDP traffic gets encapsulated in TCP traffic (with retransmission capabilities). This means that if the VPN packet will get retransmitted (along with the encapsulated UDP packet) whereas the UDP packet would simply be dropped.
This is still work in progress and scope is not fully locked. I am hoping that the following will be included (some of these may come in additional builds T2, T3, etc.)
We will have the first builds sometime in June (expected)
DOCSIS 3.1 Upstream
Not yet and I don’t have a date. I’m a little disconnected from this project unfortunately.
I can’t talk about it but there is a lot of work on it. I’m busy testing a lot of the issues reported on the CODA since the launch to make sure we don’t have similar problems.
Waiting for the next firmware to be available, I have a few more things to test with volunteers for those of you interested. The firmware 18.104.22.168 supports 2 features on WiFi that are currently not enabled by default, DFS and band steering. I need some people to test them so if you are interested, send me a PM and I’ll enable both features on your modem.
DFS will enable the UNII-2 and UNII-2 Extended WiFi bands (channels 40 to 140). This can help in congested WiFi areas.
Band steering allows to set the same SSID on both the 2.4 GHz and the 5 GHz band so that devices can dynamically pick the best channel available based on the radio conditions. Once I enable band steering, you won’t be able to have different SSID for both radio bands.
You can always bail-out of these two settings with a factory reset.
Just to add some info for Dynamic Frequency Selection (DFS), for those who might be interested in trying it out:
The DFS frequency space is protected for use by Airport Weather Radar, and possibly by extension, airborne radar as well. Wifi modems and routers are allowed to operate within that frequency band with the following Industry Canada regulation. These are the main portions of the regulations that will have the most impact on DFS users:
6.3.2 Operational requirements
Devices shall comply with the following requirements, however, the requirement for in-service monitoring does not apply to slave devices without radar detection.
a. In-service monitoring: an LE-LAN device shall be able to monitor the operating channel to check that a co-channel radar has not moved or started operation within range of the LE-LAN device. During in-service monitoring, the LE-LAN radar detection function continuously searches for radar signals between normal LE-LAN transmissions.
b. Channel availability check time: the device shall check whether there is a radar system already operating on the channel before it initiates a transmission on a channel and when it moves to a channel. The device may start using the channel if no radar signal with a power level greater than the interference threshold value specified in Section 6.3.1 above is detected within 60 seconds. This requirement only applies in the master operational mode.
c. Channel move time: after a radar signal is detected, the device shall cease all transmissions on the operating channel within 10 seconds.
d. Channel closing transmission time: is comprised of 200 ms starting at the beginning of the channel move time plus any additional intermittent control signals required to facilitate a channel move (an aggregate of 60 ms) over the remaining 10‑second period of the channel move time.
e. Non-occupancy period: a channel that has been flagged as containing a radar signal, either by a channel availability check or in-service monitoring, is subject to a 30-minute non-occupancy period where the channel cannot be used by the LE-LAN device. The non-occupancy period starts from the time that the radar signal is detected.
The following applies across the entire DFS channel range:
22.214.171.124 Power limits
The maximum conducted output power shall not exceed 250 mW or 11 + 10 log10B, dBm, whichever is less. The power spectral density shall not exceed 11 dBm in any 1.0 MHz band.
The maximum e.i.r.p. shall not exceed 1.0 W or 17 + 10 log10B, dBm, whichever is less. B is the 99% emission bandwidth in megahertz. Note that devices with a maximum e.i.r.p. greater than 500 mW shall implement TPC in order to have the capability to operate at least 6 dB below the maximum permitted e.i.r.p. of 1 W.
In a nutshell, any modem or router operating within DFS frequencies shall
a. monitor for the presence of a radar signature on the selected wifi channel
b. if a DFS wifi channel is selected for use, the modem/router has to listen for a radar signature for 60 seconds prior to commencing operation on that channel, if in fact that channel turns out to be clear of any radar systems.
c. if a radar is detected, cease operations on that channel within 10 seconds.
d. close the channel, conducting channel change operations and broadcast instructions to remote devices within a 200ms window
e. lock out that affected channel for 30 minutes before it can be considered for any use as determined by step b.
f. limit the output power to 250 mW or operate at least 6 dB below the maximum permitted e.i.r.p. of 1 W
Note that the power limits of the 5 Ghz lower channels (36 to 48) is either 50 or 200 mW depending on the date of approval of the device by Industry Canada and the limit of the upper channel range (149 to 161) is 1 watt.
If you happen to live near an airport, or near a weather radar, you will probably find that the DFS channels are of no use as they will shut down unexpectedly and shift or try to shift to another DFS channel due to the weather radar detection.
With DFS channels enabled, if the modem or router attempts to use a DFS channel and determines that its occupied by a radar system, it might then pick yet another DFS channel, wait another 60 seconds to determine if its occupied by a radar, and if so, move to yet another DFS channel.
If the logic in the channel selection is to use DFS channels first, then its possible that the modem/router might cycle thru all of the DFS channels before selecting a non DFS channel. So, for perhaps 14 minutes, there might not be any wifi network available from the modem or router as it cycles thru all of the DFS channels before arriving on a workable non-DFS channel. I suspect that the first time that someone goes through this, it will be rather infuriating to say the least.
Due to the reduced output power in the DFS channels (52 to 144), the max range or operating distance from the modem or router will be better than the lower channels but not as good as operating on the higher channels.
To see this visually, have a look at the following page:
For those who are able to make use of DFS channels, you might be able to finally run your wifi network without fighting with the neighbor for clear channels, or, perhaps the neighbor will move to a DFS channel leaving the upper channel clear for your use. That would be the better solution, a clear upper channel with its higher power output level. Perhaps a bribe for the neighbor with a hint to use DFS channels might be in order someday 🙂