Evening slowdown - Anyone else experiencing this?

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

whizbang

31 posts

Geek

#231920 20-Mar-2018 13:24

Hi,

Over the past week or 2, our Flip internet (ADSL2+) speed of connectiion to websites, during most evenings (ie peak time), has slowed down a lot. It's not actually the speed of data transfer, it's connection speed. Intermittently, sometimes a web-site connection attempt will simply wait..wait..wait..wait, and then connect and go through (finally) at normal speed, other times, a request to connect to a website will just simply timeout after a long wait. The very next request will go through at full speed with no delay at all. Occasionally some evenings are so bad that the usability of the service is quite compromised. On one occasion I gave up and tethered to my smartphone (which has only slow 3G coverage in our area), and the performance was great in comparison and I was able to finish making some reservations online.

This has been happening intermittently over the past two weeks. Before that, no problems at all. It affects both international and local traffic, but in my case, mostly international requests.

Most times during the day (off-peak), it is completely fine, this problem does not exist. Evenings with heavy loads in particular are the problem.

It does not appear to be our home network at all. Same results occur on both wired and wireless connections.

I did some digging around on geekzone, and this problem reported a few years ago looks very very similar:

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

Anyone else experiencing this slowdown??

1 | 2

7958 posts

Uber Geek

#1980565 20-Mar-2018 15:45

What troubleshooting have you done, and what have Flip indicated the problem may be?

Norton

Get easy to use, easy to install Norton antivirus protection against advanced online threats (affiliate link).

whizbang

31 posts

Geek

#1981230 21-Mar-2018 20:44

Flip homepage now has the following status when I checked at 8:20pm:

Investigating degraded international traffic/speeds. Updates to follow

- Flip Support

Troubleshooting so far:

- Rebooted wireless router.

- Confirmed DSL connection speed no problem:

Modulation Type: ADSL_2plus_AnnexM (configured as MultiMode)
Status: Up
Provider:
Downstream Rate: 18359 Kbps
Upstream Rate: 2012 Kbps
Downstream Noise Margin: 6.4 dB
Upstream Noise Margin: 12.3 dB
Downstream Attenuation: 16.0 dB
Upstream Attenuation: 11.0 dB
Downstream Power: 12.3 dBmV
Upstream Power: 0.0 dBmV

- ping to flip - no problem:

64 bytes from 103.9.40.1: icmp_seq=547 ttl=60 time=11.4 ms
64 bytes from 103.9.40.1: icmp_seq=548 ttl=60 time=11.4 ms
64 bytes from 103.9.40.1: icmp_seq=549 ttl=60 time=11.8 ms
64 bytes from 103.9.40.1: icmp_seq=550 ttl=60 time=11.7 ms
64 bytes from 103.9.40.1: icmp_seq=551 ttl=60 time=11.2 ms
64 bytes from 103.9.40.1: icmp_seq=552 ttl=60 time=11.3 ms
64 bytes from 103.9.40.1: icmp_seq=553 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=554 ttl=60 time=11.6 ms
64 bytes from 103.9.40.1: icmp_seq=555 ttl=60 time=11.1 ms
64 bytes from 103.9.40.1: icmp_seq=556 ttl=60 time=11.8 ms
^C
--- 103.9.40.1 ping statistics ---
556 packets transmitted, 555 received, 0% packet loss, time 555804ms
rtt min/avg/max/mdev = 11.073/19.936/333.433/38.588 ms

- ping to 4.2.2.4 5% packet loss

64 bytes from 4.2.2.4: icmp_seq=286 ttl=49 time=374 ms
64 bytes from 4.2.2.4: icmp_seq=287 ttl=49 time=376 ms
64 bytes from 4.2.2.4: icmp_seq=288 ttl=49 time=377 ms
64 bytes from 4.2.2.4: icmp_seq=289 ttl=49 time=374 ms
64 bytes from 4.2.2.4: icmp_seq=290 ttl=49 time=377 ms
64 bytes from 4.2.2.4: icmp_seq=291 ttl=49 time=375 ms
64 bytes from 4.2.2.4: icmp_seq=292 ttl=49 time=375 ms
^C
--- 4.2.2.4 ping statistics ---
293 packets transmitted, 278 received, 5% packet loss, time 292114ms
rtt min/avg/max/mdev = 365.898/377.836/586.953/16.218 ms

- And again but to 4.2.2.2 52% packet loss:

ping 4.2.2.2
PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_seq=24 ttl=51 time=353 ms
64 bytes from 4.2.2.2: icmp_seq=25 ttl=51 time=351 ms
64 bytes from 4.2.2.2: icmp_seq=26 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=27 ttl=51 time=351 ms
64 bytes from 4.2.2.2: icmp_seq=28 ttl=51 time=348 ms
64 bytes from 4.2.2.2: icmp_seq=29 ttl=51 time=355 ms
64 bytes from 4.2.2.2: icmp_seq=30 ttl=51 time=349 ms
64 bytes from 4.2.2.2: icmp_seq=31 ttl=51 time=348 ms
64 bytes from 4.2.2.2: icmp_seq=32 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=33 ttl=51 time=349 ms
64 bytes from 4.2.2.2: icmp_seq=34 ttl=51 time=347 ms
64 bytes from 4.2.2.2: icmp_seq=35 ttl=51 time=349 ms
64 bytes from 4.2.2.2: icmp_seq=36 ttl=51 time=348 ms
64 bytes from 4.2.2.2: icmp_seq=37 ttl=51 time=349 ms
64 bytes from 4.2.2.2: icmp_seq=38 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=39 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=40 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=41 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=42 ttl=51 time=349 ms
64 bytes from 4.2.2.2: icmp_seq=43 ttl=51 time=351 ms
64 bytes from 4.2.2.2: icmp_seq=44 ttl=51 time=348 ms
^C
--- 4.2.2.2 ping statistics ---
44 packets transmitted, 21 received, 52% packet loss, time 43204ms
rtt min/avg/max/mdev = 347.125/350.224/355.592/2.006 ms

- And again:

ping 4.2.2.2
PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_seq=16 ttl=51 time=346 ms
64 bytes from 4.2.2.2: icmp_seq=17 ttl=51 time=346 ms
64 bytes from 4.2.2.2: icmp_seq=18 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=19 ttl=51 time=346 ms
64 bytes from 4.2.2.2: icmp_seq=20 ttl=51 time=349 ms
64 bytes from 4.2.2.2: icmp_seq=21 ttl=51 time=345 ms
64 bytes from 4.2.2.2: icmp_seq=22 ttl=51 time=345 ms
64 bytes from 4.2.2.2: icmp_seq=23 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=24 ttl=51 time=349 ms
64 bytes from 4.2.2.2: icmp_seq=25 ttl=51 time=347 ms
64 bytes from 4.2.2.2: icmp_seq=26 ttl=51 time=348 ms
64 bytes from 4.2.2.2: icmp_seq=27 ttl=51 time=346 ms
64 bytes from 4.2.2.2: icmp_seq=28 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=29 ttl=51 time=349 ms
64 bytes from 4.2.2.2: icmp_seq=30 ttl=51 time=350 ms
64 bytes from 4.2.2.2: icmp_seq=31 ttl=51 time=344 ms
64 bytes from 4.2.2.2: icmp_seq=32 ttl=51 time=349 ms
^C
--- 4.2.2.2 ping statistics ---
33 packets transmitted, 17 received, 48% packet loss, time 32130ms
rtt min/avg/max/mdev = 344.991/348.076/350.489/1.995 ms

- At the same time as above is running, ping to flip 0% packet loss:

64 bytes from 103.9.40.1: icmp_seq=270 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=271 ttl=60 time=11.4 ms
64 bytes from 103.9.40.1: icmp_seq=272 ttl=60 time=11.4 ms
64 bytes from 103.9.40.1: icmp_seq=273 ttl=60 time=11.6 ms
64 bytes from 103.9.40.1: icmp_seq=274 ttl=60 time=11.5 ms
64 bytes from 103.9.40.1: icmp_seq=275 ttl=60 time=11.6 ms
64 bytes from 103.9.40.1: icmp_seq=276 ttl=60 time=11.8 ms
64 bytes from 103.9.40.1: icmp_seq=277 ttl=60 time=11.4 ms
64 bytes from 103.9.40.1: icmp_seq=278 ttl=60 time=11.1 ms
^C
--- 103.9.40.1 ping statistics ---
278 packets transmitted, 278 received, +1 duplicates, 0% packet loss, time 277399ms
rtt min/avg/max/mdev = 10.953/19.998/695.922/55.008 ms

- Speedtest:

speedtest-cli --server 4118
Retrieving speedtest.net configuration...
Could not retrieve speedtest.net configuration: <urlopen error timed out>

- again

time speedtest-cli --server 4118
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Traceback (most recent call last):
File "/usr/bin/speedtest-cli", line 9, in <module>
load_entry_point('speedtest-cli==0.3.4', 'console_scripts', 'speedtest-cli')()
File "/usr/lib/python2.7/dist-packages/speedtest_cli.py", line 790, in main
speedtest()
File "/usr/lib/python2.7/dist-packages/speedtest_cli.py", line 631, in speedtest
servers = closestServers(config['client'], True)
File "/usr/lib/python2.7/dist-packages/speedtest_cli.py", line 436, in closestServers
serversxml.append(uh.read(10240))
File "/usr/lib/python2.7/socket.py", line 384, in read
data = self._sock.recv(left)
File "/usr/lib/python2.7/httplib.py", line 612, in read
s = self.fp.read(amt)
File "/usr/lib/python2.7/socket.py", line 384, in read
data = self._sock.recv(left)
socket.timeout: timed out

real 0m50.368s
user 0m0.104s
sys 0m0.028s

- Earlier today speedtest would run with no problem:

1:39pm

speedtest-cli --server 4118
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Flip Services Limited (103.224.128.96)...
Hosted by Spark (Wellington) [270.44 km]: 38.632 ms
Testing download speed........................................
Download: 14.81 Mbit/s
Testing upload speed..................................................
Upload: 1.70 Mbit/s

7:22pm

speedtest-cli --server 4118
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Flip Services Limited (103.224.128.49)...
Hosted by Spark (Wellington) [270.44 km]: 33.724 ms
Testing download speed........................................
Download: 14.13 Mbit/s
Testing upload speed..................................................
Upload: 1.57 Mbit/s

- Speedtest - FINALLY (the speed results may be incorrect due to the long time taken to connect?? ) -

time speedtest-cli --server 4118
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Flip Services Limited (103.224.128.49)...
Hosted by Spark (Wellington) [270.44 km]: 367.551 ms
Testing download speed........................................
Download: 3.68 Mbit/s
Testing upload speed..................................................
Upload: 1.19 Mbit/s

real 3m49.806s
user 0m0.444s
sys 0m0.124s

- Traceroute

time traceroute -I www.stuff.co.nz
traceroute to e14449.dsce2.akamaiedge.net (23.222.94.202), 64 hops max
1 192.168.1.1 2.235ms 1.108ms 0.755ms
2 103.9.40.36 14.664ms 13.352ms 13.426ms
3 * * *
4 * * *
5 202.180.100.109 13.674ms 14.286ms 13.614ms
6 * * *
7 23.222.94.202 12.218ms 11.861ms 12.630ms

real 4m40.653s
user 0m0.000s
sys 0m0.012s

hio77

'That VDSL Cat'
12982 posts

Uber Geek

ID Verified

Trusted

Voyager

Subscriber

#1981231 21-Mar-2018 20:53

discount experience from tonight, there is a fibre cut affecting flip's main international link.

that's what the update relates to.

#include <std_disclaimer>

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

RunningMan

7958 posts

Uber Geek

#1981232 21-Mar-2018 20:54

Bad night to choose for testing - there is a major fibre cut in Sydney which is affecting a lot of transit.

Maybe run some tests again tomorrow.

EDIT: Snap @hio77

hio77

'That VDSL Cat'
12982 posts

Uber Geek

ID Verified

Trusted

Voyager

Subscriber

#1981233 21-Mar-2018 20:55

RunningMan:

EDIT: Snap hio77

man, you need to be running faster than that to beat me ;)

#include <std_disclaimer>

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

RunningMan

7958 posts

Uber Geek

#1981235 21-Mar-2018 21:05

Just having a quick snooze...

Sounddude

I fix stuff!
1903 posts

Uber Geek

Trusted

2degrees

Lifetime subscriber

#1981239 21-Mar-2018 21:25

hio77:

RunningMan:

EDIT: Snap hio77

man, you need to be running faster than that to beat me ;)

I might as well go to the pub! don't need me :-)

hio77

'That VDSL Cat'
12982 posts

Uber Geek

ID Verified

Trusted

Voyager

Subscriber

#1981240 21-Mar-2018 21:27

Sounddude:

I might as well go to the pub! don't need me :-)

just wait till tomorrow, then we can say you broke it all ;)

#include <std_disclaimer>

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

RunningMan

7958 posts

Uber Geek

#1981305 22-Mar-2018 07:08

Sounddude:

I might as well go to the pub! don't need me :-)

Good idea - your shout!

jimmycnz

2 posts

Wannabe Geek

#1981711 22-Mar-2018 20:11

Yeah we've been battling with this too. Peak time (8:30pm) has slowly been getting worse since Xmas. Over the past month it'd gotten so bad that we too were hot-spotting our phones if we needed to do anything on the internet.

I logged a ticket with tech support about three weeks ago which they've been dragging out. They asked me to reconfigure, reset and replace all manner of things on our end despite the tracert and pathping logs suggesting that the packet loss was occurring after the first hop to their servers and that the packet loss was only at peak times.

Long story short, I've switched ISPs and our connection is back to normal now. It's worth noting that Flip's parent company, Vocus, is currently up for sale and have reported 'disappointing' half-year results. I'll let you read between the lines ...

whizbang

31 posts

Geek

#1983833 26-Mar-2018 21:26

Ok - This time maybe no cut fibre in Sydney??

Flip website network status reported as 'All Good'.

Wifi turned off on router, network connection only, single host connected.

Observed problem - speed is fine (once it finally connects), it's the intermittent long connection time that is the problem. Sometimes immediate, next time very very slow.

8:45pm - 9:10pm time of testing 26/3/18.

Check DSL - no problem

Modulation Type: ADSL_2plus_AnnexM (configured as MultiMode)
Status: Up
Provider:
Downstream Rate: 18297 Kbps
Upstream Rate: 2012 Kbps
Downstream Noise Margin: 6.5 dB
Upstream Noise Margin: 13.7 dB
Downstream Attenuation: 16.0 dB
Upstream Attenuation: 11.0 dB
Downstream Power: 13.2 dBmV
Upstream Power: 0.0 dBmV
Total Bytes Sent: 157464 Bytes

Ping both Flip and 4.2.2.2 at the same time on multiple occasions - 63% packet loss to 4.2.2.2, 0% to flip server:

9:04pm

time ping 4.2.2.2
PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_seq=8 ttl=50 time=308 ms
64 bytes from 4.2.2.2: icmp_seq=9 ttl=50 time=305 ms
64 bytes from 4.2.2.2: icmp_seq=10 ttl=50 time=312 ms
64 bytes from 4.2.2.2: icmp_seq=11 ttl=50 time=305 ms
^C
--- 4.2.2.2 ping statistics ---
11 packets transmitted, 4 received, 63% packet loss, time 10051ms
rtt min/avg/max/mdev = 305.714/308.159/312.878/2.937 ms

real 0m10.627s
user 0m0.000s
sys 0m0.000s

64 bytes from 103.9.40.1: icmp_seq=109 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=110 ttl=60 time=11.8 ms
64 bytes from 103.9.40.1: icmp_seq=111 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=112 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=113 ttl=60 time=12.4 ms
64 bytes from 103.9.40.1: icmp_seq=114 ttl=60 time=12.3 ms
64 bytes from 103.9.40.1: icmp_seq=115 ttl=60 time=11.6 ms
64 bytes from 103.9.40.1: icmp_seq=116 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=117 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=118 ttl=60 time=11.6 ms
64 bytes from 103.9.40.1: icmp_seq=119 ttl=60 time=11.4 ms
64 bytes from 103.9.40.1: icmp_seq=120 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=121 ttl=60 time=11.6 ms
64 bytes from 103.9.40.1: icmp_seq=122 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=123 ttl=60 time=12.1 ms
^C
--- 103.9.40.1 ping statistics ---
123 packets transmitted, 123 received, 0% packet loss, time 122164ms
rtt min/avg/max/mdev = 11.348/13.501/78.890/7.387 ms

real 2m2.790s
user 0m0.008s
sys 0m0.004s

Again....27% packet loss, 0% to flip server.

8:57pm

time ping 4.2.2.2
PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_seq=6 ttl=50 time=306 ms
64 bytes from 4.2.2.2: icmp_seq=7 ttl=50 time=312 ms
64 bytes from 4.2.2.2: icmp_seq=8 ttl=50 time=312 ms
64 bytes from 4.2.2.2: icmp_seq=9 ttl=50 time=317 ms
64 bytes from 4.2.2.2: icmp_seq=10 ttl=50 time=317 ms
64 bytes from 4.2.2.2: icmp_seq=11 ttl=50 time=317 ms
64 bytes from 4.2.2.2: icmp_seq=12 ttl=50 time=311 ms
64 bytes from 4.2.2.2: icmp_seq=13 ttl=50 time=315 ms
64 bytes from 4.2.2.2: icmp_seq=14 ttl=50 time=308 ms
64 bytes from 4.2.2.2: icmp_seq=15 ttl=50 time=306 ms
64 bytes from 4.2.2.2: icmp_seq=16 ttl=50 time=302 ms
64 bytes from 4.2.2.2: icmp_seq=17 ttl=50 time=298 ms
64 bytes from 4.2.2.2: icmp_seq=18 ttl=50 time=293 ms
^C
--- 4.2.2.2 ping statistics ---
18 packets transmitted, 13 received, 27% packet loss, time 17050ms
rtt min/avg/max/mdev = 293.387/309.318/317.924/7.486 ms

real 0m17.954s
user 0m0.000s
sys 0m0.000s

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=13.2 ms
64 bytes from 103.9.40.1: icmp_seq=2 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=3 ttl=60 time=12.0 ms
64 bytes from 103.9.40.1: icmp_seq=4 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=5 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=6 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=7 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=8 ttl=60 time=11.8 ms
64 bytes from 103.9.40.1: icmp_seq=9 ttl=60 time=11.6 ms
64 bytes from 103.9.40.1: icmp_seq=10 ttl=60 time=12.2 ms
64 bytes from 103.9.40.1: icmp_seq=11 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=12 ttl=60 time=11.6 ms
64 bytes from 103.9.40.1: icmp_seq=13 ttl=60 time=12.5 ms
^C
--- 103.9.40.1 ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12017ms
rtt min/avg/max/mdev = 11.646/12.118/13.246/0.397 ms

real 0m12.297s
user 0m0.000s
sys 0m0.000s

And again.... 27% packet loss to 4.2.2.4, 0% direct to flip server.

8:55pm

time ping 4.2.2.4
PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data.
64 bytes from 4.2.2.4: icmp_seq=6 ttl=48 time=313 ms
64 bytes from 4.2.2.4: icmp_seq=7 ttl=48 time=311 ms
64 bytes from 4.2.2.4: icmp_seq=8 ttl=48 time=300 ms
64 bytes from 4.2.2.4: icmp_seq=9 ttl=48 time=313 ms
64 bytes from 4.2.2.4: icmp_seq=10 ttl=48 time=303 ms
64 bytes from 4.2.2.4: icmp_seq=11 ttl=48 time=298 ms
64 bytes from 4.2.2.4: icmp_seq=12 ttl=48 time=302 ms
64 bytes from 4.2.2.4: icmp_seq=13 ttl=48 time=303 ms
64 bytes from 4.2.2.4: icmp_seq=14 ttl=48 time=308 ms
64 bytes from 4.2.2.4: icmp_seq=15 ttl=48 time=303 ms
64 bytes from 4.2.2.4: icmp_seq=16 ttl=48 time=298 ms
64 bytes from 4.2.2.4: icmp_seq=17 ttl=48 time=300 ms
64 bytes from 4.2.2.4: icmp_seq=18 ttl=48 time=297 ms
^C
--- 4.2.2.4 ping statistics ---
18 packets transmitted, 13 received, 27% packet loss, time 17047ms
rtt min/avg/max/mdev = 297.632/304.235/313.842/5.581 ms

real 0m17.797s
user 0m0.000s
sys 0m0.000s

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=13.8 ms
64 bytes from 103.9.40.1: icmp_seq=2 ttl=60 time=12.1 ms
64 bytes from 103.9.40.1: icmp_seq=3 ttl=60 time=12.0 ms
64 bytes from 103.9.40.1: icmp_seq=4 ttl=60 time=11.7 ms
64 bytes from 103.9.40.1: icmp_seq=5 ttl=60 time=11.8 ms
64 bytes from 103.9.40.1: icmp_seq=6 ttl=60 time=12.3 ms
64 bytes from 103.9.40.1: icmp_seq=7 ttl=60 time=11.8 ms
64 bytes from 103.9.40.1: icmp_seq=8 ttl=60 time=11.9 ms
64 bytes from 103.9.40.1: icmp_seq=9 ttl=60 time=12.3 ms
^C
--- 103.9.40.1 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8012ms
rtt min/avg/max/mdev = 11.726/12.238/13.810/0.598 ms

real 0m8.586s
user 0m0.000s
sys 0m0.000

Ping to Telstra speedtest server...45% packet loss, 0% to flip server.

9:07pm

time ping 203.39.77.13
PING 203.39.77.13 (203.39.77.13) 56(84) bytes of data.
64 bytes from 203.39.77.13: icmp_seq=4 ttl=50 time=48.8 ms
64 bytes from 203.39.77.13: icmp_seq=5 ttl=50 time=46.7 ms
64 bytes from 203.39.77.13: icmp_seq=6 ttl=50 time=46.8 ms
64 bytes from 203.39.77.13: icmp_seq=7 ttl=50 time=46.9 ms
64 bytes from 203.39.77.13: icmp_seq=8 ttl=50 time=46.6 ms
64 bytes from 203.39.77.13: icmp_seq=9 ttl=50 time=46.5 ms
64 bytes from 203.39.77.13: icmp_seq=10 ttl=50 time=47.1 ms
64 bytes from 203.39.77.13: icmp_seq=11 ttl=50 time=47.2 ms
64 bytes from 203.39.77.13: icmp_seq=12 ttl=50 time=46.7 ms
^C
--- 203.39.77.13 ping statistics ---
12 packets transmitted, 9 received, 25% packet loss, time 11011ms
rtt min/avg/max/mdev = 46.565/47.091/48.875/0.722 ms

real 0m11.214s
user 0m0.000s
sys 0m0.000s

time ping mel1.speedtest.telstra.net
PING mel1.speedtest.telstra.net (203.39.77.13) 56(84) bytes of data.
64 bytes from mel2.speedtest.telstra.net (203.39.77.13): icmp_seq=6 ttl=50 time=47.2 ms
64 bytes from mel2.speedtest.telstra.net (203.39.77.13): icmp_seq=7 ttl=50 time=46.8 ms
64 bytes from mel2.speedtest.telstra.net (203.39.77.13): icmp_seq=8 ttl=50 time=46.7 ms
64 bytes from mel2.speedtest.telstra.net (203.39.77.13): icmp_seq=9 ttl=50 time=46.7 ms
64 bytes from mel2.speedtest.telstra.net (203.39.77.13): icmp_seq=10 ttl=50 time=46.0 ms
64 bytes from mel2.speedtest.telstra.net (203.39.77.13): icmp_seq=11 ttl=50 time=46.9 ms
^C
--- mel1.speedtest.telstra.net ping statistics ---
11 packets transmitted, 6 received, 45% packet loss, time 10007ms
rtt min/avg/max/mdev = 46.092/46.768/47.240/0.388 ms

real 0m10.635s
user 0m0.004s
sys 0m0.000s

3 x Speedtest samples with 3 minutes of each other. Speed reported back varies wildly - due to connection problems maybe?? -

9:02pm

time speedtest-cli --server 4118
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Flip Services Limited (103.224.128.49)...
Hosted by Spark (Wellington) [490.61 km]: 1200184.911 ms
Testing download speed........................................
Download: 11.11 Mbit/s
Testing upload speed..................................................
Upload: 1.12 Mbit/s

real 0m54.340s
user 0m0.672s
sys 0m0.248s
darryl@turtle2:~/flip_262$ cat speedtest2.txt
9:03pm

time speedtest-cli --server 4118
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Flip Services Limited (103.224.128.96)...
Hosted by Spark (Wellington) [490.61 km]: 563.341 ms
Testing download speed........................................
Download: 3.32 Mbit/s
Testing upload speed..................................................
Upload: 0.20 Mbit/s

real 0m33.974s
user 0m0.480s
sys 0m0.128s
darryl@turtle2:~/flip_262$ cat speedtest3.txt
9:05pm

time speedtest-cli --server 4118
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Flip Services Limited (103.224.128.96)...
Hosted by Spark (Wellington) [490.61 km]: 1200059.973 ms
Testing download speed........................................
Download: 4.30 Mbit/s
Testing upload speed..................................................
Upload: 0.20 Mbit/s

real 0m51.571s
user 0m0.484s
sys 0m0.100s

Traceroute Google...

time traceroute -I www.google.co.nz
traceroute to www.google.co.nz (216.58.220.99), 64 hops max
1 192.168.1.1 0.771ms 0.750ms 0.689ms
2 103.9.40.36 14.189ms 13.306ms 13.335ms
3 103.9.40.18 15.180ms 14.127ms 15.336ms
4 101.98.5.72 13.874ms 13.178ms 16.893ms
5 * * *
6 * * *
7 * * *
8 * * 108.170.232.233 36.590ms
9 216.58.220.99 35.772ms 34.973ms 35.603ms

real 0m48.406s
user 0m0.004s
sys 0m0.000s

Traceroute local NZ one immediately after the other....

9:00pm

traceroute -I www.pncc.govt.nz
traceroute to www.pncc.govt.nz (192.245.185.5), 64 hops max
1 192.168.1.1 0.783ms 0.975ms 0.707ms
2 103.9.40.36 14.336ms 13.749ms 20.887ms
3 * 103.9.40.18 14.333ms 13.908ms
4 101.98.5.72 13.679ms 13.434ms 13.750ms
5 101.98.5.128 13.988ms 13.553ms 20.129ms
6 101.98.5.129 13.816ms 13.755ms 13.279ms
7 203.114.149.34 14.588ms 13.673ms 13.369ms
8 203.114.191.69 20.399ms 20.381ms 20.190ms
9 121.79.246.1 20.122ms 20.513ms 20.134ms
10 192.245.185.5 29.136ms 18.664ms 18.796ms

traceroute -I www.pncc.govt.nz
traceroute to www.pncc.govt.nz (192.245.185.5), 64 hops max
1 192.168.1.1 0.814ms 0.731ms 0.725ms
2 103.9.40.36 14.358ms 13.004ms 12.733ms
3 * * *
4 * * *
5 * 101.98.5.128 14.406ms 13.684ms
6 101.98.5.129 13.205ms 13.637ms 13.767ms
7 203.114.149.34 14.533ms 13.593ms 14.156ms
8 203.114.191.69 77.063ms 29.232ms 35.543ms
9 * * *
10 192.245.185.5 18.829ms 18.786ms 18.456ms

richms

26393 posts

Uber Geek

Trusted

Subscriber

#1983836 26-Mar-2018 21:30

how about pinging to other NZ IP addresses like trademe or something?

edit: at the same time as flip and the others. Just to see if its international or not, the later NZ stuff looked fine.

Richard rich.ms

hio77

'That VDSL Cat'
12982 posts

Uber Geek

ID Verified

Trusted

Voyager

Subscriber

#1983840 26-Mar-2018 21:32

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?

#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

#1983841 26-Mar-2018 21:33

jimmycnz:

Yeah we've been battling with this too. Peak time (8:30pm) has slowly been getting worse since Xmas. Over the past month it'd gotten so bad that we too were hot-spotting our phones if we needed to do anything on the internet.

I logged a ticket with tech support about three weeks ago which they've been dragging out. They asked me to reconfigure, reset and replace all manner of things on our end despite the tracert and pathping logs suggesting that the packet loss was occurring after the first hop to their servers and that the packet loss was only at peak times.

Long story short, I've switched ISPs and our connection is back to normal now. It's worth noting that Flip's parent company, Vocus, is currently up for sale and have reported 'disappointing' half-year results. I'll let you read between the lines ...

That is the same issue with performance as we have experienced. Usually from about 8:30pm onward. Thankfully only 1 night I have had to resort to the mobile hotspot - websites timing out trying to connect, but other nights, although it works, it had been painfully slow to connect - but does eventually get through. This problem does not happen every night of the week, just some nights (heavy load nights maybe). I wonder if it is the same issue which I posted a geekzone link to in my first post....

whizbang

31 posts

Geek

#1983845 26-Mar-2018 21:45

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.

1 | 2