- last edited on by
RogersMoin
One of the questions that arose out of the deployment of V4.5.8.27 to the test group of CGN3ACSMRs is "does it work?" In a nutshell, yes. But, to really appreciate the difference from before to after you would have to run an extended ping test to the CMTS to see the result. Fortunately @RogersDave as allowed me to do that during the firmware development. The images below show that difference, from earlier this summer when the CGNM-3552s were introduced to now where v4.5.8.27 is loading onto the trial CGN3ACSMRs.
The one thing that everyone should keep in mind is that this latency reduction is only for IPV4 ICMP. IPV6 ICMP has not changed, nor has TCP/IP and UDP for both IPV4 and IPV6. So, latency will still be observed in applications that use those protocols. That will inevitably lead to an IPV4 ping test which uses ICMP and which will not display the same latency seen in the application. So, there is a possibility of confusion due to the conflicting indications and data. At this point, users will have to keep the differences in mind between IPV4 ICMP and any other protocol that is in use. This is just the start, and that baring any unforeseen obstacles during development, the other protocols will follow, hopefully not very far behind.
From what I've seen in other forums, Rogers is the first ISP, anywhere, to release firmware aimed at resolving the latency thru a Puma 6/6MG modem. As I hav e indicated previously, the latency is not a "Rogers" or "Hitron" problem. This is a problem caused by the Puma 6/6MGs method of processing the data packets thru a CPU software based process. The plots below this show the result of using the Puma's Hardware Processor instead. The Puma 6/6MG chipset is used by other modem manufacturers and numerous ISPs in Canada, the U.S. and Europe so the issue of latency that many gamers on this forum are complaining about are also seen on many other systems. The difference in this case is that the Rogers engineering staff is well aware of the issue and working with Hitron to develop firmware to eliminate that latency. Users with other ISPs are still at the point where they realize that there is a problem but, can't get any traction on the issue from their ISP, "all is well", "yup, it looks good in our system". The ISPs blame the user equipment and the modem manufactures blame the ISPs and basically indicate that they have no control over external data beyond the modem, "Not our problem".
So at the present time the Hitron modems used by Rogers aren't there yet, but, with @RogersDave leading the charge at this time, Rogers is well ahead of any other ISP. There has been a lot of work done to get this far, but there is still much to do.
Looking at the following charts, you will notice the actual response time from the CMTS. In the top chart that response time is buried in the ping times of the modem. Strip out that modem ping time and you can see what the CMTS does throughout the day. There are peaks (very few) up into the 100ms range but that only occurs during higher load times. That can be seen on the Friday 23 Sept charts with higher loads around 3:30pm, when the neighborhood kids arrive home from school and during the evening hours. The average ping times usually remain in a 10 to 14 ms range to the CMTS.
Ok, without further ado....
The "before" picture from earlier this summer from a CGNM-3552 to its connected CMTS and back again. The firmware versions are listed on the chart.
Chart one from my image library is a 12 hour run, with 30 second ping intervals. This is from an IPV6 test from the 29th of June with V4.5.8.22 loaded on my CGNM-3552. Note that it does not make any difference whether you test with IPV4 or IPV6. The end result is basically the same. As this run was set for 30 second ping intervals, there are fewer high ping times displayed, compared to plots takes with pingplotters default interval of 2.5 seconds. Note the average ping time of 20 ms. This has been seen to vary between 20 to 30 ms.
The" after" picture running V4.5.8.25 in September which has been rolled into V4.5.8.27. This is plotted with Excel as Pingplotter has incorporated a bug that prevents proper display its own data taken over several hours. The black indicates a 1 min moving average. This is also a 2:30 am to 2:30 pm run, as shown above, scaled to the same scale as above for comparison purposes. In this case the test is an IPV4 test to the CMTS with a ping interval of 2.5 seconds, so, there is a greater amount of data compared to the chart above.
This is a close up of the same timeframe:
This shows an all day, 24 hour run from Friday Sept 23rd 2016. The interesting item to notice are the high load times around 3:30 pm (end of school day) and during the evening.
Lastly the closeup of the same day:
Okay, thats it for now. Hopefully I'll be able to show similar results for TCP/IP tests when Hitron has completed further development work.
*Edited Labels*
Hello, @Datalink
Awesome! Thank you for sharing your analysis and expertise with the Community. I appreciate all the hard work in producing the before and after charts. It's great to see the IPV4 ICMP latency reduction with .27 firmware. I extend my gratitude on behalf of the Community to @RogersDave as well for all the great work.
Cheers,
RogersMoin
@lvectorA at some point @RogersDave will make a decision to roll .27 out network wide to the CGN3ACSMRs. There is still some paperwork to finish up from what I understand, so, at the moment, it is only being pushed out to the trial CGN3ACSMRs, followed possibly by the trial CGN3ACRs and CGN3AMRs. I think it will depend on how fast Hitron can make the changes they have been asked to make and how long it might take to roll out .27. Perhaps the next version will be ready to roll sooner rather than later, so, maybe the successor to .27 will roll out network wide instead of .27. This is speculation on my part but keep in mind that there are several time factors involved in determining which version hits the network and when that happens.
@User7354 please read thru the first post in this thread as it will most likely explain what you are seeing with pingplotter. When you run pingplotter, right click on the column title area and select MAX to bring up the MAX Ping time column. Drag that column to the right to sit next to the min column. With that set up, you can tell at a glance what the max ping times are.
Your friend must be using DSL for his internet service. Nice ping numbers!!
When you have pingplotter up and running, right click on the hop #2 address and select Copy IP Address. Then pause pingplotter, paste that address into the address bar and hit go. In that configuration you will be watching the return from the CMTS, which will show any packet loss and the latency thru the modem. That will clearly show how the modem data processing causes the ping spikes that you are seeing.
That depends on where you are. If you have access to fibre, then you might want to consider that. If you're like the thousands of others who don't live in Toronto, aka, Bell's Fibreland, you're stuck with 5 mb/s down 800kb/s up. That has been discussed at length in another forum.
There are issues that have come up with slow speeds seen on gigabit installs, which are rather perplexing to say the least. My advice in that case is to run a factory reset, and check the signal levels, then get tech support involved to determine if there is any obvious reason for the slow service.
-
13893 views
-
8 Likes
-
-
