[Snap] 100Mb / 20Mb UFB only connects to the USA via a 10Mb pipe

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › [Snap] 100Mb / 20Mb UFB only connects to the USA via a 10Mb pipe

1 | 2 | 3

1476 posts

Uber Geek

Trusted

Lifetime subscriber

#1303142 12-May-2015 20:13

Can't say I'm too upset with the speed to the West Coast of the US, 100/20 plan, peak time on snap.

speed test result

timmmay

20580 posts

Uber Geek

Trusted

Lifetime subscriber

#1303155 12-May-2015 20:55

Here's mine to a random server in the US west coast. I'm on 30/10 so that's pretty good.

Aussie is a bit faster

insane

3239 posts

Uber Geek

ID Verified

Trusted

#1303177 12-May-2015 22:15

sbiddle: Are you aware of how TCP works and how latency affects speed? ...

Hopefully we'll see less and less of this as hosts support QUIC. SPDY has made some difference already but QUIC is where the big gains are.

michaelmurfy

meow
13247 posts

Uber Geek

Moderator

ID Verified

Trusted

Lifetime subscriber

#1303226 13-May-2015 00:48

I am on 200/200, this speedtest was done on a cheap Chromebook connected to WiFi at the other end of the house so don't take them seriously. I have never personally noticed any speed issues to the US and I am one to notice as I have a few servers over there.

Snaps international speeds are fine, go have a look at Orcon's current speeds to make yourself feel even better.

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.

raytaylor

4014 posts

Uber Geek

Trusted

#1303227 13-May-2015 01:17

They are right about the tcp acks. Windows XP would top out at 4mbits for international downloads to nz because of its settings.
Speedtest.net uses 5x tcp streams to test - its performing an http get to grab 5x jpg files of different sizes.
The ping is also not a true ping - its an http get also.

Torrents can use both UDP and TCP. UDP doesnt require acks and therefore packets flow much faster over greater distances.

I am just doing some testing to the same destinations...

Quincy

San Diego
Less distance to travel when you get off the southern cross, than say New York or the eastern USA - hency why there isnt much difference between quincy and SD because they are both on the eastern side of the country. But you can definitley see a speed drop over the relatively short distance between SD and Quincy.

Sydney as predicted... much faster since its closer

Notice the *HUGE* difference in speed there between sydney and San Diego

And then of course to Auckland from Napier

So the speed test to auckland is incredibly fast, but as you move further away, the TCP ack delays have an even greater effect per millisecond of delay.
Going from auckland to sydney has only a small effect - a slow down of 24mbits which is 1.04mbits per millisecond of delay.
Now that would mean we expect the san diego to be 1.04mb x 108ms = 112mbits slower than sydney, when in fast it is much much slower due to the dynamic windowing / learning effect.
The tcp packet tuning is also a feature of the device sending the packets - so its not really something you can fine tune very much from your end.

Ray Taylor

There is no place like localhost

Spreadsheet for Comparing Electricity Plans Here

dwl

371 posts

Ultimate Geek

#1303313 13-May-2015 08:53

Good points above about TCP and variability. In addition to latency (which needs larger window sizes as latency increases) the loss can become a driving factor. When completely lossless and no congestion the rates are limited by window size (and equipment limits). When small amounts of loss start to appear then the higher delay sources (i.e. offshore) will suffer proportionally worse than more local and when gets too high TCP will really die. High rates to Auckland and low to US might be due to same amount of loss.

As seen above there are varying results depending on ISP and location of speedtest server. The variability could be congestion/loss anywhere in the path which might be under the control of the ISP (e.g. international bandwidth) but also due to exact paths taken with the US especially variable depending on carriers used within the US. ISPs do try and peer with better performing providers if they can.

"Speedtest" also comes in different forms. The free mini version is limited to two threads while the original paid version could have anything from 2 threads up to 8 threads which is set by the ISP. I have seen better results by finding servers that have more threads enabled but if other downloads are single threaded then it can be misleading.

If you want to dig into what is happening then a packet capture and using tools like tcptrace (Linux) helps expose window sizes achieved and extent of retransmissions. Wireshark is also useful and it can be worth checking large transfers over a period of time (with the TCP graphing tools) to see whether for short periods higher rates can be achieved (i.e. not window size limited) and maybe congestion is at work. If the result is similar 24/7 it could be local settings or issues as 10 Mbps max is getting low.

raytaylor

4014 posts

Uber Geek

Trusted

#1303325 13-May-2015 09:24

This all adds up to the driving point behind UFB
When it was being proposed, many technicians were saying its a waste of money because tcp acks for international downloads wont make it any faster than ADSL2.

But now we are seeing more and more companies placing CDN nodes within NZ (netflix) and companies like microsoft setting up data centres in sydney/australia.

Ray Taylor

There is no place like localhost

Spreadsheet for Comparing Electricity Plans Here

Quic Broadband

Move to New Zealand's best fibre broadband service (affiliate link). Free setup code: R587125ERQ6VE. Note that to use Quic Broadband you must be comfortable with configuring your own router.

dwl

371 posts

Ultimate Geek

#1304891 14-May-2015 08:31

raytaylor: This all adds up to the driving point behind UFB
When it was being proposed, many technicians were saying its a waste of money because tcp acks for international downloads wont make it any faster than ADSL2.

But now we are seeing more and more companies placing CDN nodes within NZ (netflix) and companies like microsoft setting up data centres in sydney/australia.

If ADSL and UFB services were being constrained at the same point of limited bandwidth (due to contention) then they might get similar performance. However, I would hope that UFB is over different paths and a few UFB connections don't have to share with many ADSL2 users as they could all get pulled down to common lower rates.

The CDN nodes and especially Google caches should be helping lots but these might also be making it slightly worse for international traffic if sharing the same pinch point (higher delay source suffers worse). I don't know how ISPs provision these services but I suspect there are some items in their toolbox that could help but no doubt come at a cost. Truenet is one of the few ways we have to get some visibility of this variability.

NonprayingMantis

6434 posts

Uber Geek

#1304923 14-May-2015 09:38

dolsen: Can't say I'm too upset with the speed to the West Coast of the US, 100/20 plan, peak time on snap.

that seems remarkably high, given the TCP scaling issues etc. Are you doing any tweaking or anything else unusual?

(this might be very out of date, I'm certainly no expert, but interesting reading anyway)

https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

wasabi2k

2096 posts

Uber Geek

#1304929 14-May-2015 09:44

That page has some interesting findings and information, but it hampered by being written like Microsoft is an evil overlord out to steal your downloads!!111

Microsoft is intentionally restricting Internet download speeds!

FFS.

slingynz

154 posts

Master Geek

#1304930 14-May-2015 09:48

That page seems to only be relevant if you set your networks to "public".

NonprayingMantis

6434 posts

Uber Geek

#1304931 14-May-2015 09:49

wasabi2k: That page has some interesting findings and information, but it hampered by being written like Microsoft is an evil overlord out to steal your downloads!!111

Microsoft is intentionally restricting Internet download speeds!

FFS.

Are you saying Microsoft is not an evil overlord? :P

dolsen

1476 posts

Uber Geek

Trusted

Lifetime subscriber

#1304935 14-May-2015 09:52

NonprayingMantis:
dolsen: Can't say I'm too upset with the speed to the West Coast of the US, 100/20 plan, peak time on snap.

that seems remarkably high, given the TCP scaling issues etc. Are you doing any tweaking or anything else unusual?

(this might be very out of date, I'm certainly no expert, but interesting reading anyway)

https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

No tweaking at all. Windows 8.1 Pro on one of the "Geekzone special dell laptops" from the bargains and deals thread upgraded with a SSD and a faster wireless card. Wireless (AC) as it is faster for me (laptop only has 100Mb/s Ethernet interface). It was the fastest of the results (I checked all of the San Francisco endpoints), however, they were all quite good.

Edit - as the test progressed, the speed was getting faster. Not sure about this particular one, but, for the others, if the test was longer it might have even gone faster.

dwl

371 posts

Ultimate Geek

#1305010 14-May-2015 11:03

dolsen: Edit - as the test progressed, the speed was getting faster. Not sure about this particular one, but, for the others, if the test was longer it might have even gone faster.

It seems too good to me for peak time but maybe Snap has some magic at work. Many ISPs are running caches and I thought speedtest might not get cached but this looks a bit like more local source. Don't be fooled by the ping time. Maybe Snap could confirm?

One way to tell is to do a packet capture and check the RTT on a TCP analysis - I have been surprised to see a customer comparing providers and supposedly getting very good international speeds and the RTT was down to about 4ms - it was coming out of an ISP cache in Auckland.

Publius

276 posts

Ultimate Geek

#1305197 14-May-2015 14:57

dwl:
dolsen: Edit - as the test progressed, the speed was getting faster. Not sure about this particular one, but, for the others, if the test was longer it might have even gone faster.

It seems too good to me for peak time but maybe Snap has some magic at work. Many ISPs are running caches and I thought speedtest might not get cached but this looks a bit like more local source. Don't be fooled by the ping time. Maybe Snap could confirm?

One way to tell is to do a packet capture and check the RTT on a TCP analysis - I have been surprised to see a customer comparing providers and supposedly getting very good international speeds and the RTT was down to about 4ms - it was coming out of an ISP cache in Auckland.

Yep, most ISPs do mess with speedtest and cache it to make it "faster".

Best way to test your speed is using Bittorrent. Find a large well-seeded torrent (latest debian dvd iso would be a good start), put your bittorrent client into prefer-udp mode (if possible), change it to display download speed in MBit/sec instead of MBytes/sec (generally the default), and see what you get. Likely your router will be the bottleneck at this point, as too many open tcp/udp connections will kill most routers and all cheap routers.

raytaylor: This all adds up to the driving point behind UFB
When it was being proposed, many technicians were saying its a waste of money because tcp acks for international downloads wont make it any faster than ADSL2.

But now we are seeing more and more companies placing CDN nodes within NZ (netflix) and companies like microsoft setting up data centres in sydney/australia.

UFB like all fast internet isn't just about downloading one thing faster, its also for multiple people/computers downloading different things without interfering. Windows can be downloading its service packs, with apple doing its ios upgrade, all while watching netflix.

Also, most good streaming tv providers also get around the TCP latency problem by chunking the stream into small pieces and downloading them independently.

1 | 2 | 3