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
Tried to play some stadia but:
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.
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.
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]
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:
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:
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 :
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).
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.
So it's now almost 12am, people should be going to bed and things are pretty much back to normal:
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.
