07-28-2021 05:55 PM - last edited on 07-28-2021 06:20 PM by RogersMoin
Perhaps before I dive in to troubleshooting, it may be helpful to understand what is an "acceptable" amount of packet loss. Doing some ping tests from command line for a PC connected directly to the modem, I tend to get 1%-2% packet loss when pinging google.com / facebook.com / Rogers DNS 64.71.255.204
That said, I find it most noticeable in a few scenarios 1) streaming live video such as twitch, live youtube, or on sites like cbc that are broadcasting online. 2) gaming online in rocket league or warzone 3) uploading live such as through video chats / meetings
Here is the CODA-4582U DOCSIS Status
Rogers modem was replaced today, and the tech changed out the cable ends in my unit. He apparently did this for my unit in the cable room as well (live in a townhouse)
I know 1% - 2% doesn't sound like a lot (and maybe I should just deal with it) but I do have periods where I run a 50 count ping test against google.com for example and get 8%-12%
Wondering if I should continue to push forward with trying to resolve or just give up and handle it.
*Added Labels*
07-28-2021 07:27 PM
When we had the CODA modem we had the same issue, however since switching to the Ignite XB7 the problem seems to have gone away. Used to get packet loss all the time(1-2% on and off sometimes more), still do but it's a lot more rare and usually only happens after bad weather/rain, However your signal looks good (ours gets really bad after a ton of rain or a storm), better than ours so I bet it is just the . modem, see if you can get one of the Ignite XB modem's they are way better
07-28-2021 09:28 PM
You signal levels and SNR look really good. A few things:
1. I believe Rogers considers anything less than 5% packet loss acceptable but don't quote me on that. I'm going off memory based on what I remember being told by tech support a while back. The problem with that is, it's too high of a threshold in my opinion because even 1% packet loss (heck, even just 1 dropped packet out of 1000) is enough to disrupt real-time data apps such as Skype, MS Teams, Zoom, etc. And I guess that's what you're noticing...anything that buffers, such as Netflix, will be fine, but the stuff that runs in real-time (like Teams) suffers. I know because I've been there 🙂
2. One thing to try testing is if you get packet loss on both IPv4 and IPv6 or just one and not the other. For me, I used to get (and probably still do, but haven't tested recently) packet loss ONLY on IPv6.
3. Are you running your gateway in gateway mode (i.e. as the modem, router, and WiFi access point)? Or do you have your modem bridged with your own 3rd party router? If you're using your own router, you can try disabling IPv6 on the router (i.e. so that all of your traffic is IPv4) to see if that resolves your issue.
Tagging @Datalink as I suspect he'll have some additional thoughts to add.
07-28-2021 11:43 PM - edited 07-28-2021 11:43 PM
@pk17 your downstream QAM channels (1 to 32) and upstream QAM channels (1 to 4) look ok, so there's nothing obvious to suggest any issue that would cause packet loss.
The downstream Orthogonal Frequency Division Multiplex (OFDM) channel is a mystery as the modem doesn't present enough data to determine the status of that channel. Looking at the QAM channels that cover the OFDM frequency range, one would think that the OFDM channel should be ok, but, only the moderators and Tech Support Level II could actually confirm that.
You also have an Orthogonal Frequency Division Multiple Access (OFDMA) upstream channel running. That is slowly being enabled across the Rogers network. A previous attempt at this ground to a halt when customers with CODA-4582 modems experienced upstream packet loss or latency. Rogers halted the implementation of OFDMA and then at a later point recommenced that implementation without any explanation of what the problem was or is. So, the primary question that comes to mind is whether or not this is a recent development, which might coincide with an OFDMA channel going active at your Cable Modem Termination System (CMTS). The CMTS controls all of the modems connected to it and provides data services to those modems. Rogers has been rolling out OFDMA upstream channels across the network, perhaps it was enabled at your CMTS.
So, I'll tag @RogersIan at this point to provide an explanation of the issue with the CODA-4582 modems and the OFDMA upstream channel. Ian is probably the only person on the forum who can provide an answer to this problem. Please give him two or three days to get back to you, either by private message or thru this thread. If that doesn't happen, please let me know.
In terms of looking for packet loss, do the following, which is to ping the CMTS.
1. Run a trace to anywhere, google.com for example.
2. Take note of the second hop IP address in the trace. With the modem in Gateway mode or in Bridge mode with a router behind it, the second IP address is the CMTS.
3. Ping the CMTS, using that 2nd hop address. You should get a response.
If the modem is running in Dual (IPV4 plus IPV6) mode, then I'd expect the ping returns to show IPV6 addresses. If not, you can force the issue by using the following trace and ping command:
tracert -6 www.google.com
ping -6 -t 2607.xxxxxxxxxxxxxxxxxxxxxxxx where this is the 2nd hop IP address as copied from the trace.
I usually advise to ping the CMTS for at least an hour. In your case I'd say let it run for 24 hours to see what the loss numbers are during that entire period.
When your finished with the ping test, copy the bottom ping test results and paste them into a post. Select, or highlight the test results, use Ctrl C to copy the results to the clipboard, and in a new post, use Ctrl V or right click .... Paste, to paste the ping results into a post.
The other issue that comes to mind is a potential IPV6 issue at the CMTS. Log into your modem and navigate to BASIC .... GATEWAY FUNCTION. If the Router Mode indicates "Dual" your modem and network will be using both IPV4 and IPV6 with IPV6 being the primary address choice, with IPV4 being the backup choice. For test purposes, you can switch to IPV4 only. If you do, the modem will take two to three minutes to switch over to IPV4 only mode. I usually run a modem reboot immediately following the change over to IPV4 .... ADMIN .... DEVICE RESET .... Reboot. I would also reboot all devices connected to the networks to switch them over to IPV4 only mode of operation.
If the modem is already in IPV4 mode, consider running a 24 hour test ping test to the CMTS.
If the modem is in Dual mode and your ping tests are running in IPV6, then continue with a 24 hour IPV6 ping test to the CMTS.
When that is complete, switch the modem to IPV4 only mode, reboot the router and PC/laptop and run another 24 hour ping test to the CMTS using an IPV4 address.
Those results will tell you if there is an IPV6 issue at your CMTS. If the results are basically the same for IPV4 and IPV6, then I'd say that something else is afoot.
There is always the possibility of packet loss with good signal stats. Any packet loss would probably be due to external cable or connector degradation. That external cable doesn't last forever and every once in a while has to be replaced. As the cable ages, you can get degraded signal levels which really indicate an problem with the cable and/or connectors, or, you can simply see packet loss due to water ingress into the cable or mechanical weathering if the cable is an overhead cable. That would be my typical approach to this, but, the presence of the OFDMA upstream channel completely clouds the issue. Ergo, we need @RogersIan to wade into this to determine if this is yet another OFDMA problem with the 4582 modem. If your seeing packet loss occurring, a reboot of the modem will temporarily resolve external cable issues but it won't fix the underlying cause, which is a degraded cable/connector issue. So, you can give that a try to see if it resolves the problem for a period of time. With a real cable/connector issue, the problem will return. Once again, the OFDMA channel clouds the issue, making it much harder to determine the real cause.
Can you log into your modem and check the Software version which is loaded. That is actually the firmware version. Please post the version number.
07-29-2021 09:24 AM - last edited on 07-29-2021 11:26 AM by RogersMoin
@Datalink wrote:
So, the primary question that comes to mind is whether or not this is a recent development, which might coincide with an OFDMA channel going active at your Cable Modem Termination System (CMTS).
I only really started noticing the issue in the last week or so, at least that's when it started to get so bad that clicking "mute" on a google meet would actually not always mute if it happened to get stuck.
@Datalink wrote:
1. Run a trace to anywhere, google.com for example.
2. Take note of the second hop IP address in the trace. With the modem in Gateway mode or in Bridge mode with a router behind it, the second IP address is the CMTS.
3. Ping the CMTS, using that 2nd hop address. You should get a response.
If the modem is running in Dual (IPV4 plus IPV6) mode, then I'd expect the ping returns to show IPV6 addresses.
So currently I have the modem set up "residential gateway function" disabled so in that mode the modem doesn't seem to have ipv4 vs ipv6 mode as an option. Instead relying on the router for this setting (ASUS RT-AC68U)
Here is when I enable ipv6 through my router and traceroute to google.com (note that prior to today, my router was exclusively in ipv4 mode, so this ipv6 testing is new to me.)
hop 2:
2 12 ms 11 ms 11 ms 2607:f798:804:105::1
Assuming this is the one, i've started a ping test on this and will run for 24 hours (i'm also pinging the ipv6 address assigned to the router just to validate it's not that connection dropping packets - probably not necessary but whatever)
Once this is complete for 24 hours, i'll turn off ipv6 on the router, reboot everything, and do essentially the same test for ipv4 (although I think in that case it would be hop 3 I would be pinging since 1 is the router's local ip and 2 is the public ip, and so 3 would be the CMTS). Then I'll post the results of each one.
@Datalink wrote:
Can you log into your modem and check the Software version which is loaded. That is actually the firmware version. Please post the version number.
Software version: 7.1.1.33
07-29-2021 11:43 AM - edited 07-29-2021 11:43 AM
@pk17 it won't matter if you run an IPV4 or IPV6 trace. With your current configuration of the modem in Bridge mode with a router behind it, the first IP address in the trace is the router. The 2nd hop IP address is the CMTS. The modem is invisible for trace purposes when its running in Bridge mode.
Given that you were only running IPV4 before, I'd say that there's either a cable/connector issue, or, there's an issue with OFDMA upstream ops which only @RogersIan can determine.
You can leave the IPV6 ping test running, or simply bail out of IPV6 altogether and carry on with IPV4 only. If you're using any sort of malware filtering, there's a good chance that IPV6 will bypass that filtering, so, don't want you to risk any exposure to sites that might have malware on them. Leaving a ping test running will give you a good idea of the extent of the packet loss during the day.
Fwiw, there's some issue with the forum logging in process. I can't log in using Chrome, which is what I normally use. MS Edge works, which I don't normally use. Forum users shouldn't have to play web browser games in order to log into the site!!!!
07-29-2021 12:03 PM
Hey, maybe I can help YOU on the forum thing - I cleared cache in chrome and the log in issue seems to be resolved!
Oh interesting that the second hop ID is the CMTS. Ah yes when compare the ipv4 hop 2, it isn't actually my public facing IP (all digits match except for the last field), so that makes sense and I'll be able to do that. I'll continue to let the IPV6 ping to the CMTS run for now (when I was just watching it run i did see packet drops, so i'll monitor and at the end of day will update on what the packet loss is before kicking off an ipv4 ping.
If i'm running my router in ipv6 mode, is it possible to also start an ipv4 ping from the same device or would it start to cause confusion? wasn't sure if I should run those test sequentially or concurrently. I just sort of assumed I would actually limit the router to ipv4 when I do that test
07-29-2021 12:10 PM
Yes, you could run an IPV4 ping test as well. Just have to bring up a second command prompt. When you run the trace, run it as:
tracert -4 www.google.com
That will provide the usual IPV4 trace.
Two simultaneous traces shouldn't impact on each other. It would be rather interesting so see a packet loss incident on one trace but not the other. In theory, for a cable/connector issue, or possibly an OFDMA upstream issue, you should see simultaneous packet loss. So, we'll see how this turns out 🙂
07-29-2021 12:27 PM
Ok, so both IPV4 and IPV6 are running from the same wired connection: PC>Router>Modem
Both pinging their respective CMTS addresses.
I'll leave it for a period to see what the long-term packet drop looks like. But based on my first 2 minutes of watching, I saw both:
1) two instances where both IPV6 and IPV4 timed out on a ping at the same time
2) two instances where IPV4 timed out on a ping but IPV6 did not.
We will wait and see.
07-30-2021 12:53 AM
Ok so this is what I have found. Around 18 hours ping on the ipv6 and about 12 hours for ipv4.
IPV6:
Ping statistics for 2607:f798:804:105::1:
Packets: Sent = 69019, Received = 67881, Lost = 1138 (1.649% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 703ms, Average = 13ms
07-30-2021 11:29 AM
07-30-2021 01:35 PM
07-30-2021 05:07 PM - edited 07-30-2021 05:15 PM
08-01-2021 05:44 PM
Ok just got home. Will switch the modem over to gateway mode and do the tests again to confirm connecting directly to the modem.
I also checked the long 24 hour + IPV4 and IPV6 ping test that has been running (this one is still hardwired through router>Modem (in bridge mode) )
IPV4: Lost 948/103951 = 0.91%
IPV6: Lost 1543/101441 = 1.52%
It's gateway time for the modem that i'll set up now, and will then run same ping test
08-02-2021 10:44 AM
A little over 12 hours in to the ipv4 ping test to the CMTS with the modem in gateway mode here are the results.
default buffer size (32kb): 0.81% (min 3ms, max 949ms, avg 18ms)
max buffer size (65500kb) : 2.73% (min 74ms, max 828ms, avg 94ms)
Just for fun I tried the max buffer size ping of 65500kb and found a higher drop rate. In my mind this was expected as a larger buffer size would likely mean any small packets lost would be more likely to be captured within one of the pings, but let me know if this looks abnormal.
Since the packet drop rate was roughly 0.91% in bridge mode, and 0.81% in gateway mode, it seems like gateway mode MIGHT produce a lower packet drop rate, but also its a 0.1% difference so maybe largely negligible difference.
So with this being the case, anything more I should do / try?
08-02-2021 11:24 AM - edited 08-02-2021 11:48 AM
I don't think there's much more that you can do at the moment other than keep an occasional eye on the packet loss by running another 24 hour IPV4 test at some time. Fwiw, since your IPV4 packet loss is under 1% I don't expect Rogers to do anything. The IPV6 packet loss is interesting. I don't have any explanation for the fact that its almost doubled, in comparison to the IPV4 packet loss. They should be equal.
Your IPV4 packet loss is under 1% but, fwiw, its higher than what I normally see. That might be a result of traffic thru your network or out to the neighbourhood node which is a mixture of all of the traffic on the cable run from the neighbourhood node to the end of the cable run. If you ran 24 hour test sessions throughout the week, you would probably find that each day is unique, in terms of its max latency and packet loss. If you did this for a week, you would have a pretty good idea of what's typical and what isn't.
For now, I think all you can do is look out for upload issues, given that you have an OFDMA upstream channel running. Look for instances on conference calls where you can see and hear everyone on the conference call and its all in sync, but, the other attendees can't hear you. That is what has been observed in the past. Since @RogersIan hasn't chimed in here, I don't know if the upstream OFDMA issues for the 4582 modem have been resolved.
I think at this point I'd go back to running IPV4 only and leave it at that, given that it has a lower packet loss rate compared to IPV6. You had the router configured to run Native IPV6?
08-02-2021 01:38 PM
Ya my “normal” mode was modem in Bridge mode, router running just IPV4, with ipv6 disabled, but when I did the ipv6 config on the router I found instructions on this forum that said I should use “native” so did that.
I agree it’s fairly low, and I admittedly haven’t seen the really bad issues in a few days, so maybe it was just an one-off that was causing some random issues. I’ll continue to monitor and see if I have any more of the major issues. Will also play around with gateway vs bridge mode. It seems I can get the same level of access whether i do
a) modem in bridge > router
b) modem in gateway (configure a dmz for router) > router
seems like either way works from a NAT / connectivity perspective, so I’ll do some long term testing to see if one happens to work better than another for me.
thanks for all your help!
08-22-2021 04:07 PM - last edited on 08-22-2021 04:41 PM by RogersMaude
I am noticing occasional stutter/pauses when watching videos and streams on my computer with ethernet and wireless. I did some searching and when I ping the primary rogers ipv4 DNS server 64.71.255.204 with command prompt I get packet loss(request timed out) about 40% of the time. Is this supposed to happen or should I contact Rogers support?
Thank you.
08-23-2021 04:31 PM
Good day @eliashasan123,
Welcome to the Rogers Community! We know troubleshooting isn’t everyone’s idea of a great time, but we’ve compiled a few steps here that should help put some of the control back in your hands.
Please share with us the details of the ping test you ran while connected via ethernet. 🙂
If you are experiencing poor performance with your Rogers Internet, log in to your gateway and observe the following on your internet modem:
If you have any doubt concerning your internet performance, please post your downstream tables, upstream tables and the results from a Rogers Speedcheck with an ethernet connected PC or laptop. Post in any additional information such as whether or not you have services which include Rogers Cable TV and/or Rogers Home Phone, and if you are observing any problems with those services as well. As well, indicate whether your home is an apartment, single family house, or other, as this may change the approach required to solve an internet problem.
Lookng forward to your reply!
RogersMaude
10-07-2021 01:17 PM
I found this thread after noticing packet loss more and disabling ipv6 did the trick as a workaround. I think Forza Horizon 4 multiplayer is the only application of mine that needed ipv6 to connect, but it's a worthwhile trade-off to go from ~2% to 0.02% packet loss. Could be coincidence but the packet loss did go away as soon as I disabled ipv6.
02-13-2022 10:11 PM - last edited on 02-14-2022 08:09 PM by RogersRahul
Experiencing this issue when streaming to any streaming service: Twitch, Youtube, Discord. Sometimes connection is stable with no frames dropped, but frequently experience 80%-90% frame drops over extended periods of time. Running PingPlotter shows 96% PL% on the first hop. Have tried swapping cables, ethernet adapters, even testing different machines on wifi and wireless connections.