I'm trying to setup 2 rb500's with a CM9 card using 5ghz-turbo and nstreme. Now I'm not quite seeing the speeds I was expecting. I can get upto about 45Mbps. Now with some old standard P2-400's, and using 2.4g-turbo, I was able to sustain 65-70Mbps. What would be the difference here? Is the rb500's cpu not enough to sustain the higher throughput? I've tried 2.4-turbo and 5ghz-turbo with about the same result, 50Mbps. All cards are based off the Atheros AR5213 chipset, just the ones in the PC's are only 2.4ghz. These units are also running 2.9 release.

Thanks

Nik

You need a more powerful CPU.
on x86 platforms, above 600MHz CPU speed (Pent M)

Regards

But why does a p2-400 suffice on the pc side then?

Here is are the results that I got in the lab with RB500's and CM9 cards.
D~

Guess I'm doing better then you. I'm seeing 45Mbps each way. I am testing directly from the RB500 though. (I've tested on each side of it aswell with no real difference)

Thanks

45 mbit's each way you say? That's 90mbit's aggregated throughput. That's what you get out a turbo link isnt it? Have we forgotten it's a half-duplex medium?

i find 45mbit really impressive.

i am currently doing lab testing with 2pc's and 2 ver2.8 routers. They are not actual pc's just the router circuit boards with pc (laptop) wireless cards.

i.e : Geode 266mhz cpu, 128mb ram and Atheros AR5213 802.11a wireless cards.

the fastest i got was 23mbit receive using standard 5Ghz (turbo wont work for some reason) and Nstream exact size of 2048.

for this kind of set up would you expect this speed or faster??

24Mbps is the max you get on Geode 266MHz CPU.
That's assuming Nstreme and everything else turned off.

RB532 will get you faster, and for the fastest (i.e. CPU not limiting) with Nstreme enabled, you need 600MHz assuming x86 architecture.

Regards

Have you looked at these test results:
http://www.mikrotik.com/Documentation/wireless_test.pdf

Sounds about right with the Geode 266mhz processor.

Hi Uldis,

Can you clarify, on your test document for RB230, Nstreme

- CPU speed is 266MHz ?
- speed is measured on the wireless interface, or on the test celeron?
- framer size?
- routed or bridged (WDS) connection?
- celerons were running RouterOS with bandwidth test, or windows bandwidth test?

We did our 266MHz geode-platform testing many months back and only got 24Mbps in the lab.
Your test results shows 45Mbps using "old package" and 47Mbps using "new".

Would be nice to know the "latest results" - I don't have any 266 boxes here just at present.

Regards

45 mbit's each way you say? That's 90mbit's aggregated throughput. That's what you get out a turbo link isnt it? Have we forgotten it's a half-duplex medium?

I believe he meant that he was getting 45mbps both ways, one way one each test. Example, when doing a receive test he was getting 45mbps, then switch to transmit test and got 45mbps.

In my case, I was seeing 56mbps doing the receive test, and only getting 26mbps when switching to the transmit test. I haven't been able to figure out, why I was only seeing 26mbps on the transmit test. It should be the same as the receive test.

Dan

Thanks uldis for that pfd.

Has anyone out there gotten faster speeds using the fast frames feature?

- CPU speed is 266MHz ?
CPU was 333Mhz
- speed is measured on the wireless interface, or on the test celeron?
on test celeron
- framer size?
default values
- routed or bridged (WDS) connection?
routed
- celerons were running RouterOS with bandwidth test, or windows bandwidth test?
RouterOS with bandwidth test

Hi Uldis,

Can you clarify, on your test document for RB230, Nstreme

- CPU speed is 266MHz ?
- speed is measured on the wireless interface, or on the test celeron?
- framer size?
- routed or bridged (WDS) connection?
- celerons were running RouterOS with bandwidth test, or windows bandwidth test?

We did our 266MHz geode-platform testing many months back and only got 24Mbps in the lab.
Your test results shows 45Mbps using "old package" and 47Mbps using "new".

Would be nice to know the "latest results" - I don't have any 266 boxes here just at present.

Regards

Thanks uldis for that pfd.

Has anyone out there gotten faster speeds using the fast frames feature?

There is no 'fast frames' feature anymore in v2.9

I won't believe any of these throughput claims until I see it for myself. Anyone have a screenshot showing the NStreme Interface passing more than 20MB FDX?

NStreme2 FDX bench tests I have run with RB532s set to 333MHz rarely achieve better than 22MB FDX. In the field will typically produce slightly less even at stable -52 rssi readings.

Running the MT bandwidth test in "both" directions from a P4 3.2GHz MT router to a P4 2.4GHz MT router across a NStreme2 link with RB532s will yield just shy of 20MB FDX.

I challange anyone to submit screenshots, NStreme2 configuration and RB532 hardware configuration that can sustain greater payload than 20MB FDX.

Somebody please prove me wrong. <grin>

Best,

Brad

Hmmm
Sorry I don't have any RB532's (yet ... have ordered a pair for test, waiting for delivery - I think the new architecture looks very promising for medium speed radios).

But here are some results we had on 1.5GHz Pent M platforms in the lab., Nstreme, bridged using WDS. Test was through the router, using external 1GHz test routers running bandwidth test
Like you say, Belwave, I think a small prize for someone reporting RB532 Nstreme or Nstreme2 with max throughput is in order ....

Regards

Screenshot of NMS from full-speed lab testing, 83Mbps UDP test traffic with ~20% CPU load
http://www.cablefreesolutions.com/radio ... %20UDP.png
Screenshot of NMS from full-speed lab testing, 74Mbps TCP/IP test traffic with ~20% CPU load
http://www.cablefreesolutions.com/radio ... %20TCP.png

Hmmm
Screenshot of NMS from full-speed lab testing, 83Mbps UDP test traffic with ~20% CPU load
http://www.cablefreesolutions.com/radio ... %20UDP.png
Screenshot of NMS from full-speed lab testing, 74Mbps TCP/IP test traffic with ~20% CPU load
http://www.cablefreesolutions.com/radio ... %20TCP.png

In this test you have v2.8.18. Have you tried the same test with v2.9?

Good point Uldis,
We should do another lab test shortly on that 1.5GHz platform using 2.9.1.

We have range tested the radios with good results, but with obscured Fresnel zone (Near LOS) 5m height over water at 8.2km - so we could not achieve more than 40Mbps (still impressive) on that site with the 23dBi antennas - radio levels were flickering around -72dBm, so 2x24Mbps in 5GHz Turbo gave the best throughput.

Interestingly, we tested our 600MHz Pent M platform in the lab and it runs slightly slower than the results above - around 65Mbps, even using various 2.9 releases and 2.9.1, though the CPU load is never more than 40%. The platform runs cooler (fanless, outdoor grade case) and a lot cheaper than the 1.5GHz, so the slight performance penalty seems worth it.
So perhaps for x86 platforms that is "normal" to lose something from the theoretical maximum, perhaps some latency in the drivers or something.

While these are impressive HDX results lets see what FDX looks like. I imagine there will be a significant drop in payload capacity.

Also, what hardware platform are you using? Is there any "hardened" equipment suitable for outdoor deployment other than the RB532? These tests are great for indoor use, but we need this gear to survive 60*C to really be of any use.

Best,

Brad

Good point Uldis,
We should do another lab test shortly on that 1.5GHz platform using 2.9.1.

We have range tested the radios with good results, but with obscured Fresnel zone (Near LOS) 5m height over water at 8.2km - so we could not achieve more than 40Mbps (still impressive) on that site with the 23dBi antennas - radio levels were flickering around -72dBm, so 2x24Mbps in 5GHz Turbo gave the best throughput.

Interestingly, we tested our 600MHz Pent M platform in the lab and it runs slightly slower than the results above - around 65Mbps, even using various 2.9 releases and 2.9.1, though the CPU load is never more than 40%. The platform runs cooler (fanless, outdoor grade case) and a lot cheaper than the 1.5GHz, so the slight performance penalty seems worth it.
So perhaps for x86 platforms that is "normal" to lose something from the theoretical maximum, perhaps some latency in the drivers or something.

Do you have a URL for this product? Specifically interested in the fanless, outdoor grade case product. Even then I would expect FDX results to cut the 65Mbps in half if not more. If that is the case then we are not a whole lot better off than using the RB532s.

I sure would like to setup one of your outdoor solutions with NStreme2 just to see first hand what it is capable of.

Best,

Brad

Belwave, here is your screenshot. These are 2 RB512's (333Mhz on either side running Atheros CM9 5250Mhz Turbo with Nstreme, 1 radio each unit, UDP).

Zorker, thank you for your screenshot. What version are you running? BTW, I have another screen shot showing 22Mbps FDX running v2.9rc5. It seems as new firmware versions are released the throughput keeps dropping.

Ok, here is a snapshot of two RB532s running a FDX (both) bandwidth test between themselves.

(1) Both RB532 CPUs are set to 266MHz. 333MHz showed no improvement.

(2) Using CM9s for RX and SR5s for TX

(3) Data rate on both RB532s is set to 18Mbps in standard 5Ghz mode. Higher data rates either produced asymmetrical results e.g. 21Mbps/9Mbps or overall less throughput.

(4) rssi readings were -43 & -50. This was a bench test with each RB532 loaded inside outdoor cases with U.fl pigtails attached. The cases were a few inches apart.

(5) Framer Policy = Best Fit

(6) Not sure what the blanks or drops indicate in the graphs, but considering the continuous ping did not drop any packets I can assume the link did not loose any data.

(7) Test ran for several minutes with no lockups. Running later versions v2.9.rc10 & v2.9.1 etc do occasionally lockup requiring a reboot or disable/enable of the NStreme2 interface to bring the link back up.

So, anyone care to share why I'm not seeing more than 17Mbps FDX and why later versions of the MikroTik OS are performing worse than older versions?

Hi Belwave,

The difference is you are running Nstreme2 - that's twice the "atheros processing" for the CPU to do on the data than Zorker, who is using one radio with Nstreme.

I have my RB532s now and tested yesterday, and got similar (a bit slower) than Zorker's. I'll post a link to a file with the test results soon.
Mine was bridged with WDS, which might explain a bit of slowness, routed is faster I believe.
RB532 is a huge improvement on the Geode 266 platforms, but people need to be aware the CPU is still limiting for wireless throughput in Turbo mode. An excellent product, well done MT.

MT don't like people advertising non-MT products on their forum, send me a mail and I'll give you info on the Pent M solution.

Regards

My results are off of 2.9.1. I am running in routed mode, not bridge. These were the numbers I was getting (actually a little slower) when they were next to each other in my office. NOw they are mounted outdoors around 2000ft apart I would say. I'm seeing a -27db signal. woohoo.

You will not get correct information if you run the bandwidth test utility on the same RB500 that you are testing -- please remember this!

You should use two other routers to generate and receive the traffic -- that goes through the RB500s.

This has been written to the forum many times and I think it is in the manual also.

John

Hi Belwave,

The difference is you are running Nstreme2 - that's twice the "atheros processing" for the CPU to do on the data than Zorker, who is using one radio with Nstreme.

Wow, that doesn't say much for the NStreme2 now does it... Is it safe to say the NStreme2 protocol is just a little ahead of it's time? What good is it if we don't have enough horsepower to use it? As you suggested I sent you a reply off list.

I'm going to setup two more RB532s with just a basic NStreme1 configuration and CM9s. The drawback to NStreme1 is you cannot bridge across the WLAN and Ether1 Interfaces. With NStreme2 you can bridge across the NStreme and Ether1 Interfaces. What is the workaround this problem and does it adversely affect performance?

BTW, can you run a FDX test and post results on your faster CPU radios?

Many thanks,

Brad

You will not get correct information if you run the bandwidth test utility on the same RB500 that you are testing -- please remember this!

You should use two other routers to generate and receive the traffic -- that goes through the RB500s.

This has been written to the forum many times and I think it is in the manual also.

John

How much of a toll will doing this take on the test? 1Mbps, 4Mbps, 10Mbps? Certainly not 50Mbps! There are claims of 80Mbps flying in here yet my tests have shown far less throughput.

Regardless my tests have shown running the BW test from the RB532 does reduce throughput, but not by much. Probably <5%...

Running the BW test from a P4 3.2GHz MT router to a P4 2.8GHz MT router yeilds about the same as running the test from the RB532.

BTW, any input as to why rc5, rc8 & rc9 are performing better than 2.9 & 2.9.1?

Best,

Brad

John Tully is correct that you should run BW tests through the routers (unless you have massively powerful CPUs, and/or are prepared to accept inaccurate results).
Also I think the "receiving" end of a BW test takes more CPU power than "sending".

I have been planning to do an Nstreme2 test for some time, just haven't got round to it. We do have all the hardware here to do it.
Would you be interested in helping set this up? Results would be interesting for everyone here ... we could put a port in our firewall to allow remote access to the boxes I guess if you would be interested in helping configure them.

Any PC-based router will hit CPU limits quickly as there isn't "parallel processing" to take care of things - it's a single CPU and all the data has to go through it.

Regards

I have been planning to do an Nstreme2 test for some time, just haven't got round to it. We do have all the hardware here to do it.
Would you be interested in helping set this up? Results would be interesting for everyone here ... we could put a port in our firewall to allow remote access to the boxes I guess if you would be interested in helping configure them.

Regards

Sure, I can configure two MTs for an NStreme2 setup fairly quickly. Configure Ether2 or Ether3 as the management port where I will configure the radios from and I will bridge Ether1 to the NStreme2 Interface. Hit me offlist and we can coordinate.

Thanks,

Brad

Hi Belwave,

The difference is you are running Nstreme2 - that's twice the "atheros processing" for the CPU to do on the data than Zorker, who is using one radio with Nstreme.

Wow, that doesn't say much for the NStreme2 now does it... Is it safe to say the NStreme2 protocol is just a little ahead of it's time? What good is it if we don't have enough horsepower to use it? As you suggested I sent you a reply off list.

I'm going to setup two more RB532s with just a basic NStreme1 configuration and CM9s. The drawback to NStreme1 is you cannot bridge across the WLAN and Ether1 Interfaces. With NStreme2 you can bridge across the NStreme and Ether1 Interfaces. What is the workaround this problem and does it adversely affect performance?

BTW, can you run a FDX test and post results on your faster CPU radios?

Many thanks,

Brad

Set up an eoip interface pointing at the other wireless card. create a bridge with the new eiop interface as well as the ether 1 interface and you have effectively brdged the card.

Hi,

WDS is easier to set up, and allows bridging of the WDS interface with the ethernet. I recommend this.

EOIP I tried early on, it caned the CPU on the slow Geode-based system, and the advise from MT was not to use it.
Not sure how that looks on an RB532, but assume it still takes up a lot more CPU time than running WDS.

Regards

Hi,

WDS is easier to set up, and allows bridging of the WDS interface with the ethernet. I recommend this.

EOIP I tried early on, it caned the CPU on the slow Geode-based system, and the advise from MT was not to use it.
Not sure how that looks on an RB532, but assume it still takes up a lot more CPU time than running WDS.

Regards

wds has less overhead than eoip, both protocol and computational.