Yes, there are a good number of Bell fibre customers who have noted latency to the U.S. East Coast.
https://www.dslreports.com/forum/r32655473-Lag-packet-loss-issue-to-AWS-us-east-1-VIRGINIA
@herrshaun I absolutely disagree with that statement. That is not what I've seen in all the time that I've chatted back and forth with the engineering staff. Unfortunately, these days, it seems that after @RogersDave departed Rogers, the remaining engineers on staff are far less inclined to converse directly thru the forum. No doubt they are busy, but, keeping one's ear to the ground, so to speak, is a very efficient way to determine what problems exist so that an on the ball engineer can resolve the problems, simultaneously, for a number of users. Please do not take that comment from the chat agent as a true indication of the attitudes of the engineering staff. Full disclosure, I don't work for Rogers, never have and probably never will.
Personal opinion, there's something going on with the Rogers infrastructure around the GTA that is causing major congestion, maybe its a DDOS issue, maybe its network configuration issues, or just plain growing amounts of traffic, don't know. Whatever it is, Rogers is keeping silent about the problems, leaving the lower level tech staff to deal with a problem that they probably can't solve and unhappy customers as a result.
@herrshaun I agree with you. Troubleshooting a congestion issue several hours later will no doubt lead to a "nothing seen, sank same", type of response. That's very predictable. It should be very easy however to look at the historical load numbers for the neighbourhood node, CMTS and follow on servers to see where congestion problems might have been present. I think that not looking at that historical data is being wilfully blind to the problem. I also find it hard to believe that the Network Operations Center staff wouldn't have the ability to look at load data in real time and do something about it. I only wish that I had a better insight into how Rogers manages traffic. I really wish that there was more contact within the forum with the engineering staff and the network operations staff. That would go a long way in sorting out some of these issues. This nightly congestion problem that appears to have arisen over the last month needs to go well beyond the moderators and field techs who have limited tools and limited authorization to address the issues.
@AHxCode your signal levels look much better. Looking at the before and after numbers, I would guess that the tech installed a signal attenuator on the modem. If you look at the back of the modem, do you now have a signal attenuator which looks like the following:
https://www.antronix.com/products/other/attenuators.aspx
If so you should see a number on the attenuator barrel, most likely a "12" as in a 12 db attenuator. Can you let me know if the tech installed an attenuator and if so, what number is on the barrel of it. If not, did the tech indicate how he reduced the signal levels?
You indicated that you have a temporary line to your apartment. Are you in a small apartment block or perhaps an apartment in a house? Just trying to figure out the details.
Downstream Overview Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID Signal noise ratio (dB)
1 609000000 256QAM 4.700 10 40.946
2 603000000 256QAM 5.100 9 40.366
3 597000000 256QAM 5.200 8 40.366
4 615000000 256QAM 4.300 11 40.366
5 303000000 256QAM 3.000 1 40.366
6 579000000 256QAM 4.500 5 40.366
7 585000000 256QAM 4.800 6 40.366
8 591000000 256QAM 5.100 7 40.946
9 621000000 256QAM 4.200 12 40.366
10 633000000 256QAM 3.800 13 40.366
11 639000000 256QAM 3.900 14 40.366
12 645000000 256QAM 4.200 15 40.366
13 651000000 256QAM 4.500 16 40.946
14 657000000 256QAM 4.300 17 40.366
15 663000000 256QAM 4.300 18 40.366
16 669000000 256QAM 3.900 19 40.366
17 675000000 256QAM 3.700 20 40.946
18 681000000 256QAM 3.400 21 40.366
19 687000000 256QAM 3.300 22 40.366
20 693000000 256QAM 3.800 23 40.366
21 699000000 256QAM 4.000 24 40.366
22 705000000 256QAM 4.100 25 40.946
23 711000000 256QAM 4.400 26 40.366
24 717000000 256QAM 3.600 27 40.366
25 723000000 256QAM 3.400 28 40.946
26 825000000 256QAM 4.800 29 40.366
27 831000000 256QAM 5.400 30 40.366
28 837000000 256QAM 5.000 31 40.366
29 843000000 256QAM 4.400 32 40.366
30 849000000 256QAM 4.700 2 38.983
31 855000000 256QAM 4.600 3 38.983
32 861000000 256QAM 4.400 4 40.366
OFDM Downstream Overview Receiver FFT type Subcarr 0 Frequency(MHz) PLC locked NCP locked MDC1 locked PLC power(dBmv)
0 NA NA NO NO NO NA
1 4K 290600000 YES YES YES 4.800003
Upstream Overview Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID Bandwidth
1 36996000 ATDMA - 64QAM 37.000 4 6400000
2 22100000 ATDMA - 64QAM 38.750 1 3200000
3 30596000 ATDMA - 64QAM 37.000 3 6400000
4 25300000 ATDMA - 64QAM 39.000 2 3200000
OFDM/OFDMA Overview Channel Index State lin Digital Att Digital Att BW (sc's*fft) Report Power Report Power1_6 FFT Size
0 DISABLED 0.5000 0.0000 0.0000 -inf -1.0000 4K
1 DISABLED 0.5000 0.0000 0.0000 -inf -1.0000 4K
@AHxCode ok, that makes sense now. You're so close to the neighbourhood node that you can't avoid having high signal levels. It is what it is, so signal attenuators are the way to go. Here's the attenuators:
For now you could run a ping test to the CMTS, looking for any packet loss. Given that you're so close to the neighbourhood node, you shouldn't see any packet loss, but, I'd run a minimal test just to see what turns up.
To do this, bring up a command prompt. Type in:
tracert -4 www.google.com This run an IPV4 trace to google
Assuming that you have the modem in Gateway mode with a direct ethernet connection to the modem, the first IP address in the trace is the modem, the second IP address is the Cable Modem Termination System (CMTS). The path in this case is:
PC -> modem -> splitter -> local tap -> neighbourhood node -> CMTS
The path from the pc to the neighbourhood node is copper cable, the path from the neighbourhood node to CMTS is fibre. In theory you shouldn't see any packet loss in either path or from the CMTS itself in high load periods. But the only way to determine that is to run a ping test to the CMTS. So, take the second IP address and use that for a ping target:
ping -n 3600 xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is that second IP address.
That test will run for one hour. At the end of the hour, to copy the bottom results, right click on the top title bar of the command box, select Edit .... Select All. Then right click on the top title bar again and select Edit .... Copy. Then paste that into a text editor so that you can copy just the bottom results, and then paste than into a message. For now thats the starting point, a limited test to the CMTS. The next test will be a limited test to the Rogers primary IPV4 DNS at 64.71.255.204
ping -n 64.71.255.204 That is a one hour test to the primary IPV4 DNS
Same as before, please post the bottom test results.
-
211137 views
-
156 Likes
-
-
