There has been some discussion in various online forums and the media recently about the performance of some UFB services, in particular that end customers are not getting the full speed that they have purchased. 

At Chorus we thought we might add to the discussion with some insights from our perspective, so here goes:

Why can’t I get 100 Megabits per second downstream speed and 50 Megabits per second upstream speed from my 100/50 UFB fibre service?

LFC’s such as Chorus have designed and built a Layer 2 100/50 service.  This is what we provide to the retail service providers (RSP). The RSP puts their service wrap around it and presents a Layer 3 service to their end-users. The IP protocol overhead required to do this consumes approx 5-10% of the available bandwidth, depending on what is being delivered and how you measure it and what colour the fibre is.  Depending on your type of service wrap, you can expect to “lose” around 5% of your speed when measured at Layer 3.

This is what happens when you test your connection using something like speedtest.net – or any other Layer 3 test service.  Not only that, but Layer 3 speed tests are not actually measuring linespeed, they are using throughput as a proxy for attainable speed.  The speedtest.net platform initiates three separate http sessions to run the test and is sensitive to latency, so distance from the platform will show up in the result.

Another way to look at it is to use the car example. A car that can happily run at 100 kilometres per hour.  You drive from Auckland to Wellington and it takes 10 hours.  The distance from Auckland to Wellington is ~600 kilometres.  Divide distance by time and you get an average travelling speed of ~60 kilometres per hour.  The reason you can’t make the journey in six hours is due to the “overhead” in the network.  The traffic encounters buffers (traffic lights) that holds the traffic for short periods of time until it can be safely forwarded, it encounters congestion  (road works, single lane bridges, limited speed zones etc) which means that 100 kilometres per hour is not possible for some sections of the network.

Another consideration with speed test platforms is the routing from the ISP network to the test server.  Not all traffic travels via the most obvious and direct route.  You may live in Auckland and the test server might be in Wellington, but if the traffic goes via a circuitous route (because it cheaper to do so) then the results will reflect that.  Using our car analogy, if you were to drive from Auckland to Wellington – via Gisborne and Napier – you would never get to Wellington in six hours, no matter what sort of car you owned and regardless of the speed limit.

Distance from you to the speed test server is not necessarily going to make the sort of difference you expect, due to interconnect and routing arrangements between the ISP you are connected to and the ISP that hosts the test server.  For example I live in Wellington and have my service from ISP Y (based in Auckland), they have a speedtest.net server inside their network in Auckland and I experience 90-95% of the rated speed which is what I expect – given that I am 600kilometres from the server.  However, when I select a local Wellington server which is hosted in Network C (i.e. less than 4 kilometres from my home) the speedtest server delivers only 60% of the rated speed.  I can prove that this is not local or national network congestion within my ISPs network by simply switching my test server selection to Canberra Australia where the results come back at 85-90% of my rated speed. 

Potential improvements to your speed test results include some or all of the following (in no particular order);

Raise the speed limit
One way around the problem is to raise the speed limit, the buffers and the congestion will still exist, but where it is safe to do so you can travel faster, meaning you can make up for lost time (i.e. carry more packets on the network for some of the time).  Noting that the speed test platforms are not perfect, they are next to the only thing an end-user can use to test what they have.

Chorus has spent some time analysing what it would take in terms of faster Layer 2 speeds so that once a Layer 3 service is presented to the end-user they experience the speed they think they signed up for.  We are talking to the industry on our next tranche of products and are considering the  release of a 217/57.5 Layer 2 service that will show up for customers as a 200/50 at Layer 3. 

We’re looking at applying this same sort of approach to our suite of UFB services, so for example a revised 100/50 service designed to show 100/50 to the end user would actually be 110/57.5 at the Layer 2 level. We need to coordinate this with our customers (the ISPs) as there will be some config and service management they will need to do, but you can expect something like this to show up in the New Year.

Put Speed test servers inside the ISP network
Instead of routing your traffic onto someone else’s network to perform a test, if your ISP hosted their own server, inside their own network, in your city then we would see the fairest Layer 3 representation of attainable speed – noting the limitations of measuring speed at Layer 3 discussed above.

Select your own ISPs speed test server
Check the default speed test server is the closest to you and that it is inside the same network you are connected to before doing the test.

Hope this goes some way to explaining why measuring broadband speed is problematic and helps put things in perspective.  

^GL