Origin have asked me to run WinMTR. and send them results - I did this morning.. I assume they will want me to this evening too...

Not sure if they will show anything but it's another test other than speedtests

Until the price at the supermarket comes up at the till then you aren't being overcharged. Up to the buyer to agree to the price being charged and accept.

Running a traceroute during the slowdown will find which hop between you and the Internet the delay / contention is. You should run it now while it's working OK and compare & contrast.

You should also have a look at the 'Analysis' button on the thinkbroadband speedtest to check the general ping latency. It's precisely that which would get fixed by the QoS I mentioned.

I've not had any experience with any of these routers, so don't quote me on this, but according to the manuals:

TP-Link TL-MR6400 (pp17) V2 and later: Only basic QoS. Won't help much with latency issues caused by contention unless you want to reserve bandwidth for VoIP etc.

TP-Link Archer D5: no QoS at all.

Asus DSL-N16 (pp27): Yes, click 'Smart Queues'.

Apologies for being off-topic but I don't quite follow your logic there, if there wasn't another customer mistakenly trying to take over your line it is difficult to figure out who placed an order with PlusNet to do just that? What do you think happened, as others have said it was Origin who failed to inform you of the pending line takeover.

In reply to a post by zzing123:

Running a traceroute during the slowdown will find which hop between you and the Internet the delay / contention is. You should run it now while it's working OK and compare & contrast.

You should also have a look at the 'Analysis' button on the thinkbroadband speedtest to check the general ping latency. It's precisely that which would get fixed by the QoS I mentioned.

Thanks for the info... here it is when running ok... bbc.co.uk

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|--------------------------------------------- ---|------|------|------|------|------|------|
| 192.168.1.1 - 1 | 8081 | 8080 | 0 | 1 | 64 | 0 |
| 10.0.254.95 - 0 | 8078 | 8078 | 13 | 16 | 55 | 23 |
| 10.0.244.241 - 1 | 8071 | 8069 | 14 | 21 | 145 | 19 |
| 10ge2-3.core1.lon2.he.net - 1 | 8063 | 8059 | 13 | 19 | 79 | 18 |
| e0-35.core3.lon1.he.net - 0 | 8078 | 8078 | 14 | 22 | 903 | 38 |
| ip81-60.fastly-gw2.lonap.net - 1 | 8075 | 8074 | 14 | 16 | 69 | 15 |
| 151.101.128.81 - 1 | 8075 | 8074 | 13 | 16 | 83 | 15 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Edited by bounderboy (Wed 22-Apr-20 19:52:37)

This is what happened when the speed dropped after 8pm 9.30pm - still not that bad ... really

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 305 | 305 | 0 | 2 | 21 | 1 |
| 10.0.254.95 - 2 | 289 | 285 | 14 | 17 | 39 | 15 |
| 10.0.244.241 - 2 | 293 | 290 | 15 | 19 | 85 | 16 |
| 10ge2-3.core1.lon2.he.net - 2 | 293 | 290 | 14 | 19 | 50 | 16 |
| e0-35.core3.lon1.he.net - 2 | 285 | 280 | 14 | 17 | 37 | 16 |
| ip81-59.fastly-gw1.lonap.net - 3 | 281 | 275 | 15 | 17 | 32 | 28 |
| 151.101.192.81 - 2 | 289 | 284 | 14 | 18 | 37 | 27 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

In reply to a post by Realalemadrid:

... as others have said it was Origin who failed to inform you of the pending line takeover.

They also said they had failed to do so.

Matt

In reply to a post by bounderboy:

This is what happened when the speed dropped after 8pm 9.30pm - still not that bad ... really

No. Those stats are actually improved on the normal lol.

However, you can tell a few things, but it looks more like an enterprise network than a broadband one. Here's what you can decipher:

Hop 1: 192.168.1.1 is your router
Hops 2 & 3: 10.0.254.95 & 10.0.244.241 are most likely the overlay network run by Origin. Whether it's MPLS or IP VPN you can't tell. But it's strange there are only 2 hops as there's usually a few more in a normal broadband connection.
Hops 4 & 5: Traffic is then going over Hurricane Electric transit. This means your traffic is routed to a datacentre first and then going over a central pipe to LONAP, which is one of 2 main internet exchanges in London (the other is LINX).

We don't know what the deal is between Origin and Hurricane Electric. But Origin don't seem to have their own router in LONAP or LINX, which is strange as it's unlike just about every other ISP in the UK.

If there's any issue, it seems to appear between Origin's network and the HE transit to LONAP, as evidenced by the 'Worst' blips at both ends of the HE network (between hop 3 & 4 showing 147ms and hop 5 & 6 with 903ms): you're looking for inconsistent latencies like that. Also when testing line quality, you should always take pings when your line is heavily loaded like when watching Netflix or a big download. That's the worst case scenario for latencies.

Anyway, send both plots to Origin and keep whinging.

This is really intriguing. From what I can tell, Origin's network is segmented in half; a CGNAT side used for most customer connections, and a static IP side.

My main Origin line has a IP, and almost always hit the same LNS (10.0.254.93), which gets the same HE transit. I have another two CGNAT lines that hit random LNS' and almost always get Cogent transit.

Origin used to have LINX and LONAP public peering, but they culled them sometime last year. It was a wise move IMO. Less traffic to bulk around docklands, so it works out cheaper for them, because transit is cheaper to upgrade than adding more cross/interconnects.

I always observe niggling issues on the CGNAT lines, with stuck TCP connections (probably TCP-SYN issues), particularly to busier local sites like BBC. Before COVID-19, some evening peak congestion was evident. Nowadays, the 40/10 line halves throughput during the evening, and 80/20 about halves throughput too. But it's not a problem for me as they're lightly used and work flawlessly for their intended purpose.

However my main Origin line with static IP hits full 80/20 all day and all night. Never, ever, get any congestion. It's practically uncontended. I don't know whether I'm hitting lucky with the LNS (10.0.254.93) or what. I notice your HE route and you're on a neighbouring LNS (10.0.254.95), so I'd say either your LNS is hot, or its backhaul is congested. It's definitely not a transit issue.

So what I'd suggest is to disconnect your modem entirely for 60 minutes to let your session completely expire throughout Openreach, TalkTalk and Origin's networks, and then reconnect. Maybe you'll connect to a different LNS (take note of the IP, it's the second hop in your trace) and the speed issue will be resolved. If you do get a different LNS but still face evening peak congestion, it'll be TalkTalk's network at fault.

TalkTalk don't often publish info about congestion, but if it's the case here, you might find some planned works on their status page: https://managed.mytalktalkbusiness.co.uk/network-sta...

Edited by olorinh (Wed 22-Apr-20 23:46:03)