By turning off RTS/CTS you mean setting it to its maximum setting of 2347 on both APP and ABO correct?
When playing with the frag settings, should I change them on both units? Should I match the values ? It sure would be cool if I could fix this from my desk. Scott > If it is a PtP link you should turn off RTS/CTS. It is only for PtM. Try > setting frag down to 1250 then 1000 then 750 then 500 and see what > difference that makes. Since one of the radios is only seeing 60% you will > only see about 1meg throughput. An earlier post mentioned that the speed was > fixed at 5meg with no auto fall back. Not sure if it was you. You will want > to enable auto fallback or fix it at 1meg on both sides. Are the radios > plugged directly in to a computer on both ends or is there other hardware in > between? > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of shoffman > Sent: Wednesday, November 26, 2003 2:49 PM > To: [EMAIL PROTECTED] > Subject: Re: [smartBridges] upload vs download > > Brian, > > Yes, I understand. Thats what is puzzling. If you look at my test data > below, we had RTS/CTS set on all clients for that AP set to 128, AND > 256. It actually got SLOWER upload speeds then when we completely turn > it off. And thats the funny part also is that the AB(CPE) reports hardly > ANY (less than 2%) retries! Now seeing that made us think cable issue, > but we tested it CLEAN! (And yes, we have a GREAT cable tester, it > analyzes everything and even allows me to ping and measure voltage across > the connector!) > > So, last thought is multi-pathing but again I wonder why no retries being > recorded? I have started a packet count on both counters (AP receive and > CPE send so I can compare the counters.....) > > I am at a loss! In any of these events, why is the CPE not showing > retries!!??? Damn its frustating... > > Oh.. btw, we have simplespeed loaded. Only thing we haven't done (and > its gonna be tried before we give up) is modifying the MTU size on the > customers computer. I just hate screwing with registries on a customer's > computer though! > > Oh well.. back to the "imperical" design equations. I am going to call > working with smartbridge equipment not RF engineering but instead H&M > Engineering (Hit and Miss)..... Nothing Normal appears to work for this > stuff! > > Scott > > > -----Original Message----- > From: "Brian Winter" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Date: Wed, 26 Nov 2003 18:05:43 -0000 > Subject: Re: [smartBridges] upload vs download > > > Scott, > > Isn't this exactly what we are talking about on the other thread ? > > > > For this discussion AP = Access Point rather than APO etc > > > > AP > client > > Your client does not hear many other client transmissions cos its got > > directional antenna pointing towards AP, or not many clients nearby > > etc. So > > when AP transmits, it can hear it no probs, no retries. Good bandwidth > > > > Client > AP > > AP hears all the clients - thats its job. When your client transmits > > it > > doesn't know that others are also transmitting to it ("hidden nodes" as > > far > > as your client is concerned), the AP does not ACK. the packet is > > retried. > > Poor bandwidth due to retries. > > > > Suggest you check retied packet stats at the client. Does reducing the > > value of RTS help ? Say to 200 ? Need to find the balance possibly > > > > > > ----- Original Message ----- > > From: "Scott" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, November 26, 2003 5:22 PM > > Subject: Re: [smartBridges] upload vs download > > > > > > > I really hate "me too" emails but we've experienced the exact same > > > behaviour. I'm wondering how many people have witnessed this > > happening. > > > This is an ABO to AP link and SimpleNMS shows the following: > > > > > > The AP client table shows RSSI 92% -17dbm and a link quality of > > 90% > > > The ABO statistics show RSSI 60% -42dbm and link quality 72% > > > > > > If I understand this properly you would _think_ that you would get > > higher > > > bandwidth from the ABO to the AP (am I right here theoretically ?) > > but > > this > > > is exactly the opposite. > > > > > > This is a 14 mile link which is very stable. From the ABO, download > > is > > over > > > 1Mbps but upload is probably 250kbps. > > > > > > Running 1.4j.6 and 0.01.08 > > > > > > Scott > > > > > > > > > > I have seen this also in some cases so you are not alone. Anyone > > with a > > > > clue as to what is happening here? > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] Behalf Of shoffman > > > > Sent: Tuesday, November 25, 2003 6:43 PM > > > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > > Subject: [smartBridges] upload vs download > > > > > > > > > > > > Hi all, > > > > > > > > Know this has been discussed several times.. hate to repeat an old > > topic. > > > > > > > > Here is scenario: > > > > > > > > Customer has ABTotal. RSSI 75%, Link quality 95% on its reading. > > Long > > > > Preamble, 5 MBps auto (also tried at 11 Mbps auto). > > > > > > > > Frag set at two different levels: 512 and 2336 (off) > > > > RTS set at two different levels (4combos in all): 128 and 2337 > > (off) > > > > > > > > Ethernet card at 10 - 1/2 duplex > > > > > > > > AP is Cisco 350 - RTS Off, Frag 2336. Signal Strength at 50%. > > > > > > > > In all cases: Download 600-800 kbps, upload (best with RTS off) 36 > > kbps, > > > > with RTS 8 kbps. > > > > > > > > Network has RTS on all other devices pointed at that AP at 128. > > > > > > > > So... thoughts? We are going to re-terminate...go with an outdoor > > and > > > > parabolic.. But is this interfernce? SB device see no other > > signal, > > > > have not sent out an SA yet. All other clients are doing pretty > > good on > > > > this network. We will send an SA out to be sure, but still..... > > > > > > > > > > > > Thoughts > > > > > > > > Scott > > > > > > > > The PART-15.ORG smartBridges Discussion List > > > > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe > > > > smartBridges <yournickname> > > > > To Remove: mailto:[EMAIL PROTECTED] (in the body type > > unsubscribe > > > > smartBridges) > > > > Archives: http://archives.part-15.org > > > > > > > > The PART-15.ORG smartBridges Discussion List > > > > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe > > > smartBridges <yournickname> > > > > To Remove: mailto:[EMAIL PROTECTED] (in the body type > > unsubscribe > > > smartBridges) > > > > Archives: http://archives.part-15.org > > > > > > > > > > The PART-15.ORG smartBridges Discussion List > > > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe > > smartBridges <yournickname> > > > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe > > smartBridges) > > > Archives: http://archives.part-15.org > > > > > > > The PART-15.ORG smartBridges Discussion List > > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe > > smartBridges <yournickname> > > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe > > smartBridges) > > Archives: http://archives.part-15.org > > The PART-15.ORG smartBridges Discussion List > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe > smartBridges <yournickname> > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe > smartBridges) > Archives: http://archives.part-15.org > > The PART-15.ORG smartBridges Discussion List > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) > Archives: http://archives.part-15.org > > The PART-15.ORG smartBridges Discussion List To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) Archives: http://archives.part-15.org
