@lethalsniper wrote:
had 2 timeouts
Ping statistics for 64.71.255.204:
Packets: Sent = 3600, Received = 3598, Lost = 2 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 74ms, Average = 10ms
That's actually not bad compared to what I typically see.
pinging the CMTS
Ping statistics for 99.x.x.x:
Packets: Sent = 1000, Received = 1000, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 105ms, Average = 13ms
I see the same: pings to the CMTS router taking longer than pinging a host across the Internet. This because the local node seems to be the primary contributor to the excessive latency and jitter that we are seeing. It also shows that the CMTS router is busy doing something, and that this is also slowing its response time to processing ICMP Echo requests, and that the processor load is likely contributing to "micro-freezes" where the local node briefly stops forwarding packets and causing/introducing the latency spikes that we see.
You can also get additional insights by running separate simultaneous ping tests to your local CMTS and to an Internet host of your choice. Most likely, you will see similar response times with the CMTS router taking a few extra milliseconds to respond.
@lethalsniper wrote:
I do t see any timeouts on your test
I don't see as much packet loss as others have because I suspect that my local node is not as heavily loaded as others' may be. However, I have seen it happen under some circumstances where packet forwarding in my local node freezes for longer periods of time, which causes more network traffic to back up beyond the node's ability to buffer it.
I am also performing my ping tests on Linux, not Windows. I have seen RTTs to my local CMTS router exceeding 12000 milliseconds (yes, > 12 seconds) in the past. On Windows, I think that this would have been reported as a sequence of successive timeouts during the ping test and lost packets in the final stats.
@AngryChicken you need to talk to a Tier II tech, specifically about the data throughput load at your neighbourhood node and the Cable Modem Termination System that you're connected to. The tech probably won't tell you the total capacity of either one, as in Hundreds of gigabits for the neighbourhood node and tens of terrabits for the CMTS, but, he or she should be able to tell you the percentage of max load that each is running and their historical loads over some previous amount of time. The moderators should be able to do the same !! Talking with a Tier I tech for this situation is a waste of time, and as you say, the field tech will wiggle the thingamajig in hopes of keeping you happy and stupid. That's a complete waste of money by Rogers for which their shareholders should be taking them to task. The truck roll costs have to add up to a rather huge amount of money for absolutely no gain. Instead, a little honesty from Rogers would go a long way these days to keep customers reasonably satisfied with the info that they receive. All personal opinion of course.
@AngryChicken the problem is that the Tier I & II techs serve as a barrier between the customers and the engineering staff. This includes the moderators here in the forum. No disrespect to the moderators, but, any one of them should be able to pick up the phone, or send an email to the network engineering staff referencing a specific oddball problem that has arisen. This is a customer to customer forum, not a customer to engineer forum or vice versa. At a point in time in the past, @RogersDave who has left Rogers for Hitron, would spend time in the forum, when possible to, address latency issues with the Puma 6 modems. I've said this in the past, and I'll say it again, this forum needs engineering support to address issues that arise from time to time. That doesn't necessarily mean full time support, which from a manpower perspective would be very expensive, but at least on a weekly or bi-weekly basis. Keeping an ear to the ground, so to speak, is a dirt cheap way for the engineering staff to pick up on issues that arise that happen to be beyond Tier I or II techs. As an example, there is an ongoing issue with the XB6 modems and Ubiquiti routers which is resulting in unpredictable, slow, data rate problems. That's well beyond Tier I and II techs. Its going to take a Rogers network engineer and a few data captures to possibly point out the issue to Intel or Broadcom. So who calls the engineering staff??? Not the Tier I or II techs. Hello moderators ....... over to you, and the engineering staff.
So, communications to and from the engineering staff is a definite problem. They don't always get it right on a product launch so there has to be some method to elevate issues that weren't seen in pre-launch testing.
Network issues, as you're experiencing have been on the go since January, and the current Covid 19 situation is just making that worse that it already was. This is an engineering issue, and no amount of truck rolls is going to solve what appears to be a huge problem for a number of customers. Its very unfortunate that Rogers chooses to remain radio silent on the real cause of the slow data rates, packet loss and latency. Covid 19 is an excuse, not the real reason, which started in January. Yes, data throughput has increased by more than 50%, so, ok, what was going on before that 50% increase came along?
Just to point out, some customers these days such as yourself and others are professional IT staff, so, you're considerably more knowledgeable than most of the tech staff. The usual Tier I routine of unplug or reboot your modem just doesn't cut it, it never will. Again, the problem here is the lack of a communication path up to the network engineering staff. Yes, you're a customer .... but, one that can most likely provide a great deal of experience and knowledge in troubleshooting network issues.
Part of the problem in addressing what you're experiencing is the lack of data that adequately documents all protocols, ICMP, TCP/IP and UDP. Personal opinion, an ICMP ping test doesn't cut it. Don't think anyone else is going to do this, so, its time to address the issue with Wireshark plots and text data files where applicable. Providing evidence of very poor response times to the CMTS and Rogers DNS for all protocols will hopefully raise the visibility of problems at the CMTS and beyond. Working on it .... its a work in progress.
Fwiw ......
This is a good example of what I was pointing to. You shouldn't have to go down the route of Sharing a Concern, or going to the Office of the President to start resolving a technical problem when there are staff present in the forum who can get the ball rolling. All it takes is to simply pass along a message to the relevant technical staff member. That's either a phone call, message or email.
https://communityforums.rogers.com/t5/Internet/Unable-to-Receive-Emails-on-Outlook/m-p/461578#M61093
I'll still wager that the Rogers Network Team needed to make a significant configuration change, the vendor(s) probably told them that it should work fine, it didn't, and now Rogers is committed and cannot revert back.
This is all pure speculation on my part.
@super_robot please remember I'm just another customer, same as you. Don't work for Rogers, never have, never will. Trust me, Rogers wouldn't want me working for them.
-
209339 views
-
156 Likes
-
-
