Re-4: [Voyage-linux] Mesh

[(spam-protected)]

>
> 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.