Well, they seem to be taking my query seriously at least, and have escalated to "the tier 3 team" with the promise to extend my cancellation window until after they've replied. I'm still expecting the response to amount to "that's how it is, deal with it" but for a cheapo ISP I've been fairly impressed with their support handling overall.

Will be interested to hear how you get on & if they commit to reducing latency or improving performance somehow.

Their bandwidth/throughput is very good, I've had the HB service for over 2 years and have almost never had any bandwidth issues. However, latency performance is far more important for me and if anything has been getting worse recently, to the point of it being noticeably slower on my work connection.

In reply to a post by Kans:

I hadn't seen these Azure/AWS test sites before, so I ran some comparative tests on my connections. I have both HeyBroadband FTTP and TalkTalk FTTC at the moment. Both are running through the same firewall, so it's a relatively good comparative test. HB goes directly from ONT to the firewall, TalkTalk through an openreach modem, the TalkTalk router, then the firewall (so has extra hops/steps).

These tests are from https://www.azurespeed.com/Azure/Latency and https://www.cloudping.cloud/aws. The AWS version of the first one doesn't seem to work properly for me, it shows over 100ms to everything.

Text
1 23 45 67 89 1011	HeyBroadband Azure Spain Central (Madrid)      40 msSwitzerland North (Zurich)  45 ms Italy North (Milan)         46 ms  HeyBroadband AWSParis eu-west-3             19.6 London eu-west-2            27.4Stockholm eu-north-1        40.4 Ireland eu-west-1           41.8Zürich eu-central-2         48.4

Text
1 23 45 67 89 1011	TalkTalk Azure UK South (London)           15 msUK West (Cardiff)           17 ms France Central (Paris)      20 ms  TalkTalk AWSLondon eu-west-2             7.6 CloudFront CDN               9.6Paris eu-west-3             17.4 Ireland eu-west-1           19.4Frankfurt eu-central-1      22.6

This shows the considerable latency and routing difference between the two providers. I'm having TalkTalk FTTP installed on Monday (or at least that's the schedule), so I'll re-run these tests to see if there's much difference between their FTTC and FTTP products for latency.

I had F&W install a few days ago and I'm currently with Hey!BB. I see similar weirdness.

It looks like the problem is that connections to Azure go via NEAR IP and Tata Communications, and Tata is routing the traffic via Frankfurt (for reasons which aren't entirely obvious to me). I discovered this by running an MTR to a RIPE Atlas probe hosted by Azure in London:

Host                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                         0.0%   159    0.6   0.3   0.2   0.7   0.1
 2. 193-28-11-2.fwnetworks.co.uk                     0.0%   159    4.6   4.5   3.7   5.3   0.2
 3. 172.16.245.0                                    47.2%   159    4.9   4.8   4.4   5.3   0.2
 4. 194.35.42.8                                     95.6%   159    4.9   4.8   4.6   5.0   0.1
 5. ix-xe-0-1-7-0.thar2.ld5-slough.as6453.net        0.0%   159    4.9   5.1   4.5  19.1   1.4
 6. if-be-24-2.ecore1.ld5-slough.as6453.net         21.4%   159   21.8  21.6  21.0  22.5   0.3
 7. if-bundle-36-2.qcore4.ldn-london.as6453.net     84.8%   159   22.1  21.7  21.2  22.6   0.4
 8. 195.219.213.138                                 79.1%   159   22.3  22.1  21.5  23.0   0.4
 9. if-bundle-13-2.qcore2.pye-paris.as6453.net      42.1%   159   21.6  22.0  20.8  23.7   0.5
10. if-bundle-2-2.qcore1.pye-paris.as6453.net       48.1%   159   21.3  21.5  20.7  23.9   0.5
11. if-bundle-22-2.qcore1.pvu-paris.as6453.net      79.1%   159   22.5  22.2  21.5  24.1   0.5
12. if-bundle-12-2.qcore2.pvu-paris.as6453.net      83.0%   159   21.7  21.9  21.3  22.7   0.4
13. if-bundle-56-2.qcore1.fr0-frankfurt.as6453.net  88.5%   158   22.3  22.0  21.2  22.6   0.4
14. (waiting for reply)
15. (waiting for reply)
16. (waiting for reply)
17. (waiting for reply)
18. (waiting for reply)
19. (waiting for reply)
20. (waiting for reply)
21. (waiting for reply)
22. (waiting for reply)
23. (waiting for reply)
24. (waiting for reply)
25. 20.117.70.193                                    3.9%   152   50.4  50.4  49.9  53.2   0.4

NEAR IP has an open peering policy and Microsoft has a selective peering policy (although the policy itself doesn't seem too bad -- minimum of 500MB [sic. ?] of traffic). They're both present on LINX LON1 and LONAP so hopefully they'll peer.

They've just got back to me again, claiming to have had a "peering issue with one of their providers", which is now apparently resolved. They also said that they've been working on direct Azure peering, which is due to go live sometime in the next 2 weeks.

So far no change from my end in terms of fastest routes to Azure or overall ping times, but if the claim about direct peering is true then that should improve dramatically soon. I'll post back if/when I hear anything further.

In reply to a post by behuk:

I had F&W install a few days ago and I'm currently with Hey!BB. I see similar weirdness.

It looks like the problem is that connections to Azure go via NEAR IP and Tata Communications, and Tata is routing the traffic via Frankfurt (for reasons which aren't entirely obvious to me). I discovered this by running an MTR to a RIPE Atlas probe hosted by Azure in London:

Seeing as this thread is titled Swish vs Hey!?, here's an mtr to the same probe via Swish:

Packets               Pings
 Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev 
 1. gateway                                     0.0%    25    0.1   0.2   0.1   0.2   0.0 
 2. 31.xx.xx.x                                  0.0%    25   14.2  15.7   2.4  56.9  12.4 
 3. 10.240.10.16                                0.0%    25    3.2   3.9   3.0  17.3   2.9 
 4. 10.240.10.251                               0.0%    25    3.8   3.5   3.3   3.8   0.1 
 5. cust-141-195-128-178.jurassic-fibre.net     0.0%    25    3.6   3.7   3.5   3.9   0.1 
 6. 172.20.0.76                                 0.0%    25    4.0   4.0   3.5   4.5   0.2 
 7. 172.20.0.87                                 0.0%    25    3.7   3.8   3.5   4.2   0.2 
 8. 5.57.81.18                                  4.0%    25  127.5  83.5   6.1 139.6  53.0 
 9. ae21-0.icr04.lon24.ntwk.msn.net             0.0%    25    4.4   7.7   4.2  23.7   5.1 
10. (waiting for reply)
11. (waiting for reply)
12. (waiting for reply)
13. (waiting for reply)
14. (waiting for reply)
15. (waiting for reply)
16. (waiting for reply)
17. (waiting for reply)
18. (waiting for reply)
19. (waiting for reply)
20. (waiting for reply)
21. (waiting for reply)
22. 20.117.70.193                               0.0%    24    4.8   4.8   4.7   5.0   0.1

We're not talking about Swish much because they're boringly straightforward. Your trace shows that they peer with Microsoft at LONAP (hop 8), which is what I'd expect for any major ISP in the UK (I expect they also have a peering session at LINX for redundancy).

Sadly Swish seem to struggle with pricing and replying to emails -- I emailed sales@ to try and discuss my options now I've completed my minimum commitment but didn't get any reply. It's difficult to justify paying £50 per month when Hey!Broadband have a Black Friday sale at £21.50 per month!

Regarding Hey!Broadband and Microsoft... I now see my traffic going via LEAP IP (of course) and Arelion. There's still more latency then we would expect, but at least London is now "only" ~38ms away (and it's the lowest latency Azure region). Hopefully LEAP end up successfully establishing peering with Microsoft in London.

In reply to a post by behuk:

Sadly Swish seem to struggle with pricing and replying to emails -- I emailed sales@ to try and discuss my options now I've completed my minimum commitment but didn't get any reply. It's difficult to justify paying £50 per month when Hey!Broadband have a Black Friday sale at £21.50 per month!

Just been through something similar. Have just renewed with Swish at £28/mo, but with considerable misgivings. My only other alternative for FTTP is Trooli, and their current offer was tempting, but it would mean more boxes and holes in the wall, and long term (when OR finally get here) I don't see myself staying with either Swish or Trooli. Swish's CS is pants these days, they hardly ever reply to emails, they don't follow up when they say they will, and finding someone on the phone who talks sense is increasingly hard. OTOH I've been with them 2 years now, their service has been good, so I rarely need to tangle with CS.

In reply to a post by Thaumaturge:

Just been through something similar. Have just renewed with Swish at £28/mo, but with considerable misgivings. My only other alternative for FTTP is Trooli, and their current offer was tempting, but it would mean more boxes and holes in the wall, and long term (when OR finally get here) I don't see myself staying with either Swish or Trooli. Swish's CS is pants these days, they hardly ever reply to emails, they don't follow up when they say they will, and finding someone on the phone who talks sense is increasingly hard. OTOH I've been with them 2 years now, their service has been good, so I rarely need to tangle with CS.

Same, to be honest. I renewed onto the 900Mb package at £37/mo plus £3 static IP. Billing switchover went fine but my static IP disappeared. Took a week of daily calls, each with a promise from them of an update that never came and a continued insistence that it 'should' work and they couldn't see anything wrong. At one point I was told to call their NOC (which, I know now, is 24/7 except for when the engineer's on lunch) myself and sort it out directly. Still didn't help and the NOC guy was very confused as to why he was getting a call direct from a customer.

The way Swish does static IPs is by mapping the router's WAN MAC address to the IP, so if you change routers you lose your static IP and are back to CGNAT. However I hadn't changed anything. Eventually one of the agents read back to me the MAC they'd allocated my static IP to and it turned out someone must have manually prepended two extra hex digits to my router's WAN MAC address in their mapping table. Once I pointed this out to them they could finally fix it.

The way Swish does static IPs is by mapping the router's WAN MAC address to the IP, so if you change routers you lose your static IP and are back to CGNAT.

Nearly all modern routers support MAC spoofing. I spoof the MAC of the Swish provided router that I have never used.

You can find the expected MAC on the devices tab of the Swish account page.

https://portal.swishfibre.com/Devices

I agree with everything you've said here. Their service largely works as you'd expect, but what was a great deal when I first signed up to them is now quite expensive compared to other offerings and while they were quick on the ball to get a replacement sorted when my ONT died, your chances of engaging their email support is slim to none.

Hey, on the other hand, I've honestly been very impressed with. They have a live chat on their website, which is a bit hit and miss, but I raised this whole Xbox latency thing with them via email and for a query that I expected to go nowhere they've been fantastic. The same agent followed the case right up to their peering team and they've emailed today to say that the direct Azure peering has gone live, and I've confirmed that my Xbox pings have dropped from ~80ms to 14ms - the same as I got with Swish. Meanwhile, the Azurespeed website is now showing the two UK datacentres and France as the "closest", rather than Spain, Italy, and Germany.

I'd happily recommend them.