YouTube Caching Results: detailed analysis from live systems


Since the release of YouTube caching support on our NetEqualizer bandwidth controller,  we have been able to review several live systems in the field. Below we will go over the basic hit rate of YouTube videos and explain in detail how this effects the user experience. The analysis  below is based on an actual snapshot from a mid-sized state university, using a 64 Gigabyte cache, and approximately 2000 students in residence.

The Squid Proxy server provides a wide range of statistics. You can easily spend hours examining them and become exhausted with MSOS, an acronym for “meaningless stat overload syndrome”.  To save you some time we are going to look at just one stat from one report.  From the Squid Statistics Tab on the NetEqualizer, we selected the Cache Client List option. This report shows individual Cache stats for all clients on your network. At the very bottom is a summary report totaling all squid stats and hits for all clients.

TOTALS

  • ICP : 0 Queries, 0 Hits (0%)
  • HTTP: 21990877 Requests, 3812 Hits (0%)

At first glance it appears as if the ratio of actual cache hits,  3812, to HTTP requests,  21990877,  is extremely low.  As with all statistics the obvious conclusion can be misleading. First off, the NetEqualizer cache is deliberately tuned to NOT cache HTTP requests smaller than 2 Megabytes. This is done for a couple of reasons:

1) Generally, there is no advantage to caching small Web pages, as they normally load up quickly on systems with NetEqualizer fairness in place. They already have priority.

2) With a few exceptions of popular web sites , small web hits are widely varied and fill up the cache – taking away space that we would like to use for our target content, Youtube Videos.

Breaking down the amount of data in a typical web site versus a Youtube hit.

It is true that web sites today can often exceed a Megabyte.  However ,rarely does a web site of 2 Megabytes load up as a single hit. It is comprised of many sub-links, each of which generates a web hit in the summary statistics. A simple HTTP page typically triggers about 10 HTTP requests for perhaps 100K bytes of data total. A more complex page may generate 500K. For example, when you go to the CNN home page there are quite a few small links, and each link increments the HTTP counter. On the other hand, a YouTube hit generates one hit for about 20 megabits of data. When we start to look at actual data cached instead of total Web Hits, the ratio of cached to not cached is quite different.

Our cache set up is also designed to only cache Web pages from 2 megabytes to 40 megabytes, with an estimated average of 20 megabytes. When we look at actual data cached (instead of hits) this gives us about 400 gigabytes of regular HTTP data of which about 76 Gigabytes  came from the cache. Conservatively about 10 percent of all HTTP data came from cache by this rough estimate. This number is  much more significant than the  HTTP statistics reveal.

Even more telling, is that effect these hits have on user experience.

YouTube streaming data, although not the majority of data on this customer system, is very time-sensitive while at the same time being very bandwidth intensive.  The subtle boost made possible by caching 10 percent of the data on this system has a discernible effect on the user experience. Think about it, if 10 percent of your experience on the Web is video, and you were resigned to it timing out and bogging down, you will notice the difference when those YouTube videos play through to completion, even if only half of them come from cache.

For a more detailed technical overview of NetEqualizer YouTube caching (NCO) click here.

Setting Up a Squid Proxy Caching Co-Resident with a Bandwidth Controller


Editor’s Note: It was a long road to get here (building the NetEqualizer Caching Option (NCO) a new feature offered on the NE3000 & NE4000), and for those following in our footsteps or just curious on the intricacies of YouTube caching, we have laid open the details.

This evening, I’m burning the midnight oil. I’m monitoring Internet link statistics at a state university with several thousand students hammering away on their residential network. Our bandwidth controller, along with our new NetEqualizer Caching Option (NCO), which integrates Squid for caching, has been running continuously for several days and all is stable. From the stats I can see, about 1,000 YouTube videos have been played out of the local cache over the past several hours. Without the caching feature installed, most of the YouTube videos would have played anyway, but there would be interruptions as the Internet link coughed and choked with congestion. Now, with NCO running smoothly, the most popular videos will run without interruptions.

Getting the NetEqualizer Caching Option to this stable product was a long and winding road.  Here’s how we got there.

First, some background information on the initial problem.

To use a Squid proxy server, your network administrator must put hooks in your router so that all Web requests go the Squid proxy server before heading out to the Internet. Sometimes the Squid proxy server will have a local copy of the requested page, but most of the time it won’t. When a local copy is not present, it sends your request on to the Internet to get the page (for example the Yahoo! home page) on your behalf. The squid server will then update a local copy of the page in its cache (storage area) while simultaneously sending the results back to you, the original requesting user. If you make a subsequent request to the same page, the Squid will quickly check it to see if the content has been updated since it stored away the first time, and if it can, it will send you a local copy. If it detects that the local copy is no longer valid (the content has changed), then it will go back out to the Internet and get a new copy.

Now, if you add a bandwidth controller to the mix, things get interesting quickly. In the case of the NetEqualizer, it decides when to invoke fairness based on the congestion level of the Internet trunk. However, with the bandwidth controller unit (BCU) on the private side of the Squid server, the actual Internet traffic cannot be distinguished from local cache traffic. The setup looks like this:

Internet->router->Squid->bandwidth controller->users

The BCU in this example won’t know what is coming from cache and what is coming from the Internet. Why? Because the data coming from the Squid cache comes over the same path as the new Internet data. The BCU will erroneously think all the traffic is coming from the Internet and will shape cached traffic as well as Internet traffic, thus defeating the higher speeds provided by the cache.

In this situation, the obvious solution would be to switch the position of the BCU to a setup like this:

Internet->router->bandwidth controller->Squid->users

This configuration would be fine except that now all the port 80 HTTP traffic (cached or not) will appear like it is coming from the Squid proxy server and your BCU will not be able to do things like put rate limits on individual users.

Fortunately, with the our NetEqualizer 5.0 release, we’ve created an integration with NetEqualizer and co-resident Squid (our NetEqualizer Caching Option) such that everything works correctly. (The NetEqualizer still sees and acts on all traffic as if it were between the user and the Internet. This required some creative routing and actual bug fixes to the bridging and routing in the Linux kernel. We also had to develop a communication module between the NetEqualizer and the Squid server so the NetEqualizer gets advance notice when data is originating in cache and not the Internet.)

Which do you need, Bandwidth Control or Caching?

At this point, you may be wondering if Squid caching is so great, why not just dump the BCU and be done with the complexity of trying to run both? Well, while the Squid server alone will do a fine job of accelerating the access times of large files such as video when they can be fetched from cache, a common misconception is that there is a big relief on your Internet pipe with the caching server.  This has not been the case in our real world installations.

The fallacy for caching as panacea for all things congested assumes that demand and overall usage is static, which is unrealistic.  The cache is of finite size and users will generally start watching more YouTube videos when they see improvements in speed and quality (prior to Squid caching, they might have given up because of slowness), including videos that are not in cache.  So, the Squid server will have to fetch new content all the time, using additional bandwidth and quickly negating any improvements.  Therefore, if you had a congested Internet pipe before caching, you will likely still have one afterward, leading to slow access for many e-mail, Web  chat and other non-cachable content. The solution is to include a bandwidth controller in conjunction with your caching server.  This is what NetEqualizer 5.0 now offers.

In no particular order, here is a list of other useful information — some generic to YouTube caching and some just basic notes from our engineering effort. This documents the various stumbling blocks we had to overcome.

1. There was the issue of just getting a standard Squid server to cache YouTube files.

It seemed that the URL tags on these files change with each access, like a counter, and a normal Squid server is fooled into believing the files have changed. By default, when a file changes, a caching server goes out and gets the new copy. In the case of YouTube files, the content is almost always static. However, the caching server thinks they are different when it sees the changing file names. Without modifications, the default Squid caching server will re-retrieve the YouTube file from the source and not the cache because the file names change. (Read more on caching YouTube with Squid…).

2. We had to move to a newer Linux kernel to get a recent of version of Squid (2.7) which supports the hooks for YouTube caching.

A side effect was that the new kernel destabilized some of the timing mechanisms we use to implement bandwidth control. These subtle bugs were not easily reproduced with our standard load generation tools, so we had to create a new simulation lab capable of simulating thousands of users accessing the Internet and YouTube at the same time. Once we built this lab, we were able to re-create the timing issues in the kernel and have them patched.

3. It was necessary to set up a firewall re-direct (also on the NetEqualizer) for port 80 traffic back to the Squid server.

This configuration, and the implementation of an extra bridge, were required to get everything working. The details of the routing within the NetEqualizer were customized so that we would be able to see the correct IP addresses of  Internet sources and users when shaping.  (As mentioned above, if you do not take care of this, all IPs (traffic) will appear as if they are coming from the Proxy server.

4. The firewall has a table called ConnTrack (not be confused with NetEqualizer connection tracking but similar).

The connection tracking table on the firewall tends to fill up and crash the firewall, denying new requests for re-direction if you are not careful. If you just go out and make the connection table randomly enormous that can also cause your system to lock up. So, you must measure and size this table based on experimentation. This was another reason for us to build our simulation lab.

5. There was also the issue of the Squid server using all available Linux file descriptors.

Linux comes with a default limit for security reasons, and when the Squid server hit this limit (it does all kinds of file reading and writing keeping descriptors open), it locks up.

Tuning changes that we made to support Caching with Squid

a. To limit the file size of a cached object of 2 megabytes (2MB) to 40 megabytes (40MB)

  • minimum_object_size 2000000 bytes
  • maximum_object_size 40000000 bytes

If you allow smaller cached objects it will rapidly fill up your cache and there is little benefit to caching small pages.

b. We turned off the Squid keep reading flag

  • quick_abort_min 0 KB
  • quick_abort_max 0 KB

This flag when set continues to read a file even if the user leave the page, for example when watching a video if the user aborts on their browser the Squid cache continues to read the file. I suppose this could now be turned back on, but during testing it was quite obnoxious to see data transfers talking place to the squid cache when you thought nothing was going on.

c. We also explicitly told the Squid what DNS servers to use in its configuration file. There was some evidence that without this the Squid server may bog down, but we never confirmed it. However, no harm is done by setting these parameters.

  • dns_nameservers   x.x.x.x

d. You have to be very careful to set the cache size not to exceed your actual capacity. Squid is not smart enough to check your real capacity, so it will fill up your file system space if you let it, which in turn causes a crash. When testing with small RAM disks less than four gigs of cache, we found that the Squid logs will also fill up your disk space and cause a lock up. The logs are refreshed once a day on a busy system. With a large amount of pages being accessed, the log will use close to one (1) gig of data quite easily, and then to add insult to injury, the log back up program makes a back up. On a normal-sized caching system there should be ample space for logs

e. Squid has a short-term buffer not related to caching. It is just a buffer where it stores data from the Internet before sending it to the client. Remember all port 80 (HTTP) requests go through the squid, cached or not, and if you attempt to control the speed of a transfer between Squid and the user, it does not mean that the Squid server slows the rate of the transfer coming from the Internet right away. With the BCU in line, we want the sender on the Internet to back off right away if we decide to throttle the transfer, and with the Squid buffer in between the NetEqualizer and the sending host on the Internet, the sender would not respond to our deliberate throttling right away when the buffer was too large (Link to Squid caching parameter).

f. How to determine the effectiveness of your YouTube caching statistics?

I use the Squid client cache statistics page. Down at the bottom there is a entry that lists hits verses requests.

TOTALS

  • ICP : 0 Queries, 0 Hits (0%)
  • HTTP: 21990877 Requests, 3812 Hits (0%)

At first glance, it may appear that the hit rate is not all that effective, but let’s look at these stats another way. A simple HTTP page generates about 10 HTTP requests for perhaps 80K bytes of data total. A more complex page may generate 500k. For example, when you go to the CNN home page there are quite a few small links, and each link increments the HTTP counter. On the other hand, a YouTube hit generates one hit for about 20 megabits of data. So, if I do a little math based on bytes cached we get, the summary of HTTP hits and requests above does not account for total data. But, since our cache is only caching Web pages from two megabits to 40 megabits, with an estimated average of 20 megabits, this gives us about 400 gigabytes of regular HTTP and 76 Gigabytes of data that came from the cache. Abut 20 percent of all HTTP data came from cache by this rough estimate, which is a quite significant.

Seventeen Unique Ideas to Speed up Your Internet


By Eli Riles
Eli Riles is a retired insurance agent from New York. He is a self-taught expert in network infrastructure. He spends half the year traveling and visiting remote corners of the earth. The other half of the year you’ll find him in his computer labs testing and tinkering with the latest network technology.  For questions or comments please contact him at
admin@netequalizer.com

Updated 11/30/2015 – We are now up to sixteen (17) tips!
————————————————————————————————————————————————

Although there is no way to actually make your true Internet speed faster, here are some tips for home and corporate users that can make better use of the bandwidth you have, thus providing the illusion of a faster pipe.

1) Use A VPN tunnel to get to blocked content.

One of the little know secrets your provider does not want you to know is that they will slow video or software updates if the content is not hosted on their network. Here is an article with details on how you can get around this restriction.

 

 

 

2) Time of day does make a difference

During peak internet Usage times, 5 PM to Midnight local time, your upstream provider is also most likely congested.  If you have a bandwidth intensive task to do, such as downloading an update for your IPAD, you can likely get a much faster download by doing your download earlier in the day. I have even noticed that the more obscure YouTube’s and videos,  have problems running at peak traffic times. My upstream provider does a good job with Netflix and popular videos during peak hours ( these can be found in their cache), but if I get something that is not likely stored in a local copy on their servers the video will lag during peak times. (see our article on caching)

3) Turn off Java Script

There are some trade offs with doing this , but it does make a big difference on how fast pages will load. Here is an article where cover all the  relevant details.

Note: Prior to 2010  setting your browser to text only mode was a viable option, but today most sites are full of graphics and virtually unreadable in text only mode.

  • If you are stuck with a dial-up or slower broadband connection, your  browser likely has an  option to load text-only. If you are a power user that’s gaming or watching YouTube, text-only will obviously have no effect on these activities, but it will speed up general browsing and e-mail.  Most web pages are loaded with graphics which take up the bulk of the load time, so switching to text-only will eliminate the graphics and save you quite a bit of time.

4) Install a bandwidth controller to make sure no single connection dominates your bandwidth

Everything you do on the Internet creates a connection from inside your network to the Internet, and all of these connections compete for the limited amount of bandwidth your ISP provides.

Your router (cable modem) connection to the Internet provides first come/first serve service to all the applications trying to access the Internet. To make matters worse, the heavier users, the ones with the larger persistent downloads, tend to get more than their fair share of router cycles.  Large downloads are like the school yard bully, they tend to butt in line, and not play fair.

Read the full article.

5) Turn off the other computers in the house

Many times, even during the day when the kids are off to school, I’ll be using my Skype phone and the connection will break up.  I have no idea what exactly the kids’ computers are doing, but if I log them off the Internet, things get better with the Skype call every time. In a sense, it’s a competition for limited bandwidth resources, so, decreasing the competition will usually boost your computer’s performance.

6) Kill background tasks on your computer

You should also try to turn off any BitTorrent or background tasks on your computer if you are having trouble while trying to watch a video or make a VoIP call.  Use your task bar to see what applications are running and kill the ones you don’t want.  Although this is a bit drastic, you may just find that it makes a difference. You’d be surprised what’s running on your computer without you even knowing it (or wanting it).

For you gamers out there, this also means turning off the audio component on your games if you do not need it for collaboration.

7) Test your Internet speed

One of the most common issues with slow internet service is that your provider is not giving you the speed/bandwidth that they have advertised.  Here is a link to our article on testing your Internet speed, which is a good place to start.

Note:  Comcast has adopted a 15 minute Penalty box in some markets. Your initial speed tests will likely show no degradation, but if you persist at watching high-definition video for more than 15 minutes, you may get put into their Penalty box.  This practice helps preserve a limited resource in some crowded markets.  We note it here because we have heard reports of people happily watching YouTube videos only to have service degrade.

Related Article: The real meaning of Comcast generosity.

8) Make sure you are not accidentally connected to a weak access point signal

There are several ways an access point can slow down your connection a bit.  If the signal between you and the access point is weak, the access point will automatically downgrade its service to a slower speed. This happens to me all the time. My access point goes on the blink (needs to be re-booted) and my computer connects to the neighbor’s with a weaker signal. The speed of my connection on the weaker signaled AP is quite variable.  So, if you are on wireless in a densely populated area, check to make sure what signal you are connected  to.

9) Caching — How  does it work and is it a good idea?

Offered by various vendors and built into Internet Explorer, caching can be very effective in many situations. Caching servers have built-in intelligence to store the most recently and most frequently requested information, thus preventing future requests from traversing a WAN/Internet link unnecessarily.

Many web servers keep a time stamp of their last update to data, and browsers such as the popular Internet Explorer will check the time stamp on the host server. If the page time stamp has not changed since the last time you accessed the page, IE will grab it and present a local stored copy of the Web page (from the last time you accessed the page), saving the time it would take to load the page from across the Internet.

So what is the downside of caching?

There are two main issues that can arise with caching:

a) Keeping the cache current. If you access a cached page that is not current, then you are at risk of getting old and incorrect information. Some things you may never want to be cached, for example the results of a transactional database query. It’s not that these problems are insurmountable, but there is always the risk that the data in cache will not be synchronized with changes. I personally have been misled by old data from my cache on several occasions.

b) Volume. There are some 100 million Web sites out on the Internet. Each site contains upwards of several megabytes of public information. The amount of data is staggering and even the smartest caching scheme cannot account for the variation in usage patterns among users and the likelihood they will hit an uncached page.

Recommended: Related article on how ISPs use caching to speed up NetFlix and Youtube Videos.

For information on turning off caching, click here.

 

10) Kill your virus protection software

With the recent outbreak of the H1N1 virus, it reminded me of  how sometimes the symptoms and carnage from a vaccine are worse than the disease it purports to cure.  Well, the same holds true for your virus protection software. Yes, viruses are real and can take down your computer, but so can a disk crash, which is also inevitable.  You must back up your critical data regularly.  However, that virus software seems to dominate more resources on my desktop than anything else.  I no longer use anything and could not be happier.  But be sure to use a reliable back-up (as you will need to rebuild your computer now and then, which I find a better alternative than running a slow computer all of the time).

11) Set a TOS bit to provide priority

A TOS bit  is a special bit within an IP packet that directs routers to give preferential treatment to selected packets.  This sounds great, just set a bit and move to the front of the line for faster service.  As always, there are limitations.

– How does one set a TOS bit?
It seems that only very special enterprise  applications, like a VoIP PBX, actually set and make use of TOS bits. Setting the actual bit is not all that difficult if you have an application that deals with the network layer, but most commercial applications just send their data on to the host computer’s clearing house for data, which in turn puts it into IP packets without a TOS bit set.  After searching around for a while, I just don’t see any literature on being able to set a TOS bit at the application level. For example, there are a couple of forums where people mention setting the TOS bit in Skype but nothing definitive on how to do it.

– Who enforces the priority for TOS packets?
This is a function of routers at the edge of your network, and all routers along the path to wherever the IP packet is going. Generally, this limits the effectiveness of using a TOS bit to networks that you control end-to-end. In other words, a consumer using a public Internet connection cannot rely on their provider to give any precedence to TOS bits, hence this feature is relegated to enterprise networks within a business or institution.

–  Incoming traffic generally cannot be controlled.
The subject of when you can and cannot control a TOS bit does get a bit more involved.  We have gone over this in more detail in a separate  article.

12) Avoid Quota Penalties

Some providers are implementing Quotas where they slow you down if you use too much data over a period of time.  If you know that you have a large set of downloads to do, for example synching your device with iTunes Cloud, go to a library and use their free service. Or, if you are truly without morals, logon to your neighbor’s wireless network and do your synch.

13) Consider Application Shaping?

Note: Application shaping is an appropriate topic for corporate IT administrators and is generally not a practical solution for a home user.  Makers of application shapers include Blue Coat (Packeteer) and Allot (NetEnforcer), products that are typically out of the price range for many smaller networks and home users.

One of the most popular and intuitive forms of optimizing bandwidth is a method called “application shaping”, with aliases of “deep packet inspection”, “layer 7 shaping”, and perhaps a few others thrown in for good measure. For the IT manager that is held accountable for everything that can and will go wrong on a network, or the CIO that needs to manage network usage policies, this at first glance may seem like a dream come true.  If you can divvy up portions of your WAN/Internet link to various applications, then you can take control of your network and ensure that important traffic has sufficient bandwidth, right?  Well, you be the judge…

At the center of application shaping is the ability to identify traffic by type.  For example, identifying between Citrix traffic, streaming audio, Kazaa peer-to-peer, or something else.  However, this approach is not without its drawbacks.

Drawback #1: Applications can purposely use non-standard ports
Many applications are expected to use Internet ports when communicating across the Web. An Internet port is part of an Internet address, and many firewall products can easily identify ports and block or limit them. For example, the “FTP” application commonly used for downloading files uses as standard the well-known “port 21”. The fallacy with this scheme, as many operators soon find out, is that there are many applications that do not consistently use a standard fixed port for communication. Many application writers have no desire to be easily classified. In fact, they don’t want IT personnel to block them at all, so they deliberately design applications to not conform to any formal port assignment scheme. For this reason, any product that aims to block or alter application flows by port should be avoided if your primary mission is to control applications by type.

So, if standard firewalls are inadequate at blocking applications by port, what can help?

As you are likely aware, all traffic on the Internet travels around in what is called an IP packet. An IP packet can very simply be thought of as a string of characters moving from Computer A to Computer B. The string of characters is called the “payload,” much like the freight inside a railroad car. On the outside of this payload, or data, is the address where it is being sent. These two elements, the address and the payload, comprise the complete IP packet.

In the case of different applications on the Internet, we would expect to see different kinds of payloads. For example, let’s take the example of a skyscraper being transported from New York to Los Angeles. How could this be done using a freight train? Common sense suggests that one would disassemble the office tower, stuff it into as many freight cars as it takes to transport it, and then when the train arrived in Los Angeles, hopefully the workers on the other end would have the instructions on how to reassemble the tower.

Well, this analogy works with almost anything that is sent across the Internet, only the payload is some form of data, not a physical hunk of bricks, metal and wires. If we were sending a Word document as an e-mail attachment, guess what, the contents of the document would be disassembled into a bunch of IP packets and sent to the receiving e-mail client where it would be re-assembled. If I looked at the payload of each Internet packet in transit, I could actually see snippets of the document in each packet and could quite easily read the words as they went by.

At the heart of all current application shaping products is special software that examines the content of Internet packets (aka “deep packet inspection”), and through various pattern matching techniques, determines what type of application a particular flow is. Once a flow is determined, then the application shaping tool can enforce the operator’s policies on that flow. Some examples of policy are:

Limit AIM messenger traffic to 100kbs
Reserve 500kbs for Shoretell voice traffic

The list of rules you can apply to traffic types and flow is unlimited.

Drawback #2: The number of applications on the Internet is a moving target.
The best application shaping tools do a very good job of identifying several thousand of them, and yet there will always be some traffic that is unknown (estimated at 10 percent by experts from the leading manufacturers). The unknown traffic is lumped into the unknown classification and an operator must make a blanket decision on how to shape this class. Is it important? Is it not? Suppose the important traffic was streaming audio for a webcast and is not classified. Well, you get the picture. Although theory behind application shaping by type is a noble one, the cost for a company to stay up-to-date is large and there are cracks.

Drawback #3: The spectrum of application types is not static
Even if the application spectrum could be completely classified, the spectrum of applications constantly changes. You must keep licenses current to ensure you have the latest in detection capabilities. And even then it can be quite a task to constantly analyze and change the mix of policies on your network. As bandwidth costs lessen, how much human time should be spent divvying up and creating ever more complex policies to optimize your WAN traffic?

Drawback #4: Net neutrality is comprised by application shaping.
Techniques used in application shaping have become controversial on public networks, with privacy issues often conflicting with attempts to ensure network quality.

Based on these drawbacks, we believe that application shaping is not the dream come true that it may seem at first glance.  Once CIOs and IT Managers are educated on the drawbacks, they tend to agree.

14) Bypass that local consumer reseller

This option might be a little bit out of the price range of the average consumer, and it may not be practical logistically –  but if you like to do things out-of-the-box, you don’t have to buy Internet service from your local cable operator or phone company, especially if you are in a metro area.  Many customers we know have actually gone directly to a Tier 1 point of presence (backbone provider) and put in a radio backhaul direct to the source.  There are numerous companies that can set you up with a 40-to-60 megabit link with no gimmicks.

15) Speeding up your iPhone

Ever been in a highly populated area with 3 or 4 bars and still your iPhone access slows to crawl ?

The most likely reason for this problem is congestion on the provider line. 3g and 4g networks all have a limited sized pipe from the nearest tower back to the Internet. It really does not matter what your theoretical data speed is, when there are more people using the tower than the back-haul pipe can handle, you can temporarily lose service, even when your phone is showing three or four bars.

Unfortunately, you only have a couple of options in this situation. If you are in a stadium with a large crowd, your best bet is to text during the action.  If you wait for a timeout or end of the game,  you’ll find this corresponds to the times when the network slows to a crawl,  so try to finish your access before the last out of the game or the end of the quarter. Pick a time when you know the majority of people are not trying to send data.

Get away from the area of congestion. I have experienced complete lockout of up to 30 minutes, when trying to text, as a sold out stadium emptied out.  In this situation my only chance was  to walk about  1/2 mile or so from the venue to get a text out. Once away from the main stadium, my iPhone connected to a tower with a different back haul away from the congested stadium towers.

Shameless plug: If you happen to be a provider or know somebody that works for a provider  please tell them to call us and we’d be glad to explain the simplicity of equalizing and how it can restore sanity to a congested wireless backhaul.

16) Turn off HTTPS and other Encryption

Although this may sound a bit controversial , there are some providers that,  for sake of survival assume that encrypted traffic is bad traffic.  For example p2p is considered bad traffic, they usee be able to use special equipment to throw it into a lower priority pool so that it gets sent out at a slower speed.   Many applications are starting to encrypt p2p , face book etc…. The provider may assume that all this is “bad”traffic because they don’t know what it is, and hence give it a lower priority.

17) Protocol Spoofing

Note:  This method is applied to Legacy Database servers doing operations over a WAN.  Skip this tip if you are a home user.

Historically, there are client-server applications that were developed for an internal LAN. Many of these applications are considered chatty. For example, to complete a transaction between a client and server, tens of messages may be transmitted when perhaps one or two would suffice. Everything was fine until companies, for logistical and other reasons, extended their LANs across the globe using WAN links to tie different locations together.

To get a better visual on what goes on in a chatty application, perhaps an analogy will help.  It’s like  sending family members your summer vacation pictures, and, for some insane reason, putting each picture in a separate envelope and mailing them individually on the same mail run. Obviously, this would be extremely inefficient, as chatty applications can be.

What protocol spoofing accomplishes is to fake out the client or server-side of the transaction and then send a more compact version of the transaction over the Internet, i.e. put all the pictures in one envelope and send it on your behalf, thus saving you postage.

You might ask why not just improve the inefficiencies in these chatty applications rather than write software to deal with the problem? Good question, but that would be the subject of a totally different article on how IT organizations must evolve with legacy technology, which is beyond the scale of the present article.

In Conclusion

Again, while there is no way to increase your true Internet speed without upgrading your service, these tips can improve performance, and help you to get better results from the bandwidth that you already have.  You’re paying for it, so you might as well make sure it’s being used as effectively as possible. : )

Related Article on testing true video speed over the Internet

A great article from the tech guy regarding tips on dealing with your ISP

Other Articles on Speeding up Your Internet

Five tips and tricks to speed up your Internet

How to speed up your Internet Connection Without any Software

Tips on how to speed up your Internet

About APconnections

Created by APconnections, the NetEqualizer is a plug-and-play bandwidth control and WAN/Internet optimization appliance that is flexible and scalable. When the network is congested, NetEqualizer’s unique “behavior shaping” technology dynamically and automatically gives priority to latency sensitive applications, such as VoIP and email. Click here to request our full pricelist.

%d bloggers like this: