Slashdot Mirror
Linux-based Mesh Router Aims at VoIP and Video
An anonymous reader writes "A startup in Santa Clara, Calif. is shipping a Linux-based mesh router aimed at VoIP and video. The Mesh Dynamics Module uses multiple radios -- along with custom real-time Linux extensions -- to create a duplexing backhaul network said to improve bandwidth more than 64 times over conventional mesh technology. Normal, single-radio access points function in a half-duplex manner, a limitation that reduces bandwidth by 50 percent for each hop in the mesh. Mesh Dynamics is attempting to solve this problem by dedicating separate radios to upstream and downstream traffic of a 'backhaul' network that relays traffic between mesh nodes, thus simulating full-duplex operation."
Granted, a lot can be done with increased selectivity in transceivers and protocols designed specifically not to walk on each other's signals, but having a system that can measure and dynamically employ the relative signal strength of nearby equipment to form an optimal network under suboptimal conditions is what it's all about.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
I'm not so sure that VOIP and video are good applications for this mesh product. Clearly the mesh product sounds like a better way to provide your hotel guests with IP connectivity. But to have your phone call drop or pr0n cut off because the chief decides to microwave your omlett or the lady next door uses her hair dryer would suck.
Someone you trust is one of us.
"thus simulating full duplex"
If there are separate channels for uplink and downlink, this is not simulating full duplex, it IS full duplex.
However, this makes me wonder about something. Compare this with another wireless mesh network - AX.25 (amatuer radio packet). In AX.25, rather than an end-to-end ack, each node acks the packet upon receipt, then forwards the packet to the next hop - thus acks need only move one hop.
Now, while this does increase the complexity of each node's processing (for example, how do you handle it when a packet has been accepted by a node, but that node cannot deliver the packet to the next hope), it cuts the delay on moving freight.
Now, TCP has a means to work around this (the TCP ack window), but it makes me wonder - would it be beneficial to a node system like this to have a protocol-layer store and forward system?
For example, what if each node ran a HTTP cache, and when a client requests a page, each node in the chain from client to server buffered the data so that any drop-outs and/or turnaround delays would have a minimal effect on the transfer?
I wonder which would have the greater effect upon throughput - full duplex, or caching? And would both have an even greater effect?
www.eFax.com are spammers
Really? I'm not sure.
Excuse my ignorance, but what is a mesh router? How is it different than a normal router?
[insert lame joke here]
So according to the manufacturer, this stuff does not work...
The GPL clearly states that when code derived from GPL code or linked with GPL code is distributed, this code must be released under a GPL license. There is no exception for non-working code.
It looks to me like the manufacturer isn't willing to release their code under the GPL license.
http://en.wikipedia.org/wiki/Wireless_mesh_network
every day http://en.wikipedia.org/wiki/Special:Random
If you are going to be an armchair GPL cop, at least bother to fucking read it!
I'll make the plastic case myself
Will the processor being used actually support 4 802.11a or g channels? I am willing to be that the overhead of the OS + the overhead with the packet processing (signal vs noise) and finally raw data processing and routing will likely cripple one with 4 radios.
802.11n will likely prove the real backbone of mesh networking in the next year.
I mention this just in case these guys have tried to patent my old idea. Wouldn't be the first time some company has tried to claim sole credit for something done a decade or two earlier by radio hams.
Not to be a complete wet blanket, but any wireless network with half a clue has been doing this for a long time. Presumably the ample precedent for this technique means these folks will be granted a patent...
I've commented on the math that Mesh Dynamics uses to justify their system on several occasions -- needless to say, it's wrong and overstates degradation. More importantly, their systems is _extremely_ expensive. Meanwhile, groups like CUWiN, FreiFunk and others are developing free open source mesh networking systems. CUWiN's software (and, for full disclosure, I cofounded and coordinate the project) can be downloaded by anyone, it's under an open source license, and everything (including the developers' environment) is freely available. We haven't implemented multi-radio solutions yet -- mainly because the bandwidth degredation hasn't been bad enough to justify it. But to do so, we're only talking about a few weeks of work -- which can be done by anyone who wants to add the feature -- and then you'd have a system that does the same thing as Mesh Dynamics, but is freely avaialable to anyone who wants it.
Nice to see you're still around and digging into stuff ...
Yes, isn't it amazing that autonomous HTS-free links between mesh access points are somehow "new" ?
OTOH I can't be too critical of people who were likely still in diapers when we hams were actually building the first ad-hoc wireless data networks.
How would they know? Oh, whoops, they could READ about it, I guess!
73 Steve KZ1X/4
...if we had wireless network interface hardware that operated in some other part of the spectrum than the 2.4GHz and 5.8GHz license free 802.11x, which is already so swamped with traffic around here that it's now more useless than CB radio was in the late 1970's - early 1980's when 18 bazillion people were trying to talk all at the same time on the same rf channels.
forget it! fast! nothing to see here. move on.