For those that are interested I conducted a few benchmark tests using two routerboard 230’s. I would have connected the N connectors with a LMR cable for optimal performance, unfortunately I didn’t have any laying around…
Test Laptop Specs:
Pentium 4M 1.7Ghz
256MB RAM
Windows XP SP2
MT Bandwidth test software
In the first test I setup a WDS bridge between MT1 and MT2 (basic PtP setup), NSTREAM disable, 5GHZ Turbo, fastframes enabled. View the results.
Second test same PtP link however I enabled the Senao 200mW card and ran it in PtMP (AP Bridge 2.4Ghz) mode. I then associated my test laptop to MT2 and ran the MT Bandwidth tester from my laptop. View the results.
I ran some other tests however I didn’t take screenshots for them, I enabled NSTREAM and played around with that for a little while, but all NSTREAM did was increase ping times and decrease throughput. NSTREAM requires a more CPU power to reap the benefits of increased bandwidth.
I didn’t test EoIP yet, I may do that later this evening and post more results.
Very interesting - and thanks for sharing those results.
Do I guess correct you had no antennas?
When doing this type of test I found the results sometimes very hard to repeat when just pointing RF connectors (no antennas) at each other - I guess the RF can get messed up without any matched load.
Has anyone tried back-to-back with RF cables? I would have thought this likely to damage the radio cards, you have up to 100mW out coupled directly to a sensitive receiver.
I am planning to get a load of 20dB attenuators and try this with something like 50-60dB inline attenuation. That way we should be getting repeatable results for lab verification and production testing.
For systems where the CPU can be a bottleneck, you must use separate routers to generated and receive the bandwidth test. Otherwise, this info is not useful to plan for real life networking.
In the next version of 2.9rc, we have optimized Nstreme a little so that does somewhat better when the CPU is the bottleneck. In a couple of months, we will have a test-wireless package that should make Nsteme much less CPU intensive.
IMHO Nstreme is one of the “killer features” of MT for wireless apps, and making it more useable on low-CPU power CPE-type platforms will be a great advantage.
Not everyone wants a P4 monster on their mast
Yup, we always do that for tests, through the router, not onto it.
Like john said, we’re all waiting for the “New Nstreme” that doesn’t cane the CPU too much …
