That depends on how long your peaks last. The bottom line is that peaks generally only last short periods. If you run out of peak capacity, the side effect is usually minimal. All that occurs is that transfers during those peak time slow down a bit and spreadout over a longer period of time. TCP in nature handles this for you automatically. The longer you hold off on upgrading, (meaning increasing average usage) The usage graph starts to flatten out, with less distance between average and peak. If you have a large number of subs on a backbone, that may not have much of a negative effect on the users at all. Remember most people cant tell the difference between 1mb and 2mb without running a speed test. For this reason, I care very little about peak usage stats.
What is way more relevant is "average usage". I personally think when average usage is around 50%, its time to think about upgrading, and when average usage exceeds 70%, you are way overdue How much you push the limits and how quickly you move to upgrade is determined on several factors. 1) How long it will take to deliver an upgraded pipe. If its 6 months, think ahead. If its 1 week, you might be able to wait till users start to complain. 2) Your SLA. If you have a bunch of high ARPU customers with SLA, you may want to upgrade sooner. For example, if you sell 100mb end user pipe, where custoemr may not use it much, so oversubscription can be significant, but the customer pays a lot to make sure 100mbps is available when they send their large docs once a week. Where as if selling best effort end user services, does it really matter if they slow down during peak usage hours? 3) What you charge. There is a reality to market price and costs. If your selling price is low enough, and your costs are high enough, you may not have any choice but to attempt to change end user's usage patterns. For example, if average bandwdith gets to high, the answer may be to start blocking or slowing down certain types of services, to discourage end users from performing those functions. For $19.95 do you allow then to stream NetFlix, or do you change your AUP and firewall to fix it? The first thing we always ask is.... Why is the bandwidth usage so high? For example, have you checked how much inbound bandwdith is from Internet born DOS, SPAM, Spyware, Scanning, etc? OR what about network overhead? Whether to roue versus bridge, VLAN or not VLAN, Monitor end-to-end centrally versus distributed local monitoring, all have a factor on bandwidth usage. A more relevent question might be... How much bandwdith per user should be allocated on a backbone, for healthy operation and profitabilty of the WISP? That number may depend on how Internet savy the commuity base is, or cost structures of that market. My point here is that the decission on backbone bandwdith may not be a technical decission. And if its technical, the solution may not always be to add bandwdith, and the anser might be to stop wasting bandwidth. But from a technical perspective there are realities that need to be addressed. There becomes a time when action must be taken in some capacity. Most importantly let me point out an example regarding the effect of peak usage and why it is not bad. Set bandwdith management to heavilly restrict bandwdith. For example, set a CIR to 512k and MIR to 1mb. You will see low peak usage, and a lot of bandwidth being wasted, meaning you can never go back in time to recover unused badnwdith. Now set CIR to512, and MIR to 10mbps. You will see peak usage skyrocket for short periods, but the average usage will go way down, because users use the network for short periods, and IF there is any unused bandwdith they are free to use it, before the opportunity in time is lost to do so. The mentality if always free the network up for the next guy as soon as possible. Operating a network in that way (high MIRs) can easilly double the amount of capacity that can be aggreegated accross a backbone. In many cases, all you have to do to prevent bandwdith shortage, is just to INCREASE your customer's configured peak speed. If there usage need stays the same, you will waste less bandwdith and more efficiently use the network. The other thing is it may matter what type backbone you have. For example, a PTP network can use a Ethernet segment very effectively, probably up to close to 85-90%. But on a Multi-user segment like an office LAN, Ethernet capacity will saterate at about 50% because of collision avoidance issues. If you are agreegating multiple feeds into a backbone, whether the data fed into it collides with other data fed into it may depend on the bandwidth management methods and switching technology. IF the network is not always available, it can cause retransmits or higher latency, and that can effect end user's experience. So again, whether 50% or 80% backbone usage is acceptable may depend on many factors in your network design. Remember a network is only as fast as its weakest link, and a saturated backbone closest to the Intenet will have an effect on all links inline prior to on the way to the customer. IF bottle necks are reached, end user speed slows down. (as long as capacity is free outside of peak). Packet loss and high latency WONT occur much until capacity is saturated to often during average usage (considering TCP, UDP is different). When you end user 1mb circuit is averaging 100mbps, How do you know if its because low customer usage/activity, or because bottlenecks are incurred somewhere inline? And how important is it to you, for that customer to have better than 100kb speed? How drastic is the spread between peak usage and average. Many what percentage of your daily network usage occurs at a reasonable window around that peak period? Short peaks and a long peaks can have much different effects on end user's experience. But whats important is that measuring backbone bandwdith usage may not give you enough data to know when to upgrade. You will also want to measure average packetloss and latency. You might find that the time to upgrade might be better determined when average latency exceeds a specific threshold. And the feedback from subscribers may also be important. Also note, there are many different meaning to "average" and how it is calculated. There is a reason that many bandwdith sellers use the 95%tile algorythm. To remove the highest and lowest 5%, for the data to be more meaningful. (or something like that). But.... in summary, without all the factors to consider.... start considering upgrading when "average" usage exceeds 50%, and you'll be plenty safe, and you'll still have some flexibility to wait longer if you need to. Tom DeReggi RapidDSL & Wireless, Inc IntAirNet- Fixed Wireless Broadband On Thu, May 20, 2010 at 9:09 AM, Jeremie Chism <jchi...@gmail.com> wrote: > At what percentage of your backbone usage do you look at adding more > capacity. At peak times I run at 65-70 percent of capacity. Just > looking for suggestions. > > Sent from my iPhone > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
