Follow

OmniWAN - Bandwidth performance

 

 

Introduction:

Bandwidth is the number one selling point ISPs push to their customers, yet bandwidth availability is rarely guaranteed.  Why is that?  Before we get into that, consider this. It's important to define bandwidth as a RATE and NOT a performance metric.  Though it is still an important metric, it defines capacity and not the speed of packets actually getting to their destination on time and in the right order.  This is a much more important metric to deliver a better end user experience, than simply sheer capacity is.  It is much more cost effective for carriers to allow lots of packets from many customers (shared subscriber lines) without guaranteeing any bandwidth or real-world performance values (low latency, jitter, no packet loss).  This is why bandwidth is not guaranteed.  It hurts their bottom dollar since infrastructure costs go up and their ability to price competitively would no longer be an option.

 

OmniWAN and it's benefits

OmniWAN take the best of the capacity of your ISP and keeps latency, jitter, and packet loss in check.  As capacity and quality changes, OmniWAN keeps the lines in control by adjusting on the fly.  See here for more details.

 

Physical limitations

(The following tests were conducted with no regular business traffic load on the line)

 

OmniBridges are equipped with 1Gb interfaces. Bandwidth testing has shown capacity of 900 Mbps+ on a dedicated fiber line.  It is important to remember a percentage of that will be used for protocol overhead etc as is typical with TCP based switching.  Many factors influence the actual speeds achieved with the primary being the path from your office through the edge of your ISPs network, and also the path to the OmniWAN datacenter thereafter.  A bandwidth test while on OmniWAN is NOT the same measurement as while you are off of OmniNet. 

 

OmniNet Datacenters

- OmniNet data centers do not have throttling on the interfaces that provide hosting for OmniWAN services

- Speeds achieved from a client site to OmniNet data centers are dependent on and can be susceptible to carrier specific slow downs that are upstream that can affect performance.  That's why checking with a sites' ISP is so important.

- Have monitoring in place to verify resources are plentiful for normal operations

 

Experience lower than ideal speed test results?

 

First of all, if you are a shared subscription line (Commonly DSL and Cable based lines) you provider has not sold you guaranteed bandwidth.  When you run a speed test, the ISP can (and most likely will) see the traffic going to a speed test server and will prioritize this test, to show you the capacity the line is capable of bursting up to.  This is not the same speed you will be able to consume in a constant stream at all times.  The term, shared subscriber line means this is expected.  Lines with dedicated speed are a much better option when available. 

Common means for this type are carrier via fiber subscriptions.  Its important to find out if the fiber is dedicated (guaranteed) and NOT shared as some providers are now using that trick as well.  A key indicator that a line may be dedicated is checking if the ISP states the provisioning upload speed is the same as the download speed (symmetrical provisioning).

 

The following information can help you narrow down where an issue may be

A. What kind of connection is this? Cable/DSL/Fiber?***
B. Who is the carrier? (Helps you understand if there may be any known carrier issues)
C. What consistent speeds were you seeing previously?

1. Used wired ports as close to the OmniBridge as possible for testing (least hops, bypassing switches if possible) to establish baseline

- Choose speed testing servers regionally near the data center your OmniBridge is connected to (Overview tab)

- Check with speakeasy.net/speedtest and Speedtest.net

- Review results and compare

2. Test speeds without the OmniBridge in place


- Choose speed testing servers regionally near the data center your OmniBridge is connected to

- Check with speakeasy.net/speedtest and Speedtest.net

- Review results

 

***If location is on DSL please read the following article:

Finding the Maximum MTU Value


Below are the kind of considerations we review when speed issues are reported.


----Throughput performance Issues and considerations----

- Testing to carrier related speed test site would likely yield better results for traffic originating from their own network (Less hops etc.)

- Regular business hours traffic - load from day to day traffic will affect the speedtests since bandwidth is being consumed on the line

- Customer not on a business class ISP subscription - Residential subscriptions do not offer the level of "guaranteed" bandwidth expectations a business plan would carry. This is carrier based behavior, and is NOT uncommon in the industry.

- Machine the test is running on - Testing could be influenced by the machine the test is running from including network card reliability and performance itself, patch cable to switch, switch load, resource availability on the machine

- Replication/Backup operations - Scheduled or Ad-hoc large data transfers will hog up bandwidth and can affect the speedtest results

- Carrier throughput issues - at times carriers don't provide the advertised speed consistently 24/7

- Speed testing to sites not regionally located near the datacenter - Traffic beyond the datacenter traversing networks across states may pass many more hops and be at the mercy of "normal" or expected speed reduction across large regions (i.e. Atlanta to Los Anglees etc.)

- Differing speedtest algorithms - used by different websites that offer speed testing. This is why comparisons are beneficial

- Chatty or physical traffic issues on the local network - If a network switch interfaces devices in between OmniNet and the rest of the segment, speeds are influenced by the network switch performance in between OmniNet and local load on the switch itself (See CPU/Memory/other resource limitations).

- Path from ISP to hosting center - If routers that manage traffic between ISP and our datacenter have less than ideal performance or experience performance degradation

- Issues with the OmniBridge device itself or patch cables leading to it

For the more paranoid---

- Carrier analysis - Major ISP's have been suspected to regulate or even capture traffic and analyze traffic that they don't "understand" and this scenario would most likely include encrypted tunneled traffic - Carriers would not disclose this information to the public for obvious reasons

To help us reach a valid comparison, when customer or partner provides speedtest results, there are a couple of things that will help such as:

- Location ISP type and what carrier

- Time/Date of testing

- Service they are testing with (Speedtest.net or Speakeasy.net/speedtest etc.)

- Location they are testing against (This should be somewhere regionally near the Datacenter the customer is assigned to)

- A comparison on speed tests from multiple speed testing sites would be far more valuable

Typically providing this information your OmniNet reseller will help quickly reference the service, time, and location to help understand if and where an issue may be.

 

Have more questions? Submit a request