@Datalink , just ran the 1 hour test using hrPING (thanks for the instructions!). I pinged the second IP address listed on my tracert to google.ca. The IP was the same as my external IP EXCEPT for the last two digits (I guess the CMTS ends with ".1" and my ip ended with ".xx". Hopefully I used the right IP.
Here's the results:
Packets: sent=14400, rcvd=14339, error=0, lost=61 (0.4% loss) in 3599.781794 sec
RTTs in ms: min/avg/max/dev: 4.932 / 25.948 / 571.193 / 45.196
Bandwidth in kbytes/sec: sent=0.240, rcvd=0.238
Quite a bit off loss and high pings.
To answer your previous question about my 15 minute test: No, the high pings never occur when I start the test - they are scattered throughout. While running the ping test I browse/use my computer as normal. When I notice my browsing/downloading becoming sluggish I open my command prompt and viola, notice my ping is well into the triple digit range, so there's definitely a problem - this happens both wired (for which I performed the test) and wireless on multiple device (so it's not device specific).
Last night while running a ping test to google's DNS for about 30 mins or so my max response time was 2800+ ms.
From what I can gather it is the intermittent high response times that are causing issues...
EDIT: Do you happen to know Rogers DNS IP so I can ping those?
Hi @Corx, here's the DNS IP addresses. The IPV6 addresses won't be of use for now .... down the road.
Rogers IPV4 DNS:
Rogers IPV6 DNS:
Primary IPv6 DNS:
Secondary IPv6 DNS:
So, looking at your results with the 1 hour test, its good that your losses are under 1%, but, personal opinion, you should be in the 0.1% range or lower. The high times could be a product of running the test and browsing, etc on the same pc, but, personal opinion, those high times are much higher than they should be. The age of the pc, processor, memory type and amount can enter into the picture here.
What you can consider is to download Wireshark and install it. It will install NpCap during the install as well. NpCap doesn't have to load at startup, or run in a Winpcap mode, so you can deselect those options during the install. Wireshark will record all of the traffic outbound and inbound and with that data I can plot the return times to see whats going on. The plotted data will show the real response times, whereas Pingplotter averages the data plot, losing the high time return times in the process.
So, the idea here is to use HRPing to run the ping test and collect the data with Wireshark. When you start Wireshark there will be a connection selection that is shown in the bottom of the start page. Select Ethernet if you're running the test via ethernet, or wifi, if you run a test via wifi. Wireshark will then start recording the inbound and outbound traffic from that adapter. Hit the red stop button to stop recording. To save the file, go File .... Save .... and save that to a directory somewhere. I have a test directory set up where I dump the data files into numbered sub-directories or sub folders to keep them where their supposed to be. Each test day is dumped into a new sub-directory.
To start or restart a recording session, go Capture ..... Start. If you haven't saved the current file, you'll get a warning to save the current file or Continue without Saving.
When you have time, I'd like you to run another 1 hour test using HRPing and record the data with Wireshark. Then I'll get you to send that file to me using send.firefox.com, which is an anonymous file transfer / send site that Mozilla has set up. All you do is drag and drop the file to the send window and the next page will display a link to the file and expiration time or max downloads (leave that at 1). You can send the link to me so that I can download the file and take a look at it.
Before you send the file, in the title bar in Wireshark, with that file up, type in: icmp
That will cause Wireshark to display only the icmp component of the recorded data and filter out everything else from the display. Right click on the top recorded line and select "Mark". Right click on the bottom recorded line at the end of the file, and Select "Mark". Then go File .... Export Specified Packets and select First to last marked in the pop up save window. Give this a file name and hit save. That will export only the icmp traffic from the original file, leaving out any personal data. Then you can upload that file and send me the link via private message. If you already use a file uploading site, that works as well as long as I can download the file. After the file is exported, you can unmark the top and bottom lines and delete the "icmp" from the search bar. That will return the file appearance to its original state.
I'll dig up a plot command file that will allow you to plot this yourself using Wireshark, and send that to you. I probably won't get to that this afternoon, but, we'll see.
Edit: please run all of these tests via ethernet.
Thanks @Datalink, I really appreciate your help. I'll try do this this evening when I get home and post back with the results.
In the meantime, could whatever is happening be contributing to my pings jumping to 500ms or so when I perform a speedtest? My neighbour was kind enough to let me use their wifi (Bell) and when I run a speedtest via wifi (not ideal) my pings (loaded/unloaded) remain pretty constant (maybe +10-20ms).
What you're seeing on your ping test, when you do something like web cruising or running a speedtest, is the pc's and modem's traffic management scheme in action. From the reaction that we typically see, that is the ping time can increase dramatically when some other function is running, that really indicates that the ICMP ping takes a backseat to the other traffic, which isn't a bad thing. It all comes down what traffic management scheme is running and what is it set to do? Every device runs a traffic management scheme of some type, whether we know it or not and it will always have some effect on the results that we see. Anyone running some type of ping test, whether its ICMP, TCP/IP or UDP has to consider what effect that management scheme has on the results and whether or not he or she is satisfied with the results.
When @RogersDave was around, he and/or the engineering staff implemented a new traffic management scheme for the 4582 modem to reduce the latency thru the modem for all protocols. The IPV4 result can be seen here:
If you look at the before and after results, you can see that there is a reduction in the latency for the ICMP ping, and what is probably a TCP/IP download and upload. I don't know if that was the maximum capability at the time for the Realtime Response under Load or not. I think that the test has since been improved to provide better results, or expanded results for all protocols. That test hasn't been repeated for these modems as far as I'm aware, which is unfortunate. One of my "to do" items is to figure out how to load ubuntu onto a pc, without creating havoc with the Windows installation, end target is to run those tests again just to see how the current firmware compares to that test.
When you look at the after plot, and look at a plot obtained using Fair Queuing Controlled Delay, or FQ_CODEL as its referred to, you can see that there are similarities in the final outcome. So, best guess is that there is a traffic management scheme in effect in the modem which comes close to FQ_CODEL behaviour.
Since that implementation, its been common to see spiky behaviour when you run a ping test with other activity in progress. The problem is to separate that behaviour from other possible issues at the neighbourhood node or CMTS. One of the best ways to do it is to run the ping test overnight, when the demands on the CMTS and network node are greatly reduced throughout the very early morning hours.
What you can do is to run a ping test to the DNS instead of the CMTS, and run that overnight. I'd still like to see the results to the CMTS as there are limits to the spiky behaviour. I don't expect to see return times in the thousands, and the fact that you can run the same scenario via wifi and see much better results is rather interesting to say the least. Is your neighbour running Fibre to the Home by any chance? Just curious.
Here's a couple of links for perusal:
@Corx yes, in theory, running the modem in Bridge mode with a router after the modem could potentially help. I say potentially as the router would have to be able to run FQ_CODEL, or Cake, which means running DD-WRT on a router, or an Asus router (RT-AC86U for example) with Merlin's Asuswrt and Fresh JR's Adaptive QOS add-on loaded. There is also the pfSense route which I believe allows the user to run FQ_CODEL. On my list of things to do is to load Fresh JR's adaptive QOS on my RT-AC86U, which changes the order of the priority of the protocol types and changes the bandwidth that each category is allowed. Its received good reviews by other users, so I have some exploring to do to see if the add-on terminal menu has been updated to load it. Here's the link for the thread. This is in effect what really needs to happen, select the traffic categories in the order that you want them to run, and assign the appropriate bandwidth to those categories, ie, gaming, downloading, voip, etc, etc. Thats what all of the traffic management work has been about, managing those traffic categories with better algorithms to improve the response:
The fly in the ointment is the fact that DOCSIS 3.1 modems are supposed to be running Active Que Management. I really don't know if the Rogers 4582 is actually running AQM at the moment, or, if its only going to be active when DOCSIS 3.1 upstream is enabled, hopefully somewhere in the near future. So, the question is, if a customer goes all out and implements FQ_CODEL or CAKE in a router, will, or does the modem's AQM foul this up with its own packet management scheme which apparently is Proportional Integral Controller Enhanced (PIE) algorithm, called DOCSIS-PIE. Does DOCSIS-PIE run all the time, regardless of what mode the modem is running in, Gateway or Bridge modes? I can see that happening as the modem will support more than one device in bridge mode.
In addition to this is a recent Low Latency DOCSIS development by Cablelabs, who developed the DOCSIS 1, 2, 3, and 3.1 specifications. Are we going to see that implemented and what does that do for the current management scheme in the modem.
Lastly, the impending implementation of DOCSIS 3.1 upstream should make a significant difference in the latency that everyone observes. The latency should decrease given the fact that there should be an increase in the number of transmit time slots that the modems can use. We'll have to wait to see those effects, hopefully soon.
So, there's more questions that answers unfortunately, but, yes, a router with the right firmware should make a difference.
In terms of an overnight ping test, ping the primary DNS, 220.127.116.11
Yup, having fibre to the home should result in much better performance as you're not dealing with the copper cable power and signal quality issues. I'd expect much better performance thru fibre. So the question is, whats the problem ??? Just a matter of digging and complaining, again and again and again
@Datalink just wanted to give you a little update. I went and purchased an RT-AC68U today and that seems to have smoothed out my browsing experience a bit. Pings seem a bit more stable and less extreme. Here's my latest ping to the CMTS:
Packets: sent=9600, rcvd=9561, error=0, lost=39 (0.4% loss) in 2399.773595 sec
RTTs in ms: min/avg/max/dev: 4.138 / 24.716 / 335.912 / 44.372
Bandwidth in kbytes/sec: sent=0.240, rcvd=0.239
Still getting quite a bit of loss though...
What's interesting though is that I'm pinging the CMTS from a different connection (with a different provider) and am seeing spikes in ping still. This seems to suggest to me that there is something up with the CMTS? In a 15min ping test to the CMTS from a Bell fiber line (1 gigabit) I'm getting spikes up to 500ms to the CMTS (using the same computer, etc). I'm not getting the same type of loss (though I am not doing a hrping with it at the moment).
Any thoughts on this?
@Datalink , sorry for the multiple replies, but here's an overnight test for both Rogers' primary DNS and my CMTS:
Packets: Sent = 32961, Received = 32879, Lost = 82 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 1116ms, Average = 18ms
Packets: Sent = 32311, Received = 32231, Lost = 80 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 822ms, Average = 17ms
Not too bad, though the ping spikes I think are what's killing me... Any thoughts on how to solve this? I called Rogers again last night and apparently a maintenance team came to my node outside and found some issues with the signal that they were supposedly able to fix - though I'm still experiencing really sluggish browsing, etc. They've now requested a senior tech to come out to my place... again. I have no idea what's going on. Whether I'm connect straight into the ONT right at the drop, or I'm using the coax in my house the issue persists... I'm thinking maybe an issue with the line from the node to the drop? All techs say this would be super noticeable if there was an issue and don't actually seem to be checking anything in depth - all they do is come by, insert their signal reader into my coax outlet say "oh everything looks good, there's some interference though so I'll submit a maintenance request to have it resolved" then leave.... Maintenance then says nothing is wrong and I'm back at square one. Ugh!
Do you have any idea how to escalate these things?
@Corx congrats on the router purchase. Just to point out, the RT-68U is getting a little long in the tooth now. It only has an 800 Mhz processor. Its replacement, the RT-86U has a 1.8 Ghz processor, and is hardware equipped to handle VPNs, so, if VPN performance such as OpenVPN is important, the 86U might be worth considering. For anyone running gigabit service, my recommendation is to look for a router with a 1.4 or 1.8 Ghz processor or faster. Most routers are dual core, but, the Asus RT-AX88U is apparently a quad core, and from what I've read very briefly, Netgear is coming out with a 2.2 (?) Ghz processor in a router. Don't know if tha's dual or quad core. With gig data rates, the name of the game is processor speed, not only to handle the gig rates, but, more importantly to do that when you have some router function enabled that requires more processing by the router CPU.
Fwiw, the latest Merlin Asus-wrt version was released last weekend. Here's the link to the version thread:
If you're interested in trying out Merlin's Asuswrt, download the RT-68U firmware version, and after logging into the router, run a factory reset. Navigate to the Restore/Save/Upload setting tab and run the Factory Default function with Initialize selected. After the reboot, log in again and navigate to the Administration .... Firmware Upgrade tab and select "Choose File" to navigate to the unzipped upload file, then hit .... "Upload". If you haven't run a factory reset prior to this, the upload will update the router, keeping all of the settings intact. When the upload has finished, run a factory reset and then reset the router from scratch. Don't use a backup file to reload the settings as there are a good many more settings available with Merlin's Asus-wrt version.
Ok, so, its time to return to this and sort this out. Have you made any headway with this since the weekend? The next step is to run a TCP/IP ping test to the DNS and possibly a run with a DNS query that I use in order to check the UDP responses. I'd like to see a Wireshark plot to get a better idea of whats going on, so that is one of the next steps.
In terms of escalating this, my recommendation is to get @RogersAndy involved as he's looking into issues similar to this. @RogersMoin could probably assist in this one as well. Both gentlemen are moderators in the forum.