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" <stewa...@westcreston.ca> To: "WISPA General List" <wireless@wispa.org> 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" <stewa...@westcreston.ca> >>To: "WISPA General List" <wireless@wispa.org> >>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/
