Got downgraded as of the 13th to 2.0.10.34T6 back to inconsistent speeds again. At least they are towards the higher end currently. Latency also is noticeably higher on servers. Also streams are back to buffering again and dropping resolution.
@Makaveli99 wrote:Rogers dave left and works for another company.
That is not how thing works when people leave jobs.
What do you mean get him back?
@Makaveli99I was being facetious when I posted that question. 
... I41 miss RogersDave.
I would almost argue with that. The CGNM-3552 is a 32 channel modem, capable of supporting gigabit rates without issue. The firmware update in Sept 2016 to resolve the IPV4 ICMP latency showed that the 3552 IPV4 ICMP is pretty good compared to the 4582. Close enough for Government Work, as they say. The question is, what do the rest of the protocols look like given the ongoing updates? Has Intel finally resolved all of the latency issues for all protocols for both IPV4 or IPV6, or, do latency issues still exist in the 3552? I probably won't have a chance to test the modem, looking for latency issues, so, its still an open question.
Granted the Puma 7 is a newer processor and is able to run DOCSIS 3.1. For those reasons, okay, the Puma 7 is a better, newer modem, and, you don't see latency issues with this modem, except for ICMP to the CMTS. That's been a problem since firmware version .27
Running a ping test to the CMTS will result in higher than expected return times. Those times will cycle between a low-high-low-high cycle. This can be seen with Pingplotter or any other plot of the return times. The ping interval time requires a low time in order to see the issue. Pingplotter will also display a false packet loss indication.
1. To see this with hrPing, download hrPing and park the extracted contents somewhere that is handy to navigate to via command line. This is a command line program:
https://www.cfos.de/en/ping/ping.htm
2. Run a trace to anywhere, www.google.com for example. With a modem in Gateway mode, or a modem in Bridge mode with a follow on router, the 2nd IP address is the CMTS.
3. Ping the CMTS with the following hrPing command: hrping -s 10 -n 1000 xxx.xxx.xxx.xxx
Where: -s 10 is the ping interval in milli-seconds. The default is 500 ms.
-n 1000 is the number of pings
xxx.xxx.xxx.xxx is the CMTS address
When that run is complete, read thru the data starting at the top. You will see period of low - high - low - high ping times where the high ping times are actually a series of about 14 high ping times, ranging up to possibly 100 ms. The average ping response time from the CMTS should be in the 8 to 13 ms timeframe.
4. To see the plotted times, run the following command: hrping -s 10 -n 3000 -g xxx.xxx.xxx.xxx
Where: -s 10 is the ping interval in milli-seconds. The default is 500 ms.
-n 1000 is the number of pings
-g invokes the plot command
xxx.xxx.xxx.xxx is the CMTS address
When the plot is running, right click on the plot area and select Time Scale. Set that to 10 or 30 seconds. Then Select average time and set that to 100 ms. That's the lowest averaged time that you can set.
What you will see are regular ping spikes, that are actually comprised of the 14 or so high ping times.
Those high ping times did not exist prior to version .27. Although you can use a ping test to the CMTS to test for packet loss between the modem and CMTS, the presence of the high ping times makes this a useless test for latency issues. To get around that, you have to ping another target, preferably within the Rogers network to keep any ISP border issues and beyond out of the results. So, pick the Domain Name Servers, ie, 64.71.255.204 and 64.71.255.198 for IPV4 testing. I think I was using Fping for IPV6 addresses. It doesn't plot the results so I use Wireshark for the plots. For longer 24 hour tests and beyond I collect the data with Wireshark and use Wireshark to plot the result for ICMP, TCP/IP and UDP.
If you run the same plotted test to 64.71.255.204, you should see the major difference between the CMTS and DNS return times. The DNS return times average 11.4 seconds from West Ottawa with max times that can occasionally range up to the 24 ms mark. There are no extended runs with high ping times.
hrPing's plot capability isn't the greatest, but, its okay for a quick and dirty test run. When you have one plot done, you can swap out the -g command for the -G command, which will keep using the same plot, so you don't have to reset the plot time and average time for every run.
Edit: If you run the DNS ping test for a longer period you may see a shift in the times between low times averaging around the 6 ms mark and a higher time period around averaging around 12 ms. If you extend the number of pings to 5000 or higher, you should see that occur. That's a new observation. Normally the return times stay fairly stable minute to minute.
-
966843 views
-
669 Likes
-
-
