Strange thoughput problems and a possible fix

[zappaDPJ]

Since early this morning the majority of sites have been extremely slow to respond for me. I don't beleive it's due to an issue at my end and a speed test confirms I'm getting my expected throughput. tracert responses however have been inconsistently odd to say the least.


PS C:\Users\zappa> tracert www.idnetters.co.uk

Tracing route to www.idnetters.co.uk [212.69.40.200]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  RT-AX53U-DD90 [192.168.50.1]
  2     *        *       16 ms  redbus-gw10.idnet.net [212.69.63.25]
  3    29 ms    18 ms    18 ms  telehouse-gw7.idnet.net [212.69.63.166]
  4    16 ms     *       17 ms  cpanel8.idnet.net [212.69.40.200]

Trace complete.
PS C:\Users\zappa> tracert www.idnetters.co.uk

Tracing route to www.idnetters.co.uk [212.69.40.200]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  RT-AX53U-DD90 [192.168.50.1]
  2    18 ms    16 ms    17 ms  redbus-gw10.idnet.net [212.69.63.25]
  3    84 ms    50 ms    50 ms  telehouse-gw7.idnet.net [212.69.63.166]
  4     *       17 ms     *     cpanel8.idnet.net [212.69.40.200]
  5     *       17 ms     *     cpanel8.idnet.net [212.69.40.200]
  6     *       18 ms    17 ms  cpanel8.idnet.net [212.69.40.200]

Trace complete.


Support suggested I change my MTU which was set at 1492 to 1460. That does so far seem to have fixed the issue.

[Simon]

It does make you wonder, given your MTU must have been at 1492 for some time, what's changed?

[zappaDPJ]

I found the whole thing strange. It was as if data was being sent down the wire in chunks separated by a few seconds rather than just being overall slow.

Also hops 5 and 6 (or 4 and 5) of the second tracert makes no sense at all. I've never seen that happen before and I've run hundreds of similar tests in the past.

My extremely limited understanding of MTU suggests something within in the Internet is broken and lowering the MTU results in less time spent retransmitting corrupted packets

[Simon]

It seems like the usual response of getting the end user to change their settings to work around a problem within the network, rather than admitting there's a problem and getting it fixed!

That said, I've noticed any issues at my end.

[isirate]

There is no sense to them asking to reduce your MTU if nothing else has changed. With PPPoE the MSS will be 1452 and the MTU 1492, there should be no reason to reduce this further.

I see you live in London and the first hop latency is super high. You should have a first hop latency <5ms. Presumably this is Zen backhaul and your connection is taking the scenic route from London to Manchester to Docklands... did that change at the same times as your slow browsing?

[zappaDPJ]

I actually live in Kent on the SE coast but I'm not aware of any changes. That said we have had multiple fibre companies (five that I'm aware of) working in this area 16+ hours a day, 7 days a week for the last 6 months and it's been mayhem. In fact some of their antics have made the national press, including the installation of cabinets on private property without permission.

[Postal]

There is no sense to them asking to reduce your MTU if nothing else has changed. With PPPoE the MSS will be 1452 and the MTU 1492, there should be no reason to reduce this further.

I see you live in London and the first hop latency is super high. You should have a first hop latency <5ms. Presumably this is Zen backhaul and your connection is taking the scenic route from London to Manchester to Docklands... did that change at the same times as your slow browsing?

This Zen behaviour to load-balance their network by forcing people from the southern part of the country to access the internet via their Manchester hub has caused lots of adverse comment elsewhere on the internet.  Zen appear to have taken the view that it is not a problem and that users will have to put up with it.  IDNet seem to think that this is collateral damage after their money-saving move from BT backhaul to Zen and seem to have have no interest in helping their domestic customers as we are presumably individually not significant in their revenue streams.

At the moment we have no mobile signal or fibre so I don't want to change ISP and be forced onto VOiP.  We are having a mobile phone mast erected in our village; as soon as we have a viable signal so will have a time window for contact calls when we have a power cut IDNet will be consigned to the waste-bin where it can deal happily with its business customers while I find an ISP that actually wants to assist domestic customers.

[Adrian]

Recently, I almost returned to IDNet from AAISP but bottled out as I wasn't happy with IDNet's reliance on Zen backhaul.I'm glad I made that decision and I will be remaining with AAISP at least for the foreseeable future.

In the event that full fibre finally arrives in my postcode - not likely an time soon, sadly, even though Trooli provide a fibre service on the main road not 50 metres from my house, I may have to think again but until then I'll stick with what works extremely well.

[nowster]

Traceroute is not always a reliable measure, especially if there are heavily loaded routers on the way.

ICMP echo reply and UDP TTL hops exceeded messages are low priority and are often rate limited.