Spark VDSL High Latency

Forums › Spark New Zealand (including Skinny and BigPipe) › Spark VDSL High Latency

1 | 2 | 3 | 4 | 5 | 6 | 7

24 posts

Geek

#2037886 14-Jun-2018 21:29

thanks team spark I could see you are trying to solve from your end. understand it is coming from Telstra.

For me a latency of 200 ms on browsing or youtube does not make a difference.

but 200 ms instead of 35 ms on VPN Corporate network (Which I am using) make a Huge difference on large database, SAP and other files that are network depend. Indeed, the bandwidth also decrease from 600 kb/s to 80 kb/s so yeah I am greatly affected.

Luckily that Talkinet does not have any issue with his Spark connection. Maybe he could try at least routing my IP to his subnet that could temporarily solve my issue. I know it is a wider issue that need more time.

Please keep me post either option changing IP or see any update tomorrow.

latency tonight is worst:

traceroute to www.telstra.com.au (203.36.148.11), 64 hops max, 72 byte packets

1 192.168.1.254 (192.168.1.254) 2.991 ms 5.808 ms 1.759 ms

2 * * *

3 * mdr-ip24-int.msc.global-gateway.net.nz (122.56.116.6) 6.079 ms 7.753 ms

4 ae8-10.akbr6.global-gateway.net.nz (122.56.116.5) 12.306 ms 8.690 ms 12.138 ms

5 ae2-6.tkbr12.global-gateway.net.nz (122.56.127.17) 11.457 ms 7.563 ms 10.421 ms

6 xe7-0-0.sebr3.global-gateway.net.nz (203.96.120.98) 58.250 ms 35.753 ms 31.891 ms

7 122.56.119.86 (122.56.119.86) 34.292 ms 36.896 ms 31.633 ms

8 ae-17.r20.sydnau02.au.bb.gin.ntt.net (103.13.80.121) 33.282 ms 32.385 ms 32.568 ms

9 ae-0.au.sydnau02.au.bb.gin.ntt.net (129.250.9.14) 33.732 ms 32.007 ms 31.368 ms

10 202.68.65.137 (202.68.65.137) 35.948 ms 32.225 ms 37.788 ms

11 tengige0-2-0-5.ken45.sydney.telstra.net (139.130.40.245) 270.101 ms 321.770 ms 309.789 ms

12 bundle-ether13.ken-core10.sydney.telstra.net (203.50.11.94) 301.856 ms 163.066 ms 451.243 ms

13 bundle-ether12.win-core10.melbourne.telstra.net (203.50.11.123) 320.622 ms 174.653 ms 167.432 ms

14 tengigabitethernet7-1.win22.melbourne.telstra.net (203.50.80.162) 169.188 ms 172.895 ms 221.656 ms

15 telstr745.lnk.telstra.net (139.130.39.114) 223.034 ms 169.046 ms 222.085 ms

16 * * *

17 203.36.148.11 (203.36.148.11) 350.464 ms 330.624 ms 174.596 ms

ping

PING www.telstra.com.au (203.36.148.11): 56 data bytes

64 bytes from 203.36.148.11: icmp_seq=0 ttl=237 time=233.842 ms

64 bytes from 203.36.148.11: icmp_seq=1 ttl=237 time=457.323 ms

Request timeout for icmp_seq 2

64 bytes from 203.36.148.11: icmp_seq=3 ttl=237 time=295.764 ms

64 bytes from 203.36.148.11: icmp_seq=4 ttl=237 time=215.588 ms

64 bytes from 203.36.148.11: icmp_seq=5 ttl=237 time=443.633 ms

64 bytes from 203.36.148.11: icmp_seq=6 ttl=237 time=359.019 ms

64 bytes from 203.36.148.11: icmp_seq=7 ttl=237 time=278.014 ms

64 bytes from 203.36.148.11: icmp_seq=8 ttl=237 time=195.572 ms

64 bytes from 203.36.148.11: icmp_seq=9 ttl=237 time=422.963 ms

64 bytes from 203.36.148.11: icmp_seq=10 ttl=237 time=341.784 ms

64 bytes from 203.36.148.11: icmp_seq=11 ttl=237 time=261.927 ms

64 bytes from 203.36.148.11: icmp_seq=12 ttl=237 time=181.624 ms

64 bytes from 203.36.148.11: icmp_seq=13 ttl=237 time=409.797 ms

64 bytes from 203.36.148.11: icmp_seq=14 ttl=237 time=325.532 ms

64 bytes from 203.36.148.11: icmp_seq=15 ttl=237 time=243.070 ms

64 bytes from 203.36.148.11: icmp_seq=16 ttl=237 time=472.960 ms

Request timeout for icmp_seq 17

64 bytes from 203.36.148.11: icmp_seq=18 ttl=237 time=308.358 ms

64 bytes from 203.36.148.11: icmp_seq=19 ttl=237 time=230.608 ms

64 bytes from 203.36.148.11: icmp_seq=20 ttl=237 time=454.988 ms

64 bytes from 203.36.148.11: icmp_seq=21 ttl=237 time=374.267 ms

64 bytes from 203.36.148.11: icmp_seq=22 ttl=237 time=292.850 ms

64 bytes from 203.36.148.11: icmp_seq=23 ttl=237 time=214.676 ms

64 bytes from 203.36.148.11: icmp_seq=24 ttl=237 time=437.373 ms

64 bytes from 203.36.148.11: icmp_seq=25 ttl=237 time=355.867 ms

64 bytes from 203.36.148.11: icmp_seq=26 ttl=237 time=172.576 ms

64 bytes from 203.36.148.11: icmp_seq=27 ttl=237 time=196.664 ms

64 bytes from 203.36.148.11: icmp_seq=28 ttl=237 time=420.507 ms

Request timeout for icmp_seq 29

64 bytes from 203.36.148.11: icmp_seq=30 ttl=237 time=257.717 ms

64 bytes from 203.36.148.11: icmp_seq=31 ttl=237 time=483.450 ms

64 bytes from 203.36.148.11: icmp_seq=32 ttl=237 time=402.394 ms

64 bytes from 203.36.148.11: icmp_seq=33 ttl=237 time=174.864 ms

64 bytes from 203.36.148.11: icmp_seq=34 ttl=237 time=243.522 ms

64 bytes from 203.36.148.11: icmp_seq=35 ttl=237 time=470.443 ms

64 bytes from 203.36.148.11: icmp_seq=36 ttl=237 time=386.926 ms

64 bytes from 203.36.148.11: icmp_seq=37 ttl=237 time=308.916 ms

64 bytes from 203.36.148.11: icmp_seq=38 ttl=237 time=227.793 ms

64 bytes from 203.36.148.11: icmp_seq=39 ttl=237 time=450.620 ms

Request timeout for icmp_seq 40

64 bytes from 203.36.148.11: icmp_seq=41 ttl=237 time=286.522 ms

64 bytes from 203.36.148.11: icmp_seq=42 ttl=237 time=204.139 ms

64 bytes from 203.36.148.11: icmp_seq=43 ttl=237 time=427.373 ms

64 bytes from 203.36.148.11: icmp_seq=44 ttl=237 time=347.240 ms

64 bytes from 203.36.148.11: icmp_seq=45 ttl=237 time=264.734 ms

64 bytes from 203.36.148.11: icmp_seq=46 ttl=237 time=182.984 ms

64 bytes from 203.36.148.11: icmp_seq=47 ttl=237 time=406.743 ms

64 bytes from 203.36.148.11: icmp_seq=48 ttl=237 time=329.216 ms

64 bytes from 203.36.148.11: icmp_seq=49 ttl=237 time=246.601 ms

--- www.telstra.com.au ping statistics ---

50 packets transmitted, 46 packets received, 8.0% packet loss

round-trip min/avg/max/stddev = 172.576/319.551/483.450/96.096 ms

jspk

35 posts

Geek

#2037895 14-Jun-2018 21:53

Talkiet:

We don't authoritatively know what the unaffected ranges are. It's also possible this isn't the only predictive factor - it could be isolated to some BNGs and not others. I know it's not what you want to hear and and I WILL see if I can get an update tomorrow, but attempting to 'fix' this by putting people on temporary IPs would create more work to undo as well - plus might not fix the issue.

If you haven't already, it would be worth trying a VPN - that will effectively change your IP and might provide a temporary workaround.

Cheers - N

To clarify I don't have a static IP and I don't use a VPN (will try though), was just curious if this was an option.
Thanks for following up on the issue

jspk

35 posts

Geek

#2038486 16-Jun-2018 08:01

Talkiet:

We don't authoritatively know what the unaffected ranges are. It's also possible this isn't the only predictive factor - it could be isolated to some BNGs and not others. I know it's not what you want to hear and and I WILL see if I can get an update tomorrow, but attempting to 'fix' this by putting people on temporary IPs would create more work to undo as well - plus might not fix the issue.

If you haven't already, it would be worth trying a VPN - that will effectively change your IP and might provide a temporary workaround.

Cheers - N

Can you give any updates on the situation?

geektahiti

24 posts

Geek

#2040051 18-Jun-2018 21:22

Yep any update will be greatly appreciated :)
It is still not solved

geektahiti

24 posts

Geek

#2042043 21-Jun-2018 22:31

Up :)

Talkiet

4792 posts

Uber Geek

Trusted

#2042045 21-Jun-2018 22:34

Have been very busy on other stuff but will see if I can get an update tomorrow.

Cheers - N

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

jspk

35 posts

Geek

#2042715 23-Jun-2018 00:05

Talkiet:

Have been very busy on other stuff but will see if I can get an update tomorrow.

Cheers - N

Still experiencing this issue, been nearly 3 weeks now, pretty disappointing :/
Upgraded to Fibre MAX (900+ down/400 up) few days ago (was planned before these issues started happening) and the high latency still occurs on the new connection.
Here is a recent traceroute and ping:

Sharesies kids

Free kids accounts - trade shares and funds (NZ, US) with Sharesies (affiliate link).

geektahiti

24 posts

Geek

#2042759 23-Jun-2018 11:02

same for me

Very disappointed.

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#2042761 23-Jun-2018 11:09

Changing to UFB isn't going to change the routing for traffic inside Australia.

Talkiet

4792 posts

Uber Geek

Trusted

#2042925 23-Jun-2018 17:38

I am still giving this some attention when I can, but you are able to see what 2 providers have the direct issue here right? Your traffic gets to Australia in reasonable time, and is handed across to another party, who THEN has the issue with Telstra.

There are definitely some routes to NZ that don't have the issue (My own fibre100 connection for example doesn't exhibit the issue), but it's not feasible to always move all traffic to avoid issues in all non directly connected networks.

Telstra know about the issue, but we don't have an SLA for how well NTT and Telstra talk to each other.

I'll see if our international people have any update on Monday, but as can be clearly seen from the tracerts above, it's not something wrong in our network (although I admit it's impacting some users to a very very small number of destinations in terms of increased latency)

Cheers - N

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

geektahiti

24 posts

Geek

#2042939 23-Jun-2018 18:59

Hey
Thank you for the update. Appreciate the follow up on Monday.
Glad to hear Telstra is aware about the issue but I would line some EstA for resolution. With the transmania cable fober we should not be having this high latency from Telstra it is quite disappointing hearing Vodafone, Spark and Telstra doing partnership to fund that cable and in results not being able to benefit from it.

All I need is a correct latency for my work from home but it is impacting my performance.

The rest is transparent for me

Talkiet

4792 posts

Uber Geek

Trusted

#2042954 23-Jun-2018 20:14

The trans Tasman cables have nothing to do with this issue. You can see that from the tracerts. It wouldn't matter if there was a magical zero ms latency magiccable from Akl to Sydney, if there are issues upstream of that, they still impact us.

Although we are trying to find stuff out and see what is happening, we have no contractual basis to request urgent (or any!) fixes.

A more direct route would be to have the people in charge of the resources on the network where the problem is raise the issue with their account manager or helpdesk. By the sound of it your company hosts critical resources on that network so if you haven't already, you should get the issues raised by them as well.

(Notwithstanding the above, I'll still see what I can find out Monday)

Cheers - N

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

noroad

949 posts

Ultimate Geek

Trusted

#2043034 24-Jun-2018 06:45

TBH, its kinda a bit funny, you see if Telstra Peered in Sydney on the public exchanges (Equinix/NSW-IX, Mega-IX etc) then the problem would not exist. Also if Spark Peered in Auckland (Auckland-IX, Mega-IX, APE etc then the problem would not exist. So its really a case of the bully in NZ meets the bully in Australia and the customers lose.

People forget that New Zealand's two biggest Telco's still refuse to peer with anyone else (apart from themselves) unless payment is made and now Spark is reaping what it sows. This could be fixed really fast if Spark just peered in Auckland as the affected networks are available on the peering exchanges practically for free. Spark, stop blaming Telstra/NTT and do what's best for your customers, Auckland-IX is available in your very own Mayoral drive exchange right now should you wish to plug in and solve the issue.

noroad

949 posts

Ultimate Geek

Trusted

#2043036 24-Jun-2018 06:59

noroad:

People forget that New Zealand's two biggest Telco's still refuse to peer with anyone else (apart from themselves) unless payment is made and now Spark is reaping what it sows. This could be fixed really fast if Spark just peered in Auckland as the affected networks are available on the peering exchanges practically for free. Spark, stop blaming Telstra/NTT and do what's best for your customers, Auckland-IX is available in your very own Mayoral drive exchange right now should you wish to plug in and solve the issue.

To be clear, the routes that the OP was complaining about (gaming servers) are on the Auckland exchanges, Telstra itself is not of course as they don't peer with anyone unless they pay.

Any Spark guys, I'm very happy to help our your GGI guys if they want help getting routes to the exchanges that politics prevents access to, quid pro quo of course.

yitz

2075 posts

Uber Geek

#2043110 24-Jun-2018 12:01

Vocus might pick up traffic for Blizzard/WoW in Auckland but Softlayer (Discord voice, Path of Exile) doesn't have a similar arrangement. (Discord virtual IP: 168.1.24.108 PoE: au.login.pathofexile.com). Also my understanding is that Telstra path does carry a sizable volume of traffic destined for Spark including the likes of Amazon's Australian AWS region.

And of course owning the relevant cable systems has something to do with it, why else would peering such as "spark_newzealand-peer.sydp01.pr.telstraglobal.net" exist?

1 | 2 | 3 | 4 | 5 | 6 | 7