Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.
View this topic in a long page with up to 500 replies per page Create new topic
1 | 2 
'That VDSL Cat'
8103 posts

Uber Geek
+1 received by user: 1693

Trusted
Spark
Subscriber

  Reply # 1983848 26-Mar-2018 21:48
Send private message quote this post

whizbang:

 

hio77:

 

i wouldn't recommend speedtest cli as a primary for throughput tests as it's typically a poor performer.

 

 

 

seems a little spikey particularly looking at the spark server tests, was the network isolated while running these tests?

 

 

 

 

Yes - so first I disabled wifi and rebooted the router.  My PC is directly connected by ethernet cable and is the only device turned on, which is connected to the router.  The only other device which is connected via ethernet is another PC, which has been turned off all day.

 

 

perfect.

 

 

 

can you do some more traceroutes/pings to affected routes while running one to a normal route (say trademe) at the same time for compassion

 

 





#include <std_disclaimer>

 

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.




24 posts

Geek


  Reply # 1983852 26-Mar-2018 21:56
quote this post

hio77:

 

whizbang:

 

hio77:

 

i wouldn't recommend speedtest cli as a primary for throughput tests as it's typically a poor performer.

 

 

 

seems a little spikey particularly looking at the spark server tests, was the network isolated while running these tests?

 

 

 

 

Yes - so first I disabled wifi and rebooted the router.  My PC is directly connected by ethernet cable and is the only device turned on, which is connected to the router.  The only other device which is connected via ethernet is another PC, which has been turned off all day.

 

 

perfect.

 

 

 

can you do some more traceroutes/pings to affected routes while running one to a normal route (say trademe) at the same time for compassion

 

 

 

 

 

 

Unfortunately I have had to re-enable wifi as the other members of the house were on verge of mutiny, so the readings now won't be as accurate or reliable i'm afraid.




24 posts

Geek


  Reply # 1985121 28-Mar-2018 20:26
quote this post

Ok, here are some pings to Flip and to trademe which were running concurrently....

 

time ping www.trademe.co.nz
PING www.trademe.co.nz (202.162.73.2) 56(84) bytes of data.
64 bytes from www.trademe.co.nz (202.162.73.2): icmp_seq=2 ttl=248 time=22.0 ms
64 bytes from www.trademe.co.nz (202.162.73.2): icmp_seq=3 ttl=248 time=14.2 ms
64 bytes from www.trademe.co.nz (202.162.73.2): icmp_seq=4 ttl=248 time=13.6 ms
64 bytes from www.trademe.co.nz (202.162.73.2): icmp_seq=5 ttl=248 time=14.0 ms
64 bytes from www.trademe.co.nz (202.162.73.2): icmp_seq=6 ttl=248 time=19.9 ms
64 bytes from www.trademe.co.nz (202.162.73.2): icmp_seq=7 ttl=248 time=14.7 ms
^C
--- www.trademe.co.nz ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 6008ms
rtt min/avg/max/mdev = 13.608/16.447/22.091/3.315 ms

 

real 0m6.588s
user 0m0.000s
sys 0m0.009s

 

 

 

time ping 103.9.40.1
PING 103.9.40.1 (103.9.40.1) 56(84) bytes of data.
64 bytes from 103.9.40.1: icmp_seq=1 ttl=60 time=16.3 ms
64 bytes from 103.9.40.1: icmp_seq=2 ttl=60 time=13.4 ms
64 bytes from 103.9.40.1: icmp_seq=3 ttl=60 time=13.8 ms
64 bytes from 103.9.40.1: icmp_seq=4 ttl=60 time=13.5 ms
64 bytes from 103.9.40.1: icmp_seq=5 ttl=60 time=16.1 ms
64 bytes from 103.9.40.1: icmp_seq=6 ttl=60 time=15.0 ms
64 bytes from 103.9.40.1: icmp_seq=7 ttl=60 time=13.1 ms
64 bytes from 103.9.40.1: icmp_seq=8 ttl=60 time=12.8 ms
64 bytes from 103.9.40.1: icmp_seq=9 ttl=60 time=12.8 ms
64 bytes from 103.9.40.1: icmp_seq=10 ttl=60 time=14.9 ms
64 bytes from 103.9.40.1: icmp_seq=11 ttl=60 time=12.8 ms
64 bytes from 103.9.40.1: icmp_seq=12 ttl=60 time=12.8 ms
64 bytes from 103.9.40.1: icmp_seq=13 ttl=60 time=13.3 ms
64 bytes from 103.9.40.1: icmp_seq=14 ttl=60 time=14.2 ms
64 bytes from 103.9.40.1: icmp_seq=15 ttl=60 time=13.2 ms
64 bytes from 103.9.40.1: icmp_seq=16 ttl=60 time=13.8 ms
64 bytes from 103.9.40.1: icmp_seq=17 ttl=60 time=12.9 ms
^C
--- 103.9.40.1 ping statistics ---
17 packets transmitted, 17 received, 0% packet loss, time 16023ms
rtt min/avg/max/mdev = 12.817/13.860/16.355/1.104 ms

 

real 0m16.461s
user 0m0.005s
sys 0m0.005s

 

 

 

14% Packet loss to trademe, 0% to Flip's server.  Both running concurrently.  It is still early in the evening, usually the slowdown (when it happens) becomes apparent from 8:30pm-9:45pm, but can vary slightly from these times.  But this is a symptom.  It's intermittant too.  If I pinged trademe again, it would 80% of the time be fine, it is just the other 20% it can sit for before connecting.  The rate of this occurrence increases between 8:30 - 9:45pm on a bad night.

 

The initial connection is almost always the problem.  After that fine.  Both for local and international traffic, but as the majority of sites I look at are international, that is what I notice first.  The ping to some extent mirrors the symptoms of web browsing, just with web browsing, the connection speed sometimes has greater delay, and occasionally will timeout all-together.  The very next time I request the same website, no problem.




24 posts

Geek


  Reply # 1985122 28-Mar-2018 20:29
quote this post

And again, dropped packets to both trademe and tvnz, while ping to flip server running concurrently while trademe and tvnz ping ran, is fine with 0% loss.

 

time ping 103.9.40.1
PING 103.9.40.1 (103.9.40.1) 56(84) bytes of data.
64 bytes from 103.9.40.1: icmp_seq=1 ttl=60 time=14.8 ms
64 bytes from 103.9.40.1: icmp_seq=2 ttl=60 time=23.3 ms
64 bytes from 103.9.40.1: icmp_seq=3 ttl=60 time=13.2 ms
64 bytes from 103.9.40.1: icmp_seq=4 ttl=60 time=13.2 ms
64 bytes from 103.9.40.1: icmp_seq=5 ttl=60 time=13.8 ms
64 bytes from 103.9.40.1: icmp_seq=6 ttl=60 time=13.3 ms
64 bytes from 103.9.40.1: icmp_seq=7 ttl=60 time=13.2 ms
64 bytes from 103.9.40.1: icmp_seq=8 ttl=60 time=13.4 ms
64 bytes from 103.9.40.1: icmp_seq=9 ttl=60 time=13.6 ms
64 bytes from 103.9.40.1: icmp_seq=10 ttl=60 time=13.5 ms
64 bytes from 103.9.40.1: icmp_seq=11 ttl=60 time=12.9 ms
64 bytes from 103.9.40.1: icmp_seq=12 ttl=60 time=13.7 ms
64 bytes from 103.9.40.1: icmp_seq=13 ttl=60 time=15.2 ms
64 bytes from 103.9.40.1: icmp_seq=14 ttl=60 time=25.1 ms
64 bytes from 103.9.40.1: icmp_seq=15 ttl=60 time=13.7 ms
64 bytes from 103.9.40.1: icmp_seq=16 ttl=60 time=215 ms
64 bytes from 103.9.40.1: icmp_seq=17 ttl=60 time=13.4 ms
64 bytes from 103.9.40.1: icmp_seq=18 ttl=60 time=13.3 ms
64 bytes from 103.9.40.1: icmp_seq=19 ttl=60 time=13.3 ms
64 bytes from 103.9.40.1: icmp_seq=20 ttl=60 time=13.2 ms
64 bytes from 103.9.40.1: icmp_seq=21 ttl=60 time=15.9 ms
64 bytes from 103.9.40.1: icmp_seq=22 ttl=60 time=13.1 ms
^C
--- 103.9.40.1 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21035ms
rtt min/avg/max/mdev = 12.965/23.847/215.588/41.957 ms

 

real 0m21.464s
user 0m0.001s
sys 0m0.008s

 

 

 

time ping www.tvnz.co.nz
PING www.gslb.tvnz.co.nz (103.231.156.164) 56(84) bytes of data.
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=2 ttl=244 time=15.6 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=3 ttl=244 time=109 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=4 ttl=244 time=14.7 ms
^C
--- www.gslb.tvnz.co.nz ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3003ms
rtt min/avg/max/mdev = 14.743/46.626/109.470/44.439 ms

 

real 0m3.194s
user 0m0.009s
sys 0m0.000s

 

 

 

time ping www.trademe.co.nz
PING www.trademe.co.nz (202.162.73.2) 56(84) bytes of data.
64 bytes from www.trademe.co.nz (202.162.73.2): icmp_seq=2 ttl=248 time=13.6 ms
64 bytes from www.trademe.co.nz (202.162.73.2): icmp_seq=3 ttl=248 time=15.6 ms
64 bytes from www.trademe.co.nz (202.162.73.2): icmp_seq=4 ttl=248 time=13.3 ms
^C
--- www.trademe.co.nz ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3002ms
rtt min/avg/max/mdev = 13.379/14.223/15.607/0.991 ms

 

real 0m3.396s
user 0m0.000s
sys 0m0.008s




24 posts

Geek


  Reply # 1987295 2-Apr-2018 20:22
quote this post

2/4/18 8:07pm Terrible performance on flip tonight.  All tests done using network cable direct connected to router, no wifi.  Flip network status ' all good '.

 

 

 

PIng to Flip server - no problem at all.  Other NZ server terrible packet loss on the initial connection.  Note ping to Flip server was running concurrently as other NZ server pings (as below) were suffering packet loss..

 

Flip server:

 

64 bytes from 103.9.40.1: icmp_seq=152 ttl=60 time=11.6 ms
64 bytes from 103.9.40.1: icmp_seq=153 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=154 ttl=60 time=12.4 ms
64 bytes from 103.9.40.1: icmp_seq=155 ttl=60 time=12.2 ms
64 bytes from 103.9.40.1: icmp_seq=156 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=157 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=158 ttl=60 time=11.7 ms
64 bytes from 103.9.40.1: icmp_seq=159 ttl=60 time=11.8 ms
64 bytes from 103.9.40.1: icmp_seq=160 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=161 ttl=60 time=12.2 ms
64 bytes from 103.9.40.1: icmp_seq=162 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=163 ttl=60 time=12.3 ms
64 bytes from 103.9.40.1: icmp_seq=164 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=165 ttl=60 time=12.4 ms
64 bytes from 103.9.40.1: icmp_seq=166 ttl=60 time=12.1 ms
^C
--- 103.9.40.1 ping statistics ---
166 packets transmitted, 166 received, 0% packet loss, time 165234ms
rtt min/avg/max/mdev = 11.615/12.250/18.575/0.823 ms

 

real 2m45.928s
user 0m0.000s
sys 0m0.012s

 

 

 

Trademe wouldn't even connect - 100% packet loss after 262 packets....

 

time ping www.trademe.co.nz
PING www.trademe.co.nz (202.162.73.2) 56(84) bytes of data.
^C
--- www.trademe.co.nz ping statistics ---
262 packets transmitted, 0 received, 100% packet loss, time 262502ms

 


real 4m22.824s
user 0m0.000s
sys 0m0.016s

 

 

 

Same command run again  very very slow to connect, 45% packet loss-

 

time ping www.trademe.co.nz

 

PING www.trademe.co.nz (202.162.72.2) 56(84) bytes of data.
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=11 ttl=246 time=21.8 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=12 ttl=246 time=21.7 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=13 ttl=246 time=21.7 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=14 ttl=246 time=21.1 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=15 ttl=246 time=22.4 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=16 ttl=246 time=21.4 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=17 ttl=246 time=21.4 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=18 ttl=246 time=21.9 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=19 ttl=246 time=21.6 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=20 ttl=246 time=21.5 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=21 ttl=246 time=21.8 ms
64 bytes from www.trademe.co.nz (202.162.72.2): icmp_seq=22 ttl=246 time=21.4 ms
^C
--- www.trademe.co.nz ping statistics ---
22 packets transmitted, 12 received, 45% packet loss, time 21088ms
rtt min/avg/max/mdev = 21.178/21.693/22.401/0.324 ms

 

real 0m21.319s
user 0m0.000s
sys 0m0.000s

 

 

 

TVNZ server -

 

 

 

time ping www.tvnz.co.nz
PING www.gslb.tvnz.co.nz (103.231.156.164) 56(84) bytes of data.
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=26 ttl=244 time=14.8 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=27 ttl=244 time=13.0 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=28 ttl=244 time=13.7 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=29 ttl=244 time=13.6 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=30 ttl=244 time=13.3 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=31 ttl=244 time=13.2 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=32 ttl=244 time=13.2 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=33 ttl=244 time=13.9 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=34 ttl=244 time=13.4 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=35 ttl=244 time=14.5 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=36 ttl=244 time=14.0 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=37 ttl=244 time=13.1 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=38 ttl=244 time=13.5 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=39 ttl=244 time=13.2 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=40 ttl=244 time=13.2 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=41 ttl=244 time=13.6 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=42 ttl=244 time=13.2 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=43 ttl=244 time=13.8 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=44 ttl=244 time=13.7 ms
64 bytes from cmsprod1.tvnz.co.nz (103.231.156.164): icmp_seq=45 ttl=244 time=13.7 ms
^C
--- www.gslb.tvnz.co.nz ping statistics ---
45 packets transmitted, 20 received, 55% packet loss, time 44025ms
rtt min/avg/max/mdev = 13.051/13.625/14.831/0.456 ms

 

real 0m44.749s
user 0m0.004s
sys 0m0.000s

 

 

 

Anyone from Flip, please, what is the problem?


'That VDSL Cat'
8103 posts

Uber Geek
+1 received by user: 1693

Trusted
Spark
Subscriber

  Reply # 1987320 2-Apr-2018 21:04
Send private message quote this post

the fact that it seems to be consistent tells me it's likely not the connection itself and something upstream...

 

 

 

The fact that you intermittently can't even ping points towards maybe an issue with the nat pool?..

 

Seems like a weird one  regardless.





#include <std_disclaimer>

 

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.




24 posts

Geek


  Reply # 1987324 2-Apr-2018 21:26
quote this post

hio77:

the fact that it seems to be consistent tells me it's likely not the connection itself and something upstream...


 


The fact that you intermittently can't even ping points towards maybe an issue with the nat pool?..


Seems like a weird one  regardless.




I agree. As mentioned in my opening post, I think it's the same problem as occurred 2 years ago....

https://www.geekzone.co.nz/forums.asp?forumid=147&topicid=177182

Hopefully someone will sort it out. Does anyone from Flip check this forum? Or should I log a call tomorrow and point them to this (current) thread. I think enough has been done to prove the problem is highly likely upstream from the end user.



24 posts

Geek


  Reply # 1995554 13-Apr-2018 15:05
quote this post

Just curious, does anybody know which entity looks after Flip CG-NAT?  Is it Chorus, or is it Flip/Vocus network team?  I have no idea if it is a service provided by Chorus, or an in-house ISP network configuration.

 

Also, could a local ADSL2+/cabinet/cabinet feed/exchange issue result in the following slowdown symptoms during peak usage time- ie ping to Flip DNS server always 100% fine with no packet loss, while at the same peak time, running a ping to either www.trademe.co.nz, or www.tvnz.co.nz, the first 2-11 replies (or sometimes more) are lost/dropped frequently (no of non-replies depending on how busy the network is).  Or on very rare occasions, no reply for the duration of the ping (100% packet loss).  All the while, while ping to Flip DNS server runs happily with no loss.  My thinking is that if it was a local ADSL2+/cabinet/cabinet feed issue, then the ping to Flip's DNS server would also be dropping packets.  But I could be wrong.  Any thoughts?


'That VDSL Cat'
8103 posts

Uber Geek
+1 received by user: 1693

Trusted
Spark
Subscriber

  Reply # 1996640 15-Apr-2018 21:31
One person supports this post
Send private message quote this post

whizbang:

 

Just curious, does anybody know which entity looks after Flip CG-NAT?  Is it Chorus, or is it Flip/Vocus network team?  I have no idea if it is a service provided by Chorus, or an in-house ISP network configuration.

 

Also, could a local ADSL2+/cabinet/cabinet feed/exchange issue result in the following slowdown symptoms during peak usage time- ie ping to Flip DNS server always 100% fine with no packet loss, while at the same peak time, running a ping to either www.trademe.co.nz, or www.tvnz.co.nz, the first 2-11 replies (or sometimes more) are lost/dropped frequently (no of non-replies depending on how busy the network is).  Or on very rare occasions, no reply for the duration of the ping (100% packet loss).  All the while, while ping to Flip DNS server runs happily with no loss.  My thinking is that if it was a local ADSL2+/cabinet/cabinet feed issue, then the ping to Flip's DNS server would also be dropping packets.  But I could be wrong.  Any thoughts?

 

 

 

 

Chorus will provide the physical DSL link, highly unlikely this is congested - Chorus operate a 'no congestion' policy. 

 

Rest is all Flip team.





#include <std_disclaimer>

 

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.




24 posts

Geek


  Reply # 2003487 27-Apr-2018 13:48
quote this post

This may well be a local Waikato/Hamilton issue. MyRepublic users reporting the same issues (read all of the thread below):

https://www.geekzone.co.nz/forums.asp?forumid=165&topicid=232206

Myrepublic status page is reporting degraded performance for Hamilton users due to a backhaul provider.

May be the same backhaul Flip is using, and also impacting Flip Waikato users.



24 posts

Geek


  Reply # 2003488 27-Apr-2018 13:50
quote this post


354 posts

Ultimate Geek
+1 received by user: 201

Trusted

  Reply # 2003595 27-Apr-2018 15:17
Send private message quote this post

whizbang: This may well be a local Waikato/Hamilton issue. MyRepublic users reporting the same issues (read all of the thread below):

https://www.geekzone.co.nz/forums.asp?forumid=165&topicid=232206

Myrepublic status page is reporting degraded performance for Hamilton users due to a backhaul provider.

May be the same backhaul Flip is using, and also impacting Flip Waikato users.

 

 

 

Flip does use the same Vocus backhaul as MR to Hamilton currently

 

 

 

@sounddude

 

 


354 posts

Ultimate Geek
+1 received by user: 201

Trusted

  Reply # 2003600 27-Apr-2018 15:27
Send private message quote this post

hio77:

 

Just curious, does anybody know which entity looks after Flip CG-NAT?  Is it Chorus, or is it Flip/Vocus network team? 

 

 

 

 

Vocus NOC looks after the Flip network nowadays, there is no separate team any more.




24 posts

Geek


  Reply # 2016359 15-May-2018 15:45
quote this post

noroad:

 

whizbang: This may well be a local Waikato/Hamilton issue. MyRepublic users reporting the same issues (read all of the thread below):

https://www.geekzone.co.nz/forums.asp?forumid=165&topicid=232206

Myrepublic status page is reporting degraded performance for Hamilton users due to a backhaul provider.

May be the same backhaul Flip is using, and also impacting Flip Waikato users.

 

 

 

Flip does use the same Vocus backhaul as MR to Hamilton currently

 

 

 

@sounddude

 

 

 

 

Any ideas as which ISP's don't use a vocus backhaul from Hamilton?  Spark/Bigpipe/2degrees?  As at last night still getting this issue unfortunately...


1 | 2 
View this topic in a long page with up to 500 replies per page Create new topic

Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:





News »

Hawaiki Transpacific cable ready-for-service
Posted 20-Jul-2018 11:29


Microsoft Dynamics 365 Business Central launches
Posted 10-Jul-2018 10:40


Spark completes first milestone in voice platform upgrade
Posted 10-Jul-2018 09:36


Microsoft ices heated developers
Posted 6-Jul-2018 20:16


PB Technologies charged for its extended warranties and warned for bait advertising
Posted 3-Jul-2018 15:45


Almost 20,000 people claim credits from Spark
Posted 29-Jun-2018 10:40


Cove sells NZ's first insurance policy via chatbot
Posted 25-Jun-2018 10:04


N4L helping TAKA Trust bridge the digital divide for Lower Hutt students
Posted 18-Jun-2018 13:08


Winners Announced for 2018 CIO Awards
Posted 18-Jun-2018 13:03


Logitech Rally sets new standard for USB-connected video conference cameras
Posted 18-Jun-2018 09:27


Russell Stanners steps down as Vodafone NZ CEO
Posted 12-Jun-2018 09:13


Intergen recognised as 2018 Microsoft Country Partner of the Year for New Zealand
Posted 12-Jun-2018 08:00


Finalists Announced For Microsoft NZ Partner Awards
Posted 6-Jun-2018 15:12


Vocus Group and Vodafone announce joint venture to accelerate fibre innovation
Posted 5-Jun-2018 10:52


Kogan.com to launch Kogan Mobile in New Zealand
Posted 4-Jun-2018 14:34



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



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.

Alternatively, you can receive a daily email with Geekzone updates.