One NZ Fibre from Wellington

As others have said, 45.63.24.38 doesn't respond to ICMP, however it looks like its neighbour, 45.63.24.40, does - so this would probably help any testing.

With that in mind, here's a neutral measurement from all 114 RIPE Atlas probes across New Zealand (noting there may be some ISPs without probes inside their network, or don't operate their own ASN):
https://atlas.ripe.net/measurements/157789108

This shows:

• Probe 61351 should be ignored, as it's clearly in Australia and has been misclassified as being in NZ.
• 23-25ms ex Auckland is pretty normal across a number of providers, in particular those with residential offerings are (in no particular order):

   

  • Vetta/Quic
  • Compass
  • Mercury
  • Lightwire
  • 2degrees
  • Sky
  • Voyager
  • Spark

Also as others have mentioned, the above should be taken purely as a "point in time" reference, as paths and routes are dynamic and changing for various reasons, however given this is only in Sydney and not in somewhere like Europe, I wouldn't imagine a massive amount of fluctuation, somewhat already shown within the RIPE Atlas results.

Hope this helps with some cross-ISP data. All the best with your search!

Hello again everybody, firstly I would like to thank all of you in helping me make my decision, currently experiencing around 50ms of jitter on the Mercury ASN handoff ( as55850.sydney.megaport.com ). so I will look into choosing an ISP that routes via Auckland. Just out of curiosity do any ISP's offer Traffic Prioritization as an add on. I guess you guys would call it High Priority Access. I see Chorus offer this but my fibre infrastructure is managed by Tuatahi fibre. Had a quick look at their website i cant see any higher traffic options. Appreciate the Atlas RIPE Probe just looking at all the routes now. Everyone's been a huge help.

yitz:

 

Main difference with Quic would be all your traffic will go to Auckland first, your current ISP Purelink is locally based and looks to pick up their international connectivity in Hamilton (their handover hop 5 looks to be on hn-br-1.as55850.net) so probably send it directly to Sydney via Tasman Global Access submarine cable.

 

That wouldn't make much difference to latency though.

 

Was your traceroute run over WiFi?

 

Hi no it was run over hardwired ethernet via pingplotter.

Smedcy:

 

Hello again everybody, firstly I would like to thank all of you in helping me make my decision, currently experiencing around 50ms of jitter on the Mercury ASN handoff ( as55850.sydney.megaport.com ). so I will look into choosing an ISP that routes via Auckland. Just out of curiosity do any ISP's offer Traffic Prioritization as an add on. I guess you guys would call it High Priority Access. I see Chorus offer this but my fibre infrastructure is managed by Tuatahi fibre. Had a quick look at their website i cant see any higher traffic options. Appreciate the Atlas RIPE Probe just looking at all the routes now. Everyone's been a huge help.

 

Not on a residential offering, no. That would be something which providers would look at from a Business or Enterprise service, with prioritisation and/or CIR. 

Is the 50ms jitter between you and your end point actually causing an issue?

I think the end point matters the most so as a gamer (and as someone who is a Mercury customer currently*) and am surrounded by some amazing, knowledgeable peers... I don't think this is an issue, unless you can absolutely prove it. I certainly haven't noticed anything ill between me and Sydney as of late.

ICMP deprioritization can happen. The in-between hops can just either drop ICMP, give it very very low priority or pass it as is. And it looks like there's some serious depriortization. The end point isn't seeing the same deviation OR the up to 130ms spikes in between.

Here it is from a Mercury connection in Christchurch. And apart from adding anywhere between 15-16ms additional latency... honestly for 363 pings it's pretty decent.

https://smokeping-nz1.yukaritakeba.com/smokeping/?displaymode=n;start=2025-03-06%2012:01;end=now;target=Vultr.AP.ap-au-sydney
I'm also looking at the test target to Vultr's own speedtest and nothing has changed that would cause a significant issue.

For giggles, I have added this to my smoke ping. https://smokeping-nz1.yukaritakeba.com/smokeping/?target=Testing.GZThread324100EndPoint