FWIW, Cisco 871's will route wirespeed at 100 megabits/sec, but can only firewall/NAT/VPN at 25 megabits/sec.
John >-----Original Message----- >From: Al Stewart [mailto:[email protected]] >Sent: Friday, October 16, 2009 03:05 PM >To: 'WISPA General List' >Subject: Re: [WISPA] Simultaneous connections > >Thanks Tom ... > >I know some of the cheaper wireless routers on our system have been >causing speed problems for various reasons. And I can see the reasons >for the problems. But for most people, I guess a router is a router, >and they don't want to spend big bucks. > >For myself, I'm looking to replace my own personal D-Link DI-704P >(wired) with another wired unit. Researching models gives all kinds >of conflicting info/complaints/recommendations. Someone here >recommended, so I guess I'll see what I can track down on that. > >Al > >------ At 05:54 PM 10/16/2009 -0400, Tom DeReggi wrote: ------- > >>Yes they can be the cause for numerous reasons. >> >>1) they can start to go flaky, and when gone flaky they can cause hesitent >>throughput, (sorta like when a CPU overheats, or when a bus or cache limit >>gets exceeded) that will force TCPIP congestion to slow throughput. Its not >>uncommon to have cases where we replace a router with another of the same >>brand/model and the speed testing improves by 4x. BUT when this happens it >>is because the product had become defective, not because the unit wasn't >>originally capable.. >> >>2) a 10mbps port does not guarantee that a route can push 10mbps. 10mbps is >>just the speed of the NIC itself. Many cheaper or older generation routers >>have very slow processors and can slow down with small packet traffic. Not >>just processors but memory and bus design. Also, all firmwares might not be >>optimize for higher speeds. For example, for GB you might want large network >>buffers, where as routers that were developed at the day of 1mbps max DSL, >>may have optimized for the typic speed, and used fewer buffers to conserve >>RAM, and use less ram to lower costs. >> >>However, MOST routers of current generation are pretty capable, and usually >>do fine up at higher speeds. Also be cautious of using a VPN router, >>because it can take quite a bit of overhead to encrypt or compress the >>tunnel, and could get slowed at high speed. The best thing to do is to >>certify the peak speed of any Router that you plan to use regularly. Dont >>believe the Spec sheet, believe your own Iperf test results. >> >>The issue is how do you tell if a router is flaking out and how can you test >>the router's capabilty remotely if a support call arises? >>If you dont have a way to test certify it working to spec, how do you know >>it is? >> >>This is why we tend to use more power routers when we can. We like them to >>have processor powerful enough to run full speed throughput tests directly >>to the router. >>In other words, A router can always pass much more traffic speeds through >>it, than it can actuallu hald directly to or from it. Having fast >>processors in the routers, creating extra headroom, gets aroud this problem. >> >> >>Tom DeReggi >>RapidDSL & Wireless, Inc >>IntAirNet- Fixed Wireless Broadband >> >> >>----- Original Message ----- >>From: "Al Stewart" <[email protected]> >>To: "WISPA General List" <[email protected]> >>Sent: Thursday, October 15, 2009 2:30 PM >>Subject: Re: [WISPA] Simultaneous connections >> >> >> > Thanks ... this helps. >> > >> > One more question. Do routers being used by the subscribers (wired or >> > wireless) ever affect the speed/bandwidth. I don't see how that can >> > be as they are designed to pass 10 Meg to the WAN, which is six times >> > at least what the >> > nominal bandwidth would be. One tech guy is trying to blame routers >> > for all problems. But I have yet to see the logic in that. Unless of >> > course one is malfunctioning or dying or something. But that can't be >> > ALL the routers in the system. >> > >> > Al >> > >> > ------ At 02:15 PM 10/15/2009 -0400, Tom DeReggi wrote: ------- >> > >> >>Everything goes to crap, unless you've put in bandwdith management to >> >>address those conditions. >> >>The problem gets worse when Traffic becomes... Lots of small packets >> >>and/or >> >>lots of uploads. >> >>Obviously Peer-to-Peer can have those characteristics. >> >>The bigger problem is NOT fairly sharing bandwidith per sub, but instead >> >>managing based on what percentage of bandwidth is going up versus down. >> >>This can be a problem when Bandwdith mangement is Full Duplex, and Radios >> >>are Half Duplex, and its never certain whether end user traffic is gfoing >> >>to >> >>be up or down during the congestion time. >> >>Generally congestion will happen in teh upload direction more, because its >> >>common practice to assume majority of bandwidth use is in teh download >> >>direction, so most providers allocate more bandwdith for download. >> >>Therfore >> >>when there is an unsuspecting surge in upload bandwdith, the limited >> >>amount >> >>of upload capacity gets saturated sooner. >> >> >> >>We took a two prong approach to fix. >> >> >> >>1) We used Trango 900Mhz internal bandwidth management, to help. MIRs set >> >>to >> >>end user sold full speed, and CIR set really low (maybe 5% of MIR speed). >> >>Primary purpose was to reserve ENOUGH minimal capacity for end users to >> >>have >> >>a time slice for uploading. >> >> >> >>2) At our first hop router, we setup Fair Weighted Queuing, so every users >> >>gets fair weight to available bandwdith. >> >> >> >>With 5.8Ghz, we did not use Bandwdith management on the trango itself. >> >> >> >>If you have good queuing, customers rarely ever notice when there is >> >>congestion. They might slow down to 100kbps now and then, but end uses >> >>really dont realize it for most applications, becaue the degragation of >> >>service rarely lasts long because oversubscription is low comparatively to >> >>most ISPs. Usually end use bandwidth tests will still reach in the 1-1.5 >> >>mbps level ranges. We run about 40-50 users per AP, selling 1mb and 2mb >> >>plans. >> >> >> >> But the key is Queuing.... If you dont have it, when congestion is >> >> reached >> >>packet loss occurs, and degregation is much more noticeable by the end >> >>user, >> >>because TCP will become way more sporatic in its self-tunning. We also >> >>learned faster speeds w/ Queuing worked much better than Limiting to >> >>slower >> >>speeds. We also learned avoid having speed plans higher than 60-70% of >> >>the >> >>radio speed, to minmiize the damage one person can do. >> >> >> >>VIDEO can quickly harm that model for the individual end user doing video, >> >>it prevents the video guy from harming all the other subs. Therefore if >> >>someone complains about speeds, its jsut teh one person that gets >> >>discruntled, not the whole subscriber base.. >> >> >> >>Tom DeReggi >> >>RapidDSL & Wireless, Inc >> >>IntAirNet- Fixed Wireless Broadband >> >> >> >> >> >>----- Original Message ----- >> >>From: "Al Stewart" <[email protected]> >> >>To: "WISPA General List" <[email protected]> >> >>Sent: Thursday, October 15, 2009 11:45 AM >> >>Subject: Re: [WISPA] Simultaneous connections >> >> >> >> >> >> > Okay, that's the ideal ratio. Which under normal casual usage >> >> > probably works great most of the time. But what happens if, say, 15 >> >> > or 20 of them are all connected and using for downloads/uploads etc >> >> > at the same time? >> >> > >> >> > Al >> >> > >> >> > ------ At 11:34 AM 10/15/2009 -0400, chris cooper wrote: ------- >> >> > >> >> >>At 500k per user I would cap users at 50 on that single AP. 35 would >> >> >>be >> >> >>better. >> >> >> >> >> >>Chris Cooper >> >> >>Intelliwave >> >> >> >> >> >>-----Original Message----- >> >> >>From: [email protected] [mailto:[email protected]] On >> >> >>Behalf Of Al Stewart >> >> >>Sent: Thursday, October 15, 2009 11:21 AM >> >> >>To: WISPA General List >> >> >>Subject: [WISPA] Simultaneous connections >> >> >> >> >> >>Using a 900 AP (like Trango) theoretically allows up to 3000 (3.0 >> >> >>meg) bandwidth. But there has to be a limit on how many simultaneous >> >> >>connections can go through the AP and maintain bandwidth. At what >> >> >>point -- how many using/downloading etc at the same time -- would the >> >> >>bandwidth be reduced by usage to below 500 (.5 meg) or lower? There >> >> >>has to, logically, be some kind of limit to what the pipe will hande. >> >> >> >> >> >>We're trying to evaluate our user to AP ratio in real life. >> >> >> >> >> >>Al >> >> >> >> >> >> >> > -------------- END QUOTE --------------------- >> > --------------------- >> > Al Stewart >> > [email protected] >> > --------------------- >> > >> > >> > >> > >> -------------------------------------------------------------------------------- >> > WISPA Wants You! Join today! >> > http://signup.wispa.org/ >> > >> -------------------------------------------------------------------------------- >> > >> > WISPA Wireless List: [email protected] >> > >> > 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: [email protected] >> >>Subscribe/Unsubscribe: >>http://lists.wispa.org/mailman/listinfo/wireless >> >>Archives: http://lists.wispa.org/pipermail/wireless/ >-------------- END QUOTE --------------------- >--------------------- >Al Stewart >[email protected] >--------------------- > > > >-------------------------------------------------------------------------------- >WISPA Wants You! Join today! >http://signup.wispa.org/ >-------------------------------------------------------------------------------- > >WISPA Wireless List: [email protected] > >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: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
