Please write with reports on nstreme single radio mode over large distances. We would like to confirm that you can get the max radio throughput over distance 50km+.
The single radio speed should be about 35Mb/s total for non-turbo mode. Turbo should be about 72Mb/s.
The newest package has additional support for the AR5004 (5213) and framing for the nstreme single radio mode.
Eugene once wrote that the N-Streme package should also contain support for hardware WEP encryption.
My two test systems (both 2.8.10 with n-streme rev. 5 package, one AP, one client) refuse to talk when WEP encryption is switched on (/interface wireless security set wlan1 encryption=required).
The interfaces are an Atheros 5211 in one system, an Atheros 5212 in the other one.
Has anyone got this to work (or even tried it)?
WEP is not a priority now. It might just be better that documentation is needed – because I did see it tested here. We should have a new package at the end of next week and we will check for WEP.
John
I see that WEP was never a high priority for you - I have discussed this several times with Normunds and others. From my point of view I can understand your arguments that WEP is weak anyhow and one should use stronger encryption when wanting to secure a wireless link (IPsec, PPPoE with encryption, …).
On the other hand if you want to operate a “standard” AP using RouterOS, you just have to support WEP correctly, as it is an expected feature. And the current implementation in software obviously takes lot of CPU power to get some throughput - a RouterBoard will only make perhaps 3 Mbit/s throughput, if I recall my last lab tests correctly.
I just put up this question, as Eugene directed me to the N-Streme package as a response to my question how far WEP hardware support was…
As you said, WEP is not worth it. It’s as easy to crack as they come and it just adds overhead to the packets.
It’s like running ssh implementation with security holes. Would anyone sane do that intentionally?
There are far more secure and reliable ways to secure your network.
Hi Tully. You say :
The newest package has additional support for the AR5004 (5213) and framing for the nstreme single radio mode.
Are you saying that 5213 based cards will not work with nstreme2 yet? Do you have more details? The manual still says that only AR5211 and AR5212 MAC chips are supported
v2.8 does support the 5213, because the 5213 works with the same setup as the 5212.
The nstreme package has a new setup for the 5213 that will allow us to add the additional lower rates (coming soon) and may have some other improvements (we don’t know all of what the changes mean as Atheros does not give this out).
John
So we can use AR5004 (5213) based cards with nstreme in both single radio mode and dual radio mode?
what type of antennas should I use to get these speeds and distances (5.8 GHz band)?
John,
I can confirm that it shows 35 Mbps in bandwidth-test over 57km link. This, when the link is not loaded with other traffic of course, and with both revision 4 and revision 5.
As far as I could tell, revision 4 too, handled somehow the framing-mode setting for single radio setup. (in short, I can’t find the difference in both revisions 
However, real-world performance does not seem to be that good … CPU load is getting high on routers.. For an 4-hop link, I could get about 6 Mbit in single ftp session.
I have noted, that with nstreme, there are variable RTT times - the dispersion, even on idle link is significant.
For example, the same router, having both links (first without nstreme, second with nstreme), over ~57km distances (both links). Link 1 also has P3P enabled, with compress-all in both directions. When this test ran, there was around 3 Mbps traffic from link 1 to link 2;
link 1:
round-trip min/avg/max = 44/71.5/100 ms
link 2:
round-trip min/avg/max = 84/184.1/537 ms
Hope this sheds some light.
Daniel
35Mb/s is good for a 57KM link. I don’t know if you are in turbo mode or not.
There are a number of optimizations we will be working on – should be ready in about four weeks – that will find the optimum frame size and rate and dynamically adjust it. At the moment, he rate is dynamically set, but the frame size is static.
I would prefer to see a bandwidth test from a celeron able router with ‘randon-data’ set to no. An single ftp test over four links is not best.
You might change the noise-floor setting to a higher number if you think your radios are not transmitting because they are so close together. Maybe -30 (I don’t really know). As nstreme is polling, it should not matter to how the clients of the AP work.
John
Ths 35Mbit at 57km is with non-turbo mode, unidirectional, with random-data=no. Machines on both ends are 700MHz C3. During the test, both routers (that have few more Atheros interfaces each), were not transporting traffic.
With unidirectional traffic, CPU load is around 30. With bidirectional traffic, it always hits 100.
Do you believe turbo mode will work well on such distances?
What might be causing the jitter? noise? If it is because of noise, why is the non-nstreme mode better?
Unfortunately, I have moved one antena on my slightly over 60km setup, that didn’t work with 2.7 - might be good try.
Daniel
35Mb/s with non-turbo mode means that you have an excellent signal. You can use turbo mode – you will have to see if it will improve the throughput.
We will check on the CPU usage with bidirectional.
I really don’t know about the four hop setup. Can you check the speed between each hop and then go an additional one and so on.
John
Note: We only let our radios go to 24Mbps in order to improve link stability (might be better now that we are running 2.8.10 (will try 36Mbps and higher tonight)).
We are seeing about 15-19Mbps UDP and 10-16Mbps (TCP) across each of 4 50km+ links running nstreme. This is a BIG improvement per link. However, when we run test traffic across all 4 router links we only see 5-6Mpbs TCP. However the UDP numbers are still around 15Mbps. Our routers are 1GHz processors, 128Mb RAM with 2 or 3 wlan cards in each so power should not be a problem. I will run some more tests tonight and pay attention to processor utilization while I do it.
Any ideas why the routers slow down with TCP when passing traffic from link to link?
Thanks,
Ken
There is no need to restrict the higher rates of 802.11. There is an algorithm that calculates which rate will produce the highest throughput even with lost frames and such. Packets will never be lost unless the quality at the lowest rate is so bad that the client will be unregistered.
One session of TCP will never use the full throughput of a link. Many multiple sessions of TCP will get close, but a UDP bandwidth test will give the accurate number.
John
John,
What do you mean that packets will never be lost? Do you mean, that packets get lost only on congestion? I have found, that restricting the higher rates sometimes helps keep the RTT values reasonable.
As far as I understand the specifications of the Athros chipset, it will have higher output power at lower speeds, which I guess is to keep the average energy at different modulations ‘consistent’. But this may also mean, that at different speeds, there is different signal distortion because of different amplification etc.
Daniel
Packets will never be lost unless the connection becomes so bad the the client is unregistered. The AP lowers the rate if all the retries at a higher rate fail. If the packet continues to fail until it hits the lowest rate, then the client is unregistered – bacause the link quality is considered to be too bad.
The clients rate is increased as the algorithm determines that the throughput will be higher (accounting for the retransmits as well).
So, all of the rate calculations and such are done dynamically (and automatically) so that you do not need to set anything other than the defaults to get the highest throughput for your AP.
John
What is new with nstreme revision6?
Revision 6 has bridging for all nstreme clients.
John
The nstreme-dual interface is still not seen by OSPF. Any idea when this will be fixed?
Daniel