so the likely the issue will be resolved with the polling feature
available with N-stream.
When this solution was installed Nstream would not work correctly WDS, (even
though MT claimed it would at the time).
Its possible the later firmwares allow it to work right. I'm jsut afraid to
try it, because I'm afraid I'll break the radios in the attempt, causing
significant down time. Its hard to emulate all the weird real world
configurations in a lab with two radios. Even updating the firmware is risky
venture, when you don't do it on a regular basis with MT. What I need to do
is test in the lab first, then send an engineer onsite to wait there in case
a radio is left lifeless, then remotely make the upgrades. I was avoiding
this, until I felt it really was my best option.
I currently use N-stream over WDS for one of my main back hauls to a new
bandwidth source and it has performed flawlessly for 6 months. This is
using 2.9.28 software.
If NStreme polling can be made work with my WDS/VLAN configuration, it would
of course solve this problem or at minimum rule it out.
Looks like its time to give it a try.
Thanks,
Tom DeReggi
Anthony Will
Tom DeReggi wrote:
To be clear, Mikrotik us being used, and the 4 remote building are in wds
station mode and only configured to talk to the 1 central master WDS AP,
the four client WDS radios are not configured to talk to each other. So
all the CPE radios only have one hop to the APconnected to the Internet
backhaul.
My theory for design was...
I had a 10 mbps backhaul. The WDS PtMP would have 16mbps (54 mbps
modulation), to help with waste from re-transmissions. All clients are
bandwidth managed (priority weighted method) centrally on other end of
backhaul, to also assist with fair transmission time. Also radios use
CDMA/CA, with the CA also assisting. The question is, is this enough to
let it work well with only four buildings.
I'm starting to think that it might not be. But the problem shouldn't be
that they hear each other. we want them to hear each other, so they don't
transmit at the same time. Thats what 802.11 needs. Hidden node happens
because CPEs don't hear each other, and don;t know someone else is
transmitting, from my understanding.
Part of my question is, Does WDS work differently when in Mikrotik
Station WDS mode than a normal WDS AP?
Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband
----- Original Message ----- From: "Anthony Will"
<[EMAIL PROTECTED]>
To: "WISPA General List" <[email protected]>
Sent: Saturday, October 07, 2006 11:57 AM
Subject: Re: [WISPA] WDS PtMP
It would seem to me that as your load increased your WDS/APs are
transmitting over each other as clients are trying to transmit to the
central AP. client -->WDS/AP transmitting carrier beacons or other data
to client and passing onto to -->WDS/AP<--WDS/AP<--Client (transmitting
to local AP)
In this scenario you have the two clients talking and one AP all trying
to talk at the same time and thus raising your noise floor because they
are all on the same channel.
There is not a feature in standard WDS to coordinate who can talk and
who can not talk other then the standard CDMA layer of the 802.11
protocol. This will create issues as the more load you have on this
setup the more self interference and retransmissions you will incur.
The big thing the mesh brings to the table is the ability to help
coordinate all of this traffic so that you can utilize the spectrum more
efficiently. At least that is my opinion as soon as someone actually
does it. You likely are going to have to switch to a station /AP
solution for this setup because everything is to close and can hear each
other. This will destroy your bridge setup unless you change to a
propitiatory system such as Trango, Canopy, etc. One other thing to
note is that this is all half duplex so you might have two many hops and
thus running out of bandwidth.
Anthony Will
Broadband Corp.
Tom DeReggi wrote:
Background....
In standard WIFI, a principle exists called hidden note, where two CPEs
transmit at the same time and colide because they do not hear each
other. There are three ways to get around that, using WIFI between
Client and AP. 1) Polling (Karlnet, Nstream, Proprietary), 2) Use
Omnis, so radios can hear each other if in close proximity, 3) RTS/CTS
which effectively solves the problem at a significant performance
degregation. A well know problem with well known solutions.
Issue.....
How does this play our with WDS? AP to AP communication. Sure in PtP
its a non-issue, because there are only two radios involved to complete
the link. But WDS allows PtMP operation.
How does WDS commuication work? Does the Hidden Node problem exist with
PtMP WDS? And if so, is there a way to address it? If so, will it help
to make the CPE's Omnis, so they hear each other?
My confusion is how WDS/WDS works compared to Station/AP modes.
Example application:
Using 802.11a gear.
5 seperate MTU buildings, spread out within 300 yards of each other.
1 is a Master AP Site, with an Omni, and a second backhaul radio to the
Internet.
4 of the 5 have a direction CPE style antenna pointing to the Master
Antenna.
WDS is used to allow the radios to operate as true transparent bridges,
and to pass per client (5-10 clients per MTU) large packet VLAN
traffic.
(Note: There is a reason we did not select Nstreme w/ Polling. It may
have been an incompatibilty with WDS or inabilty to do transparent
bridging with large packets, which standard 802.11 station mode does
not support under protocol. May have been early version of Firmware,
not sure if still an issue)
Why I thought it might be an issue:
Surveys show low noise. However, as more clients have been taken on (2
mbps average sustained throughput all combined), the Link quality
started to degregate as if the noise floor was rising.
As a tempoirary measure, we switched to 5.2Ghz (indoor only FREQ, which
appeared not to have any detectable noise in standard 802.11 based
survey tools, and was chosen because non-detectable carrier grade gear
would not use those channels). Its hard to believe that the noise
floor would be that high using that freq. So I'm wondering if the
noise that I'm hearing is actually my own CPEs within this project?
The symptom was sparatic higher latency, what typically would happen if
802.11a had frequent retransmissions (native prorocol ARQ). I can look
at stats to see if there are re-transmissions, but that data is
pointless, as what I want to know is, is the retransmisison because my
own noise or someone elses. Its hard to tell with WiFi, as WiFi
doesn't transmit when its not in use. So testing in the middle of the
night, when clients and users in town are off, may not be meaningful.
Its also possible, that I just have a failing radio card or two, and a
totally different cause.
Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband
--
WISPA Wireless List: [email protected]
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.13.0/465 - Release Date:
10/6/2006
--
WISPA Wireless List: [email protected]
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.13.1/466 - Release Date: 10/7/2006
--
WISPA Wireless List: [email protected]
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
