04-05-2021 14:38 - edited 04-05-2021 14:49
Hi All,
I have recently moved to Virgin Media Broadband from Sky in the last month. Previously I had the Superfast package, downloads of 60/70mbps and upload of 15/20mbps. With Virgin I now am on the M200 package and average 180mbps download and 20mbps upload with the Hub4.
My issue is only with gaming on my PS5. I get lag spikes where the ping increases dramatically (over 100ms) and it becomes unplayable. I never had this issue with sky, where I had a ping of constantly lower than 20ms (average 17ms). The only difference in setup was that I had a sky booster which I ethernet cabled directly to.
I have the PS5 setup with both Wifi and also through ethernet to a Netgear powerline adapter. The lag happens on both setups. Like I say, no speed issues, just the ping/latency issue. I can't wire directly to the hub as that is in a different room.
Is there any way to fix this? Would a wired connection to a Wifi Pod fix it? I have spoken over the phone to 4/5 different Virgin Media colleagues over the past two weeks and nobody seems to understand the issue or provide any solutions.
At this moment in time I am regretting the move...
Answered! Go to Answer
on 05-05-2021 16:10
Hi Laurence, no problem taking a look and commenting, although I fear that I come bearing bad news.
There's two things I observe - the first and most serious is the over-utilisation that is evident from the BQM. I see you've got a Hub 4 on a 200 Mbps connection, the only circumstances that customers on non-1 Gigabit speeds get a Hub 4 is when VM hope that the Hub 4 will help reduce the problems of over-utilisation. This can sometimes work, but doesn't always, and the BQM shows that it's not eliminating utilisation problems for you. The second observation is that your power levels are quite high both downstream and upstream. That won't be helping, and is usually easily fixed, unfortunately I'm highly confident that sorting the power levels won't eliminate the over-utilisation and latency problems.
As you've read other posts, you'll know what I have to say:
1) VM fix some utilisation faults, others they don't; The company choose the ones they fix, individual customers have no influence on the matter.
2) Virgin Media fix dates for over-utilisation and accompanying promises of engineers working hard are automatically enrolled each year for the Booker Prize for Modern Fiction. So even if they do plan to fix it, there's no way of knowing.
3) If there's an acceptably fast Openreach option, then getting a new ISP in, checking it works and then cancelling VM is the only guaranteed solution.
4) If (as seems likely) you're in a fixed term contract, it is possible to cancel without paying VM's exorbitant, but there's certain hoops to jump through, and if the company are obtuse, then it will be a slow process involving escalation to the industry arbitration scheme CISAS.
04-05-2021 18:23 - edited 04-05-2021 18:25
Might be an issue with your Super Hub's power level, or it could be an over-utilisation issue. You'll need to post your Hub's stats, so an expert can comment, and set up a free BQM for at least 24 hours to see the latency situation.
It's worth noting that even a good DOCSIS service will have higher latency than the broadband type Sky use.
on 04-05-2021 21:44
Thanks for your response mjpartyboy.
I have set up a BQM since 6pm so will post the results of that tomorrow evening. By Hubs stats, do you mean the data on the router status page when I go to log on to my hub? And is data from all of the tabs needed?
Just want to make sure I am posting relevant data
05-05-2021 09:02 - edited 05-05-2021 09:12
Here is the link to my live BQM graph. There's a few hours to go before the 24 hours of data is available but wondering if this is useful to anyone yet?
https://www.thinkbroadband.com/broadband/monitoring/quality/share/0c628862aed27fd06409653f0fa95bf175c269b9
I didn't use my PS5 last night so the data seen on the graph is purely through usage of a single person watching TV/Netflix and mobile phone usage over Wifi.
Also can provide Hub stats if needed, if someone could explain which stats are useful. I apologise for not being too tech savvy in this regard.
on 05-05-2021 12:49
3.0 Downstream channels
Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID
5 | 171000000 | 9.400002 | 38.605377 | QAM256 | 5 |
1 | 139000000 | 10.800003 | 38.605377 | QAM256 | 1 |
2 | 147000000 | 10.400002 | 38.605377 | QAM256 | 2 |
3 | 155000000 | 9.900002 | 38.605377 | QAM256 | 3 |
4 | 163000000 | 9.599998 | 38.983261 | QAM256 | 4 |
6 | 179000000 | 9.099998 | 38.983261 | QAM256 | 6 |
7 | 187000000 | 8.800003 | 38.605377 | QAM256 | 7 |
8 | 195000000 | 8.699997 | 37.636276 | QAM256 | 8 |
9 | 203000000 | 8.699997 | 37.636276 | QAM256 | 9 |
10 | 211000000 | 8.500000 | 37.636276 | QAM256 | 10 |
11 | 219000000 | 8.300003 | 37.636276 | QAM256 | 11 |
12 | 227000000 | 8.400002 | 37.636276 | QAM256 | 12 |
13 | 235000000 | 8.199997 | 37.636276 | QAM256 | 13 |
14 | 243000000 | 8.000000 | 37.636276 | QAM256 | 14 |
15 | 251000000 | 7.900002 | 37.355988 | QAM256 | 15 |
16 | 259000000 | 7.500000 | 37.636276 | QAM256 | 16 |
17 | 267000000 | 7.000000 | 37.355988 | QAM256 | 17 |
18 | 275000000 | 6.900002 | 37.636276 | QAM256 | 18 |
19 | 283000000 | 7.000000 | 36.609653 | QAM256 | 19 |
20 | 291000000 | 7.599998 | 36.609653 | QAM256 | 20 |
21 | 299000000 | 8.300003 | 36.609653 | QAM256 | 21 |
22 | 307000000 | 8.500000 | 36.386890 | QAM256 | 22 |
23 | 315000000 | 8.000000 | 36.386890 | QAM256 | 23 |
24 | 323000000 | 8.300003 | 36.386890 | QAM256 | 24 |
3.0 Downstream channels
Channel Lock Status RxMER (dB) Pre RS Errors Post RS Errors
5 | Locked | 38.605377 | 0 | 0 |
1 | Locked | 38.605377 | 0 | 0 |
2 | Locked | 38.605377 | 0 | 0 |
3 | Locked | 38.605377 | 0 | 0 |
4 | Locked | 38.983261 | 0 | 0 |
6 | Locked | 38.983261 | 0 | 0 |
7 | Locked | 38.605377 | 0 | 0 |
8 | Locked | 37.636276 | 0 | 0 |
9 | Locked | 37.636276 | 0 | 0 |
10 | Locked | 37.636276 | 0 | 0 |
11 | Locked | 37.636276 | 0 | 0 |
12 | Locked | 37.636276 | 0 | 0 |
13 | Locked | 37.636276 | 0 | 0 |
14 | Locked | 37.636276 | 0 | 0 |
15 | Locked | 37.355988 | 0 | 0 |
16 | Locked | 37.636276 | 0 | 0 |
17 | Locked | 37.355988 | 0 | 0 |
18 | Locked | 37.636276 | 0 | 0 |
19 | Locked | 36.609653 | 0 | 0 |
20 | Locked | 36.609653 | 0 | 0 |
21 | Locked | 36.609653 | 0 | 0 |
22 | Locked | 36.386890 | 0 | 0 |
23 | Locked | 36.386890 | 0 | 0 |
24 | Locked | 36.386890 | 0 | 0 |
3.0 Upstream channels
Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID
1 | 60300000 | 50.520599 | 5120 KSym/sec | 64QAM | 1 |
2 | 39400000 | 49.520599 | 5120 KSym/sec | 64QAM | 4 |
3 | 46200000 | 49.770599 | 5120 KSym/sec | 64QAM | 3 |
4 | 53700000 | 49.770599 | 5120 KSym/sec | 64QAM | 2 |
3.0 Upstream channels
Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts
1 | US_TYPE_STDMA | 0 | 0 | 1 | 0 |
2 | US_TYPE_STDMA | 0 | 0 | 7 | 0 |
3 | US_TYPE_STDMA | 0 | 0 | 1 | 0 |
4 | US_TYPE_STDMA | 0 | 0 | 1 | 0 |
on 05-05-2021 12:50
Network Log
Time Priority Description
Thu Jan 1 00:01:29 1970 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 20:36:50 2021 | 5 | MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 20:37:19 2021 | 6 | CM-STATUS message sent. Event Type Code: 3; Chan ID: N/A; DSID: 699813; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:05:15 2021 | 3 | SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:05:20 2021 | 5 | Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:06:11 2021 | 3 | Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:21:51 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:23:15 2021 | 5 | B-INIT-RNG Failure - Retries exceeded;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:23:16 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:24:21 2021 | 5 | B-INIT-RNG Failure - Retries exceeded;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:24:23 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:25:28 2021 | 5 | B-INIT-RNG Failure - Retries exceeded;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:25:30 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:26:39 2021 | 5 | B-INIT-RNG Failure - Retries exceeded;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:27:06 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:28:19 2021 | 5 | B-INIT-RNG Failure - Retries exceeded;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:28:22 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:29:28 2021 | 5 | B-INIT-RNG Failure - Retries exceeded;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:29:30 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:30:18 2021 | 5 | B-INIT-RNG Failure - Retries exceeded;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:30:20 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:31:14 2021 | 5 | B-INIT-RNG Failure - Retries exceeded;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:31:42 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:33:19 2021 | 5 | MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:33:21 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Apr 20 23:45:43 2021 | 5 | DBC-REQ Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Wed Apr 21 06:41:56 2021 | 5 | Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Wed Apr 21 06:42:44 2021 | 3 | Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Wed Apr 21 06:43:47 2021 | 6 | CM-STATUS message sent. Event Type Code: 5; Chan ID: 1; DSID: N/A; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Wed Apr 21 06:44:14 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Wed Apr 21 06:44:39 2021 | 5 | MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Wed Apr 21 06:44:41 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Wed Apr 21 06:57:13 2021 | 5 | DBC-REQ Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Thu Apr 22 11:58:49 2021 | 6 | CM-STATUS message sent. Event Type Code: 5; Chan ID: 19; DSID: N/A; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Fri Apr 23 01:55:04 2021 | 4 | DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Fri Apr 23 01:55:04 2021 | 6 | DHCP Renew - lease parameters tftp file-cmreg-vmdg640-bbt060-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Fri Apr 23 14:10:56 2021 | 6 | CM-STATUS message sent. Event Type Code: 5; Chan ID: 17; DSID: N/A; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon Apr 26 01:53:39 2021 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon Apr 26 13:55:04 2021 | 4 | DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon Apr 26 13:55:04 2021 | 6 | DHCP Renew - lease parameters tftp file-cmreg-vmdg640-bbt060-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon Apr 26 15:37:44 2021 | 6 | CM-STATUS message sent. Event Type Code: 5; Chan ID: 17; DSID: N/A; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Fri Apr 30 01:55:04 2021 | 4 | DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Fri Apr 30 01:55:04 2021 | 6 | DHCP Renew - lease parameters tftp file-cmreg-vmdg640-bbt060-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Sun May 2 12:37:48 2021 | 6 | CM-STATUS message sent. Event Type Code: 5; Chan ID: 17; DSID: N/A; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon May 3 13:55:04 2021 | 4 | DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon May 3 13:55:04 2021 | 6 | DHCP Renew - lease parameters tftp file-cmreg-vmdg640-bbt060-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
on 05-05-2021 16:10
Hi Laurence, no problem taking a look and commenting, although I fear that I come bearing bad news.
There's two things I observe - the first and most serious is the over-utilisation that is evident from the BQM. I see you've got a Hub 4 on a 200 Mbps connection, the only circumstances that customers on non-1 Gigabit speeds get a Hub 4 is when VM hope that the Hub 4 will help reduce the problems of over-utilisation. This can sometimes work, but doesn't always, and the BQM shows that it's not eliminating utilisation problems for you. The second observation is that your power levels are quite high both downstream and upstream. That won't be helping, and is usually easily fixed, unfortunately I'm highly confident that sorting the power levels won't eliminate the over-utilisation and latency problems.
As you've read other posts, you'll know what I have to say:
1) VM fix some utilisation faults, others they don't; The company choose the ones they fix, individual customers have no influence on the matter.
2) Virgin Media fix dates for over-utilisation and accompanying promises of engineers working hard are automatically enrolled each year for the Booker Prize for Modern Fiction. So even if they do plan to fix it, there's no way of knowing.
3) If there's an acceptably fast Openreach option, then getting a new ISP in, checking it works and then cancelling VM is the only guaranteed solution.
4) If (as seems likely) you're in a fixed term contract, it is possible to cancel without paying VM's exorbitant, but there's certain hoops to jump through, and if the company are obtuse, then it will be a slow process involving escalation to the industry arbitration scheme CISAS.
05-05-2021 16:12 - edited 05-05-2021 16:14
Your connection does appear to have some problems from your stats, these might be solved by rebooting your router - when was the last time you did that?
Also, if you look at the BQM you can see that it gets bad around peak time and perfect during off-peak, this shows a classic over utilisation problem (too many people on your local node)
EDIT: What @Andrew-G says 🙂
on 05-05-2021 16:45
Thanks Andrew and Z92 for your comments.
The engineer who fitted my hub4 was surprised also as I was on a 200Mbps connection, so much so he phoned his manager and apparently it was down to low stock of the Hub3... now you've made me doubt that story. I will get in contact with them now I have some more detailed information courtesy of you guys and see what my options are. I am a little bit miffed as I only moved to VM for the higher speeds and my obvious lack of understanding meant I didn't even consider this potential problem, even though I'm sure I shouldn't really have to deal with issues like this.
Hopefully seeing as I have only been with VM 3 weeks I may be able to get them to listen. Shame I have now passed the 14 day cooling off though.
I assume there's no way I can bypass this issue by increasing the speed on my package or anything like that? Powerlines/wifi boosters are I assume going to suffer the same problems due to the issue being local over-utilisation.
It would be great if someone from VM can reply to this thread with a possible solution (if there is one) or some more information. The times I have tried to phone through to VM it has been a nightmare to get in contact.
on 05-05-2021 17:19
I assume there's no way I can bypass this issue by increasing the speed on my package or anything like that? Powerlines/wifi boosters are I assume going to suffer the same problems due to the issue being local over-utilisation.
Unfortunately there's nothing you can do that improves over-utilisation or bypasses it. VPNs, new routers, boosters, fiddling with settings etc don't make any difference, the problem is that there's simply more data traffic than the CMTS gear can process in real time, leading to very brief delays that may not affect measured speeds, but destroy good latency. The CMTS is the magic box that sits at the head of every local coax network, and acts a big multi-customer modem to translate optical data into radio frequency data that your hub understands, and the hub then converts back into electrical impulse data for your devices.
There are ways of increasing CMTS capacity, but they are usually expensive and require careful months of planning by network experts, and then more project planning to bring together the multiple different teams who would be required to do this. Hence VM's track record on this is poor, as it's usually as quick and much cheaper to let the problem "resolve itself" by unhappy customers.
It is very poor (and arguably mis-selling) to take on new customers in an area subject to over-utilisation, lets wait and see what the forum staff have to say.