Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jaydub]

My IDNet FTTP connection has been exemplary since first connected on 20th February but something has changed between my last good test on 17th May and the first poor test on 15th May.   See my testing graph attached

Ookla Speedtest single thread speed test results showing similarly poor results except than when the target server is the IDNet host (see 2nd attachment).  Is this likely to be routing issues?

[EC300]

If the speed is hitting the ideal maximum to at least one test server it indicates the issue isn't with the back haul route to the gateway, so it is likely routing related after that point.  This doesn't mean bad routing, it might just mean they have some peering arrangements that are at capacity, and the problem is likely with IDNet as I don't think they use Zen's Wholesale service (where Zen supplies the internet connectivity) but just use Zen to get your connection delivered to their data centre. 

You can get an idea of IDNets peering arrangements here https://www.peeringdb.com/net/1108

Ideally if you could get the test servers IP address you can than do a tracert and find if the slower speeds are happening over a similar routing, which would help pinpoint the bottleneck.

[jaydub]

If the speed is hitting the ideal maximum to at least one test server it indicates the issue isn't with the back haul route to the gateway, so it is likely routing related after that point.  This doesn't mean bad routing, it might just mean they have some peering arrangements that are at capacity, and the problem is likely with IDNet as I don't think they use Zen's Wholesale service (where Zen supplies the internet connectivity) but just use Zen to get your connection delivered to their data centre. 

You can get an idea of IDNets peering arrangements here https://www.peeringdb.com/net/1108

Ideally if you could get the test servers IP address you can than do a tracert and find if the slower speeds are happening over a similar routing, which would help pinpoint the bottleneck.

Since posting this originally, things have continued in the same vein. There is been a minor drop off in the multithread results but a significant reduction in the single thread results (now in the range 36-60 Mbps - down from >=74Mbps.

Testing on speedtest.net shows the same sort of pattern with the IDNet server returning 74Mpbps results, but other test servers showing significantly less (typically ~45Mbps).

The IDNet response is that they have not had any reports from any other users nor any notifications of any network issues with any of the network operators they peer with.

Thanks for the pointers, EC300.  I did try tracerouting to the thinkbroadband.com IP address returned on a ping and got the following before getting loads of asterisks on the subsequent steps:

traceroute to 80.249.106.141 (80.249.106.141), 64 hops max, 52 byte packets
 1  192.168.1.254 (192.168.1.254)  1.418 ms  0.363 ms  0.289 ms
 2  telehouse-gw10-10g.idnet.net (212.69.63.54)  11.381 ms  10.529 ms  10.120 ms
 3  212.69.63.136 (212.69.63.136)  21.138 ms  33.204 ms  51.000 ms
 4  telehouse-gw7-10g.idnet.net (212.69.63.142)  11.495 ms  10.857 ms  10.204 ms
 5  et-0-0-2-112.edge-rt2.thdo.ncuk.net (80.249.97.109)  12.220 ms  11.289 ms  10.171 ms
 6  ae11-11.edge-rt1.thn.ncuk.net (80.249.97.20)  10.212 ms  11.441 ms  10.418 ms
 7  te1-52-61.core-rs3.lcy.ncuk.net (80.249.97.103)  12.097 ms  10.598 ms  11.574 ms
 8  te1-49-62.core-rs4.lcy.ncuk.net (80.249.97.99)  12.170 ms  11.585 ms  10.214 ms

Not sure it tells us very much other than it is going via telehouse.

Any advice and guidance appreciated.

[EC300]

For me to get to the IDNet speed tester it goes via idnet-gw-a.lonap.net, that is an IP address of 2a02:390:1:0:205f:aff:feb1:83  which gives >700Meg on a single threaded test (FTTP @ 1Gps).  I'm not sure what the IPv4 address is.

You really need to know the IP addresses of several of the servers from say Speedtest.net and trace them all, to see if the route is different.  If all test servers give a low single thread speed then we might see them all using a certain route, and the IDNet having a different routing that none of the others share, probably it's quite close to the gateway and its route is a few metres of cable!  Really this is something IDNet should be looking into, but from my experience they aren't very proactive, and just because they haven't had complaints from others doesn't mean there isn't a problem.

I was with another ISP and pulled them up on terrible congestion happening at certain times and they couldn't see it and said no one else had reported the issue, this went on for a few months and was supposedly escalated, and I left the ISP as they couldn't find a problem, not long after their whole network crashed due to congestion and they had to add more capacity urgently, and I had spotted the rumblings of problems many weeks prior.

[jaydub]

I did try and do what you suggested and managed to loacte the IP addresses of some of the UK speedtest.net servers, however I couldn't see any obvious pattern to the IP routes (most of them quickly converted to * * * responses).

My single thread speeds have now dropped to a fairly consistent 28Mbps on a 80/20 connection (constant over the last week).

IDNet are saying that 'it is likely to be upstream from us as this is demonstrated by the single thread test to their speedtest.net server within their network which eliminates both their network and their wholesale supplier network.'

I remain surprised that they don't want to investigate further, so am planning to migrate out to see if I can do better elsewhere.

Edited to add the traceroute to the TBB speedtest server:

traceroute to 80.249.107.194 (80.249.107.194), 64 hops max, 52 byte packets
 1  192.168.1.254 (192.168.1.254)  1.149 ms  0.519 ms  0.444 ms
 2  redbus-gw11-10g.idnet.net (212.69.63.36)  10.833 ms  10.583 ms  12.598 ms
 3  212.69.63.140 (212.69.63.140)  12.620 ms  10.988 ms  11.173 ms
 4  telehouse-gw7-10g.idnet.net (212.69.63.142)  11.171 ms  12.569 ms  12.596 ms
 5  et-0-0-2-112.edge-rt2.thdo.ncuk.net (80.249.97.109)  11.260 ms  12.743 ms  11.237 ms
 6  * * *

[EC300]

Of course their network also extends to Internet connectivity, and it will be their onward peering arranges or a switch/router somewhere that needs sorting out or upgrading.  They are an Internet Service Provider, not an Intranet Service Provider to just their own speedtest server

When I was with them and raised issues about constant drops over Zens backhaul, which I was never notified about in advance, and that the latency varied from 7ms to 16ms depending on how Zen routed me after they pull the connection (presumably to load balance overnight), and I pointed out they advertise being the lowest latency ISP, yet they couldn't guarantee me the lowest latency as sometimes it was the worst latency I've ever seen from an ISP due to routing by Zen, they just said "nothing we can do".  So that was it, I was off as soon as contract up, and they basically falsely advertise.

[jaydub]

It's quite sad really.

Several years ago when they moved me to FTTC, they swapped me between TTB and ZenW to BTw backhauls and I felt they were really responsive to our needs as a customer.

I do wonder whether they as a company have got too focussed on margin or alternatively they know they have issues and are on a party line in terms of their responses.

Either way it doesn't feel like the current IDNet is the same company as the one I have been recommending to others for the last few years.

Time to move on.  Favouring staying with BTw backhaul, which leaves AA, Aquiss and UNO as the favoured options.

[EC300]

IDNet did swap customers from ZenW to TTB if there were problems, but this stopped being an option a few years ago, around the same time that Zen stopped doing it for their own customers.  So IDNet are pretty much tied to Zen and are probably using Zen's wholesale service to get their customers data into their kit. 

Uno were always brilliant when I was with them for a number of years, unfortunately they still don't do IPv6 which is now a requirement for me to get to some work machines when working from home.  When I checked pricing for FTTP 1000/100, they were quite expensive, matching AAs pricing.

I went to Aquiss after IDNet and had problems from day one.  I had really bad congestion at certain times of day, we are talking 900Meg dropping to 8 or 10 Meg on the worst days and huge increases in latency!

Worth noting that Aquiss aren't an ISP, they are reseller, they resell Entanet's product (Entanet now owned by CityFibre). So Aquiss can't buy new kit, add capacity, reboot switches etc, it all goes via CityFibre Wholesale.  After months of back and forth CityFibre said they could find no issue or problems with congestion and Aquiss let me leave the contract early.  A few months after I left, Aquiss/CityFibre had problems with their network and invoked their 'emergency' network teams, apparently they had run out of capacity and everyone was grinding to a halt.  I can't believe they didn't know they were running their network hot, people like me had been suggesting capacity problems for months and just told to go away essentially.

So I bit the bullet and paid a premium for AA, went live, all my kit was exactly the same as it was with Aquiss, just updated the username and password and all congestion issues vanished instantly. Aquiss had been suggesting my problems were local to me and likely related to capacity issues in my area, i.e. a BT Wholesale issue, but that was proved completely false as I was still going via BT Wholesale with AA.

As for AA, just can't fault them, over a year now and its been reliable with no slow downs.  Think I've had one issue where I got thrown offline during the day as they had a problem with a router.  As their service status gets updated immediately (not hours after the event like most), I could see it wasn't my end so saved all the rebooting of kit to rule me out, so I went for cup of tea, and by the time I was back it was up and running again.

Good luck with who you decide to move to next.

[jaydub]

Had an interesting call with Uno this morning.  They are moving to 1 month contracts only (good news) and not declaring who their backhaul providers are other than to confirm they aren't using ZenW (not such good news!).  Prices for 80/20 and 115/20 slightly undercut AAISP for 115/20, but it does leave an air of uncertainty about who would be providing the underlying connection.  Obviously not BTw as they don't do 1 month contracts, but who?

I still get caught in the quandary of the quality of AAIDP vs the cost savings of Aquiss.  The free router with AAISP does is some way negate the cost difference, so slightly favouring them at the moment.

Edited:  Went with AAISP.  The router and the additional analysis tools won the day.

[EC300]

You will be glad of your choice I'm certain of that.  Sometimes it is worth paying more, i.e. you do get what you pay for.

Odd UNO will not tell you which back-haul they use.

Let us know how you get on when you make the switch.

[jaydub]

You will be glad of your choice I'm certain of that.  Sometimes it is worth paying more, i.e. you do get what you pay for.

Odd UNO will not tell you which back-haul they use.

Let us know how you get on when you make the switch.

The migration went through in the early hours of the morning and the difference between IDNet and AAISP is night and day.

Minimum ping times have dropped from 9ms to 7ms and the TBB speed test results are markedly different.  Compare last nights IDNET result with this morning's AAISP result.

The only issue I have had was with my AAISP VOIP line, where I couldn't find where I had set the outgoing IP address.  A quick phone call to the AAISP help desk had it sorted in very quick time.

I have always been reluctant to pay AAISP's prices, however on the first few hour's experience that is a case of more fool me!  I am seriously impressed so far.

[EC300]

Good news it sorted your speed issues (so proving IDNet was the problem) and that you are up and running with AAISP.  Those charts couldn't be more different.