[WISPA] Bandwidth Cap Implementation
Since there has been a lot of discussion about bandwidth caps on this list recently, I thought that I would share the one that we recently implemented, along with some details on how we are enforcing it and how we established the caps. Going back to day 1, we have had a 3gig cap on broadband customers with a $25/gig surcharge for anyone exceeding that amount. When we were using all StarOS V2, the radius accounting information was keeping fairly close track of the bandwidth per customer. Fast forward six years, and that cap was so low as to be a joke -- and we had not been enforcing it. It was also very difficult to collect accurate accounting data - StarOS evolved and the radius accounting became useless in version 3, so some access points were tracking it and others were not. We also have a few Tranzeo and Mikrotik access points in the system and no good way to collect the individual subscriber download information from them either. After looking at several different options for collecting the bandwidth traffic information, we decided to use open source tools to develop our own solution. We installed a switch between our core and edge routers -- behind the NAT so that it could see all customer's IP addresses -- and mirrored a port to our new collection server. The collection server is a Linux box running CentOS 5.2. The linux box is using softflowd-0.98 to collect the netflows, and flow-tools-v-0.68.5 to look at the data. Daily reports are mailed out to our techs list to show the customer who are nearing or over their caps. A customer page was created that shows the customers how much bandwidth they have used, how much they have left before charges and what their overage charges are (if any). The customer page also shows their historical usage trend for the last 12 months -- starting with April 2010 when we started collecting the information. Starting on June 1, we will bill overages as a separate charge to the customers on the 1^st of the month, regardless of their billing anniversary. The process of implementing this was quite interesting. Out of 2000+ customers, 80 used more than 10 gigs for the month. One customer - a 1 meg subscriber at the far eastern edge of our network, behind seven wireless hops and on an 802.11b AP -- downloaded 140gig. Another one, on the far western side of our network, downloaded 110gig. We called them and found out that they were watching a ton of online video. We discovered a county government connection that was around 100gig -- mostly because someone in the sheriff's department was pounding for BitTorrent files from 1am to 7am in the morning, and sometimes crashing their firewall machine because of the traffic. We also discovered that there was 80-100meg of stateless udp type traffic traversing our routed network and getting to our core router. Revised firewall rules on the APs fixed this problem. The majority of the rest of the subs on the list were either online video watchers, people with virus problems or who had left filesharing programs running on their computers. After reviewing the usage records, we decided on the following cap sizes for our plans: Package Monthly Download Cap 384k 10 gigabytes 640k 10 gigabytes 1 meg 20 gigabytes 2 meg 40 gigabytes 3 meg 50 gigabytes 4 meg 60 gigabytes 8 meg 80 gigabytes Additional capacity over cap $1 per gigabyte over the cap I feel that these caps are more than generous, and should have a minimal effect on the majority of our customers. With our backbone consumption per customer increasing, implementing caps of some kind became a necessity. I am not looking at the caps as a new profit center -- they are a deterrent as much as anything. It will provide an incentive for customers to upgrade to a faster plan with a higher cap, or take their download habits to a competitor and chew up someone else's bandwidth. This has been an educational experience, and probably one that we should have gone through a couple of years ago. I would like to thank the people on the WISPA and Butch Evans' Mikrotik lists for their input while we were developing this system. Matt Larsen Vistabeam.com 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/
Re: [WISPA] Bandwidth Cap Implementation
Matt; Thanks for sharing your information. Frank On 5/6/2010 11:11 PM, Matt Larsen - Lists wrote: Since there has been a lot of discussion about bandwidth caps on this list recently, I thought that I would share the one that we recently implemented, along with some details on how we are enforcing it and how we established the caps. Going back to day 1, we have had a 3gig cap on broadband customers with a $25/gig surcharge for anyone exceeding that amount. When we were using all StarOS V2, the radius accounting information was keeping fairly close track of the bandwidth per customer. Fast forward six years, and that cap was so low as to be a joke -- and we had not been enforcing it. It was also very difficult to collect accurate accounting data - StarOS evolved and the radius accounting became useless in version 3, so some access points were tracking it and others were not. We also have a few Tranzeo and Mikrotik access points in the system and no good way to collect the individual subscriber download information from them either. After looking at several different options for collecting the bandwidth traffic information, we decided to use open source tools to develop our own solution. We installed a switch between our core and edge routers -- behind the NAT so that it could see all customer's IP addresses -- and mirrored a port to our new collection server. The collection server is a Linux box running CentOS 5.2. The linux box is using softflowd-0.98 to collect the netflows, and flow-tools-v-0.68.5 to look at the data. Daily reports are mailed out to our techs list to show the customer who are nearing or over their caps. A customer page was created that shows the customers how much bandwidth they have used, how much they have left before charges and what their overage charges are (if any). The customer page also shows their historical usage trend for the last 12 months -- starting with April 2010 when we started collecting the information. Starting on June 1, we will bill overages as a separate charge to the customers on the 1^st of the month, regardless of their billing anniversary. The process of implementing this was quite interesting. Out of 2000+ customers, 80 used more than 10 gigs for the month. One customer - a 1 meg subscriber at the far eastern edge of our network, behind seven wireless hops and on an 802.11b AP -- downloaded 140gig. Another one, on the far western side of our network, downloaded 110gig. We called them and found out that they were watching a ton of online video. We discovered a county government connection that was around 100gig -- mostly because someone in the sheriff's department was pounding for BitTorrent files from 1am to 7am in the morning, and sometimes crashing their firewall machine because of the traffic. We also discovered that there was 80-100meg of stateless udp type traffic traversing our routed network and getting to our core router. Revised firewall rules on the APs fixed this problem. The majority of the rest of the subs on the list were either online video watchers, people with virus problems or who had left filesharing programs running on their computers. After reviewing the usage records, we decided on the following cap sizes for our plans: Package Monthly Download Cap 384k 10 gigabytes 640k 10 gigabytes 1 meg 20 gigabytes 2 meg 40 gigabytes 3 meg 50 gigabytes 4 meg 60 gigabytes 8 meg 80 gigabytes Additional capacity over cap $1 per gigabyte over the cap I feel that these caps are more than generous, and should have a minimal effect on the majority of our customers. With our backbone consumption per customer increasing, implementing caps of some kind became a necessity. I am not looking at the caps as a new profit center -- they are a deterrent as much as anything. It will provide an incentive for customers to upgrade to a faster plan with a higher cap, or take their download habits to a competitor and chew up someone else's bandwidth. This has been an educational experience, and probably one that we should have gone through a couple of years ago. I would like to thank the people on the WISPA and Butch Evans' Mikrotik lists for their input while we were developing this system. Matt Larsen Vistabeam.com 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
Re: [WISPA] Looking for iput on 900MHz H-Pol Sector Choices. Nothealthcare, taxes or government related.........
PC Tel (Maxrad) makes very good antennas and they stand behind them. I have sold them to many clients with very few issues ever. The Laird (Pac Wireless) products also seem to have a very low complaint rate. Please note this is the opinion of a supplier not an installer but, I do hear from a lot of people. The MTI product is also a high quality choice. Note: One of my clients has started using plexi-glass covers to replace original material on the Pac Wireless product. A simple flat piece installed with silicone. Hope this helps Tracy Tippett www.tracanllc.com --Original Mail-- From: Mike Hammett wispawirel...@ics-il.net To: WISPA General List wireless@wispa.org Sent: Thu, 06 May 2010 17:33:28 -0500 Subject: Re: [WISPA] Looking for iput on 900MHz H-Pol Sector Choices. Nothealthcare, taxes or government related. MTI is damn good quality. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com On 4/29/2010 8:17 PM, Robert West wrote: I hear ya. I will gladly pay extra now to not have to go back over and over. Pays 10X in the long run. I prefer goo quality. :) I'll give it a look to be sure. Bob- - Original Message - From: Jeremie Chismjchi...@gmail.com To: WISPA General Listwireless@wispa.org Sent: Thursday, April 29, 2010 9:11 PM Subject: Re: [WISPA] Looking for iput on 900MHz H-Pol Sector Choices. Nothealthcare, taxes or government related. Tiltek dual polarity 900 MHz. I have had 8 up for 2.5 years with no problem. Not the cheapest but definitely goo quality. I like to use equipment that I don't have to go back to. Sent from my iPhone On Apr 29, 2010, at 8:02 PM, Robert Westrobert.w...@just- micro.com wrote: I'm in need of a 120 or a couple of 90 degree 900MHz H-POL sector antenna(s). Not looking forward to buying worthless CRAP just because I've never had to buy these before so I'm asking who uses what and if it works great. I've done the Omni path, okay but noisy, but this new install needs some decent signal for 2 to 4 miles. Mostly clear path but, ofcourse , into the trees to the CPEs. I've looked at the Super Pass solution and as we all know, I'm a cheap SOB so it fits my budget but I'd gladly pay bigger $$$ for top quality if it's deserved. Thanks. Bob- The cheap SOB --- --- --- --- 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/ 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/
Re: [WISPA] Netequilizer
If you want almost the same features for free, you can still install the Bandwidth Arbitrator from where NetEQ comes from. www.bandwidtharbitrator.com I've tried it once, but never got it fully working. On 05/06/2010 08:09 PM, tim wolfe wrote: I've had a NetEq box running for over 3 years. It is a plug and play setup and does a great job if you like the hands off sorta thing. The bad side is the licensing and the upgrading policy. IT STINKS!. If you buy a unit that is only 3 months old off of Ebay, you can forget support. There was a thread awhile back on the DSL Reports wireless forum. I remember reading it and not liking the policies. You also have to purchase upgrades and some other little quirks that just didn't make me smile. - Original Message - From: Jeremie Chism jchi...@gmail.com To: WISPA General List wireless@wispa.org Sent: Thursday, May 06, 2010 9:31 PM Subject: Re: [WISPA] Netequilizer And I'm sure it can probably prioritize voip traffic. Sent from my iPhone On May 6, 2010, at 7:58 PM, Mike m...@aweiowa.com wrote: For some networks, NetEq is a good solution. I've had one on my network for a few years. It was before Butch came up with his solution. It was a real lifesaver for us; it kept any users from monopolizing the pipe at the peril of others. One major caveat, unless they've changed it, it only plays traffic cop for one subnet. It will look for long duration, multiple thread, connections and put 50 ms delays in the packets if the network gets busy and leave headroom for the bursty users. Another good thing it can do is limit the number of concurrent connections any one IP can have open. This effectively throttles torrents in an agnostic way. Friendly Regards, Mike -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Jeremie Chism Sent: Thursday, May 06, 2010 7:47 PM To: WISPA General List Subject: Re: [WISPA] Netequilizer Cisco router handles all of my routing so I was looking for something to go between. Sent from my iPhone On May 6, 2010, at 7:18 PM, Jerry Richardson jrichard...@aircloud.com wrote: Pretty expensive version of Linux iptables. MT is a pretty solid low cost solution with lotsa support. A Pentium 4 with 2GB RAM will handle a butt load of traffic. Jerry -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Jeremie Chism Sent: Thursday, May 06, 2010 4:51 PM To: WISPA General List Subject: [WISPA] Netequilizer Anybody using this product? We have a pretty good set of qos in our wimax platform but was considering a netequilizer to help with a few HD video streamers we have. 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/ --- --- --- --- 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!
Re: [WISPA] Netequilizer
yep.. :) --- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of Learn RouterOS -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Josh Luthman Sent: Thursday, May 06, 2010 7:54 PM To: WISPA General List Subject: Re: [WISPA] Netequilizer Why can't MT do that? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 Success is not final, failure is not fatal: it is the courage to continue that counts. --- Winston Churchill On Thu, May 6, 2010 at 8:47 PM, Jeremie Chism jchi...@gmail.com wrote: Cisco router handles all of my routing so I was looking for something to go between. Sent from my iPhone On May 6, 2010, at 7:18 PM, Jerry Richardson jrichard...@aircloud.com wrote: Pretty expensive version of Linux iptables. MT is a pretty solid low cost solution with lotsa support. A Pentium 4 with 2GB RAM will handle a butt load of traffic. Jerry -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Jeremie Chism Sent: Thursday, May 06, 2010 4:51 PM To: WISPA General List Subject: [WISPA] Netequilizer Anybody using this product? We have a pretty good set of qos in our wimax platform but was considering a netequilizer to help with a few HD video streamers we have. 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/ 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/
Re: [WISPA] New WISP
I've never had this work even when using two 5 gig cards, one in the lower band and one in the upper at least when trying to run dual nstreme. My throughput just always sucks. Running 532's, however has great throughput with the same radio cards. I've put little shield envelopes over one of the cards to make it work better, but it still isn't as good as the old 532's. Just my experience. Cameron !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta content=text/html;charset=ISO-8859-1 http-equiv=Content-Type /head body bgcolor=#ff text=#00 I've been doing that for a couple of years...br br But I've only been leaving 1 or 2 empty channels between themnbsp; 20-40 MHz open space.br br Kurt Fankhauser wrote: blockquote cite=mid:7a120693fe7d4abf8ad509b168183...@dell8400 type=cite pre wrap=I have verified with a spectrum analyzer you can run two cards stacked on top in a 433 in the same 5.8 band as long as the channels you are using are at complete opposite ends of the band. 5745 and 5825 and 20mhz channels and they will not bleed over. Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 a class=moz-txt-link-abbreviated href=http://www.wavelinc.com;www.wavelinc.com/a -Original Message- From: a class=moz-txt-link-abbreviated href=mailto:wireless-boun...@wispa.org;wireless-boun...@wispa.org/a [a class=moz-txt-link-freetext href=mailto:wireless-boun...@wispa.org;mailto:wireless-boun...@wispa.org/a] On Behalf Of Mike Hammett Sent: Thursday, May 06, 2010 6:21 PM To: WISPA General List Subject: Re: [WISPA] New WISP Usually 5.8 to the tower, and 5.2 for the repeater. I haven't done any repeaters like this since DFS. I do have a couple at 2.4. - Mike Hammett Intelligent Computing Solutions a class=moz-txt-link-freetext href=http://www.ics-il.com;http://www.ics-il.com/a On 5/6/2010 4:22 PM, Josh Luthman wrote: /pre blockquote type=cite pre wrap=Are you saying you have two radios in the 433? Are they the same band? The 411 and 433 share the same horsepower, in case anyone didn't recognize /pre /blockquote pre wrap=!that. /pre blockquote type=cite pre wrap=Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 Success is not final, failure is not fatal: it is the courage to continue that counts. --- Winston Churchill On Thu, May 6, 2010 at 5:21 PM, Mike Hammetta class=moz-txt-link-rfc2396E href=mailto:wispawirel...@ics-il.net;lt;wispawirel...@ics-il.netgt;/a /pre /blockquote pre wrap=!wrote: /pre blockquote type=cite pre wrap= /pre blockquote type=cite pre wrap=Most of my repeater sites are about $150 - $200 more than the CPE. I upgrade to a 433 from a 411, add another radio, bulkhead pigtail, jumper, cheap omni or sector. - Mike Hammett Intelligent Computing Solutions a class=moz-txt-link-freetext href=http://www.ics-il.com;http://www.ics-il.com/a On 4/27/2010 10:19 AM, Josh Luthman wrote: /pre blockquote type=cite pre wrap=All of my repeater sites have 0 infrastructure cost. I'm using a TV /pre /blockquote /blockquote /blockquote pre wrap=!tower, /pre blockquote type=cite blockquote type=cite blockquote type=cite pre wrap=grain leg, etc. This means the only additional cost is a NEMA box, /pre /blockquote /blockquote /blockquote pre wrap=!cheap /pre blockquote type=cite blockquote type=cite blockquote type=cite pre wrap=battery, mt box and omni. Roughly $400. If I get one customer at 35/mo /pre /blockquote /blockquote /blockquote pre wrap=!it /pre blockquote type=cite blockquote type=cite blockquote type=cite pre wrap=takes a year for ROI. Two customers six months, etc. I typically /pre /blockquote /blockquote /blockquote pre wrap=!charge /pre blockquote type=cite blockquote type=cite blockquote type=cite pre wrap=45/mo and get 3 people a day after the AP is up. Looking at my third /pre /blockquote /blockquote /blockquote pre wrap=!screen /pre blockquote type=cite blockquote type=cite blockquote type=cite pre wrap=I've three repeater sites (at least) with only three subs. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 Success is not final, failure is not fatal: it is the courage to /pre /blockquote /blockquote /blockquote pre wrap=!continue /pre blockquote type=cite blockquote type=cite blockquote type=cite pre wrap=that counts. --- Winston Churchill On Tue, Apr 27, 2010 at 11:01 AM, Marlon K. /pre
Re: [WISPA] Bandwidth Cap Implementation
Hey Matt, Can you give us your customers' reaction to this change after a few weeks? ryan On Thu, May 6, 2010 at 11:11 PM, Matt Larsen - Lists li...@manageisp.comwrote: Since there has been a lot of discussion about bandwidth caps on this list recently, I thought that I would share the one that we recently implemented, along with some details on how we are enforcing it and how we established the caps. Going back to day 1, we have had a 3gig cap on broadband customers with a $25/gig surcharge for anyone exceeding that amount. When we were using all StarOS V2, the radius accounting information was keeping fairly close track of the bandwidth per customer. Fast forward six years, and that cap was so low as to be a joke -- and we had not been enforcing it. It was also very difficult to collect accurate accounting data - StarOS evolved and the radius accounting became useless in version 3, so some access points were tracking it and others were not. We also have a few Tranzeo and Mikrotik access points in the system and no good way to collect the individual subscriber download information from them either. After looking at several different options for collecting the bandwidth traffic information, we decided to use open source tools to develop our own solution. We installed a switch between our core and edge routers -- behind the NAT so that it could see all customer's IP addresses -- and mirrored a port to our new collection server. The collection server is a Linux box running CentOS 5.2. The linux box is using softflowd-0.98 to collect the netflows, and flow-tools-v-0.68.5 to look at the data. Daily reports are mailed out to our techs list to show the customer who are nearing or over their caps. A customer page was created that shows the customers how much bandwidth they have used, how much they have left before charges and what their overage charges are (if any). The customer page also shows their historical usage trend for the last 12 months -- starting with April 2010 when we started collecting the information. Starting on June 1, we will bill overages as a separate charge to the customers on the 1^st of the month, regardless of their billing anniversary. The process of implementing this was quite interesting. Out of 2000+ customers, 80 used more than 10 gigs for the month. One customer - a 1 meg subscriber at the far eastern edge of our network, behind seven wireless hops and on an 802.11b AP -- downloaded 140gig. Another one, on the far western side of our network, downloaded 110gig. We called them and found out that they were watching a ton of online video. We discovered a county government connection that was around 100gig -- mostly because someone in the sheriff's department was pounding for BitTorrent files from 1am to 7am in the morning, and sometimes crashing their firewall machine because of the traffic. We also discovered that there was 80-100meg of stateless udp type traffic traversing our routed network and getting to our core router. Revised firewall rules on the APs fixed this problem. The majority of the rest of the subs on the list were either online video watchers, people with virus problems or who had left filesharing programs running on their computers. After reviewing the usage records, we decided on the following cap sizes for our plans: Package Monthly Download Cap 384k 10 gigabytes 640k 10 gigabytes 1 meg 20 gigabytes 2 meg 40 gigabytes 3 meg 50 gigabytes 4 meg 60 gigabytes 8 meg 80 gigabytes Additional capacity over cap $1 per gigabyte over the cap I feel that these caps are more than generous, and should have a minimal effect on the majority of our customers. With our backbone consumption per customer increasing, implementing caps of some kind became a necessity. I am not looking at the caps as a new profit center -- they are a deterrent as much as anything. It will provide an incentive for customers to upgrade to a faster plan with a higher cap, or take their download habits to a competitor and chew up someone else's bandwidth. This has been an educational experience, and probably one that we should have gone through a couple of years ago. I would like to thank the people on the WISPA and Butch Evans' Mikrotik lists for their input while we were developing this system. Matt Larsen Vistabeam.com 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/
Re: [WISPA] Bandwidth Cap Implementation
EXCELLENT post. This is worth framing. Thank you very much for the information and publishing this with us. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 “Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill On Fri, May 7, 2010 at 2:11 AM, Matt Larsen - Lists li...@manageisp.com wrote: Since there has been a lot of discussion about bandwidth caps on this list recently, I thought that I would share the one that we recently implemented, along with some details on how we are enforcing it and how we established the caps. Going back to day 1, we have had a 3gig cap on broadband customers with a $25/gig surcharge for anyone exceeding that amount. When we were using all StarOS V2, the radius accounting information was keeping fairly close track of the bandwidth per customer. Fast forward six years, and that cap was so low as to be a joke -- and we had not been enforcing it. It was also very difficult to collect accurate accounting data - StarOS evolved and the radius accounting became useless in version 3, so some access points were tracking it and others were not. We also have a few Tranzeo and Mikrotik access points in the system and no good way to collect the individual subscriber download information from them either. After looking at several different options for collecting the bandwidth traffic information, we decided to use open source tools to develop our own solution. We installed a switch between our core and edge routers -- behind the NAT so that it could see all customer's IP addresses -- and mirrored a port to our new collection server. The collection server is a Linux box running CentOS 5.2. The linux box is using softflowd-0.98 to collect the netflows, and flow-tools-v-0.68.5 to look at the data. Daily reports are mailed out to our techs list to show the customer who are nearing or over their caps. A customer page was created that shows the customers how much bandwidth they have used, how much they have left before charges and what their overage charges are (if any). The customer page also shows their historical usage trend for the last 12 months -- starting with April 2010 when we started collecting the information. Starting on June 1, we will bill overages as a separate charge to the customers on the 1^st of the month, regardless of their billing anniversary. The process of implementing this was quite interesting. Out of 2000+ customers, 80 used more than 10 gigs for the month. One customer - a 1 meg subscriber at the far eastern edge of our network, behind seven wireless hops and on an 802.11b AP -- downloaded 140gig. Another one, on the far western side of our network, downloaded 110gig. We called them and found out that they were watching a ton of online video. We discovered a county government connection that was around 100gig -- mostly because someone in the sheriff's department was pounding for BitTorrent files from 1am to 7am in the morning, and sometimes crashing their firewall machine because of the traffic. We also discovered that there was 80-100meg of stateless udp type traffic traversing our routed network and getting to our core router. Revised firewall rules on the APs fixed this problem. The majority of the rest of the subs on the list were either online video watchers, people with virus problems or who had left filesharing programs running on their computers. After reviewing the usage records, we decided on the following cap sizes for our plans: Package Monthly Download Cap 384k 10 gigabytes 640k 10 gigabytes 1 meg 20 gigabytes 2 meg 40 gigabytes 3 meg 50 gigabytes 4 meg 60 gigabytes 8 meg 80 gigabytes Additional capacity over cap $1 per gigabyte over the cap I feel that these caps are more than generous, and should have a minimal effect on the majority of our customers. With our backbone consumption per customer increasing, implementing caps of some kind became a necessity. I am not looking at the caps as a new profit center -- they are a deterrent as much as anything. It will provide an incentive for customers to upgrade to a faster plan with a higher cap, or take their download habits to a competitor and chew up someone else's bandwidth. This has been an educational experience, and probably one that we should have gone through a couple of years ago. I would like to thank the people on the WISPA and Butch Evans' Mikrotik lists for their input while we were developing this system. Matt Larsen Vistabeam.com 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:
Re: [WISPA] Looking for iput on 900MHz H-Pol Sector Choices. Nothealthcare, taxes or government related.........
If you keep the signal levels up, so that the data rates stay up (all stay above -73), you can move about 6-8 mbit in a 5 mhz channel at 900. I've been using UBNT radios and star-os to drive them. 900 mhz is VERY prone to interference, the RSSI levels are hugely affected by weather, humidity, and things like snow on the ground. Snow raises my client's RSSI by anywhere from 5 for the strongest to over 20 db for the weakest. Clients that are -82 in the summer are -60 or so in the winter - when there's snow on the ground.Just raining, and then falling below freezing will do a 3-8 db gain in RSSI. As you say, OFDM at 900 Mhz is one fascinating exercise. ++ Neofast, Inc, Making internet easy 541-969-8200 509-386-4589 ++ -- From: Josh Luthman j...@imaginenetworksllc.com Sent: Thursday, May 06, 2010 8:23 PM To: WISPA General List wireless@wispa.org Subject: Re: [WISPA] Looking for iput on 900MHz H-Pol Sector Choices. Nothealthcare, taxes or government related. 900.OFDMI can't sleep I'm so excited! 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/
Re: [WISPA] [OT] Chicken Currency
That was definitely one of the more memorable moments I have had with my WISP pals. There is a picture somewhere during one of these excursions where I am asking a bum if he has a dollar to spare...and he gives me one. :-) Scriv On Thu, May 6, 2010 at 3:27 PM, Jeff Broadwick jeffl...@comcast.net wrote: LOL, I still am sore that they wouldn't let us borrow their chicken picture (that was in Dallas)! Regards, Jeff Jeff Broadwick ImageStream 800-813-5123 x106 (US/Can) +1 574-935-8484 x106 (Int'l) -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Mike Hammett Sent: Thursday, May 06, 2010 2:39 PM To: WISPA General List Subject: Re: [WISPA] [OT] Chicken Currency I love that story. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com On 4/25/2010 12:24 AM, Matt Larsen - Lists wrote: 95% of the members of this list are probably not familiar with an old WISPCON story that had to do with chickens being currency in Latvia and how I love to throw some abuse at the Mikrotik guys about this when I see them. For those 5% though, I think you will appreciate that perhaps the Latvians are actually ahead of us: http://lowdenplan.com/ The full Mikrotik chicken story is at the end of this email, for those of you who might be interested. Matt Larsen vistabeam.com The Mikrotik Chickens story During one of the Chicago WISPCONs (4 or 5, I believe) we had an off-campus excursion that involved limosines, liquor and late night activities. At one point in the evening, I was in a limo with Arnis from Mikrotik. For those who don't know him, Arnis is a very softspoken and intelligent guy. The rest of the people in the limo were pretty loud and raucus, while Arnis mostly sat quietly and watched. At some point in the conversation, John Scrivner asked him what the gentlemen's clubs in Latvia were like. At the same time, someone else was talking about getting some fried chicken and coming up with money to get it. Between the two conversations, I thought that something was said about chickens being used as currency in Latvia. Smart ass that I am, I thought I'd make a comment: Me: Hey John, what's the worst thing about a Latvian gentleman's club? John: I don't know. Me: Slipping the chickens into the dancer's G-string! From that point on, I have been quite boorishly giving the Mikrotik guys the business about chickens as currency. A picture of a chicken in a hotel lobby became the Latvian Express Card. An order of wings is pocket change Etc etc. It has been an endless source of amusement for me, and not particularly funny to anyone else. Arnis got me at the last MUM. He saw my business name (Vistabeam) and started laughing at me. I asked him what was so funny. He said that Vista means chicken in Latvian. So the Latvian version of my business name is Chicken Wireless.Of course, this turned out to be total BS, but I didn't get it figured out until a week later when I went online and figured out that the Latvian word for chicken is calis. Well played Arnis. -- -- 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/ 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/
