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 | 3 | 4 | 5
mercutio
1392 posts

Uber Geek


  #702253 16-Oct-2012 21:57
Send private message

Stasis007: Maybe related, maybe not. I've had spells of horrible latency in World of Warcraft the last week or two. Usually happens between 8-11pm. Worst I've seen in over 3 years, etc. Actually DC's me often, and local pings are fine but 2k+ pings to eastern USA.

Mate on Telstra was experiencing exactly the same which seems significant.


FWIW, it seems that Diablo 3 has had some latency spikes around 7 pm recently.   (haven't played it much) and around the same time cogent interim hops seem to show packet loss.

The 203.167. clear address in the middle often shows high ping times but this doesn't seem to translate to bad performance, but the cogent and at&t ones do.

Really if you're playing wow you should use west coast servers, but I'd try using pingplotter to the destination server which you can find in "resource monitor" under network.

If jitter (time difference between minimum and average ping) is more than 10 msec near the destination, or there is packet loss showing on pingplotter it could be noticable.  The thing about playing games is there's a constant stream of packets - so if you get 1% packet loss, and the game sends 10,000 packets then you're actually missing 100 packets, which could lead to 100 spikes.  Really blizzard should fix their game to deal better with packet loss, but if you look around on the internet issues are reasonably common over whole isp's at various times, as blizzard use a provider who charge for access to their network.. (kind of liek if you hosted a game on telecom, and lots of isp's got peak congestion to telecom, they'd have to buy more transit to telecom to raise performance, adn then who should you blame, the company who decides to host on telecom, telecom for expecting others to pay to receive data from them, or ISP's not wishing to pay for direct transit. 

Right now as it stands most ISP's buy national traffic to telstraclear or globalgateway, and not both seperately.  So there'll be a longer router to providers using globalgateway for domestic traffic - but it's not generally oversubscribed in NZ.

Anyway, as it stands I'm not aware of any provider in NZ having direct connectivity to at&t, and you're relying on cogent for connectivity to at&t atm which have a reputation for oversubscribing transit links.

Although currently there aren't strong national peering issues nationally there a few between NZ<->Australia, where providers are slightly more keen to bypass the tradtional telco's.




astrial
29 posts

Geek


  #702643 17-Oct-2012 19:25
Send private message

Here's mine, pinged just now.  I was actually going to log in and say how awesome my ping has been to US West DOTA2 servers (reporting ~160ms in game generally across night peak), but I see here that the jitter to the Snap DNS server is pretty high!

Pinging 202.37.101.1 with 32 bytes of data:
Reply from 202.37.101.1: bytes=32 time=20ms TTL=61
Reply from 202.37.101.1: bytes=32 time=8ms TTL=61
Reply from 202.37.101.1: bytes=32 time=19ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=48ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=51ms TTL=61
Reply from 202.37.101.1: bytes=32 time=8ms TTL=61
Reply from 202.37.101.1: bytes=32 time=56ms TTL=61
Reply from 202.37.101.1: bytes=32 time=7ms TTL=61
Reply from 202.37.101.1: bytes=32 time=38ms TTL=61
Reply from 202.37.101.1: bytes=32 time=36ms TTL=61
Reply from 202.37.101.1: bytes=32 time=11ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=43ms TTL=61
Reply from 202.37.101.1: bytes=32 time=7ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61

Ping statistics for 202.37.101.1:
Packets: Sent = 19, Received = 19, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 56ms, Average = 20ms

I live about 1km away from Mt Eden/Dominion Road intersection; but I am on ADSL2, not VDSL.

sidefx

3711 posts

Uber Geek

Trusted

  #702687 17-Oct-2012 21:23
Send private message

@astrial: that looks a lot like I'm seeing - try it around 11:30pm \ 12pm (if you can, or maybe in the morning) I'm only seeing it in the evenings.




"I was born not knowing and have had only a little time to change that here and there."         | Octopus Energy | Sharesies
              - Richard Feynman




astrial
29 posts

Geek


  #702800 18-Oct-2012 10:34
Send private message

Yeah, my connection was poor the whole night last night, which was strange.  I'll do some more checking tonight.



Looks like I am connected to the Three Kings exchange (if I can read the Chorus network map correctly).

bender
220 posts

Master Geek


  #703063 18-Oct-2012 16:43
Send private message

Hi all,

Can you post back with the following, trying to establish a pattern here:

What suburb/city you are in:
Which exchange, if you know:
What time the high latency starts:
What time the high latency ends:
Does your throughput drop while this is happening:
If throughput drops, to approx. what speed:

Thanks

astrial
29 posts

Geek


  #703228 18-Oct-2012 21:46
Send private message

Looks fine at this time, on this night (on the Three Kings exchange)

Pinging 202.37.101.1 with 32 bytes of data:
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=12ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=5ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61
Reply from 202.37.101.1: bytes=32 time=6ms TTL=61

Ping statistics for 202.37.101.1:
Packets: Sent = 12, Received = 12, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 12ms, Average = 6ms

sidefx

3711 posts

Uber Geek

Trusted

  #703241 18-Oct-2012 22:05
Send private message

@bender:

What suburb/city you are in: Mt Eden, Auckland
Which exchange, if you know: Mt Eden (Cabinet: MOD\AN)
What time the high latency starts: ~20:30
What time the high latency ends: ~23:30
Does your throughput drop while this is happening: Yes; the upload more noticeably but download on speedtests. 
If throughput drops, to approx. what speed: Not a huge amount according to speedtest; usually Speedtests are a very consistent 33/9.4  but during these higher latency periods it drops to around 28/7.  The speedtest graph also varies a lot more during these periods, whereas during the rest of the day it tends to be quite close to a straight line.  And whereas during the rest of the day it ramps pretty much immediately to the max throughput it takes a while in the evenings. 

 

EDIT: BTW this is what my latency currently looks like to trademe (just for something different)  I'll test again a bit later but I'm pretty sure it's usually around 5-6ms too or not far off:


C:\Users\Simon>ping trademe.co.nz /t

Pinging trademe.co.nz [202.162.72.2] with 32 bytes of data:
Request timed out.
Reply from 202.162.72.2: bytes=32 time=52ms TTL=250
Reply from 202.162.72.2: bytes=32 time=47ms TTL=250
Reply from 202.162.72.2: bytes=32 time=56ms TTL=250
Reply from 202.162.72.2: bytes=32 time=47ms TTL=250
Reply from 202.162.72.2: bytes=32 time=44ms TTL=250
Reply from 202.162.72.2: bytes=32 time=52ms TTL=250
Reply from 202.162.72.2: bytes=32 time=47ms TTL=250
Reply from 202.162.72.2: bytes=32 time=54ms TTL=250
Reply from 202.162.72.2: bytes=32 time=51ms TTL=250
Reply from 202.162.72.2: bytes=32 time=47ms TTL=250
Reply from 202.162.72.2: bytes=32 time=56ms TTL=250
Reply from 202.162.72.2: bytes=32 time=56ms TTL=250

Ping statistics for 202.162.72.2:
Packets: Sent = 13, Received = 12, Lost = 1 (7% loss),
Approximate round trip times in milli-seconds:
Minimum = 44ms, Maximum = 56ms, Average = 50ms








"I was born not knowing and have had only a little time to change that here and there."         | Octopus Energy | Sharesies
              - Richard Feynman


 
 
 

Cloud spending continues to surge globally, but most organisations haven’t made the changes necessary to maximise the value and cost-efficiency benefits of their cloud investments. Download the whitepaper From Overspend to Advantage now.
Zeon
3916 posts

Uber Geek

Trusted

  #703246 18-Oct-2012 22:17
Send private message

Those cabinets have a 1gbps backhaul servicing around 200 customers. Is it really that likely for congestion ?!




Speedtest 2019-10-14


sidefx

3711 posts

Uber Geek

Trusted

  #703248 18-Oct-2012 22:20
Send private message

Zeon: Those cabinets have a 1gbps backhaul servicing around 200 customers. Is it really that likely for congestion ?!


No idea, that's why I created the thread; What are the other possibilities?

EDIT: Not sure if they would be on the cabinet but I think the area on dominion road covers at least one internet cafe. 




"I was born not knowing and have had only a little time to change that here and there."         | Octopus Energy | Sharesies
              - Richard Feynman


mercutio
1392 posts

Uber Geek


  #703257 18-Oct-2012 22:36
Send private message

sidefx:

C:\Users\Simon>ping trademe.co.nz /t

Pinging trademe.co.nz [202.162.72.2] with 32 bytes of data:


fwiw trademe is a bad place to ping to as it bounces between wellington and auckland randomly, snap's dns server is "anycast" which means it'll go to the closest location.   my trademe is currently resolving to 202.162.73.2 which pings consistently lower than 202.162.72.2

sidefx

3711 posts

Uber Geek

Trusted

  #703260 18-Oct-2012 22:39
Send private message

Hmm, good to know, that one is a bit lower:

Pinging 202.162.73.2 with 32 bytes of data:
Reply from 202.162.73.2: bytes=32 time=46ms TTL=250
Reply from 202.162.73.2: bytes=32 time=28ms TTL=250
Reply from 202.162.73.2: bytes=32 time=43ms TTL=250
Reply from 202.162.73.2: bytes=32 time=43ms TTL=250

Ping statistics for 202.162.73.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 46ms, Average = 40ms


Pinging 202.162.72.2 with 32 bytes of data:
Reply from 202.162.72.2: bytes=32 time=58ms TTL=250
Reply from 202.162.72.2: bytes=32 time=39ms TTL=250
Reply from 202.162.72.2: bytes=32 time=48ms TTL=250
Reply from 202.162.72.2: bytes=32 time=49ms TTL=250

Ping statistics for 202.162.72.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 58ms, Average = 48ms





EDIT: Of course they both look much better at 11:30 pm....

C:\Users\Simon>ping 202.162.73.2
Pinging 202.162.73.2 with 32 bytes of data:
Reply from 202.162.73.2: bytes=32 time=6ms TTL=250
Reply from 202.162.73.2: bytes=32 time=6ms TTL=250
Reply from 202.162.73.2: bytes=32 time=6ms TTL=250
Reply from 202.162.73.2: bytes=32 time=6ms TTL=250

Ping statistics for 202.162.73.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 6ms, Average = 6ms

C:\Users\Simon>ping 202.162.72.2

Pinging 202.162.72.2 with 32 bytes of data:
Reply from 202.162.72.2: bytes=32 time=14ms TTL=250
Reply from 202.162.72.2: bytes=32 time=14ms TTL=250
Reply from 202.162.72.2: bytes=32 time=14ms TTL=250
Reply from 202.162.72.2: bytes=32 time=14ms TTL=250

Ping statistics for 202.162.72.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 14ms, Average = 14ms




"I was born not knowing and have had only a little time to change that here and there."         | Octopus Energy | Sharesies
              - Richard Feynman


Ragnor
8218 posts

Uber Geek

Trusted

  #703605 19-Oct-2012 16:21
Send private message

Zeon: Those cabinets have a 1gbps backhaul servicing around 200 customers. Is it really that likely for congestion ?!


From memory the monthly fee for EUBA to Chorus gets you from your cabinet/exchange to the regional EAS (ethernet aggregation switch).

So for these guys in Mt Eden, 3 Kings that would be Mt Albert (I think).  

From there it would likely be EUBA tail extension (from Mt Albert to Mayoral Drive), then handover to Snap's Auckland network which is probably in/at Skytower.

They could be using alternative provider to backhaul from Mt Albert to their network (eg: Vector).

Suspect peak time congestion on Snap's transit from Snap's Auckland to the internet will be the issue, they've probably had significant customer growth and network improvements/upgrades haven't caught up.

Pure speculation though.



frizianz
105 posts

Master Geek


  #703803 19-Oct-2012 22:20
Send private message

Ragnor:
Suspect peak time congestion on Snap's transit from Snap's Auckland to the internet will be the issue, they've probably had significant customer growth and network improvements/upgrades haven't caught up.

Pure speculation though.


This appears not to be the case as its not effecting everyone in Auckland simply a few isolated users - If this were the case you'd see it much more widespread.

Still more than likely a contention / degradation on the local cabinet. Regardless its best to email Snap followed by a phone call to make sure it gets to their more senior CSR's to take a look.

I do understand how hard this kind of fault is to work out where exactly the issue is! But its best to get all parties on-board as they will have different visability of the network.

My 2c.

michaelmurfy
meow
13240 posts

Uber Geek

Moderator
ID Verified
Trusted
Lifetime subscriber

  #703848 20-Oct-2012 00:09
Send private message

My pings are looking pretty good tonight:

mmurphy@router:~$ ping 202.37.101.1
PING 202.37.101.1 (202.37.101.1) 56(84) bytes of data.
64 bytes from 202.37.101.1: icmp_req=1 ttl=61 time=24.4 ms
64 bytes from 202.37.101.1: icmp_req=2 ttl=61 time=23.6 ms
64 bytes from 202.37.101.1: icmp_req=3 ttl=61 time=23.5 ms
64 bytes from 202.37.101.1: icmp_req=4 ttl=61 time=23.5 ms
64 bytes from 202.37.101.1: icmp_req=5 ttl=61 time=23.0 ms
64 bytes from 202.37.101.1: icmp_req=6 ttl=61 time=24.0 ms
64 bytes from 202.37.101.1: icmp_req=7 ttl=61 time=23.4 ms
^C
--- 202.37.101.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6010ms
rtt min/avg/max/mdev = 23.049/23.672/24.413/0.454 ms

I have indeed noticed some degrade in speed / latency as of late, I thought it was my flatmates using the net getting the latest Ubuntu 12.10 distro but it turns out it wasn't - the Fritz!box is showing almost zero traffic going through.

Here are some graphs from my TrueNet probe:

 

Domestic Ping (Hourly Average - 1 week)



International Ping (Hourly Average - 1 week)




From what I can see here it seems that pinging Snap's own DNS server is showing delay during peak times, going overseas normally has no delay (assuming this is what the TrueNet probe is actually pinging)




Michael Murphy | https://murfy.nz
Referral Links: Quic Broadband (use R122101E7CV7Q for free setup)

Are you happy with what you get from Geekzone? Please consider supporting us by subscribing.
Opinions are my own and not the views of my employer.


sidefx

3711 posts

Uber Geek

Trusted

  #703857 20-Oct-2012 00:34
Send private message

(Hopefully OK to share these) Mine are even less pretty, especially the throughput graphs. I assume because they test with fairly small files and with the higher potential throughput of VDSL it's more sensitive to increased latency? It looks like it's also affecting both domestic and international latency.

Domestic ping



International Ping


Download throughput


Upload Throughput




"I was born not knowing and have had only a little time to change that here and there."         | Octopus Energy | Sharesies
              - Richard Feynman


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





News and reviews »

Air New Zealand Starts AI adoption with OpenAI
Posted 24-Jul-2025 16:00


eero Pro 7 Review
Posted 23-Jul-2025 12:07


BeeStation Plus Review
Posted 21-Jul-2025 14:21


eero Unveils New Wi-Fi 7 Products in New Zealand
Posted 21-Jul-2025 00:01


WiZ Introduces HDMI Sync Box and other Light Devices
Posted 20-Jul-2025 17:32


RedShield Enhances DDoS and Bot Attack Protection
Posted 20-Jul-2025 17:26


Seagate Ships 30TB Drives
Posted 17-Jul-2025 11:24


Oclean AirPump A10 Water Flosser Review
Posted 13-Jul-2025 11:05


Samsung Galaxy Z Fold7: Raising the Bar for Smartphones
Posted 10-Jul-2025 02:01


Samsung Galaxy Z Flip7 Brings New Edge-To-Edge FlexWindow
Posted 10-Jul-2025 02:01


Epson Launches New AM-C550Z WorkForce Enterprise printer
Posted 9-Jul-2025 18:22


Samsung Releases Smart Monitor M9
Posted 9-Jul-2025 17:46


Nearly Half of Older Kiwis Still Write their Passwords on Paper
Posted 9-Jul-2025 08:42


D-Link 4G+ Cat6 Wi-Fi 6 DWR-933M Mobile Hotspot Review
Posted 1-Jul-2025 11:34


Oppo A5 Series Launches With New Levels of Durability
Posted 30-Jun-2025 10:15









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.