Showing results for 
Search instead for 
Did you mean: 

Suffering Packet loss

I've Been Around

Hello, I have contacted tech support a few times and techs have come out to check my cables. The techs say that the signal strength is good and I do receive the advertised speeds 100/10, but I suffer packet loss. I also get dropped from Skype calls at the same times I am lagging on League.... I am not sure what the issue maybe, any advice?


Stats from the modem, it is in gateway mode and I am on a desktop connect through ethernet.
Ping statistics for
Packets: Sent = 1000, Received = 870, Lost = 130 (13% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 146ms, Average = 31ms
Downstream Overview
Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID Signal noise ratio (dB)
1 651000000 256QAM -8.700 10 37.356
2 591000000 256QAM -6.100 1 38.605
3 597000000 256QAM -7.000 2 38.605
4 603000000 256QAM -6.400 3 38.983
5 609000000 256QAM -6.800 4 38.605
6 615000000 256QAM -6.900 5 38.983
7 621000000 256QAM -7.400 6 38.605
8 633000000 256QAM -8.200 7 37.636
9 639000000 256QAM -7.600 8 37.636
10 645000000 256QAM -8.900 9 37.636
11 657000000 256QAM -9.300 11 37.356
12 663000000 256QAM -9.400 12 37.356
13 669000000 256QAM -9.400 13 35.084
14 675000000 256QAM -9.400 14 36.387
15 681000000 256QAM -9.600 15 37.356
16 687000000 256QAM -9.800 16 36.610
17 693000000 256QAM -9.800 17 36.610
18 699000000 256QAM -10.900 18 36.387
19 705000000 256QAM -10.200 19 36.610
20 711000000 256QAM -10.600 20 36.610
Upstream Overview
Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID BandWidth
1 23700000 ATDMA - 64QAM 40.250 7 6400000
2 30596000 ATDMA - 64QAM 40.250 6 6400000
3 38596000 ATDMA - 64QAM 40.250 5 3200000
201 REPLIES 201

Re: Suffering Packet loss

ah, right.  Use:  ping -t


to see the options type in:  ping/?


Re: Suffering Packet loss

Thanks. I’m guessing these test should be done later in the day when everybody is home and using the internet in the area to find packet loss / congestion issues ? @Datalink I have ran some so far no packet loss but at times I getting high ping the highest being 100 ? I find that quite high my node is just across the street

Re: Suffering Packet loss

Let the ping run for 24 hours if you want to.  That's what I do.   There is also the IPV6 ping to the CMTS to run as well.  If you have IPV6 enabled in the modem, to run the IPV6 trace use: 


tracert -6


The same situation applies, the first IP address is the modem or router, the second is the CMTS.  Ping the CMTS using the IPV6 address.  


The high time pings are the result of the modem firmware change in version .27.

Re: Suffering Packet loss

If the high pings are caused by .27 how can I tell if I’m still getting congestion on the node ... I have ipv6 disabled because of nhl 18 and to get something clear cmts and node the same ?

Re: Suffering Packet loss

As I indicated yesterday, you're going to have to ping the Rogers DNS IP.  Just let that run once per second for a 24 hour time span and you might see a difference throughout the day in in fact there are congestion issues. Ideally you would simply ping the CMTS for a 24 hour period or longer, but, that's not possible with the 4582.  Going beyond the CMTS also brings in the possibility of network issues and DNS loading as well.  I haven't found those to be an issue but, it would be hard to distinguish between a local CMTS issue and a network and/or server issue.  A large difference in response times, from very early morning to later in the evening I would consider to be a CMTS issue. 

Re: Suffering Packet loss

I Plan to Stick Around

From my router:

--- ping statistics ---
31 packets transmitted, 26 packets received, 16.1% packet loss
round-trip min/avg/max/stddev = 10.911/15.791/32.113/4.668 ms


From the CODA modem:

--- ping statistics ---
4 packets transmitted, 2 packets received, 50% packet loss
round-trip min/avg/max = 10.000/10.000/10.000 ms


I have lost my OFDM downstream lock again.

Re: Suffering Packet loss

I Plan to Stick Around

OK, I had been meaning to do this for a while. Enough with the pings. I set up an iperf3 instance in AWS and hit it from my pfSense router. (My router is a Celeron G3930 with an i340 network adapter and 8GB DDR4 memory)


Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   761 KBytes  6.23 Mbits/sec    0   45.5 KBytes
[  5]   1.00-2.00   sec  1.10 MBytes  9.24 Mbits/sec    2   41.1 KBytes
[  5]   2.00-3.00   sec  1.27 MBytes  10.6 Mbits/sec    0   72.5 KBytes
[  5]   3.00-4.00   sec  2.23 MBytes  18.7 Mbits/sec    0    105 KBytes
[  5]   4.00-5.00   sec  1.97 MBytes  16.5 Mbits/sec    2   73.7 KBytes
[  5]   5.00-6.00   sec  2.10 MBytes  17.6 Mbits/sec    2   52.3 KBytes
[  5]   6.00-7.00   sec  1.41 MBytes  11.8 Mbits/sec    0   80.8 KBytes
[  5]   7.00-8.00   sec  1.32 MBytes  11.1 Mbits/sec    2   66.7 KBytes
[  5]   8.00-9.00   sec  1.64 MBytes  13.8 Mbits/sec    2   56.7 KBytes
[  5]   9.00-10.00  sec  1.30 MBytes  10.9 Mbits/sec    0   82.3 KBytes



Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-15.00  sec  17.9 MBytes  10.0 Mbits/sec  0.000 ms  0/93745 (0%)  sender
[  5]   0.00-15.00  sec  17.8 MBytes  9.96 Mbits/sec  0.200 ms  350/93731 (0.37%)  receiver

There is a constant, persistent amount of dropped packets.  I am going to re-run this at various times of day. I restricted the bandwidth to something modest like 10mbit too. 


Compare with pfSense -> wired server, no surpirse:


Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 15 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   948 Mbits/sec    0    207 KBytes
<snip - all Retry are 0>
[  5]  14.00-15.00  sec   112 MBytes   942 Mbits/sec    0    207 KBytes

 And for UDP I can move around 100,000 packets per second with no loss.

Re: Suffering Packet loss

What version of iperf are you running.  You need to run V3.17 or later, or you will see excessive losses which are false loss indications.  Can you run iperf from the pfsense router itself?  Very cool....


Looks like iperf 3.5 is the latest version:


Re: Suffering Packet loss

I Plan to Stick Around

I think you mean 3.1.7 yeah (not trying to be pedantic :D)


[2.4.2-RELEASE][admin@pfSense]/root: iperf3 -v
iperf 3.2 (cJSON 1.5.2)
admin@server:~$ iperf3 -v
iperf 3.1.3

Will update the server, but I only used it during the tests that actually showed no loss.

Re: Suffering Packet loss

There is another way to do this for UDP testing, and that is to use DNS queries and Wireshark to record the data and plot the results.  Wireshark also has the capability to filter the results in a DNS analysis tool to determine the results.  If you're interested have a look at the following post which uses a DNS query application to run a continuous query to the Rogers DNS.


I run a continuous query with a script to run another application, collect the data with Wireshark and run the plot and analysis within Wireshark.  I need to get around to writing a post to do all of this with Wireshark.  That should help settle some of the arguments, is there packet loss or not? 


Edit:  Food for thought.  If anyone was to run continuous UDP queries for response time and loss testing, or run an iperf test to a non-existent Rogers Iperf server, you would see that the losses within the Rogers network are substantially less than what you saw with the iperf test to the AWS.  To come to any conclusion about UDP or ICMP or TCP/IP losses, anyone interested in testing for that needs a baseline set of numbers, what are the responses and losses in my ISP network and what happens when I test outside of the network.    So, consider that for future testing.  Are you able to run any type of script within pfsense to run a continuos DNS query to the DNS IP address of your choice?  That would be a great test tool to have on hand.  

Re: Suffering Packet loss

I Plan to Stick Around

I'm certainly not trying to discredit the other ways of testing. 


But you show packetloss with ping, "oh, ping isn't reliable", so you show packetloss to the DNS, "oh, the DNS servers aren't designed to respond like that", so you hit AWS, and it's like "oh, it could be anything"


No, it's Rogers -- the modem, the cable, the CMTS, something.


While there may be MORE loss to AWS than elsewhere (assuming the elsewhere is reliable -- not sure about that right now), there's still an amount of loss that, regardless, is unacceptable. Rogers can say it is out of their control, but if someone 2km away from me doesn't see the problem at all, that's a big deal.


I'm also interested in having my friend run a server and have me hit it, again, 2 km away.

Re: Suffering Packet loss

@daveinsurgent the only thing that I'm trying to point out the the possibility of incrementally higher losses outside of the ISP network, doesn't matter which ISP we're talking about.  I suspect that end users would get some grief from tech support with any method of testing that doesn't match their scripts.  Personal opinion, don't care about the scripts and I don't believe that the engineers would frown on ICMP / UDP / TCP/IP testing of any type.  I haven't run into any negative reaction from the engineering staff since I started to run these type of tests on the modems.  If you don't do this, you never see the idiosyncrasies of the modems, good or bad.  Fwiw, this is exactly the type of testing which led the engineering staff to pursue the Puma 6 latency issue with Hitron and Intel.  That's an ongoing issue worldwide and Intel is now in the middle of a class action law suit in the U.S. because of the latency issue.  Rogers decided to push on with deployment of the Puma 7 CODA-4582 and since its release in Dec 2016, there have been a steady stream of updates for the modem.  That doesn't necessarily mean that the updates have fixed everything, but, the modem has improved greatly since the initial release.  Not trying to defend Rogers here at all, just pointing out the history, all due to simple ping tests by the end users. What is it they say, the pen is mightier than the ping?  Something like that.   

Re: Suffering Packet loss

I Plan to Stick Around

Could you elaborate what you mean by Engineering Staff?


I have had senior people from Ramkey come out who basically don't care at all about these kind of tests. Online chat is also pretty indifferent, they log in to the modem, run a ping test (and I'm like 60% sure that they don't even realize they're pinging the modems IP from the modem itself, so it's almost useless)


Re: Suffering Packet loss

Engineering staff as in @RogersDave (now departed Rogers), @RogersKevin (gaming thread) and now @RogersBob and @RogersSyd, after Dave's departure.  @RogersBob hasn't been in the forum much and I haven't seen @RogersSyd yet.  I suspect that everyone is busy with the upcoming IPTV launch.  As you indicated, the tech support staff isn't much help beyond their standard tests. 

Re: Suffering Packet loss

I Plan to Stick Around

Well, you just explained why Dave hasn't answered my messages!


Dave? Dave's not here, man.

Re: Suffering Packet loss

Re: Suffering Packet loss

@Datalinkhere are some test I have done can you let me know what you think... I will let it run longer some more tomorrow . let me know if you think if  I'm getting any congestion thanks

Ping statistics for
Packets: Sent = 1187, Received = 1187, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 143ms, Average = 12ms


tues march13 @ 730pm
ping statistics for -CMST
packets sent= 696, Received=696, lost = 0 ( 0% loss )
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 107ms, Average = 13ms

thur march 15 @930pm
Ping statistics for
Packets: Sent = 381, Received = 381, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 47ms, Average = 12ms


thur march 15@ 10pm
Ping statistics for
Packets: Sent = 1396, Received = 1396, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 142ms, Average = 16ms

thur march 15@ 1030pm

Ping statistics for
Packets: Sent = 1164, Received = 1164, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 116ms, Average = 14ms


@Datalinkran some speedtest and I notice my download is acting up here is my downstream overview


Port IDFrequency (MHz)ModulationSignal strength (dBmV)Channel IDSignal noise ratio (dB)


Re: Suffering Packet loss

Does my upload signal look good ... also got getting some T2 / T3 time outs

Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID Bandwidth
1 30596000 ATDMA - 64QAM 30.750 1 6400000
2 38596000 ATDMA - 64QAM 35.250 3 3200000
3 23700000 ATDMA - 64QAM 31.000 2 6400000

Re: Suffering Packet loss

@lethalsniper I had a look at your ping data.  No packet loss shown at all.  Looking at your signal levels the downstream DOCSIS 3.0 levels are a little higher than what I would like to see, but, they're still well within spec.  Looks like the final channel didn't paste into the post.  The upstream levels are ok.  Aren't you running a 4582?  If so then you're running DOCSIS 3.1 on the download side.  That may or may not be an issue.  Several users continue to report slow data rates with this modem which points to some issue with the OFDM channel or with the OFDM processing within the modem. 


Edit:  Looking at the ping data its impossible to tell if there are any problems with upstream congestion.  That data would have to be plotted over a much longer time period to see if there is upstream congestion in the busier after school hours and into the evening. 

Re: Suffering Packet loss

I've Been Around

Hello, so I'm on rogers ignite 500 and I've been experiencing some packet loss again. I've had some really bad packet loss in the past getting upwards towards 20-30% on cmd during and after peek hours. Even after calling a technician to our home, he said packet loss is normal during these times (this was around 1-2pm).  After a while though, the problem faded away. 

Fast forward to now, the packet loss is very noticeably back when I play any game. Even at 2-4am, I still get the very noticeable packet loss on a wired connection.


Ping statistics for
Packets: Sent = 125, Received = 111, Lost = 14 (11% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 138ms, Average = 34ms


Downstream Overview

Port IDFrequency (MHz)ModulationSignal strength (dBmV)Channel IDSignal noise ratio (dB)


Upstream Overview

Port IDFrequency (MHz)ModulationSignal strength (dBmV)Channel IDBandwidth
130596000ATDMA - 64QAM35.50016400000
238596000ATDMA - 64QAM39.00033200000
323700000ATDMA - 64QAM36.25026400000


Also I'm on a wired connection.



Re: Suffering Packet loss


Hello, @RayyMango


Welcome to the Rogers Community Forums! Smiley Happy


Thank you for your detailed message. I appreciate posting the signal levels and the ping plotter screenshots. The packet loss can certainly be bothersome especially in the games. The signal levels are not ideal, however, they should not be contributing to the packet loss. I'm not sure if you are in Ontario, the issue could be related to recent severe weather conditions. 


We can check your connection and the neighbourhood, please send us a private message at @CommunityHelps. Our private messaging system is explained in this blog.