Re: [WISPA] Verizon 4G LTE - WOW - update
Shared, aka burst = $99.95/month. Dedicated = $1000/month. On Fri, Apr 8, 2011 at 12:37 AM, John Thomas jtho...@quarnet.com wrote: Rick, what price are you offering 10 megs at? In our neck of the woods Towerstream is doing 8 meg at $800 per month. John On 4/5/2011 9:23 PM, RickG wrote: Thats what I thought which is why I spent so much time and money on upgrading. I've got 30-50 megs at nearly every tower and I started offering 10Mbps posted rates. I even lowered the upgrade prices above 3Mbps. Very few care and even fewer take it. In fact, I have some that ask if we have a slower plan! I'm starting to be concerned that dial-up is good enough! On Wed, Apr 6, 2011 at 12:15 AM, Jerry Richardson jrichard...@aircloud.com wrote: For now. I doubt that you will be able to sustain that 90% with 1.5 or 3.0 indefinitely. I know we won't. - Jerry *From:* wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] *On Behalf Of *RickG *Sent:* Tuesday, April 05, 2011 9:08 PM *To:* WISPA General List *Subject:* Re: [WISPA] Verizon 4G LTE - WOW - update +100%! I've upgraded my network to the point that I cant anymore but 90% of the customers are fine with 1.5 or 3Mbps! On Tue, Apr 5, 2011 at 9:27 AM, Travis Johnson t...@ida.net wrote: The other question is how much do you pay for the service? It all comes down to price. I can deliver 10Mbps x 10Mbps up to 300Mbps x 300Mbps to anyone that wants it... however, most people don't want to pay for it... ;) Travis Microserv On 4/5/2011 5:37 AM, Charles Wu wrote: It's generally known that the 20 Mb burst given by cable companies is throttled to sustained download speeds in the 1-3 Mb range That said, the point I'm trying to make is that the technology has come so far for mobile cellular data that we are now unconsciously comparing it side-by-side to fixed terrestrial broadband technologies (think of it this way, how many WISPs can deliver up-to speeds of 8-10 Mb to a low power handset in the middle of a concrete building 3+ miles away from a tower) -Charles -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of St. Louis Broadband Sent: Monday, April 04, 2011 9:33 PM To: 'WISPA General List' Subject: Re: [WISPA] Verizon 4G LTE - WOW - update I just checked my Charter via Ookla and it said I was getting 20 Mbps down and 1 Mbps up, horse pucky. I only get that in speedtests and never when I have to upload or download a big file via FTP or whatever. It generally gets throttled to dial up speeds or worse. ~V~ -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Charles Wu Sent: Monday, April 04, 2011 9:21 PM To: WISPA General List Subject: Re: [WISPA] Verizon 4G LTE - WOW - update Sitting in my living room at 8 pm3 bars, laptop connected to wireless router on phone http://www.speedtest.net/result/1236758959.png -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Tom DeReggi Sent: Monday, April 04, 2011 6:39 PM To: WISPA General List Subject: Re: [WISPA] Verizon 4G LTE - WOW Yeah, its nice when a product is brand new, and you get the whole sector all to yourself. I guess, its amazing that you are getting the speed to a handset, without the big antenna outside. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Charles Wuc...@cticonnect.com To:paolo.difrance...@level7.it; WISPA GeneralList wireless@wispa.org Sent: Sunday, April 03, 2011 8:31 PM Subject: Re: [WISPA] Verizon 4G LTE - WOW It is my understanding that Verizon is deploying an FDD version of LTE -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Paolo Di Francesco Sent: Sunday, April 03, 2011 11:09 AM To: WISPA General List Subject: Re: [WISPA] Verizon 4G LTE - WOW most of the test are half duplex tests. In few words, they do one direction, then the other direction (e.g. first the customer download, then the customer upload). Suppose you have a 10Mb half duplex: the test will tell you that you have 10Mb in one direction and 10Mb in the other direction. Then you use the connection in 10Mb full duplex and you will discover the story is totally different ;) Also, yes it's interesting to see what is happening on the network interface when the test is running... Do a real test and report back, like FTP. Ookla Speedtest.net test are bogus 99.9% percent of the time because it's based on screwy test algorithms. On 04/01/2011 11:05 PM, Charles Wu wrote: Just got my HTC Thunderbolt, and Ookla tested 20 Mb down, 24 Mb up at Speedtest.Net to my handset -Charles
Re: [WISPA] RED queues out, PCQ queues in - anyone else doing this?
On Apr 7, 2011, at 9:53 PM, Butch Evans wrote: On 04/07/2011 06:23 PM, Greg Ihnen wrote: My little network is a wireless network with about 20 user devices (computers, iPads, iPods, Wiis, Blackberries etc). Our upstream is a 1Mbps/256KBps. I was running Butch's script with PCQ queues but I started wondering about buffer bloat (yeah, I follow NANOG too) on the router. I thought about trying RED on the outbound queue since if packets are dropped and resent on our wireless network it's no biggie. Our wireless network is way overkill as far as our bandwidth needs. But I didn't want dropped packets on our inbound side because I didn't want to waste any of our precious satellite bandwidth. So I kept PCQ queues there. It seems like it made things work better but I never know for sure because our satellite bandwidth is oversold and what we get at any given moment is effected by what the other users who are on this same bandwidth are doing. Does anyone else mix queue types like that? Is this a dumb idea? FWIW, the NEWEST version of this script uses RED queues. (just so you know). As for splitting the queues per direction like this, I'm not sure I've ever tried this, but it should perform reasonably well. Butch, Thanks for the reply and for your script! It makes our little internet connection here work so well. It truly makes a night and day difference on a poor connection with a lot of users. Greg -- * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/* Network Engineering * * http://store.wispgear.net/* Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * *NOTE THE NEW PHONE NUMBER: 702-537-0979 * 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] RED queues out, PCQ queues in - anyone else doing this?
Rubes, Thank you very much! That's great info and ideas. Greg On Apr 7, 2011, at 10:19 PM, Rubens Kuhl wrote: I was running Butch's script with PCQ queues but I started wondering about buffer bloat (yeah, I follow NANOG too) on the router. I thought about trying RED on the outbound queue since if packets are dropped and resent on our wireless network it's no biggie. Our wireless network is way overkill as far as our bandwidth needs. But I didn't want dropped packets on our inbound side because I didn't want to waste any of our precious satellite bandwidth. So I kept PCQ queues there. Before jumping into the conclusion that your network is overkill for your usage, you should first graph it in RX+TX pps if it's Wi-Fi, or RX pps and TX pps otherwise. Ideally you should also graph airtime % as well, but that's not a MIB-II standard item... AirControl might do it with UBNT gear. It seems like it made things work better but I never know for sure because our satellite bandwidth is oversold and what we get at any given moment is effected by what the other users who are on this same bandwidth are doing. Does anyone else mix queue types like that? Is this a dumb idea? I think it's not dumb, but the cause/effect relations on TCP make choosing which queue type to use in each direction a more complex decision than that. Trying more combinations might be good. One thing I would consider doing is using different queue types on each direction depending on packet size. TCP packets going outbound but have low size are just ACKs of incoming TCP data, and the other way around. non-TCP packets would also have a different QoS strategy as it's usually non-responsive to packet loss or delay variations. Rubens 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] RED queues out, PCQ queues in - anyone else doing this?
There is definately a need for different queue types at different points on the network. Multiple Queue types have been developed because there are different problems to solve for different situations. What I question is when it is necessary to solve a problem. I hardly justify a complete network queueing standard overhaul, just to satisfy the abilty to perform a single stream TCP test to Speak easy at full speed, when most business circuits serve many TCP streams at a time to fill capacity. So it boils down to weighing the scale of how bad the problem is and how badly the customers notices it. There can be a very fine line on which Queueing methods are required for specific cases, and sometimes picking one makes it easier to consistently implement, even if there are some trade offs. On our core routers we've found RED to work well. But we also have other areas where we queue where we use other things, such building routers or customer routers. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband 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] Marketing ( was Re: Verizon 4G LTE - WOW - update)
I can order metro fiber from ATT for less. On Friday, April 8, 2011, John Thomas jtho...@quarnet.com wrote: Smart marketing goes a long way. I know of a company that was basically getting a 3 x T-1 pushed its way because ATT wanted to sell it to them. Wow, for only $700 per month you can have 4.5 Megabits per second. We told them go ask about Fiber. By going through a reseller, they were able to get ATT to install a 10 meg x 10 meg fiber connection for $973 per month. Of course the equipment is 100 meg port and they are actually getting about 20 + meg both directions, and are VERY happy with this arrangement. Of course if The TW Telecom rep had actually wanted to sell the product, they could have had 100 meg over fiber to their site for about $1400 per month. The fiber is literally in the street outside their building, but the TW Telecom guy didn't want to sell it. A fellow Network Engineer has 1.5 meg / 384 k ADSL to his house. According to ATT's website, for $45 he can get 6 meg / 768 k + 5 static IP addresses for $45 per month. After having ATT *hang up* on him 3 times, hes has decided to drop ATT and look at other alternatives. John On 4/5/2011 9:19 PM, Faisal Imtiaz wrote: You can always upgrade More! The key central question is ... how to 'Capitalize' on it and make some Money. There are always two ways the Market move .. Either PUSH (try to sell your excess capacity on the network , making it attractive , lower the selling price, while increasing margins ... or Packaging your products differently for a different Target Market). or PULL .. where the customers are knocking on your doors to demand more. So.. here is bit of Challenge for All of US, including Rick Travis If we have the capacity to deliver the high bandwidth to our customers.. and in our market place the Phone Company is still selling T1' s and Metro Ethernet's like hot cakes.. then there is only one possible conclusion . We need to Review our products / pricing / packaging strategy... since we are leaving a LOT on the Table.. now, if you tell me that in your / our market place.. the Telco's are hurting in business because folks are lining up purchase your / our circuits.. .then and only then I can say you are starting to 'saturate' your territory.. time to expand and break new ground. Some Food For Thought.. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net On 4/6/2011 12:08 AM, RickG wrote: +100%! I've upgraded my network to the point that I cant anymore but 90% of the customers are fine with 1.5 or 3Mbps! On Tue, Apr 5, 2011 at 9:27 AM, Travis Johnson t...@ida.net wrote: The other question is how much do you pay for the service? It all comes down to price. I can deliver 10Mbps x 10Mbps up to 300Mbps x 300Mbps to anyone that wants it... however, most people don't want to pay for it... ;) Travis Microserv On 4/5/2011 5:37 AM, Charles Wu wrote: It's generally known that the 20 Mb burst given by cable companies is throttled to sustained download speeds in the 1-3 Mb range That said, the point I'm trying to make is that the technology has come so far for mobile cellular data that we are now unconsciously comparing it side-by-side to fixed terrestrial broadband technologies (think of it this way, how many WISPs can deliver up-to speeds of 8-10 Mb to a low power handset in the middle of a concrete building 3+ miles away from a tower) -Charles -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of St. Louis Broadband Sent: Monday, April 04, 2011 9:33 PM To: 'WISPA General List' Subject: Re: [WISPA] Verizon 4G LTE - WOW - update I just checked my Charter via Ookla and it said I was getting 20 Mbps down and 1 Mbps up, horse pucky. I only get that in speedtests and never when I have to upload or download a big file via FTP or whatever. It generally gets throttled to dial up speeds or
Re: [WISPA] RED queues out, PCQ queues in - anyone else doing this?
On 04/08/2011 12:07 PM, Tom DeReggi wrote: There is definately a need for different queue types at different points on the network. Multiple Queue types have been developed because there are different problems to solve for different situations. This is true. What I question is when it is necessary to solve a problem. I hardly justify a complete network queueing standard overhaul, just to satisfy the abilty to perform a single stream TCP test to Speak easy at full speed, when most business circuits serve many TCP streams at a time to fill capacity. This is a very good point. The current trending of internet traffic is geared toward more and more streams. Of the available queue types, only SFQ (or one of it's derivative types) and RED make much sense. FIFO queues, without properly managing the traffic entering those queues, will cause customers to sit up and take notice in a negative way. The problem with SFQ is that the algorithm used to implement this is fairly slow. It doesn't work well under heavy load. More specifically, it falls apart when the volume of traffic is excessive. Mikrotik adds another queue type called PCQ, which is sort of like FIFO queues grouped by some classifier such as source addresses and/or ports OR destination addresses and/or ports OR some wicked combination of all of the above. PCQ is an alternative, as it allows you to set per classification speed limits, but in the end, it is still FIFO per class, which requires very careful crafting of defining traffic types to be sorted into these queues. As to WHEN you need to begin managing network traffic, I personally feel it is ALWAYS necessary. The reality is that even with sufficient bandwidth available, some of that traffic is more sensitive than others to network latencies. Even if you are not creating a QOS policy, you have one. Every interface has an output queue. All a policy does is inform the operating system as to what your preferred order is when placing packets into that queue. There is obviously SOME added latency involved in doing that, but usually that added time can result in a better end user experience. QOS enables you to manage not only high bandwidth use, but high packet rates. You are not limiting packet rates per se, but when that increases (especially on a wireless network), you are more likely to experience collisions. QOS enables you to make those collisions less problematic because you are managing the output side of the interface and know that the important traffic will go first. So it boils down to weighing the scale of how bad the problem is and how badly the customers notices it. There can be a very fine line on which Queueing methods are required for specific cases, and sometimes picking one makes it easier to consistently implement, even if there are some trade offs. On our core routers we've found RED to work well. But we also have other areas where we queue where we use other things, such building routers or customer routers. QOS involves speed limits, but is not always about limiting speeds. A more accurate description of what QOS is would be something like: Management of network traffic policies such that periods of low utilization permit full access to network resources and periods of high utilization will permit preferred access to certain traffic types. Additionally, QOS policies enable an admistrator to level out peaks during very high utilization periods such that all traffic is permitted to pass the policy, but in an orderly fashion. I spent almost 1 minute coming up with that definition, so give me some slack. :-) -- * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/* Network Engineering * * http://store.wispgear.net/* Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * *NOTE THE NEW PHONE NUMBER: 702-537-0979 * 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] Newspaper Article on Myakka Technologies
Nice Article on Myakka Technologies http://www.heraldtribune.com/article/20100910/ARTICLE/9101047/2055/NEWStc=ix?p=1tc=pg http://www.heraldtribune.com/article/20100910/ARTICLE/9101047/2055/NEWStc=ix?p=1tc=pg Kudos... You are doing something right.. keep doing it. Regards. -- Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net 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] RED queues out, PCQ queues in - anyone else doing this?
Butch, Nice reply, I agree with everything you said. I agree that the time to begin managing network traffic, is always. The reason I believe this is... 1) any thing one does to help, helps. 2) If you dont have traffic management in place, when you need it, it will be to late. But its also important to recognize that flaws might exist in a network design that cant easilly be avoided, that can undermine an administrators attempt to manage their traffic. What I mean by that is that, some variable beyond one's control might have a higher effect than factors that are in one's control. So because of this, traffic management techniques cant always be 100% relied on, although they help a great deal. One of the best examples is the impact of half duplex radios, or adaptive speed (modulation) radios, on bandwdith management systems that treat outbound and inbound traffic seperately. In many cases, bandwidth management requires you to know the capacity of a link in advance. So, lets say you have a 10mbps half duplex link. If you want to be able to have 10mbps up traffic, you must tell your bandwidth management to allow that 10mbps up. But then what happens if you have 5mbps of download traffic? The upload bandwidth management still thinks it has 10mbps max, but in reality it only has 5mbps available, while 5mbps is downloading. Its impossibly to know in advance the up and down ratio. Or lets look at it a different way... RED gracefully drops packets to slow down throughput as needed. When a half duplex link gets saturated, which direction (up or down traffic) should packets be dropped from? Many of the traffic management methods are based on the assumption that links are full duplex, and get applied to outbound interfaces, therefore a different interface or queue per direction. In some cases, a different router manages the traffic in the other direction, and not able to communicate with the other router.. (example, router on each side of a link, each managing a queue for outbound). Traffic management is much easier to impliment on a full duplex fixed capacity fiber connection, than it is on a variable half duplex wireless connection. Queuing traffic management is not the same as bandwidth management, but none the less, I believe to have demonstrated my point. When our network was less congested, traffic management tools made a huge different for us to maximize the amount of data we could pass smoothly accross our network efficiently. What we found was that half duplex was efficient for RF, and not a disadvantage for wireless. This worked well for us, for 10 years. But as our network became more congested, half duplex did show to be a challenge for traffic management. It came to a point where Full Duplex licensed links was the only answer, and helped the most. And then our traffic management became more reliable as a result. My point is, its not only the method of traffic management that matters, but also the characteristics of the network. Queuing and QOS will always help make the best of one's network, but it wont fully make up for deficiencies in a physical network. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Butch Evans but...@butchevans.com To: wireless@wispa.org Sent: Friday, April 08, 2011 2:53 PM Subject: Re: [WISPA] RED queues out, PCQ queues in - anyone else doing this? On 04/08/2011 12:07 PM, Tom DeReggi wrote: There is definately a need for different queue types at different points on the network. Multiple Queue types have been developed because there are different problems to solve for different situations. This is true. What I question is when it is necessary to solve a problem. I hardly justify a complete network queueing standard overhaul, just to satisfy the abilty to perform a single stream TCP test to Speak easy at full speed, when most business circuits serve many TCP streams at a time to fill capacity. This is a very good point. The current trending of internet traffic is geared toward more and more streams. Of the available queue types, only SFQ (or one of it's derivative types) and RED make much sense. FIFO queues, without properly managing the traffic entering those queues, will cause customers to sit up and take notice in a negative way. The problem with SFQ is that the algorithm used to implement this is fairly slow. It doesn't work well under heavy load. More specifically, it falls apart when the volume of traffic is excessive. Mikrotik adds another queue type called PCQ, which is sort of like FIFO queues grouped by some classifier such as source addresses and/or ports OR destination addresses and/or ports OR some wicked combination of all of the above. PCQ is an alternative, as it allows you to set per classification speed limits, but in the end, it is still FIFO per class, which requires very careful crafting of defining traffic types to be
Re: [WISPA] Newspaper Article on Myakka Technologies
Good job, Mark! - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com On 4/8/2011 6:36 PM, Faisal Imtiaz wrote: Nice Article on Myakka Technologies http://www.heraldtribune.com/article/20100910/ARTICLE/9101047/2055/NEWStc=ix?p=1tc=pg http://www.heraldtribune.com/article/20100910/ARTICLE/9101047/2055/NEWStc=ix?p=1tc=pg Kudos... You are doing something right.. keep doing it. Regards. 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/
