Redundant / full duplex?

[jeff]

I have a link where I replaced an Orthogon with two war boards. Since there were two antennas at each end I installed a dual war and connected both. Now I am trying to figure out the best configuration. My preference would be full duplex, but I am trying to figure out how to get it to fail over to half duplex if one of the links goes down.

Using source routing or just adjusting the gateway I can simulate full duplex, but with no fail-over. My other thought was mesh with the weighting factor adjusted at each end so that opposite ends prefer opposite paths. This should fail-over with a lost link. So far I have only played with the mesh code so I am not sure this will work.

Anyone tried something like this or want to comment?

Lonne, any chance full duplex with fail-over is close?

[tog]

I've already been through it a bit and it has been discussed on the OLSR-users mailing list, unfortunately you cannot get OLSR to do the asymmetric routing necessary to make a full-duplex connection out of your setup. The only way to do it currently is to use static routes.

[lonnie]

We are working on getting the x86 V3 code released. Until then there are NO enhancements planned, so, no, full duplex with failover is not close.

[luka]

Originally Posted by jeff

I have a link where I replaced an Orthogon with two war boards. Since there were two antennas at each end I installed a dual war and connected both. Now I am trying to figure out the best configuration. My preference would be full duplex, but I am trying to figure out how to get it to fail over to half duplex if one of the links goes down.

Btw, why you replaced orthogon with war?
Not performing as advertised, or something else?

[jeff]

Originally Posted by luka

Btw, why you replaced orthogon with war?
Not performing as advertised, or something else?

Considerably more flexibility and actually gained a bit of performance as well. In non line of site applications the Orthogons can't be beat, but line of site the nod goes to the WAR. Plus it's 10% of the cost.

[jeff]

Originally Posted by tog

I've already been through it a bit and it has been discussed on the OLSR-users mailing list, unfortunately you cannot get OLSR to do the asymmetric routing necessary to make a full-duplex connection out of your setup. The only way to do it currently is to use static routes.

So if I adjust the weights so that each end prefers the opposite link I realize that will not be true full duplex, but it should be roughly the same thing and will fail over to the working link if one goes down, right?

I guess I have a few other quick questions about OLSR. It looks like it only propogates the routes for the primary IP address on interfaces it knows about not the whole routing table. It looked like you add additional routes explicitely. It also looked like routes added by OLSR are the lowest priority so they will not overide default gateway or static routes. Did anyone on the OLSR list come up with any creative solutions for running links in parallel?

[luka]

Originally Posted by jeff

Considerably more flexibility and actually gained a bit of performance as well. In non line of site applications the Orthogons can't be beat, but line of site the nod goes to the WAR. Plus it's 10% of the cost.

Thanks for the info.
As far I know, Orthogon (at least on paper) has better spectrum efficiency, better interference mitigation and better throughput, at least looking at spectra series - but anyways I have noticed there are several other people on this forum who changed from orthogon to war, some of them witnessing that in some circumstances wars work better/more stable than orthogon.

[tony]

full-duplex / fail-over features are on our todo list, but are not ready to implement it quite yet.

[jeff]

Originally Posted by luka

Thanks for the info.
As far I know, Orthogon (at least on paper) has better spectrum efficiency, better interference mitigation and better throughput, at least looking at spectra series - but anyways I have noticed there are several other people on this forum who changed from orthogon to war, some of them witnessing that in some circumstances wars work better/more stable than orthogon.

Spectra is pretty impressive, but lacks the non line of site performance of Gemini and if you did the math it would be 20 times more expensive, not 10. I replaced a Gemini and saw greater throughput and lower latencies. I also am able to use it across almost 1ghz of channels without changing anything. No cavity filters. Then lets add routing, shaping, etc. and it looks like a no brainer. I can also say that the WAR seems to be behaving better in the face of Canopy interference which is what prompted the switch in the first place.

[budi]

Originally Posted by jeff

Spectra is pretty impressive, but lacks the non line of site performance of Gemini and if you did the math it would be 20 times more expensive, not 10. I replaced a Gemini and saw greater throughput and lower latencies. I also am able to use it across almost 1ghz of channels without changing anything. No cavity filters. Then lets add routing, shaping, etc. and it looks like a no brainer. I can also say that the WAR seems to be behaving better in the face of Canopy interference which is what prompted the switch in the first place.

For Interference robustness from Canopy Interference,

I'm would like if VNC could change the CSMA/CA mac protocol together
with some polling or STDMA.

The weakness of the CSMA/CA protocol is, if other wireless user
are non behaved (like canopy and others), we is waiting
indefinitely for the medium is clear / idle. Which is never happened,
because canopy would always send regardless the medium status.

Canopy is Like "Shoot first before ask"
And 802.11b gear is "Ask first before shoot"

You know, whould survive in the real world (outdoor)

Our explanation is follow :

If you could turn off the CSMA/CA it would help many your installation
all over the world that have been disrupted by "Very ILL Behaved"
Wireless System like Canopy based system.

The canopy works like an Wireless based ATM, they sliced
their packet to very small packet (like ATM), and they use
FEC "Forward Error Correction" to get good troughput for
low SNR signal. But their gain is in our expense, because
their behaviour is "ILL Behaved" for Shared Medium
like unlicensed freq.

Why I'm calling their system is ILL Behaved ?

Because, well behaved wireless system like IEEE 802.11a/b/g
using CSMA/CA protocol that introduce backoff (random time interval)
when they detecting energy spike "ANY SIGNAL" in currently used
channel / freq. But if your product unfortunately colocated with
Cannopy Equipment, they don't adhere to this standard, and still
again, again, again using all the time slot available, and we1ll behaved
system are waiting, waiting and waiting and never get any chances to transmit any packet/data, and we would get timeout or very bad latency/troughput.

Please read statement below from one of your user :

"It seems like we have such a good system going but unfortunately the fact that 802.11 in standard mode limits the AP to CSMA/CA, polling definitely helps against hidden node interference, but unfortunately any kind of carrier on the channel is going to cause the stations to back off - other vendors don't do that, notably Canopy and Trango. If VNC was able to "turn off" the CSMA/CA, then at least we wouldn't be slowed down by the average 2.4ghz consumer device that is transmitting.
"

This statement is very true.

The problem in unlicensed freq aren't from noise / interference,
because :

- Almost all your user using very high gain directional antenna.
Good SNR (Signal to noise ratio), so the signal is not the problem.

- Why the troughput / link quality is very BAD : ?????

The problem is located in transmit part of the link. Why ?

CSMA/CA protocol inherent weakness :
- It assumed that all spectrum user are well behaved, and
don't eat all the spectrum or time for him/herself.


- If other wireless user is ill behaved (CANOPY),
we never have any "CHANCE" to transmit any data/packet.

The result, usuall "Interference like symtomps" like :
- packet timeout
- very low troughput

Even with good signal ????

So, what's the saviour ?

1. Please give option to TURN OFF CSMA/CA and replace it
with ATM based / time slot polling protocol enhanced with OFDM
protocol.

Thank's a lot for your consideration.

You don't want many of your user base forced to use canopy because
this issue, won't you ?

Thx
//Budi