Troubleshooting Packet Loss

Need Help?

That's what we're here for! The goal of the Rogers Community is to help you find answers on everything Rogers. Can't find what you're looking for? Just ask!
cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
pk17
I Plan to Stick Around
Posts: 14

Troubleshooting Packet Loss

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

 

 

FireShot Capture 005 - CODA-4582U Router - Hitron Technologies - 192.168.100.1.png

 

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*

stepy2015
I Plan to Stick Around
Posts: 133

Re: Troubleshooting Packet Loss

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

toolcubed
I'm a Senior Contributor
Posts: 521

Re: Troubleshooting Packet Loss

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.

Datalink
Resident Expert
Resident Expert
Posts: 7,368

Re: Troubleshooting Packet Loss

@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.



pk17
I Plan to Stick Around
Posts: 14

Re: Troubleshooting Packet Loss

 

@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

 
Datalink
Resident Expert
Resident Expert
Posts: 7,368

Re: Troubleshooting Packet Loss

@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!!!!



pk17
I Plan to Stick Around
Posts: 14

Re: Troubleshooting Packet Loss

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

Datalink
Resident Expert
Resident Expert
Posts: 7,368

Re: Troubleshooting Packet Loss

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 🙂



pk17
I Plan to Stick Around
Posts: 14

Re: Troubleshooting Packet Loss

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.

pk17
I Plan to Stick Around
Posts: 14

Re: Troubleshooting Packet Loss

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

 
IPV4:
Ping statistics for 99.240.138.1:
    Packets: Sent = 42100, Received = 41803, Lost = 297 (0.705% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 1150ms, Average = 14ms
 
interestingly, the ipv6 had a higher drop rate by over double that of the ipv4. As I was watching on and off, I saw all examples:
- ipv6 dropped, ipv4 did not
- ipv6 did not drop, ipv4 did drop
- both dropped
 
All that said, I didn’t notice any real concerning issue during my Google meet video calls today, so that was good. How do those drop rates look given it’s pinging the CMTS?
 
oh and for the record, my ping to the router was precisely 0 packets lost over 18 hours, so that hop seems good.