cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
scottrc
Contributor
1,401 Views
Message 21 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution

I had another look at my cab today and its actually two full sized FTTC cabs next to each other, one with a g.fast pod and then a PCP  cab about 5 metres away. They must of added another FTTC cab at some point.

0 Ratings
Reply
scottrc
Contributor
1,386 Views
Message 22 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution

Thought I would update this thread in case anyone wanted more information. A mod is currently working really hard to help me get this fixed. A fault has been raised and an engineer will be booked in soon. The BT system can see something is wrong as it automatically opened a fault and complaint last night after a speed test was well below the minimum. The mod checked for any congestion problems at the exchange SVLAN and according to their reports, there shouldn't be any issues there, as there is obviously a problem the mod contacted a specialist team in BT wholesale and they will be monitoring my connection over the next 48 hours as they did notice a potential stability issue with the line. Will keep everyone updated as things progress. Thanks again to NeilO 🙂

0 Ratings
Reply
scottrc
Contributor
1,372 Views
Message 23 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution

I'm glad the team is monitoring my line this weekend. Speeds have been pretty bad, as well as packet loss. Tried a number of different services. They will def see something for sure.

C:\Users\Scott>ping -4 google.com -n 50 -l 1452

Pinging google.com [216.58.198.174] with 1452 bytes of data:
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=11ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=11ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=15ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=11ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=14ms TTL=116
Request timed out.
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=10ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=16ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=19ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=22ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=35ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=24ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=22ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=32ms TTL=116
Request timed out.
Reply from 216.58.198.174: bytes=68 (sent 1452) time=32ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=21ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=18ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=13ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=17ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=13ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=12ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Request timed out.
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Request timed out.
Reply from 216.58.198.174: bytes=68 (sent 1452) time=19ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=15ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=18ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=12ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=14ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116

Ping statistics for 216.58.198.174:
Packets: Sent = 50, Received = 46, Lost = 4 (8% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 35ms, Average = 13ms

1.png2.png

Tried to play some stadia but:

stadiastats.png

Unusually it was also bad during the day today on Saturday. It is the weekend though. Speeds were normal at 48-49mb down about 2AM onwards Sat morning.

Tracing route to google.com [216.58.210.206]
over a maximum of 50 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 4 ms 4 ms 4 ms 172.16.10.180
3 * * * Request timed out.
4 7 ms 7 ms 7 ms 31.55.185.176
5 8 ms 7 ms 7 ms core2-hu0-15-0-7.colindale.ukcore.bt.net [213.121.192.34]
6 16 ms 20 ms 9 ms peer8-et-3-1-4.telehouse.ukcore.bt.net [109.159.252.170]
7 8 ms 8 ms 9 ms 109.159.253.187
8 8 ms 8 ms 8 ms 209.85.255.23
9 8 ms 8 ms 7 ms 172.253.68.217
10 8 ms 8 ms 8 ms mrs04s09-in-f206.1e100.net [216.58.210.206]

Trace complete.

0 Ratings
Reply
scottrc
Contributor
1,365 Views
Message 24 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution

It's now 12:30AM, offpeak (using thinkbroadband because I don't want to overrite the last BT wholesale one):

Everyone must be going to bed.

1597534194468576555

and to confirm the ping and tracert results (now zero packet loss):

C:\Users\Scott>ping -4 google.com -n 50 -l 1452

Pinging google.com [216.58.198.174] with 1452 bytes of data:
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=10ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=10ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=12ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=8ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116
Reply from 216.58.198.174: bytes=68 (sent 1452) time=9ms TTL=116

Ping statistics for 216.58.198.174:
Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 12ms, Average = 8ms

 

C:\Users\Scott>tracert -4 google.com

Tracing route to google.com [216.58.198.174]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 4 ms 4 ms 3 ms 172.16.10.180
3 6 ms 6 ms 5 ms 31.55.185.181
4 7 ms 6 ms 6 ms 31.55.185.188
5 7 ms 6 ms 6 ms core2-hu0-15-0-6.colindale.ukcore.bt.net [213.121.192.32]
6 7 ms 7 ms 11 ms 194.72.16.62
7 7 ms 6 ms 6 ms 195.99.126.137
8 8 ms 7 ms 7 ms 74.125.253.31
9 7 ms 7 ms 7 ms 108.170.232.97
10 7 ms 7 ms 7 ms lhr25s10-in-f174.1e100.net [216.58.198.174]

 

0 Ratings
Reply
scottrc
Contributor
1,337 Views
Message 25 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution

Hi all,

Just an update and some(lots) of questions for you guys. So the SVLAN reports at the exchange came back saying no congestion, they monitored it for 48 hours last Friday and speeds were just as bad as today. Line tests didn't reveal any crosstalk or any problems that could be picked up on remotely.

My router stats show a full sync speed of 55mb and that is the package I'm on.

I have an engineer booked for next week anyway, but I don't think it's going to change anything, I guess it's needed to be able to progress this further though and he can check my wiring etc to give BT more evidence I guess.

So the idea is to find out why I'm getting bad throughput speeds at peak times, if I'm not on a congested SVLAN.

Just for some info, all speed tests are done via ethernet (the one supplied with the router) and I live alone, so I know nothing else is using up bandwidth, I checked the router stats and disabled Wifi. Connected via test socket using the microfilter supplied. No phones are connected.

I did another quiet line test at the test socket and this time it was actually quiet, no noise at all.

So first the router stats, I actually heard somewhere that the noise margin on the lower Fibre 1 package is normally set at 10db due to the decrease in sync speed needed, can anyone confirm this? The noise margin also doesn't seem to either go below 10db or above 10.9db, no matter what really, just floats around 10.5 normally. Also for what it's worth, when I was with TalkTalk on their top fibre package, the target noise margin was 3db and it was 3db, didn't go above 3.9db. I don't think there is noise on the line.

Another thing is that for some reason it says BT Wifi activated, even though I opted out like 3 weeks ago. It does say it's disabled on other pages though, not sure why this page doesn't update, I also did a WiFi channel scan and did see a hidden SSID with the same channel and signal strength as mine, I'm also the only one on BT in my block of 6 flats. Could a mod confirm if BT Wifi is actually disabled for me? I know it's supposed to only use a very small percentage of bandwidth, but I don't want it on and I did turn it off on the BT.com website.

When I first reported this congestion problem via live chat, the guy on the other end did some tests and said he had problems connecting to the router and put an order in for a replacement, for some reason the despatch date is 2nd Sept and that was ordered on 31 July. I wonder if there is some hardware issue in the new hub and they are waiting for the new versions, could just be a delay in sending it out though.

Product code:Smart Hub 2
Serial number:+091298+2019002006
Firmware version:v0.17.01.12312-BT
Firmware updated:Thu Jul 30 00:50:29 2020
Board version:R01
GUI version:1.56 15_02_2019
DSL uptime:0 days,00 Hours33 Mins37 Secs (This is due to me connecting to the test socket, the resync was caused by me)
Data rate:9.997 Mbps / 55 Mbps
Maximum data rate:23.033 Mbps / 73.482 Mbps
Noise margin:14.0 / 10.7
Line attenuation:8.4 / 16.9
Signal attenuation:8.4 / 18.9
VLAN id:101
Upstream error control:Off
Downstream error control:Off
Data sent / received:74.8 MB Uploaded / 387.1 MB Downloaded
Broadband username:bthomehub@btbroadband.com
BT Wi-fi:Activated
2.4 GHz wireless network name:*
2.4 GHz wireless channel:Smart (Channel1)
5 GHz wireless network name:*
5 GHz wireless channel:Smart (Channel36)
Wireless security:WPA2 (Recommended)
Wireless mode:Mode 1
Firewall:On
MAC address:*
Software variant:-
Boot loader: 0.1.7-BT (Thu Nov 30 09:45:22 2017)

Here is the speed tests done at 12PM Friday. So ideally these should be congestion free and they are, getting full speeds, no problems at all:

1598007595825925955
btwholesale.pngmlabs12pm.pngfast1.png

I also did a couple trace routes, to see if there is any difference between 12PM and the later tests:

Tracing route to google.com [216.58.198.174]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 4 ms 3 ms 3 ms 172.16.10.180
3 * * * Request timed out.
4 7 ms 6 ms 6 ms 31.55.185.180
5 6 ms 6 ms 6 ms core1-hu0-6-0-8.colindale.ukcore.bt.net.ukcore.bt.net [213.121.192.4]
6 7 ms 7 ms 7 ms peer7-et-0-1-1.telehouse.ukcore.bt.net [109.159.252.148]
7 7 ms 7 ms 6 ms 109.159.253.235
8 8 ms 8 ms 8 ms 74.125.253.75
9 7 ms 7 ms 7 ms 108.170.232.99
10 8 ms 7 ms 7 ms lhr25s10-in-f14.1e100.net [216.58.198.174]

Trace complete.

Tracing route to bbc.co.uk [151.101.0.81]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 4 ms 3 ms 4 ms 172.16.10.180
3 * 6 ms 6 ms 31.55.185.177
4 6 ms 6 ms 6 ms 31.55.185.176
5 7 ms 15 ms 6 ms core2-hu0-12-0-1.colindale.ukcore.bt.net [195.99.127.118]
6 7 ms 7 ms 7 ms 194.72.16.230
7 * * * Request timed out.
8 7 ms 7 ms 7 ms 151.101.0.81


And here is the speed tests done at 8.30PMish Friday. I mean to me, if I get perfect speeds at 12PM and then the following at peak time, this is clear congestion, no? But what can I do if BT is saying the SVLAN is not reporting congestion?

It's pretty unlikely that the congestion is at the cabinet isn't it? Is there anywhere else that congestion can effect after the SVLAN? I would of thought anything after that would be picked up on instantly though and this problem has been going on for weeks now. Months, if you include TalkTalk also.

Peak time speed tests 8.30PM:

1598038317229853655

btwholesale2.pngfast2.pngmlab2.png

 

Tracing route to google.com [172.217.169.46]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 4 ms 4 ms 4 ms 172.16.10.180
3 * * * Request timed out.
4 9 ms 8 ms 8 ms 31.55.185.176
5 7 ms 7 ms 7 ms core1-hu0-8-0-1.colindale.ukcore.bt.net [195.99.127.144]
6 9 ms 7 ms 8 ms peer2-et0-0-1.slough.ukcore.bt.net [62.172.103.202]
7 8 ms 9 ms 9 ms 109.159.253.71
8 8 ms 8 ms 7 ms 216.239.42.41
9 8 ms 8 ms 7 ms 172.253.66.89
10 8 ms 7 ms 7 ms lhr48s08-in-f14.1e100.net [172.217.169.46]

Tracing route to bbc.co.uk [151.101.64.81]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 4 ms 3 ms 4 ms 172.16.10.180
3 * * * Request timed out.
4 7 ms 7 ms 7 ms 31.55.185.176
5 7 ms 6 ms 6 ms core2-hu0-2-0-3.colindale.ukcore.bt.net [195.99.127.114]
6 8 ms 8 ms 7 ms peer3-et-7-0-4.redbus.ukcore.bt.net [62.172.103.252]
7 * * * Request timed out.
8 7 ms 6 ms 6 ms 151.101.64.81

 

So pretty clear and well below acceptable speeds at peak times.

The reason I ask about the cabinet, is because, I also had this problem with TalkTalk, so it was either a coincidence that they also had congestion problems at the exchange. Or there is something wrong with another piece of equipment before/after the SVLAN, such as the MSE/BRAS. Even if my block of flats had crosstalk problems would that not affect the sync speed, rather than throughput speed? The sync speed is 55mb still at 8:30pm. I personally don't think we have crosstalk problems, we are a new build (ish) and they used cat5e to run from an Openreach copper distribution point to each flat. Here is a pic of the utility room, showing the DP. In the top left, is the Openreach DP with the 6 cat5e cables coming out, they are only bunched up for like 3 metres and then it's about 10 meters, maybe less, to my master socket (the rest of the stuff you see is TV aerials and some kind of SkyQ equipment that was recently installed. I dont think any of that affects it though as I would see problems all day long I would of thought? Why the developers did it this way, when we all have our own outside front doors, I dont know :

utilityroom-min.jpg

I understand some congestion is going to happen, but I would of thought it should be within a certain percentage. I'm not sure what BT even counts as a congested SVLAN. Maybe this is OK to them? Or maybe this congestion is on Openreach equipment, I have no idea.

I had another look at the actual cabinet I'm connected to. It has a large PCP cabinet with what I assume is a g.fast pod on the side of it and then the FTTC cabinet is just behind that, it's the Huawei 288 /384HD, that's the one I'm on as it has the number printed on it. Then about 10 meters away is another smaller FTTC cabinet, a Huawei 96/128. So there must be lots of users for the one PCP cabinet as I actually only just noticed the second FTTC cabinet recently. Does anyone know the bandwidth capacity of the fibre link from the FTTC cabinet to the exchange? Surely it's enough to not cause congestion there? Or it would be picked up on, I would of thought.

I also ruled out the possibility of it actually being my PC, by using other devices to test also.

I understand there is procedures in place for getting something like this fixed, but to me it's pretty obvious congestion, rather than a line fault or crosstalk. From what others have said, if it was crosstalk, then it would show a lower sync speed in the router stats, but it actually says 55mb and max 73mb. Noise margin seems stable, even after re-syncs and no noise on the telephone quiet line test now. I've tried my best to give the best proof of this as possible.

BT are saying there isn't any congestion, so what can I do? Can I request to be moved to a different SVLAN anyway? Or is there some cabinet or other equipment that needs checking?

I would love to know how the BT congestion reports are made, like are they over a 24 hour period and then averaged out? If it was done this way, it would show low congestion, as daytime speeds are fine. I have seen in the Plusnet forums, a case where the SVLAN reports came back as congestion free, the customer and mod team persisted and some kind of QC team did further testing and found that actually it was congested and they moved the customer to a less congested SVLAN, problem was solved. For example https://aastatus.net/1890 (I know this is old 2014) but it shows the point, that BT came back saying SVLAN, no congestion, then upon further inspection, found out it was actually the MSE that caused the congestion.

Something else I noticed that is strange is that in in the BT wholesale speed test report it says "For your connection, the acceptable range of speeds is 27.5-50.67 Mbps" It never used to say 27.5, this has been added after repeated tests, it used to be a lot higher. So this seems to update itself from previous tests. I'm also not sure why 27.5 is acceptable, the DSL checker shows a downstream handback threshold of 48mb, even on an impacted line, if BT think 27mb is acceptable, then they must think going from 50 to 27 during congestion is also acceptable, that's a 40%+ decrease in throughput speed, do they really allow that kind of decreases during congestion. I would of thought 20% would be enough for them to find an issue and I checked Ofcom stats and it's usually only like 10% or less of a loss during congestion on average. This range also differs from the range advertised when ordering the package and BT are supposed to be applying the new Ofcom rules that state the advertised range of speeds should reflect peak time congestion (maybe they didn't have this data yet though I guess).

dslchecker.png

The DSL checker is actually wrong though about FTTP and my status, although our area is FTTP ready, I'm an MDU not a single dwelling. Not sure why it thinks I'm single dwelling, maybe because I have my own outside facing front door. Currently trying to get Openreach to get permission from the freeholder to install FTTP, but that's another story and will most likely take months as Openreach said there is a delay at the moment for contacting freeholders. They have created a full record though and said it will be done as soon as possible. The DSL checker does show an observed speed in 2019 of 80/20 though, this was before I had problems.

Thanks for reading this far, I'm basically looking for any advice from other users, that may have some knowledge of this kind of problem. If the engineer comes back and says line is good (he's coming in the morning next week so I'm going to go ahead and say that he wont find any problems), what can I and BT do? I know it's possible now for ISP's to request a SVLAN move, I'm just not sure if they need more than what I have already provided.

 

Edit: I also forgot to mention, I just tried a VPN (NordVPN) to see if a routing change, would change anything. The answer is no, exactly the same problem except speeds were even worse as expected, so I guess that rules out the BT core network, I tried the VPN the other day off-peak and speeds were around 48mb. Here is the trace routes like above but using the VPN instead:

Tracing route to bbc.co.uk [151.101.192.81]
over a maximum of 30 hops:

1 6 ms 6 ms 7 ms 10.7.2.1
2 22 ms 31 ms 33 ms cs0-cr.ldn.as25369.net [5.226.141.129]
3 9 ms 7 ms 7 ms ae2.31-rt1-cr.ldn.as25369.net [185.38.150.226]
4 7 ms 8 ms 8 ms ae1.rt0-thn2.ldn.as25369.net [5.226.136.38]
5 8 ms 7 ms 8 ms ip81-59.fastly-gw1.lonap.net [5.57.81.59]
6 8 ms 7 ms 7 ms 151.101.192.81

Tracing route to google.com [216.58.210.238]
over a maximum of 30 hops:

1 7 ms 7 ms 7 ms 10.7.2.1
2 29 ms 38 ms 25 ms cs0-cr.ldn.as25369.net [5.226.141.129]
3 7 ms 9 ms 7 ms ae2.31-rt1-cr.ldn.as25369.net [185.38.150.226]
4 15 ms 13 ms 14 ms ae2.rt0-hex.ldn.as25369.net [5.226.136.16]
5 17 ms 29 ms 14 ms ae3-224.cr5-lon2.ip4.gtt.net [77.67.82.245]
6 32 ms 31 ms 31 ms ae22.cr10-lon1.ip4.gtt.net [89.149.185.49]
7 27 ms 26 ms 25 ms 72.14.221.145
8 11 ms 14 ms 13 ms 209.85.249.187
9 32 ms 73 ms 72 ms 172.253.68.213
10 9 ms 10 ms 11 ms lhr48s12-in-f14.1e100.net [216.58.210.238]

Trace complete.

 

 

 

 

0 Ratings
Reply
imjolly
Distinguished Sage
Distinguished Sage
1,331 Views
Message 26 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution

The normal noise margin is 6db reducing to 3db if G.INP is activated on your line.  Your noise margin appears high at 10db but that is due to your connection speed capped at 55mb whereas your attainable is 73mb on stats. If you were in fibre 2 then speed would be nearer 70mb and noise margin would be about 6db

have the mods adavised you that there is no congestion on SVLAN?



If you like a post, or want to say thanks for a helpful answer, please click on the Ratings 'Thumbs up' on left hand side.
If someone answers your question correctly please let other members know by clicking on ’Mark as Accepted Solution’.
scottrc
Contributor
1,329 Views
Message 27 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution
Cheers @imjolly I think it might of been one of your posts on here somewhere I heard about it.
0 Ratings
Reply
scottrc
Contributor
1,315 Views
Message 28 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution

And yes the mods said that wholesale monitored my SVLAN last weekend and said that no congestion was seen. Last weekend was actually the worst it's ever been, so I was really suprised they didn't come back with anything.

I'm going to stay up late tonight and show another set of speed tests when the congestion has gone down, minus the BTW one to avoid overwriting it, just to show the three sets in one day.

Tags (1)
0 Ratings
Reply
scottrc
Contributor
1,292 Views
Message 29 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution

So it's now almost 12am, people should be going to bed and things are pretty much back to normal:

1.png2.png

1598050201684504455

 

The only differences in the trace routes between the congested times and non congested times is that when I had congestion problems, the trace route introduced the following hops:

peer2-et0-0-1.slough.ukcore.bt.net [62.172.103.202]
peer3-et-7-0-4.redbus.ukcore.bt.net [62.172.103.252]

These no longer appear when I do the tracert again. It just uses

colindale.ukcore.bt.net [213.121.192.26]
telehouse.ukcore.bt.net [109.159.252.94]

and they did not appear in the earlier non congested tests either. Could be something.

0 Ratings
Reply
pippincp
Distinguished Sage
1,258 Views
Message 30 of 42

Re: Peaktime throughput speeds less than half minimum speed guarantee.

Go to solution

Your snips from the tracert are not helpful, the full tracert's may be.

0 Ratings
Reply