Well, some here need to get out a bit more. There's more to NZ than big smoke... lol!
In most urban areas, the cellsites have fibre uplink. In rural areas, however, it's a mixture, depending on site location. Example: Tukino Vodafone cellsite provides coverage to most of Desert Rd/SH1 - it is fed by radio link from Rangipo Dam and Rangipo Power Station. In the same area, the Pihanga Vodafone site on top of the mountain is also radio fed. But Spark and 2degrees sites are both in Turangi urban area and are both fed by fibre. While the Pihanga Vodafone site covers a large area, Vodafone made a decision in mid-term to not upgrade the site from 3G to 4G - the reasons for it might be that the capacity of the radio link wouldn't be able to handle the traffic, power usage, and reach of 3G is also larger - but that's just possible reasons why. The Spark and 2degrees are both 4G and fibre-fed, but without the reach of Vodafone site. RCG (Rural Connectivity Group) shared hosting sites are mostly fibre-fed, with some exceptions (like Haast's satellite uplink right now). You can see some of these radio links here: https://gis.geek.nz/map/pointtopoint/
Radio, by the nature of it, is prone to interference and is a finite resource. Technology leaps mean we can squeeze more out of it. But the fact that there are often multiple hops involved and there is finite amount of capacity, and the fact that it is a shared medium - there is a fair amount of prioritising, and then the lag increases by the nature of it. And while bandwidth could get increased without too much fuss (ignoring legal constraints), the lag is not something that can be easily controlled or reduced. So no need to diss my comment about difference between radio and fixed links.
Why am I so concerned about the lag? Because I work on remote consoles a lot... on a normal week that's 8 hours a day 5 days a week. And trust me, I can tell the difference without running a tracert, ping or mtr. My day-to-day job involves connecting to a number of SSH and RDP end-points, mostly located within NZ, with some on AWS (mostly on US East Coast - yikes)...
And unlike some others, I'm more concerned about the lag, rather than the download and upload speeds. For my work a low-lag (<20ms) 5mbps+ connection is completely sufficient. While another link that is 100mbps+ but with high latency is actually slower for me than the first!
And it seems that unlike others, I do not watch netflix, youtube and browse facebook for work, so the hop over the ditch to AWS, Google or Azure data centres is not as relevant to my needs. Some of my work involves managing automated production lines involving robotics, but a lot of that is between the machine and the server locally hosted in the factory. So I've been through a fair bit in my field to try to reduce lag internally.
I understand that there is inherent lag involved with wireless networks. I also know that 5G will be able to cut down the lag a fair amount, but the coverage of 5G will be quite limited for a long time yet.
I always try to connect to fixed networks wherever I can, or rural ISPs. But travelling around a fair bit means that I'm often stuck with Vodafone RBI and Spark as a backup. Actually, I'd like to make it clear that I am not complaining, as I feel very lucky to have these options while I chose the lifestyle that we have right now, and I'm very happy with what I got. I am just questioning the apparent extra lag on Spark's network. That's the point of my post.
I wanted to add another test to demonstrate that the extra 10-30ms on Spark (skinny) is nothing to do with peering, and I got interesting results!
I'm hitting www.spark.co.nz for ICMP and https://www.spark.co.nz/content/dam/sparkdigital/images/logo/purple.svg for HTTP head requests... Please don't tell me there is ISP cache involved. There isn't. It's https.
On Vodafone (NetSpeed RBI): LOL - it's actually going via Sydney, and back to Auckland... that's why I wasn't using spark as an example before, because as we all know, they don't play the ball peering locally ICMP: 45.3ms / 65.2ms (best/average 100 packets) HTTP: 281ms / 341ms (best/average 20 requests)
I was hoping that someone with insider knowledge can perhaps explain what happens between 10.207.xxx.xxx and 122.56.113.7 internally within Spark, as that is where the extra 10-30ms is always gained (in my experience). That particular hop changes more or less with alleged peak usage, (***roughly*** ~10ms 12am-6am, ~20ms 6am-6pm, ~30ms 6pm-12am) - I'm suspecting some kind of a network infrastructure internally is responsible for that extra delay. Is it the journey to the handover point in Auckland perhaps? Or it is CGNAT? Or is it routed through Waihopai (just kidding)?
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
ID Verified
