[CUWiN-Dev] G and A and realworld throughput

[Stelios Valavanis]

i couldn't listen to the metrofi "radio" piece (what the hell is a 'wax' 
file). from their site i see thye are using proprietary wireless with some 
kind of CPE. i wish they had more on the backhaul (my issue here) which i bet 
was in the "radio" piece.

how does roofnet compare with cuwin?

here are some more details on what i'm building. i actually would not mind 
sending a map to individuals but not to the list as it is for a client.

there are 15 nodes using atheros 802.11a radios with cuwin as a backhaul. i 
used omni but flat (donut shaped - don't know what you call it) antennas. 
these nodes feed separate 802.11g APs with sectorized antennas meant to 
penetrate into buildings across the street. the whole length of the site is 
probably 2000 feet so i can probably see every node from every other but 
since cuwin does not necessarily find the fewest hops to it's backhaul point, 
i can't guess how it's going to perform here. it could go as many as 8 hops 
(ouch!). i could do a few things to minimize this. i could use unidirectional 
antennas to make sure i'm connecting to more distant nodes closer to the 
uplink point. i could also add a second meshnode at the uplink point and 
"break up" into 2 mesh networks but that doesn't reduce hops any more than 
getting my more distant nodes to connect via nodes closer to the uplink. i 
think uni antennas is a better shot. what kind of distance should i expect 
with 802.11a atheros (100mw i think) and omnis (hypergain HG812U-PRO 12dBi) 
anyway? is there anyway other than with unis to force meshnodes to connect 
via particular nodes?


On Friday 15 July 2005 08:42 pm, listsubs0506 wrote:
>  >Stelios Valavanis wrote:
> >
> >shall i assume that the cuwin is no different and that this would be
> >applicable to cuwin mesh?
>
> I'm far from an expert in these matters and look forward this weekend to
> reading some of the material that David referred us to. But I would
> suggest you not count on any better results in the field than might be
> suggested by the Kumar article. And it could well be worse. You'll see
> here some stats on a quick test I helped with in Boston:
> http://pdos.csail.mit.edu/roofnet/doku.php?id=april2
> That has encouraged me to think that there and at similar sites, we
> should aim to use directional antennas on the perimeter as part of
> trying to minimize hops and perhaps that's something that could be
> helpful in your situation. Just this past week we've started doing more
> systematic testing using the Netgear routers so I may have a better
> understanding within the next few weeks, though they don't lend
> themselves to swapping antennas (we'll supplement with at least a couple
> of outdoor boxes that do). Perhaps if you were to describe in more
> detail the architecture in regard to which nodes would be expected to
> communicate with which other nodes, David or others on this list could
> give you a more accurate estimate.
>
> Given this description of yours: "here in chicago we're about to deploy
> a 20 node cuwin mesh backhaul network with cisco APs shooting out to the
> end users. the ciscos are getting donated fyi but i did get the metrix
> kits with dual radios for when cuwin can do dual radio"  I think you'd
> be very intested in the recent segment on Wireless Tech Radio featuring
> MetroFi founder and CEO Chuck Haas especially from minutes 7:18 to
> 10:00. You can find the entire MetroFi segment highlighted down towards
> the bottom of the page here:http://www.wirelesstechradio.com/
>
> MetroFi use a two radio backhaul system with 45 degree sector antennas
> and it sounds as if the backhaul radios tend to lock in to a particular
> path but are aware of each others' location and able to reroute if a
> backhaul node fails. I'd be interested if anyone knows more about the
> software that MetroFi uses for that purpose. It seems like the kind of
> thing that might best suit your purpose at the moment, Stel, if it or
> something similar is available.
>
>  Steve Ronan
>
> !DSPAM:42d8581b177248678017944!

-- 
_______________________________________
stel valavanis  http://www.onshore.com/