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'
7502 posts

Uber Geek
+1 received by user: 1489

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.




20 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.


 
 
 
 


Try Wrike: fast, easy, and efficient project collaboration software


20 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.




20 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




20 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'
7502 posts

Uber Geek
+1 received by user: 1489

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.




20 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.



20 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'
7502 posts

Uber Geek
+1 received by user: 1489

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.


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 »

Amazon launches the International Shopping Experience in the Amazon Shopping App
Posted 19-Apr-2018 08:38


Spark New Zealand and TVNZ to bring coverage of Rugby World Cup 2019
Posted 16-Apr-2018 06:55


How Google can seize Microsoft Office crown
Posted 14-Apr-2018 11:08


How back office transformation drives IRD efficiency
Posted 12-Apr-2018 21:15


iPod laws in a smartphone world: will we ever get copyright right?
Posted 12-Apr-2018 21:13


Lightbox service using big data and analytics to learn more about customers
Posted 9-Apr-2018 12:11


111 mobile caller location extended to iOS
Posted 6-Apr-2018 13:50


Huawei announces the HUAWEI P20 series
Posted 29-Mar-2018 11:41


Symantec Internet Security Threat Report shows increased endpoint technology risks
Posted 26-Mar-2018 18:29


Spark switches on long-range IoT network across New Zealand
Posted 26-Mar-2018 18:22


Stuff Pix enters streaming video market
Posted 21-Mar-2018 09:18


Windows no longer Microsoft’s main focus
Posted 13-Mar-2018 07:47


Why phone makers are obsessed with cameras
Posted 11-Mar-2018 12:25


New Zealand Adopts International Open Data Charter
Posted 3-Mar-2018 12:48


Shipments tumble as NZ phone upgrades slow
Posted 2-Mar-2018 11:48



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.