Title: Message
I'm one who currently believes that many "issues" seen on this forum (lockups etc) are down to the way we, all of us, expect to utilise this fragile airtime protocol in the real world - sB have little control over this if their kit is to remain standards compliant (however bad the standards are!).  There will be some problems which are due to faulty kit.  I wonder if it would be useful for list members to jointly devise a minimum working configuration which does not push the protocol to its working boundaries, and a check list of observations to best get through the most common areas of concern.  Once basic operation is achieved, each parameter can be backed off towards its expected operational state or 'til it stops working.  Time consuming, but scientifically satisfying  ;)    Does this already exist on sB site ?
 
 
The main technical concerns seem to be (list start - please add)
1. Poor receive signal strength    (long distance, non LOS, leaves and other obstructions, poor aerial/feeder etc, multipathing, dead spots)
2. Interference - Poor link quality (co-channel traffic, adjacent channel traffic, multipathing, microwaves, heavy current switches, electric railways, high power broadcast transmitters, pulsed radar etc)
3. Inappropriate data rate for low sigs or interference
4. Use of software which needs broadcast messages (eg dhcp)
5. Non-reciprocal radio paths
 
 
My first suggestions for config are:
1. Fix to one channel for results gathering - different chans may show different results - confusing.  When one channel is eliminated (noisy etc) fix to another one and start again.
 
2. Disable WEP - WEP protocol overhead means 50% of the traffic across the air is unnecessary for testing.  On top of this many (most) probs are in fringe coverage, so much of the real and overhead traffic will be retried, reducing throughput further.  If you have congestion this might relieve some of it.
 
3. Select "Basic Rate" = 1Mb "AutoFallBackRate" = off (should not matter as basic rate is set to minimum, but will prevent any rate negotiation).
 
4. Set fixed IP for client side radio, and the first device on the client side.  DHCP involves broadcast messages which are unreliable in the protocol - VERY IMPORTANT (esp thro AB)
 
5. Set preamble = ???.  For best performance in poor signal conditions.
 
6. Set allow "Non IP Traffic" off - less extraneous traffic to deal with.
 
7. Set Fragmentation = ???.  For best performance in poor signal conditions.
 
8. Set RTS/CTS = ???.  For best performance in congested conditions.  Messages of length < this value are sent without regard for others on the channel, which can give contention/retry problems on a busy channel.  Messages of length > this value tell other radios to "shut up" so it can get this message out and hear the reply without someone else butting in.  This adds a significant overhead of its own - much of the available airtime is spent "busy waiting" - Although this parameter is most beneficial in high capacity systems, thats where you need least overhead - theres the rub !!  Also note that this is only worthwhile where the other radios can hear you properly (see discussion on reciprocity later).  Also read up on the "hidden node" problem - google "hidden node".
 
9. Use a cheap router at the client end to get rid of all the default Windoze network management traffic (eg broadcasts from Computer Browser service)
 
10. Set the radio transmit power (not eirp) to be the same at both ends !!!  With tx/rx on the same aerial, there is nothing to be gained by whacking up the output power at the client end, nor by changing it for other kit with higher power output.  The link is only as good as the worst leg, and can be much worse than that.  By increasing only one end you are forcing the far end to send (and resend) replies that you just can't hear - this is just more "noise" for everyone else on the same channel, and no benefit for you.
 
 
 
Observations to report should include:
1. RSSI (should be > ??? for 1Mb data rate) - Link Status tab
 
2. LQ (should be > ???) - Link Status tab
 
3. RSSI/LQ observed on other channels ? SM for AP(CB mode), "Site Survey" tab, "Select from Available Acess Points"  (I could never figure why anyone should need a spectrum analyser when we have a perfectly good sensitive receiver in exactly the right location, with exactly the antenna arrangement, on exactly the freq of interest etc etc that we want to measure - toys for the boys)
 
4. Compare stats for transmitted "Unicast Packets" and received "Received ACK" - They should be very similar. 
 
5. Received RTS and CTS will give some idea of how the system is managing contention
 
6. Failed Packets and Aged Packets are the results of contention, poor reciprocity, one end interference etc.  Measure over fixed periods at different time of day
 
 
Its a real shame that SimpleNMS/Monitor can't let us change parameters (at both ends) and watch statistics at the same time
 
Comments welcome.
 
 
 
 
 
 
Discussion on Reciprocity:
 
Consider a pretty normal path between A (say APPO, AP mode) and B (say ABI, CB).  For this discussion ignore feeder losses, assume LOS, perfect path etc - I'm not suggesting that a link of 10Km is viable in this way !!
 
 
From A > B
 
Tx A       +17 dBm
Antenna A  +13 dBi   (eirp = +30dBm Illegal in UK)
PathLoss  -120 dB    (eg 10Km @ 2437Mhz)
Antenna B  +02 dBi
==================
Rx sig str -88 dBm   (at B)
Best Rate    2 Mbps  (assuming no fading etc !!!)
 
 
From B > A
 
Tx B       +17 dBm
Antenna B  +02 dBi   (eirp = +19dBm)
PathLoss  -120 dB    (eg 10Km @ 2437Mhz)
Antenna A  +13 dBi
==================
Rx sig str -88 dBm   (at A)
Best Rate    2 Mbps  (assuming no fading etc !!!)
 
You have a good reciprocal path.  No matter how you change the aerials you will always have a reciprocal path - Good
 
 
 
 
Now, on a whim, you decide to increase the client end transmit with an amp (yuk) or a 200mW pcmcia card
 
From A > B (no change)
 
Tx A       +17 dBm
Antenna A  +13 dBi   (eirp = +30dBm Illegal in UK)
PathLoss  -120 dB    (eg 10Km @ 2437Mhz)
Antenna B  +02 dBi
==================
Rx sig str -88 dBm   (at B)
Best Rate    2 Mbps  (assuming no fading etc !!!)
 
 
From B > A
 
Tx B       +23 dBm   (=200mW)
Antenna B  +02 dBi   (eirp = +25dBm)
PathLoss  -120 dB    (eg 10Km @ 2437Mhz)
Antenna A  +13 dBi
==================
Rx sig str -82 dBm   (at A)
Best Rate   11 Mbps  (assuming no fading etc !!!)
 
 
This has not improved the system even slightly.  In fact all we have is a client install spraying out louder messages that it can't hear the reply (ACK) to - further cluttering up the AP with useless noise.  It might even be worse than this as the dialog during association will be full of retries etc.  DHCP might be OK for client AP but pointless even trying for AB.  This could lead to all sorts of strange issues.
 
 
 
----- Original Message -----
Sent: Tuesday, November 25, 2003 3:04 AM
Subject: RE: [smartBridges] Tranzeo CPE / APPO Compatibility

Hi Ian,

 

I am sorry to hear of the problems you are having with the aBOs. Since you are running 1.08 and still having to reset, I think the problem should be some thing else. This firmware had solved the issue of occasional dis-association of the aB. This dis-association used to happen on a relatively small number of installations, depending on some combination of conditions. After many months of investigation we could never figure out what were these conditions. During these investigations we learned that this is a common and unpredictable problem with almost all manufacturers� devices. Well anyway, now we are happy that 1.08 solves the dis-association issue.   

 

As others have pointed out, this is a tech support forum. So most times you get to hear only the �I got problem� cry for help. Once the issues are resolved you would seldom find a post that clarifies the issue. We think that there are perhaps less than 1% or 2% of our users posting regularly on this forum. Typically when somebody is having problem, jumps on the forum, gets help from the experienced users and then becomes a passive reader. This is a great forum with so many friendly and willing users contributing their expertise. The forum helps us stay in close contact with our customer base. A little balance should be kept while reading the forum to get the best out of it.

 

With best regards,

 

Nimesh

sB

  

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Ellison
Sent: Tuesday, November 25, 2003 10:39 AM
To: [EMAIL PROTECTED]
Subject: Re: [smartBridges] Tranzeo CPE / APPO Compatibility

 

Yes, all of my ABO's are running 1.08.  At least 25% of them still need to reset frequently.  It isnt as bad as it was, and I am tyring to setup a "ping" keepalive system by recommendation of this list.  It shouldnt be necessary, but it it works for now, I'm game.

Ian


Pascal Losier wrote:

Are those corporate account running the 1.08 firmware and still have to power cyle their unit ????

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ian Ellison
Sent: Monday, November 24, 2003 8:55 PM
To: [EMAIL PROTECTED]
Subject: Re: [smartBridges] Tranzeo CPE / APPO Compatibility

It is great that there are those of you who are experiencing no problems withe sB equipment, sincerely.  However, that does not dismiss the fact that there are SEVERAL people using these products, who are all experiencing the same difficulties, that do not seem to exist (at least as much) in so many other manufacturers products.  I made the mistake of buying several units at an early stage (all of my units came with the old TRULY transparent firmware), with the (and Im so glad this is no more) 50' of cable attached to the radio.  Perhaps since then they have better quality control, or other factors.  In the meanwhile, those of us who are so unfortunate to be experiencing these problems are hardly seeing any "price performance" when we are constantly doing tech support and truck rolls to alleviate the issues.  the first unit i bought was an Alvarion DS.11, which has (is) run flawlessly (reaching WELL beyond 200 feet i might add ;o).  For "price performance" reasons, I made the change to smartBridges.  Noise and interference could definitely be an issue, but we are not finding any noise of significance at our location.  The suggested steps for resolving my 100% RSSI,  0% Quality problem included checking for interference, etc.  When all of htis turned up nothing, i simply replaced the ABO, and it was fine (as well as could be expected anyway).  This unit had only been in (highly problematic) operatoin for about 3 months.  We  havent even  made enought money from the subscriber to cover the cost of the unit, and we have to replace it....

I just  hope you can see why this is so frustrating to those of us who ARE experiencing these issues.  I havent tried RMA yet, but im going to have to try soon.  Hopefully smartBridges will make good on their products, and perhaps the newer units will be more robust and less problematic.  It goes without saying that one has to appreciate their online customer interaction and responsiveness to suggestions.  they get an A+ in that category.   I truly hope that the issues get resolved.  I have almost all smartBridges equipment in use, and didnt really want to mix manufacturers for CPE.

I still have about 10 ABO units brand new in the box (the ones with the attached 50' cable).   It would make my day to "trade" them back to smartBridges for the newer units so i can see if there is in fact hope to continue deploying smartBridges.

I apologize for the rant, but my largest corporate account has been on the phone ranting to me about how ridiculous it is that they have to reset their internet connection once a day....  I'm about to deploy a PTP 5.8 Ghz link as a temporary solution to make them a happy customer.  Another $1000 spent.  thats one expensive band aid :o\

Looking forward to a brigher future!

Ian


[EMAIL PROTECTED] wrote:

Just a reminder, there are many of us not having to reset the AB's or any
problems for that matter.  If you have a problem with 2.4 in general due to
noise and interference a different manufacturer is not going to help you.
 
I had a potential competitior who attempted to deploy the "higher priced"
Alvarion gear.  The furthest they could reach out from the tower was 200',
although I think it was stable at 200'.  : )
 
They threw in the towel and are no longer pursuing the wireless internet
industry.
 
Be careful in what you spend.  A $300 AP and a $1500.00 AP will both become
obsolete within 5 years.
 
Again, not everyone is experiencing problems.
 
----- Original Message ----- 
From: "Ian Ellison" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 24, 2003 4:07 PM
Subject: [smartBridges] Tranzeo CPE / APPO Compatibility
 
 
  
Has anyone tried using the Tranzeo CPE units with an APPO?  Due to the
way too many headaches I'm having with ABO's needing reset (constantly),
I am venturing out and trying some new CPE until (and then, maybe) sB
can get some issues resolved.  I'm not even using APPO at my next AP,
but am using high-priced Alvarion equipment to test the stability.
However my other AP's are still running APPO's, so I'm wondering if
anyone else has tried this combination, or has any opinions on the
Tranzeo line of products.
 
Thanks,
 
Ian
 
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