The CGN3 and CGN3ACR have high, unstable ping times. That is a known problem with the CGN3 and it looks like it has been carried into the CGN3ACR. I was hoping that the last firmware update in Dec 2014 would solve the issue, but unfortunately it hasn't. If you ping the modem a thousand time, you will probably end up with a ping time of 4 to 5 ms with a max ping time around 20 ms. Firmware version 4.2.4.5 has improved the max ping time from 100 ms down to approx 20, but that is still a far from a router ping time of 1 ms or less.
From your description it looks like you have packet losses as well, which points to a Rogers network problem.
Your signal levels and signal to noise ratios are ok, so they should not be the source of any problem.
Can you check the back of the CGN3 and confirm that all connected port LEDs are showing amber which means that the port is connected to the far port at 1 Gb/s. Green indicates that a 100 Mb/s connection is running.
You indicated that the DLINK DAP 1522 is connected as an access point. Is the hardware switch at the back set for "Access Point"? With that setting are you running a wireless network from the 1522 or is it just for wired purposes?
While not changing the SSID name.. in theory DOES allow for not having to change the wireless, etc..
It doesnt always work that well.
I have set up a few enterprise level stuff.. and even in the case of enterprise level AP's.. the handoff DOESNT always work/play nice.
A ) You could give it a try with different names.. and SEE if there is any performance difference. It could be that its fighting for WHICH to connect to at the time, and causing issues.
B) What are the CHANNELS you have set on the CGN3, and your AP? Just making sure of no interfearance there.
All in all.. as most have found.. just some minor ping issues to the ROUTER portion itself... using a 3rd party router overall with the unit in bridge mode, is usually recomended.
For wireless yes... but wired no.
Having a SMALL ping spike is pretty well known with them in gateway mode.. but your talking a 30ms max spike.. not 300 some odd.
I am GUESSING its something more down the line.. weither street, area, or the closest rogers node, etc.
If its CONSISTANTLY enough high, you could try and do some tracert's to it, and find out WHERE it is.
But if its only ocassionaly an then back to normal quickly.. might not get time for the tracert to find it.
Hi s1lva166,
Interesting that you should bring up this topic. Don't know if you were around for yesterdays session with Rogers Internet Product Manager, if not, have a look at the following thread:
http://communityforums.rogers.com/t5/forums/forumtopicpage/board-id/IGNITEAAE/thread-id/3
There are a couple of interesting items in there. One is the following Samknows report for jan-feb, detailing the results of internet testing of Rogers network:
https://www.samknows.com/broadband/uploads/Rogers_Short_Form_Report_Jan_20th_-_Feb_20th_FINAL.pdf
The second is the statment from the Shaw DSL Reports forum which reads:
The Hitron deprioritizes ICMP traffic causing any ICMP echo (ping) testing to be highly inaccurate.
Ookla speed tests (speedtest.net, speed.shaw.ca) use TCP based latency testing. You will noticed those tests show an accurately low latency.
So the ICMP numbers you see are artificially high, the actual latency for TCP data flow is typical 8ms - 12ms for the first Shaw hops. Unfortunately so many things (network performance testing, online gaming) depend on the ICMP latency figures, so even though the TCP latency is nice and low, the poor handling of ICMP (and maybe UDP) traffic needs to be solved.
Shaw engineering is aware and the vendor is working for a firmware resolution.
So, that is an interesting statement. I asked RogersShane about the latency with the modem and this statement and he indicated that he would follow up with Hitron.
This brings up the whole issue of latency testing via Ping (ICMP echo request) versus UDP and TCP testing. If the Hitron does deprioritize ICMP traffic causing ping testing to be highly inaccurate then we need to find another method of obtaining accurate test results until a firmware fix is implemented. The modems might be working perfectly well, but the ping test results might not indicate that. Digging thru a Samknows doc, it would appear that their latency testing is done via UDP packets, instead of ICMP Echo Requests. So, that alone might account for their results versus what we see via ping tests. I'm just starting to figure out the issue of testing via UDP so I don't have any ideas of what might help in terms of running an accurate test. This might be a starting point, which is PsPing. This is available from Microsoft's Technet;
https://technet.microsoft.com/en-us/sysinternals/bb896649.aspx
PsPing is used for latency and bandwidth measurements, so, maybe it might be of some use. Gkitty is probalby the best one here to respond to this, so hopefully he will have a few ideas up his sleeve. If there is a network guru on the forum, please join the discussion. Your knowledge and ideas would be most welcome.
