Re-4: [Voyage-linux] Mesh

[David Gascón]

what kind of boards are you gonna use?
if you want to put a large number of nodes you will need availability,
and you know what is going on with wrap...

regards.

David.

jake at v2gnu.com wrote:
>> Jake,
>>
>>         How do those wrap boards perform? How many subscribers as far as
>> data will they handle? I primarily run wireless video and need
>> something beefy. I use the generic pc version and run a flex atx
>> or mini-itx m/b with 800mhz cpu and 512 DDR 266. Works great! I'm
>> just breaking into mesh. I like what I've seen so far. I was just
>> told by one of my vendors that you have to divide your throughput
>> in half every time you hop. I thought that was the whole point of
>> mesh was no loss in throughput over multiple hops and self
>> healing.
>>
>>     
>
> They perform well for what I used them for. I used them mainly for IP
> cameras (Axis 2130 and 213's), with 2-3 laptop clients per unit without
> any real noticable load. Routing packets takes very little CPU time to be
> honest. The Axis cameras were at full resolution with "unlimited" set for
> the data rate.
> The reason I went with the Wrap boards was because of power. If you
> checked out the website I mentioned, you'll see that the units I designed
> were solar powered. Each of those trailers had a camera and a mesh unit,
> and a pair of deep cycle batteries to keep it running 24/7. I originally
> used Via boards, but the power draw was too much to keep it running all
> the time.
> And yes, you do cut your throughput. When they say half, that is
> technially true, but only for that hop. What mesh does is allow you to not
> have to run wires to each unit. If you have 3 nodes in a row, with node1
> being the gateway, and node3 being the camera's unit, with a 20ms ping
> time between each node, when you send something to the camera from the
> Internet it will take 20ms+20ms to reach the camera. Since each unit has
> to fully receive a packet before it can send it, you are subject to the
> hop latency between each node.
> I've been out of mesh for a couple years, but I did see a company out
> there that was using predicitive mesh technology (I think that's what they
> called it), where the repeating node sent the data to the next hop as it
> received it, not before the end of the packet. That was supposedly
> supposed to drop the latency 25% or more. It didn't make a whole lot of
> sense to me at the time looking at their diagram, but that didn't mean it
> couldn't be done.
> Anyway, yeah, the rule of thumb is that you're supposed to "re-energize"
> your mesh every 4-5 hops with a hard data connection to get your
> throughput back. And yes, it is adaptive and self healing. It should send
> a data packet along the shortest route to it's destination unless you
> override that. If the units are placed in overlapping cells, then if one
> unit goes down it will "self-heal" by rerouting the data around the lost
> node.
> There was another branch of mesh out there you may want to look into as
> well, depending on your application. The regular mesh will constantly be
> asking the nodes around it for a status to determine routing. That creates
> overhead. There was another form of mesh out there (I'm travelling and
> stuck in webmail, or I'd see if I could find some links for you in my
> boomarks) that every 6 seconds or so (configurable) would send a "status
> packet" and get answers from each node and build the routing table from
> that data. It supposedly allowed for quicker data transfers since it knew
> what the path was, instead of having to build the path every time a
> request came through. Downside was that if a unit went down, you lost the
> mesh network for 6 seconds until the routing table got rebuilt. Didn't
> seem like too bad of a trade-off to me, but your application may require
> differently.
>
>
>
> _______________________________________________
> Voyage-linux mailing list
> Voyage-linux at list.voyage.hk
> http://list.voyage.hk/mailman/listinfo/voyage-linux
>
>   


-- 
David Gascón Cabrejas
d.gascon at libelium.com
Departamento de Investigación y Desarrollo
Libelium Comunicaciones Distribuidas
http://www.libelium.com
Mov:654182554