Evening slowdown - Anyone else experiencing this?

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › Evening slowdown - Anyone else experiencing this?

1 | 2

hio77

12999 posts

Uber Geek

ID Verified

Trusted

Lizard Networks

#1983848 26-Mar-2018 21:48

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.

whizbang

31 posts

Geek

#1983852 26-Mar-2018 21:56

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.

whizbang

31 posts

Geek

#1985121 28-Mar-2018 20:26

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.

whizbang

31 posts

Geek

#1985122 28-Mar-2018 20:29

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

whizbang

31 posts

Geek

#1987295 2-Apr-2018 20:22

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?

hio77

12999 posts

Uber Geek

ID Verified

Trusted

Lizard Networks

#1987320 2-Apr-2018 21:04

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.

whizbang

31 posts

Geek

#1987324 2-Apr-2018 21:26

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.

Sharesies

Trade NZ and US shares and funds with Sharesies (affiliate link).

whizbang

31 posts

Geek

#1995554 13-Apr-2018 15:05

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?

hio77

12999 posts

Uber Geek

ID Verified

Trusted

Lizard Networks

#1996640 15-Apr-2018 21:31

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.

whizbang

31 posts

Geek

#2003487 27-Apr-2018 13:48

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.

whizbang

31 posts

Geek

#2003488 27-Apr-2018 13:50

noroad

951 posts

Ultimate Geek

Trusted

#2003595 27-Apr-2018 15:17

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

noroad

951 posts

Ultimate Geek

Trusted

#2003600 27-Apr-2018 15:27

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.

whizbang

31 posts

Geek

#2016359 15-May-2018 15:45

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