Suffering 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
Resident Expert
Resident Expert
Posts: 6,154

Re: Suffering Packet loss

Ok, the best way to do this is to run a 24 hour ping test and plot the results.  Running Pingplotter does work, but, Pingplotter averages the results on the plot.  Wireshark is a freebie program that is used for data analysis and to a degree, network analysis.  If you download and install Wireshark, I can give you the Display Filter settings to plot the data.  Another thought here is to run Hrping, which allows you to run ping interval times below 1 second.  

 

Hrping is found here:  https://www.cfos.de/en/ping/ping.htm

 

Wireshark is found here:  https://www.wireshark.org/

 

Hrping is a command line application.  The command to run a sub-minute ping test is:

 

hrping -t -s 20 -F c:\temp\HRPingdata.txt 64.71.255.204      where:

 

-t runs the test until stopped with Control^C

-s 20 runs the test with 20 ms intervals.  This time is in milli-seconds, so you could bump that up to something like 250 ms just to cut down on the amount of data.

-F c:\temp\HRPingdata.txt  dumps the data to a text file in the C:\temp directory, assuming of course that you have a c:\temp directory

64.71.255.204 is one of the Rogers DNS 

 

Note that in order to plot the data on with Wireshark using a 1 second interval plot, you need the ping interval to be low enough to result in at least two sample points per second, ergo, the use of Hrping.  If you're happy with a 10 second plot time, you can run the normal command line ping and Wireshark will plot the max, min and average time in that 10 second interval time, using the 1 second sampling points.  A 10 second plot works pretty well if you let the data collection run for 24 hours. 

 

That final plot will demonstrate if there is a continuous problem throughout the day or if its restricted to evenings during the week and during the day and evening on the weekends.  In both cases, your neighbors are home, gaming, streaming, etc, etc, resulting in a heavier upload condition at the CMTS.  That results in problems for everyone on your CMTS. 

 

Edit:  If you decide to go the Wireshark route, after running Wireshark for a period of time, stop the recording by hitting the red stop button on the Wireshark menu bar.  Go File .... Save, or File .... Save as to save the data to a file somewhere.  I have a directory set up to collect data, divided into further sub-directories for each day that I run a test of some sort.  You might be at this for a little while, so, it might be an idea to follow a similer route in order to preserve the data and give you a basis of comparison from day to day or week to week.  When the data is saved, then you can run the Statics IO Graph to plot the results.  Running a slow ping test, Wireshark will be able to keep up with the plot, but for high speed tests, it can't.  I don't believe that it was necessarily built to run real time data analysis for high speed runs.  At high speeds, as in low interval times, you well see errors on the plot, and in the case of ICMP, from what I remember there is an outstanding bug that requires attention in terms of how Wireshark processes the data.  Post processing the data will avoid any errors and misconceptions of the data that is being plotted. 

 

Edit 2:  Pingplotter will plot the actual results when you use a low plot time, 1 or 5 minutes.  As you move up in plot time, up to 12 hours, 24 hours, Pingplotter averages the data that it plots.  Basically it looks at the data in a given horizontal pixel range and averages the data for presentation purposes instead of preserving the max and min values.  As you drop the ping interval, that problem get worse as you have more data per horizontal pixel range.  So, for something like a 24 hour plot presentation, the plot looks pretty good as all of the data is averaged and the ping spikes no longer exist.  It would take a pretty remarkable rise in ping time over a longer period of time to actually move the data vertically on the longer timeframe plots. Wireshark will plot the max, min and average data as selected by the user, and in accordance with the Data Display Filter settings that I can give you, so, you will see the worst case ping times throughout the day on the plot.  So, no hiding of ping spikes on the plot.

 

Edit 3:  To access the modem thru the router, with the modem in Bridge mode, use 192.168.100.1 as the modem's login page address.  That address can also be used when you have a direct connection to the modem, when the modem is either in Gateway or Bridge mode.



I Plan to Stick Around
Posts: 43

Re: Suffering Packet loss

Hi @Datalink - I don't want to steal from @zeny12's attention but I would like to essentially run the same set of tests as we are both experiencing what seems like something very similar.

 

I am currently using the CODA-4582 in Gateway mode.

 

I ran `ping -i 0.2 64.71.255.204`

 

--- 64.71.255.204 ping statistics ---
501 packets transmitted, 415 received, 17% packet loss, time 100538ms
rtt min/avg/max/mdev = 10.381/25.383/135.322/17.301 ms

 

 

Here's an `mtr -i 0.2 64.71.255.204` note I am doing 0.2 not 0.02 as you suggested in both these tests:

 

Screen Shot 2018-01-27 at 6.18.16 PM.png

 

 

Here's `sudo ping -i 0.02 64.71.255.204`

 

--- 64.71.255.204 ping statistics ---
511 packets transmitted, 400 received, 21% packet loss, time 10953ms
rtt min/avg/max/mdev = 10.415/21.359/129.178/14.595 ms, pipe 6

 

 

The modem and whatever that gateway address seem to abhor being aggressively pinged; I can see up to 18% paketloss to the 174...1 address with a regular 1s interval and spikes to 180ms. You seem to suggest that's normal? Like its' an issue-but-not-an-issue-only-when-running-ping?

 

 

 Screen Shot 2018-01-27 at 6.21.10 PM.png

Resident Expert
Resident Expert
Posts: 6,154

Re: Suffering Packet loss

Nope, that packet loss is definitely not normal.  Packet loss to the CMTS or DNS should be down below 1%, so, there's an issue in the system somewhere.  What I can't figure out is why you have a 174.xxx.xxx.xxx address showing up in the trace.  Here's a trace from my pc to google.ca:

 

Tracing route to www.google.ca [172.217.0.227]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router.asus.com [10.0.0.1]
2 13 ms 17 ms 11 ms 99.239.xxx.xxx
3 14 ms 14 ms 14 ms 67.231.221.73
4 12 ms 15 ms 16 ms 209.148.231.73
5 19 ms 25 ms 21 ms 209.148.229.225
6 23 ms 18 ms 17 ms 209.148.230.14
7 * * * Request timed out.
8 16 ms 25 ms 23 ms 108.170.250.225
9 18 ms 18 ms 17 ms 108.170.226.219
10 21 ms 20 ms 22 ms yyz10s03-in-f3.1e100.net [172.217.0.227]

Trace complete.

 

I removed part of Hop #2's address, but, the address is valid.  Typically we see a 99.xxx.xxx.xxx address as the second hop which is the CMTS.  So, I've been wondering why you're seeing a 174 address show up in the trace. 

 

Running a 4582, you will see ping spikes to the CMTS which is a processing problem with the modem itself and not with the data.  End result, one has to ping the DNS in order to see if there is an issue in terms of latency thru the modem or latency thru the Rogers network.  Running a day long ping test, ICMP, TCP/IP or UDP, I usually see one or two wacky ping spikes per day for which I have no explanation.  Depending on the type of test that is running, ICMP, TCP/IP or UDP, I'll usually see somewhere around the low tens of ms up to around 20 ms, depending on how long I run the test.   

 

Can you outline for me your current network setup:  4582 in Bridge mode with a router behind it running in full router mode?  Model of router?

 



I Plan to Stick Around
Posts: 43

Re: Suffering Packet loss

Thanks for the quick response.

 

My current configuration is the 4582 in Gateway mode, with a TP-Link SG-3210 switch and my PC(s) connected to that. I've also tried using a Netgear R7000, or a Netgear X4S with the 4582 in bridge mode, my PC connected to either of those (never chaining or double-NAT), as well as my PC connected directly to the 4582 in bridge mode (so no other switch or any kind of  NAT device within my network) - the behavior is always the same. Packetloss and ping spikes.

 

The 174. address always shows up, and it's always in the same pattern of first two octets are the same, second octet is one less, and fourth octet is 1.

 

For example, if my whatismyip.com address is "5.4.5.5" (just making that up obviously), I will have a 2nd hop after my gateway as 5.4.4.1. If my IP was 9.9.9.9, I would have 9.9.8.1. This happens regardless of whether or not the modem is in bridge mode or gateway mode.

Resident Expert
Resident Expert
Posts: 6,154

Re: Suffering Packet loss

@daveinsurgent going to have to think about this, you've exchanged the modem already?



I Plan to Stick Around
Posts: 43

Re: Suffering Packet loss

Yes, I have. The modem that was taken away was running the latest beta firmware, this one as replaced is 2.0.10.28T2 -- though the issue remains the same.

 

I Plan to Stick Around
Posts: 23

Re: Suffering Packet loss

@Datalink 

 

My 2nd hop is also a 174.xxx.xxx.xxx address... Are you near me @daveinsurgent ? Ottawa ON?

I Plan to Stick Around
Posts: 43

Re: Suffering Packet loss

Kitchener!

I Plan to Stick Around
Posts: 23

Re: Suffering Packet loss

Strange. 

 

Is a 174.xxx.xxx.xxx address not normal for a CMTS I wonder?

 

In other news I am trying to install wireshark atm. Can I still use the pc and play games while its running or no? @Datalink

Resident Expert
Resident Expert
Posts: 6,154

Re: Suffering Packet loss

You can still use the pc for other applications, just remember that Wireshark will record all inbound and outbound traffic, including passwords.  It would be an interesting test, to run Wireshark while you're gaming.  I would back off on the ping intervals, maybe just run it at 1 per second while you're gaming.  Thats just to keep the CPU load down while you're gaming.  If you let that data recording run overnight, you will be able to look at the difference in latency, from now, thru the early morning hours when the CMTS upstream load decreases.