Right - First I need to unravel the great Scott mystery (terribly British
!!)  Are there two of you ?? :0

I think the reason for no/low retries must be that it isn't retrying (dear
Holmes) - its held off from transmitting by a cts from somewhere - possibly
all those other clients (I hear you say it makes it worse when off - but
then collisions ?), or someone elses AP.  If it was a cable you _would_ get
retries though.  If it was multipathing you _would_ get retries too (as you
have noted)  I can understand you're frustration!!!  You say all other
clients doing pretty good so it has to be another network close by this
client, eh ?
.

----- Original Message ----- 
From: "shoffman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 26, 2003 7:48 PM
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

Reply via email to