Menu
Reply
  • 11
  • 0
  • 1
Cyirak
On our wavelength
719 Views
Message 1 of 16
Flag for a moderator

Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10

Over the past 2 weeks I've been getting inconsistent speed in area 20 Bh10. First thing in the morning like now 7am I will achieve 390 down 37mb up. After work so 6pm on wards and on and off over the weekends I'll achieve speeds of 40-80mb down, upload speed seems unaffected. The other concern is that I'm experiencing spikes in latency randomly which haven't occurred previously, again only at peek times. A friend down the road has experienced similar issues recently (about 1 mile away) has anyone else experienced this? Id be surprised if there's a fault on my line as its working fine off peek.

0 Kudos
Reply
  • 11
  • 0
  • 1
Cyirak
On our wavelength
706 Views
Message 2 of 16
Flag for a moderator

Re: Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10

Just to add some additional detail;

 

I have tried rebooting the SH3, Currently set in Modem Mode. 

Tests are all done over ethernet;

Network status of router is as follows;

Downstream bonded channels

Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID

1298750000035256 qam21
21387500001.738256 qam1
31467500001.540256 qam2
41547500001.540256 qam3
51627500001.540256 qam4
61707500001.540256 qam5
71787500001.240256 qam6
81867500001.240256 qam7
91947500001.240256 qam8
10202750000140256 qam9
112107500000.740256 qam10
122187500000.740256 qam11
132267500000.740256 qam12
142347500000.240256 qam13
15242750000040256 qam14
16250750000040256 qam15
17258750000-0.240256 qam16
18266750000-0.238256 qam17
19274750000-0.238256 qam18
20282750000038256 qam19
21290750000037256 qam20
22306750000034256 qam22
233147500000.235256 qam23
243227500000.536256 qam24



Downstream bonded channels

Channel Locked Status RxMER (dB) Pre RS Errors Post RS Errors

1Locked35.7104870870
2Locked38.947228823227325
3Locked40.311966841992993
4Locked40.321270162067021
5Locked40.349812232341644
6Locked40.36829341254519
7Locked40.947892491011034
8Locked40.9793131173302
9Locked40.32288673759
10Locked40.31845793566
11Locked40.31549721374
12Locked40.3117120673
13Locked40.31352071206
14Locked40.31401352775
15Locked40.31058411054
16Locked40.379225383
17Locked40.380538479
18Locked38.91441542086
19Locked38.91084411143
20Locked38.674857265
21Locked37.661663255
22Locked34.673444456
23Locked354427472
24Locked36.33287229

 

Upstream bonded channels

Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID

1462000634.9512064 qam3
2603000004.85512064 qam1
3537000004.9512064 qam2
4394000004.9512064 qam4



Upstream bonded channels

Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

1ATDMA0000
2ATDMA0000
3ATDMA0000
4ATDMA0000

 

 

Logs are also filled with the following;

12/09/2019 20:50:5

Warning!

Lost MDD Timeout;CM-MAC=*************;CMTS-MAC=*************;CM-QOS=1.1;CM-VER=3.0;

12/09/2019 20:50:5

Warning!

RCS Partial Service;CM-MAC=*************;CMTS-MAC=**************;CM-QOS=1.1;CM-VER=3.0;

 

0 Kudos
Reply
  • 1.75K
  • 250
  • 703
Andruser
Super solver
691 Views
Message 3 of 16
Flag for a moderator

Re: Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10

The SNR figures look within spec, the real issue is all those errors on channels 2 through 8 (for comparison my Hub 3 shows 20-80 pre-RS errors on each channel, but zero post-RS errors on all channels).  Each post-RS error will be a bad data packet, and the PC will re-request the data, which takes time and slows down your connection.  Assuming there's no area problem that'll require a VM technician to sort it out.  

Wait for the forum staff to take a look, they should be able to book a visit for you, or clarify what's happening with any area problem.  Note that for a few area problems, VM have set a "review date" which comes and goes with no change or action other than they set a new review date a month or two later so that customers believe something is being done.  But worry about that if it gets to that stage.

  • 11
  • 0
  • 1
Cyirak
On our wavelength
666 Views
Message 4 of 16
Flag for a moderator

Re: Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10


@Andruser wrote:

The SNR figures look within spec, the real issue is all those errors on channels 2 through 8 (for comparison my Hub 3 shows 20-80 pre-RS errors on each channel, but zero post-RS errors on all channels).  Each post-RS error will be a bad data packet, and the PC will re-request the data, which takes time and slows down your connection.  Assuming there's no area problem that'll require a VM technician to sort it out.  

Wait for the forum staff to take a look, they should be able to book a visit for you, or clarify what's happening with any area problem.  Note that for a few area problems, VM have set a "review date" which comes and goes with no change or action other than they set a new review date a month or two later so that customers believe something is being done.  But worry about that if it gets to that stage.


Hi Andruser,

Thanks for that. I thought the SNR was in spec just seems odd that the problem occurs typically round peak times which made me think it was congestion or over subscription. Honestly, i hadnt noticed those numbers until you pointed them out. Fingers crossed i can get this resolved quickly, previous to this my broadband has been on point.

0 Kudos
Reply
  • 1.75K
  • 250
  • 703
Andruser
Super solver
662 Views
Message 5 of 16
Flag for a moderator

Re: Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10

Well, speculating way beyond my actual knowledge, I wonder if the hub is reacting to the errors by putting more load on the other channels.  As the fewer channels a hub uses, the more prone they seem to be to congestion effects, one of VM's main strategies for addressing time-of-use network congestion was to replace the older hubs with the Hub3 for the simple reason that it used more channels.  So that might explain the correlation between the effect you're seeing, and the data from the hub.

Or it could be complete cobblers invented by my febrile imagination!

  • 11.8K
  • 1.08K
  • 2.56K
griffin
Alessandro Volta
643 Views
Message 6 of 16
Flag for a moderator

Re: Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10

The number of RS Errors don't really mean much it is the rate of rise of the errors that would indicate an error, so they could be a gradual build up over time, which might not affect performance. RS errors need to be put in a time frame, so clearing the RS errors may help, and just keep an eye on.

Noise tends to be very bursty in nature, so it is normal for the SNR to be in spec unless you actually managed to catch the SNR during a noise burst.

Unfortunately the logs cover only a very short period of time, so no correlation can be gained there.

I would start a Broadband Quality Monitor get a more detailed picture on how you connection is performing and if contention  is an issue, assuming you are not hammering your connection or saturating your upstream.

BTW Anduser is quite right, he is speculating way beyond his knowledge.Smiley Happy

 

  • 11
  • 0
  • 1
Cyirak
On our wavelength
624 Views
Message 7 of 16
Flag for a moderator

Re: Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10


@griffin wrote:

The number of RS Errors don't really mean much it is the rate of rise of the errors that would indicate an error, so they could be a gradual build up over time, which might not affect performance. RS errors need to be put in a time frame, so clearing the RS errors may help, and just keep an eye on.

Noise tends to be very bursty in nature, so it is normal for the SNR to be in spec unless you actually managed to catch the SNR during a noise burst.

Unfortunately the logs cover only a very short period of time, so no correlation can be gained there.

I would start a Broadband Quality Monitor get a more detailed picture on how you connection is performing and if contention  is an issue, assuming you are not hammering your connection or saturating your upstream.

BTW Anduser is quite right, he is speculating way beyond his knowledge.Smiley Happy

 


So i monitor my connection with F8lure 

You can see the random packet loss at odd times. the numbers in the stats were after 4 days. 

 

The stats were taken when the connection was working as i'd expect, i'll take a look next time i get low speeds and see.

0 Kudos
Reply
  • 11.8K
  • 1.08K
  • 2.56K
griffin
Alessandro Volta
612 Views
Message 8 of 16
Flag for a moderator

Re: Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10

I have just realised you have posted only an extract of the logs. Unfortunately, snippets do not add much value as the logs need to be seen in their entirety to get the full picture.

The f8lure is generally fine, apart from the intermittent packet loss and the glimp at the start of the graph and a latency spike at there end which maybe correlating when people are getting back from work logging on to the network.

Whilst there is evidence of intermittent noise on your local circuit, but nothing obvious to explain prolonged loss of speed, VM will need to confirm though.

EDIT.

Just seen that the F8lure graph is a live graph and it starting to show latency spikes as we approach peak hours, (unless you are heavily downloading) so I wouldn't rule out contention at this point, I would keep an eye on the graph and wait until VM reply to this thread and arrange to have your connection looked at in detail, the intermittent noise on it's own warrants further investigation.

  • 11
  • 0
  • 1
Cyirak
On our wavelength
611 Views
Message 9 of 16
Flag for a moderator

Re: Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10


@griffin wrote:

I have just realised you have posted only an extract of the logs. Unfortunately, snippets do not add much value as the logs need to be seen in their entirety to get the full picture.

The f8lure is generally fine, apart from the intermittent packet loss and the glimp at the start of the graph and a latency spike at there end which maybe correlating when people are getting back from work logging on to the network.

Whilst there is evidence of intermittent noise on your local circuit, but nothing obvious to explain prolonged loss of speed, VM will need to confirm though.

EDIT.

Just seen that the F8lure graph is a live graph and it starting to show latency spikes as we approach peak hours, (unless you are heavily downloading) so I wouldn't rule out contention at this point, I would keep an eye on the graph and wait until VM reply to this thread and arrange to have your connection looked at in detail, the intermittent noise on it's own warrants further investigation.


Thanks for taking the time to look at this. The snippet was me being lazy on omiting the mac. anyway full logs here

 

12/09/2019 17:34Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 17:34Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 17:34Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 17:34Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 18:00Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 18:00Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 19:46Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 19:46Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 19:47Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 19:47Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 20:50Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 20:50Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 20:50Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 20:50Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 20:54Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 20:54Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 21:08Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/09/2019 21:48Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
13/09/2019 05:25Warning!Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
13/09/2019 05:25Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

 

Interestingly doesn't seem to have generated any more of the RCS partial service or Lost MDD and they're also generated out of peak times. 

 

No heavy downloading though some of those latency spikes could have been caused by speed test,  the packet loss yesterday howeever was whilst no one was using the connection as no one was home / devices downloading/uploading.

0 Kudos
Reply
  • 11
  • 0
  • 1
Cyirak
On our wavelength
533 Views
Message 10 of 16
Flag for a moderator

Re: Less than 1/4 speed at peek times for around 2 weeks - area 20 BH10

So just experienced this again. only getting 100mb down at most the stats are whilst the connection is playing up.  
 
Downstream bonded channelsChannel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID
1298750000-0.935256 qam21
2138750000138256 qam1
31467500000.740256 qam2
41547500000.940256 qam3
51627500000.740256 qam4
61707500000.740256 qam5
71787500000.540256 qam6
81867500000.540256 qam7
91947500000.440256 qam8
102027500000.240256 qam9
11210750000039256 qam10
12218750000040256 qam11
13226750000-0.240256 qam12
14234750000-0.540256 qam13
15242750000-0.938256 qam14
16250750000-0.938256 qam15
17258750000-138256 qam16
18266750000-138256 qam17
19274750000-1.238256 qam18
20282750000-137256 qam19
21290750000-0.936256 qam20
22306750000-0.936256 qam22
23314750000-0.736256 qam23
24322750000-0.537256 qam24


Downstream bonded channelsChannel Locked Status RxMER (dB) Pre RS Errors Post RS Errors
1Locked35.534575512614
2Locked38.9101574536749591
3Locked40.941099243426409
4Locked40.355159294074857
5Locked40.396960425308172
6Locked40.921971861701847
7Locked40.389587513143047
8Locked40.330558761264961
9Locked40.362502827088
10Locked40.343000722695
11Locked39.331428711469
12Locked40.326701013072
13Locked40.340029025110
14Locked40.346531629660
15Locked38.924349013991
16Locked38.91727516110
17Locked38.921005013956
18Locked38.958069828155
19Locked38.635046323239
20Locked37.61946678619
21Locked36.31550735185
22Locked36.32063928971
23Locked36.61242856111
24Locked37.31274079052

 

 

Interestingly the below logs seem to get recorded as soon at the problem occurs

 

14/09/2019 13:12:5 Warning! Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
14/09/2019 13:12:6 Warning! RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
14/09/2019 13:12:55 Warning! Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
14/09/2019 13:12:57 Warning! RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
14/09/2019 13:13:3 Warning! Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
14/09/2019 13:13:3 Warning! RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

0 Kudos
Reply