11-29-2023 02:48 AM - last edited on 11-29-2023 08:15 AM by RogersCorey
Recently work was done in my area to "improve the Rogers network" since then I am seeing values of upload much smaller than I have assigned. Shoudl be 50 Mbps and I am getting between 10 and 30 at peak hour (from 6pm to 12am) and around 45 outside.
I have contacted rogers and they can't tell if there's a problem and they sent a technician and investigated but discarded a problem with the area, but the problem persists.
I am getting amazing download (in fact 1900 Mbps) but the upload is unstable and always less than the 50 Mbps that it used to be.
Any help will be appreciated.
I copy the data from Down and upstreams. Do you see anything wrong with the upstream taht may be jsutifying this?
Downstream
|
Channel Bonding Value | ||||||||||||||||||||||||||||||||
6
|
1
|
2
|
3
|
4
|
5
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
29
|
30
|
31
|
32
|
33
|
34
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
603 MHz
|
279 MHz
|
579 MHz
|
585 MHz
|
591 MHz
|
597 MHz
|
609 MHz
|
615 MHz
|
621 MHz
|
633 MHz
|
639 MHz
|
645 MHz
|
651 MHz
|
657 MHz
|
663 MHz
|
669 MHz
|
675 MHz
|
681 MHz
|
687 MHz
|
693 MHz
|
699 MHz
|
705 MHz
|
711 MHz
|
717 MHz
|
723 MHz
|
825 MHz
|
831 MHz
|
837 MHz
|
843 MHz
|
849 MHz
|
855 MHz
|
861 MHz
|
350000000
|
216000000
|
41.0 dB
|
40.0 dB
|
41.6 dB
|
41.6 dB
|
41.6 dB
|
41.5 dB
|
41.1 dB
|
40.9 dB
|
40.7 dB
|
40.6 dB
|
40.7 dB
|
40.6 dB
|
40.8 dB
|
41.1 dB
|
41.3 dB
|
41.3 dB
|
40.8 dB
|
41.5 dB
|
41.5 dB
|
41.5 dB
|
41.9 dB
|
41.6 dB
|
41.6 dB
|
41.5 dB
|
41.6 dB
|
41.6 dB
|
41.6 dB
|
41.6 dB
|
41.6 dB
|
41.6 dB
|
41.6 dB
|
41.5 dB
|
38.8 dB
|
39.4 dB
|
4.6 dBmV
|
0.5 dBmV
|
5.3 dBmV
|
5.3 dBmV
|
5.4 dBmV
|
5.3 dBmV
|
4.5 dBmV
|
4.3 dBmV
|
3.9 dBmV
|
3.8 dBmV
|
3.8 dBmV
|
4.1 dBmV
|
4.2 dBmV
|
4.7 dBmV
|
4.7 dBmV
|
4.8 dBmV
|
4.9 dBmV
|
5.4 dBmV
|
5.4 dBmV
|
5.3 dBmV
|
6.0 dBmV
|
5.7 dBmV
|
5.5 dBmV
|
5.5 dBmV
|
5.5 dBmV
|
5.9 dBmV
|
6.1 dBmV
|
6.0 dBmV
|
6.1 dBmV
|
5.7 dBmV
|
5.6 dBmV
|
5.6 dBmV
|
0.5 dBmV
|
0.0 dBmV
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
256 QAM
|
OFDM
|
OFDM
|
Upstream
|
Channel Bonding Value | |||
1
|
2
|
3
|
4
|
10
|
Locked
|
Locked
|
Locked
|
Locked
|
Locked
|
21 MHz
|
25 MHz
|
32 MHz
|
38 MHz
|
4 MHz
|
2560
|
5120
|
5120
|
5120
|
0
|
44.8 dBmV
|
46.0 dBmV
|
46.5 dBmV
|
47.8 dBmV
|
43.7 dBmV
|
QAM
|
QAM
|
QAM
|
QAM
|
OFDMA
|
TDMA_AND_ATDMA
|
ATDMA
|
ATDMA
|
ATDMA
|
TDMA
|
***EDITED LABELS***
11-29-2023 10:07 AM - edited 11-29-2023 10:27 AM
@Qubit Your signal levels look fine.
Your downstream channel configuration has OFDM channels at 216 and 350 MHz. I only have one at 350. This isn't necessarily bad; just that the network team seems to be testing a different configuration in your area.
Upstream, looks like they are trying to get an OFDMA channel working at 4MHz. Don't know why. That can be a very noisy (and traditionally unusable) part of the spectrum, unless your cable plant is very clean. I would have expected them to be using 42 MHz. However, if that channel is unstable, it could cause the modem to drop off the network, or pause forwarding packets until all channels in the upstream bonding group come up.
As for the upload speeds that you are seeing, I'm still wondering what's going on at a protocol level. With TCP/IP, if you are transferring data and data packets get lost, your computer does not know why; it could be that the computer system at the other end of the connection is overloaded or it could be that that network is congested. Either way, the worst thing that it can do is to keep sending data as fast as it can... so the protocol stack backs off, sends data at a lower pace, then ramps up and keeps ramping up until it detects that it is sending data as fast as it sustainably can. The question is, what is happening at a network level that is causing your system to back off and send data at only 10 Mbps?
At the network level, Rogers is also doing rate limiting. From your computer's perspective (the one that is getting 1900 Mbps down), it has a 2.5 Gigabit Ethernet adapter (or faster). It wants to transmit at that speed but the network will only allow it to send data at 50 Mbps. Your computer also needs to "back off" when other computers in your home start sending data so that you share bandwidth fairly and effectively. If you have a laptop with Wi-Fi, you can move it a few feet and its network link could suddenly have only a fraction of the amount of bandwidth available that it had a moment ago.
My point is that computers, routinely, need to be able to adapt to changing network conditions without knowing why they changing, and they do their best to adapt in the most appropriate way. If the underlying network does not behave predictably, your computer may not send data at the full speed that it theoretically could.
With speed tests, keep in mind that depending on network conditions, the speed test may not always be able to measure the upload speed correctly, especially if congestion controls kicks in and your send rate does not ramp up to full speed before the speed test completes.
11-29-2023 02:04 PM
11-29-2023 03:19 PM - edited 11-29-2023 03:21 PM
@Qubit if that is what you're observing, traffic congestion during evening hours and you're back to 50 Mb/s at 3:00 am when the rest of the world is sleeping, you're dealing with a congestion issue, either at the neighbourhood node, the Cable Modem Termination System (CMTS) or both.
If you knew the load levels at the neighbourhood node and CMTS, you would understand in a heartbeat, what the problem is. Unfortunately, Rogers doesn't release that data. What you really need to know are the loads at various times, such as the evening hours. That would explain the poor performance during the evening hours. If history is any indication, you would probably see a continual ramp up until about 11 pm, and then a ramp down, reaching a minimum around 3 to 4 am. I have no doubt that Rogers has that load data for all of its neighbourhood nodes and CMTS equipment, either on a minute to minute basis, or perhaps every 5 minutes, at a minimum. Its very unfortunate that Rogers isn't forthcoming about those loads, and their affect on both downstream and upstream data rates.
Next time that you call tech support, ask to speak with a Level II tech regarding the loads on the neighbourhood node and CMTS, given the poor performance that you're seeing. You might be able to get an answer out of the Level II tech. And, next time that a field tech visits, ask him or her for the current load on the neighbourhood node. The tech should be able to access that data. Fwiw, beyond telling you what the current load happens to be, the tech really can't do anything for you in terms of resolving a neighbourhood node load issue. That's a network design issue that Rogers has to solve.
Fwiw, as @-G- pointed out, according to a Rogers filing with the CRTC, it would appear that Docsis 3.0 modems and below will be discontinued as of Dec 31st, 2023. So, if thats the actual plan, that frees up a considerable amount of bandwidth in the cable system that can be put to use for both downstream and upstream OFDM channels. Rogers is remaining silent on their intentions, but, perhaps, if that is the plan, then customers will start to see better performance after the new year. One can always hope.
11-29-2023 04:49 PM - edited 11-29-2023 04:50 PM
@Qubit wrote:
I am frankly not sure if I should pursue this route as I see that technicians come and don’t really do anything if the signal levels are good (which seems to be the case based on my router data)
I guess what I wonder is if the problem could be in my local connection (some sort of noise in the upstream channels) considering that it happens at rush hour and it works outside it?
Below your Downstream and Upstream stats, there is a "CM Error Codewords" stats table. Ideally, the "Uncorrectable Codewords" stats should be all zeros across all channels. (Don't panic if you see a huge number of uncorrectables, especially if you have not rebooted your gateway in a while. My uncorrectable errors can be all-zeros for a week, then I sometimes see a ton of errors in the morning. I think this is indicative of Rogers doing work overnight.).
If you have a large number of uncorrectable errors, I would reboot the gateway to clear the stats. If the uncorrectable counts start to climb immediately, especially on the OFDM channels, and climb at a fairly rapid rate, that is not good. Any uncorrectable errors represents packet loss, and it is also indicative that either your line or the cable plant serving your area has problems (noise?) that need to be investigated. Only Rogers can see what the error stats look like on the upstream channels.
11-30-2023 09:26 AM - edited 11-30-2023 09:26 AM
This is very helpful and informative. Thanks @Datalink and @-G-
I rebooted midday yesterday and now I got this
Channel IDUnerrored CodewordsCorrectable CodewordsUncorrectable Codewords
CM Error Codewords | |||||||||||||||||||||||||||||||||
6 | 1 | 2 | 3 | 4 | 5 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 |
457875035 | 704581910 | 704588409 | 704593456 | 704597725 | 704602851 | 704609058 | 704614276 | 704619499 | 704624356 | 704630620 | 704636464 | 704641685 | 704646185 | 704652590 | 704656670 | 704661941 | 704667319 | 704671928 | 704676777 | 704681329 | 704686448 | 704692367 | 704695917 | 704702171 | 704707053 | 704711807 | 704717337 | 704721888 | 704727237 | 704728666 | 704727817 | 593804276 | 457875035 |
390207094 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 587887924 | 390207094 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Which probably is good news and this is indeed a congestion issue. It does bother me that no CS representative or the escalation to investigate could figure anything out about it or check the neighbourhood load. Perhaps it's also taht they didn't check ti at the right time.
I was wondering too, is there any idea out there of when they're going to give more symmetric speeds over DOCSIS 3.1 or even implement DOCSIS 4 at all? perhaps that could be the beginning of the solution of the problems as they would likely need to update the nodes.
11-30-2023 09:57 AM - edited 11-30-2023 10:01 AM
I don't believe that the Level I techs, that you talk to via telephone, have access to that data. So, in a normal conversation, trouble shooting, this wouldn't come up during that conversation. You need to escalate the situation to a Level II tech. And that might be just a simple request to the Level I tech to talk to a Level II tech about the loads at the neighbouhood node and CMTS.
The problem is, that as customers, we need to understand that there is more to this than good signal levels. If your signal levels are very good, and your data rates come to a crawl when the kids arrive home from school and in the evening hours, and then return to normal during the very early morning hours, then you're looking at network congestion. Ergo, the question about the loads at the neighbourhood node and CMTS. Typically, one would never think to ask the question as you have to be somewhat aware of the network architecture, aware of the possibility of congestion at the neighbourhood node and CMTS and know enough to even ask a question regarding data loads. I suspect that in most cases, the issue is at the neighbourhood node, but, I could be wrong.
In an updated filing to the CRTC, dated 1 Nov 2023, Rogers proposed increased speeds for TPIAs. From that filing comes the following, original data rates on the left, proposed changes on the right:
1Mbps Upstream (U) / 5 Mbps Downstream (D) (Ontario only);
1MbpsU / 10MbpsD (Ontario only);
5MbpsU / 30MbpsD (Ontario only);
10MbpsU / 50MbpsD, 50MbpsU / 50MbpsD (Ontario, where available)
30MbpsU / 75MbpsD;
30MbpsU / 100Mbps (Ontario only);
30MbpsU / 150MbpsD, 150MbpsU / 150MbpsD (Ontario, where available)
30MbpsU / 300MbpsD (Ontario only);
30MbpsU / 500MbpsD, 150MbpsU / 500MbpsD (Ontario, where available)
50MbpsU / 1024MbpsD,
50MbpsU / 1500MbpsD (Ontario only), 150MbpsU / 1500MbpsD (Ontario, where available)
It will be interesting to see what the TPIAs do with this, given their wholesale costs. The interesting point is that Rogers has filed to increase the TPIA upload rates to 150 Mb/s, which brings about the question, what about Rogers own customers? I haven't seen anything regarding upload data rate increases for Rogers customers.