This could be a very touchy topic. Routers, are everywhere. Someone can't blame a router for all there problems because at some point your internet goes through a router. At your location or your ISP's its inevitable. But why have routers gotten such a bad name? I believe this is the fact that most SOHO routers are trash. Generally your average home user isn't doing much to notice a router. But then you get your users that are heavy on the P2P or something they find the router gets slow.. Most SOHO routers don't handle P2P very well because the number of connections. So they remove the router and it all works great suddenly.
As for the actual question. No, most routers are not the cause of speed/bandwidth issues. As today most of them are decently equipped. I know back in the day I saw many a netgear 614 have about a 14Mb/s ceiling on wan to lan throughput. Add in lots of P2P connections and that could come down under the 10Mb/s mark. I really like the idea of the new RB750, I have one running right now and its capable of doing 98Mb/s TCP at about 60% cpu load. This is in the standard soho config (1 wan, 4 lan, nat, no queues) Nick Olsen Brevard Wireless (321) 205-1100 x106 ---------------------------------------- From: "Al Stewart" <stewa...@westcreston.ca> Sent: Thursday, October 15, 2009 2:31 PM To: "WISPA General List" <wireless@wispa.org> 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" >To: "WISPA General List" >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: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] 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 stewa...@westcreston.ca --------------------- ---------------------------------------------------------------------------- ---- 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/
