FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

[RogersMargaret]

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.

[VivienM]

Regarding the latency issues, I wonder to what extent backbone design is contributing to this.

In particular, one issue I have noticed (for years... really a decade) involves connectivity to Rogers' transit providers and peers in the U.S., in Chicago, Ashburn, and NYC. Frankly, as far as I can tell, it is more or less random (or based on some algorithm that is not tuned around latency) whether traffic goes out through NYC, Chicago, or Ashburn. If something goes out to a transit provider in Ashburn, that's probably 5-10ms more than going out in NYC.

Similarly, for our friends in New Brunswick, if your traffic goes to Toronto, then Chicago, then back out east, potentially, that's adding latency. Even for someone in Ottawa, I would expect a Ottawa -> Montreal -> NYC fiber path would cut a decent amount of latency compared to Ottawa -> Toronto -> Chicago or Ottawa -> Toronto -> Ashburn.

I've seen lots of situations, too, where traffic to, say, a Cogent customer in Toronto goes through Ashburn, then back up on Cogent's network. Rogers has a circuit to Cogent Toronto (see the traceroute further below), but presumably for ill-advised load balancing reasons, it's rarely always used for outbound traffic, despite the latency hit.

Look at this:

  1    <1 ms    <1 ms    <1 ms  192.168.22.1
  2    11 ms     9 ms    10 ms  99.245.80.1
  3    12 ms    11 ms    14 ms  67.231.221.37
  4    22 ms    18 ms    22 ms  69.63.249.229
  5    24 ms    33 ms    24 ms  69.63.249.26
  6    27 ms    27 ms    28 ms  be812.ccr41.iad02.atlas.cogentco.com [154.54.11.217]
  7    33 ms    35 ms    28 ms  be2171.ccr41.dca01.atlas.cogentco.com [154.54.31.105]
  8    29 ms    30 ms    28 ms  be2891.ccr21.cle04.atlas.cogentco.com [154.54.82.249]
  9    51 ms    31 ms    33 ms  be2993.ccr21.yyz02.atlas.cogentco.com [154.54.31.226]
 10    37 ms    27 ms    27 ms  te0-0-2-0.rcr13.b011027-3.yyz02.atlas.cogentco.com [66.28.4.166]
 11    30 ms    27 ms    30 ms  university-of-toronto.demarc.cogentco.com [38.117.74.226]
 12    27 ms    36 ms    28 ms  mcl-gpb.gw.utoronto.ca [128.100.96.7]
 13    33 ms    29 ms    37 ms  mail.utoronto.ca [142.150.210.21]

Routing that traffic out of somewhere other than Ashburn could cut 15ms on this.

Same thing, look at a traceroute to my VPS:

  2    13 ms    15 ms    11 ms  99.245.80.1
  3    12 ms   165 ms    28 ms  67.231.221.37
  4    14 ms    15 ms    26 ms  69.63.249.229
  5    33 ms    33 ms    26 ms  64.71.241.110
  6   145 ms    56 ms    49 ms  10gigabitethernet2-2.core1.ash1.he.net [206.126.236.37]
  7    38 ms    26 ms    26 ms  100ge12-1.core1.tor1.he.net [184.105.64.46]
  8    35 ms    33 ms    31 ms  fibernetics-corporation.10gigabitethernet3-1.core1.tor1.he.net [209.51.163.214]
  9     *        *        *     Request timed out.
 10    33 ms    33 ms    34 ms  host-74-205-214-59.static.295.ca [74.205.214.59]

[Last hop removed.]

Look at the reverse traceroute:

 3  vl3831.te-0-1-0-3.tor0151-asr9a.ne.fibernetics.ca (74.205.214.57)  5.238 ms  5.510 ms  5.659 ms
 4  * * *
 5  te0-0-0-1.rcr12.b011027-3.yyz02.atlas.cogentco.com (38.122.70.209)  5.074 ms  5.217 ms  5.240 ms
 6  te0-7-0-30.ccr22.yyz02.atlas.cogentco.com (154.54.43.89)  5.086 ms  5.193 ms  5.181 ms
 7  24.153.3.113 (24.153.3.113)  4.634 ms  4.648 ms  4.636 ms
 8  van58-9-230-5.dynamic.rogerstelecom.net (209.148.230.5)  24.267 ms  22.572 ms  24.287 ms
 9  69.63.249.230 (69.63.249.230)  24.278 ms 69.63.252.249 (69.63.252.249)  8.419 ms 69.63.249.230 (69.63.249.230)  24.278 ms

[Note: last hop showing my IP removed.]

See the 20ms jump between hop 7 and 8? That's because the Rogers network is sending the response packets through Ashburn. That has nothing to do with the cable modems, gateways versus modems, Hitron vs Cisco, CMTS, etc.

Frankly, I think that this network's routing policy was designed to balance (large) traffic volumes across interfaces and circuits in different cities, not to optimize latency on traffic to north-eastern North America.

@RogersDave, any thoughts? (oh, and while I have your attention: can you please put some PTR records on your router interfaces' IPs?)

[Ancileah85]

I got the upgrade 24 hours ago and since then I've had to reset my box and the chromecast multiple times. It's not working properly.

[RogersDave]

A quick note regarding the observed latency in that scenario. When a modem is running in bridge mode, the modem includes a packet bridge function and a host (webserver / SNMP server) used for some management functions. The interface responding to pings at 192.168.100.1 is the management host and is not in the normal traffic path. It’s a process that runs on the cable modem, entirely in software and with a fairly low priority. I am not surprised to see high variation in ping times towards that address. I am also not surprised to see large differences between modem vendors as this is entirely implementation specific.

That being said, as I mentioned previously we are actively working on reducing latency and more importantly jitter. This is a medium term project as it involves reviewing the performance of multiple components along the path including the modems, CMTSs and traffic peering. It is high on my project list as I understand it is of great importance to a lot of you. The initial target is to reduce jitter towards the gateway IP address on the CMTS (.1 in the WAN subnet) and I've been working on towards this goal for the last couple of weeks.

@VivienM, I will review the traceroute you provided but generally when it comes to transit, we have little control. From a cost perspective, it is better for us to send traffic to the closest point (transport cost) so if traffic is taking a longer path, it might be based on what routes are being advertised to us at each peering point.

Regarding the PTR records, I feel the same but this is outside my control. I can ask but I don’t have high hopes.

[lethalsniper]

So is there a date you think this latency/ jitter be fixed how much longer would you say

[rddavistoronto2]

Got the upgrade push yesterday. All good. Did a factory reset to get ipv6 happening. Success. Had a few hiccups reconencting IOT devices to the wifi network, but that resolved with abit of fiddling. Most importantly, Googlecast is back in action.

No negatives to report on the firmware upgrade after a day.

[dto7]

This firmware update fixed my Chromecast connectivity issues. Thank you.

[user12343543]

---

@dto7 wrote:

This firmware update fixed my Chromecast connectivity issues. Thank you.

---

Who are you thanking? They broke it in the first place lol

[dto7]

You're right. I've been frustratingly waiting for months for a fix, it's like I have stockholm syndrome.

[soundwave80]

Just received the update, so far Web pages seem to load faster but according to speedtest I'm still getting only 325-350 Mbps down and 35 upload on the gigabite package.

[soundwave80]

I can no longer log into the modem, the default username and password has changed .

[Windwalker]

Hi, I'm on the 500U package with a gigabit modem.

My chromecast is working well.

I noticed something unusual.  I have one computer with an onboard Intel NIC that connects typically at a steady 585mbps down and 21mbps up.  Latency around 8ms.  Connection graph is usually smooth. Computer is five years old.

On three other computers with different NIC, two more Intels and one D-Link, the speeds vary and I get a very spiky connection graph.  I made sure all were running the latest drivers.  Note that these computers are six to seven years old.

All computers connected via ethernet and I have switched cables and ports with no change. Cables are CAT5e and CAT6.

Is there an issue with older computers/drivers communicating with the gigabit modem?

Appreciate any feedback.

[Jurk]

Chromecast is working well now.
Thank you!

[JohnBeaudin]

Can we expect a fix for the high latency in online game.. before the end of the month ( August)? 

[robinheider1]

Curently connection is stable and much quicker especially casting off my Plex server. Issues with chromecast seem to be completely resolved for the moment. Thank you

[Triple_Helix]

---

@soundwave80 wrote:
I can no longer log into the modem, the default username and password has changed .

This is the default and still works fine on my CGN3ACSMR. Maybe try another factory reset by pushing the reset button in the back with a very small thing, I use a small nail.

cusadmin

password

Not sure about the CGN3552 Modem?

HTH,

Daniel 

[tylereidt]

Chromecast now works perfectly...again. Thanks for the update.

[soundwave80]

The username stayed the same but the password automatically changed to my WiFi password.

[abel06]

chromecast working 100%

[Triple_Helix]

---

@soundwave80 wrote:
The username stayed the same but the password automatically changed to my WiFi password.

---

Yes it will do that after a factory reset and you enter the Rogers easy setup but make sure you go back in a change the master password to something else via 192.168.0.1 

Thanks,

Daniel 

[soundwave80]

When I plug my laptop into the modem I only get around 150 mbps when testing on WiFi I hit around 350 mbps on the gigabit plan. The signal and noise on my line is fine , speeds were the same before upgrading the firmware . Any help would be appreciated.

[Windwalker]

---

@Windwalker wrote:

Hi, I'm on the 500U package with a gigabit modem.

My chromecast is working well.

I noticed something unusual.  I have one computer with an onboard Intel NIC that connects typically at a steady 585mbps down and 21mbps up.  Latency around 8ms.  Connection graph is usually smooth. Computer is five years old.

On three other computers with different NIC, two more Intels and one D-Link, the speeds vary and I get a very spiky connection graph.  I made sure all were running the latest drivers.  Note that these computers are six to seven years old.

All computers connected via ethernet and I have switched cables and ports with no change. Cables are CAT5e and CAT6.

Is there an issue with older computers/drivers communicating with the gigabit modem?

Appreciate any feedback.

---

So, is anyone else having issues with different ethernet cards?

Having a real issue with a "Realtek PCIe GBE Family Controller". Tried different drivers.  The newest one from Realtek slowed it down to 100 mbps!  Bought a TP link card and same issue as it uses the Realtek chip and drivers.

The only ethernet card not giving me grief is an Intel 82579LM.

Also noticed that I have a different IP address now and I am on a different CMTS.  Not related to the etherenet issue, but with other cards, speeds are a bit more erratic. Ping varies more as well.