![]() ![]() ![]() |
|
I can hardly believe it - RBI Wireless now has better figures than UFB Fibre!
Pinging geekzone.co.nz [104.24.3.14] with 32 bytes of data:
Reply from 104.24.3.14: bytes=32 time=65ms TTL=56
Reply from 104.24.3.14: bytes=32 time=68ms TTL=56
Reply from 104.24.3.14: bytes=32 time=67ms TTL=56
Reply from 104.24.3.14: bytes=32 time=70ms TTL=56
Wahoo.. ๐
colinuu:
I can hardly believe it - RBI Wireless now has better figures than UFB Fibre!
Pinging geekzone.co.nz [104.24.3.14] with 32 bytes of data:
Reply from 104.24.3.14: bytes=32 time=65ms TTL=56
Reply from 104.24.3.14: bytes=32 time=68ms TTL=56
Reply from 104.24.3.14: bytes=32 time=67ms TTL=56
Reply from 104.24.3.14: bytes=32 time=70ms TTL=56
Wahoo.. ๐
apples and oranges
its down to routing, compare that to someone on im guessing vodafone and they will likely beat you on that stat.
Ping wird ausgeführt für geekzone.co.nz [2606:4700:20::6818:30e] mit 32 Bytes Daten:
Antwort von 2606:4700:20::6818:30e: Zeit=12ms
Antwort von 2606:4700:20::6818:30e: Zeit=14ms
Antwort von 2606:4700:20::6818:30e: Zeit=15ms
Antwort von 2606:4700:20::6818:30e: Zeit=13ms
via WiFi
- NET: FTTH, OPNsense, 10G backbone, GWN APs, ipPBX
- SRV: HA server cluster, 0.1PB storage capacity on premise
- IoT: zigbee, tasmota, BidCoS, LoRa, WX sensor suite, IR
- 3D: two 3D printers, 3D scanner, CNC router, laser cutter
If you are interested in performance to peered end points, then don't use an ISP that refuses virtually all peering as Spark does, that's your bottom line. Your traffic will still work, but optimal routing is just not on the cards.
[root@nostromo ~]# ping www.geekzone.co.nz
PING www.geekzone.co.nz (104.24.3.14) 56(84) bytes of data.
64 bytes from 104.24.3.14 (104.24.3.14): icmp_seq=1 ttl=57 time=2.75 ms
64 bytes from 104.24.3.14 (104.24.3.14): icmp_seq=2 ttl=57 time=2.08 ms
64 bytes from 104.24.3.14 (104.24.3.14): icmp_seq=3 ttl=57 time=2.18 ms
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
noroad:
If you are interested in performance to peered end points, then don't use an ISP that refuses virtually all peering as Spark does, that's your bottom line. Your traffic will still work, but optimal routing is just not on the cards.
[root@nostromo ~]# ping www.geekzone.co.nz
PING www.geekzone.co.nz (104.24.3.14) 56(84) bytes of data.
64 bytes from 104.24.3.14 (104.24.3.14): icmp_seq=1 ttl=57 time=2.75 ms
64 bytes from 104.24.3.14 (104.24.3.14): icmp_seq=2 ttl=57 time=2.08 ms
64 bytes from 104.24.3.14 (104.24.3.14): icmp_seq=3 ttl=57 time=2.18 ms
A smart user will balance this (fair) comment with the performance of the other 98% (approx guess) of your internet use. There will be some users that spend all day downloading only from peered locations and I would expect those users to be over-represented here, but some ISPs invest massively in distributed CDNs which have a MUCH higher benefit for most customers than some peering connections.
N.
--
Please note all comments are the product of my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.
A smart user will balance this (fair) comment with the performance of the other 98% (approx guess) of your internet use. There will be some users that spend all day downloading only from peered locations and I would expect those users to be over-represented here, but some ISPs invest massively in distributed CDNs which have a MUCH higher benefit for most customers than some peering connections.
N.
Yep, CDN's are good, but Spark could fire up a 100G link within Mayoral Drive (doesn't even need to leave Spark's own building) to Auckland-IX and significantly improve its customer performance to peered services for the princely sum of $1200/month, but doesn't care enough to do so.... Damn cheap way to make those customers happy, but policies are policies eh
Bigpipe UFB from wired ethernet connected linux desktop:
$ ping -c 5 www.geekzone.co.nz
PING www.geekzone.co.nz (104.24.3.14) 56(84) bytes of data.
64 bytes from 104.24.3.14: icmp_seq=1 ttl=53 time=210 ms
64 bytes from 104.24.3.14: icmp_seq=2 ttl=53 time=211 ms
64 bytes from 104.24.3.14: icmp_seq=3 ttl=53 time=210 ms
64 bytes from 104.24.3.14: icmp_seq=4 ttl=53 time=213 ms
64 bytes from 104.24.3.14: icmp_seq=5 ttl=53 time=212 ms
--- www.geekzone.co.nz ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 307ms
rtt min/avg/max/mdev = 210.284/211.324/213.042/1.032 ms
#include <standard.disclaimer>
Talkiet:
A smart user will balance this (fair) comment with the performance of the other 98% (approx guess) of your internet use. There will be some users that spend all day downloading only from peered locations and I would expect those users to be over-represented here, but some ISPs invest massively in distributed CDNs which have a MUCH higher benefit for most customers than some peering connections.
N.
Or you could choose an ISP which does both :-)
Sounddude:
Talkiet:
A smart user will balance this (fair) comment with the performance of the other 98% (approx guess) of your internet use. There will be some users that spend all day downloading only from peered locations and I would expect those users to be over-represented here, but some ISPs invest massively in distributed CDNs which have a MUCH higher benefit for most customers than some peering connections.
N.
Or you could choose an ISP which does both :-)
I would give you kudos for a nice comeback .... if it hadn't taken you 5 weeks to think of it. How's that for latency? ;)
Spark beats Vocus on both Netflix and Youtube performance. Just sayin'.
My views are my own, and may not necessarily represent those of my employer.
cbrpilot:
I would give you kudos for a nice comeback .... if it hadn't taken you 5 weeks to think of it. How's that for latency? ;)
Spark beats Vocus on both Netflix and Youtube performance. Just sayin'.
Hey now - according to that list 2degrees ranks below Orcon etc and yet, YouTube 4K content and Netflix 4K content starts straight away with me. My user experience is great. I am very tempted to move to Spark in order to shave a few ms off the time it takes to start a video as that could equal a whole second of time saved over a year. NZ broadband is great so really, that list means nothing.
From the users running a test to geekzone.co.nz it does show that users don't understand that Spark are (IIRC) the only ISP that don't peer with Cloudflare in NZ. But it isn't only just Cloudflare, there are other services also.
Many ISP's understand end user experience is a very important aspect. Sure, you can have the best caches in the country but if you're missing the little things such as services that are getting more and more popular by the day then you really don't care about end user experience.
This is what Vocus, 2degrees and other ISP's just simply get right. Everything works and well.
Anyway... This is waaay off topic. Lets just get back on topic here guys.
Michael Murphy | https://murfy.nz | https://keybase.io/michaelmurfy - Referral Links: Sharesies | Electric Kiwi
Are you happy with what you get from Geekzone? Please consider supporting us by making a donation.
cbrpilot:
Spark beats Vocus on both Netflix and Youtube performance. Just sayin'.
We share our CDN nodes with a large number of ISP's who don't have their own CDN nodes. So the number you see doesn't actually reflect the true Vocus brands results, but a larger portion of the NZ ISPs (many who are RBI or Community Wireless).
Sounddude:cbrpilot:Spark beats Vocus on both Netflix and Youtube performance. Just sayin'.
We share our CDN nodes with a large number of ISP's who don't have their own CDN nodes. So the number you see doesn't actually reflect the true Vocus brands results, but a larger portion of the NZ ISPs (many who are RBI or Community Wireless).
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
hio77: Implying there aren't community wireless providers who sit behind sparks CDN nodes?...
Just saying that stats are pretty meaningless in their current form. :-)
|
![]() ![]() ![]() |