Hi Lonnie,

Would be great to see your test results using smaller packet sizes of
100bytes which seems to be around the average packet size for the majority
of the traffic on my network. This test always seems to have a massive
impact on the available throughput and is currently the reason why we use
StarOS for high speed dedicated private lines but Mikrotik w/nstreme for
anything shared.

Tom, can you confirm if your test RB532's had connection tracking disabled
and cpu set at 330MHz? It has been said a few times that N/Streme2 uses too
much CPU for the RB532 however I have seen much better results than your
tests show using N/Streme and a single CM9. There is a company in the UK
that mass produces outdoor grade Mikrotik solutions with 1GHz x86 CPU's so
that the CPU is no longer the bottle neck. We are in the process of tested a
few off the shelf x86 boards in outdoor enclosures using 56byte random TCP
data in both directions at the same time on a single CM9 in turbo mode and
have been able to get 37-38Mbps in both directions (about 75Mbps aggregate)
which seems to be better than most other more expensive options. These
results don't change if we then use larger packets of 1500bytes.

Cheers,

P.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Lonnie Nunweiler
Sent: 12 August 2006 06:48
To: WISPA General List
Subject: Re: [WISPA] Routerboard 532 and NStreme2

If you are interested, here is the real world test results from my
house to the office through a middle repeater, so it involves 4
Atheros radios and three of our WAR4 533 MHz systems.  The middle
repeater has 4 radios, two of which are used in this test.  The end
points are x86 servers, (a 600 MHz P3 and a 2.4 GHz P4  both running
new V3 x86PC) so the test shows available throughput and does not load
the radios with the speed test software.  Our own speed test shows a
bit higher but is in the right ballpark and also uses tcp.


Lonnie

war-platform ~ > traceroute 10.10.250.254
traceroute to 10.10.250.254 (10.10.250.254), 30 hops max, 40 byte packets
 1  192.168.250.10 (192.168.250.10)  1.017 ms  0.593 ms  0.536 ms
 2  10.10.48.254 (10.10.48.254)  1.426 ms  1.519 ms  1.242 ms
 3  10.10.226.254 (10.10.226.254)  2.176 ms  2.467 ms  2.256 ms
 4  10.10.250.254 (10.10.250.254)  3.058 ms  2.852 ms  2.545 ms
war-platform ~ > iperf -c 10.10.250.254
------------------------------------------------------------
Client connecting to 10.10.250.254, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  8] local 192.168.250.1 port 4716 connected with 10.10.250.254 port 5001
[  8]  0.0-10.0 sec  61.6 MBytes  51.6 Mbits/sec
war-platform ~ > iperf -c 10.10.250.254 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 10.10.250.254, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 10] local 192.168.250.1 port 4717 connected with 10.10.250.254 port 5001
[  9] local 192.168.250.1 port 5001 connected with 10.10.250.254 port 1340
[ 10]  0.0-10.0 sec  25.9 MBytes  21.7 Mbits/sec
[  9]  0.0-10.0 sec  42.6 MBytes  35.6 Mbits/sec
war-platform ~ >
war-platform ~ > starutil 10.10.250.254 he1pm3 -rx
rx rate: 5598 KB/sec  (Press Ctrl-C to exit)
war-platform ~ >

Next week I will upgrade our server 100 km away to V3 for x86PC and
report the results for the following system that goes through 4
repeaters (radio in and radio out mid point) and a unit at each end,
so 10 radios are involved.  The remote server does not have iperf but
I have shown the results of our own speedtest which the first test
shows is pretty close to what iperf will show.

war-platform ~ > traceroute 10.10.29.1
traceroute to 10.10.29.1 (10.10.29.1), 30 hops max, 40 byte packets
 1  192.168.250.10 (192.168.250.10)  1.031 ms  0.683 ms  0.548 ms
 2  10.10.48.254 (10.10.48.254)  1.701 ms  1.253 ms  1.895 ms
 3  10.10.227.254 (10.10.227.254)  2.737 ms  2.982 ms  2.267 ms
 4  10.10.12.4 (10.10.12.4)  3.649 ms  2.653 ms  2.51 ms
 5  10.10.47.253 (10.10.47.253)  4.644 ms  3.539 ms  3.661 ms
 6  10.10.51.254 (10.10.51.254)  5.651 ms  4.832 ms  5.519 ms
 7  10.14.99.254 (10.14.99.254)  7.248 ms  5.907 ms  5.803 ms
 8  10.10.29.1 (10.10.29.1)  7.314 ms  6.75 ms  5.856 ms
war-platform ~ >
war-platform ~ > starutil 10.10.29.1 password -rx
rx rate: 2306 KB/sec  (Press Ctrl-C to exit)
war-platform ~ >



On 8/11/06, Tom DeReggi <[EMAIL PROTECTED]> wrote:
>
>
> Task: Test Max Speed doable using Mikrotik NStreme 2 (two MPCI cards in
one
> board).
>
> test environment...
>
> AMD 3Ghz Laptop wired -> Mikrotik 532 w/ CM9 -> Mikrotik 532 w/CM9 ->
wired
> to HP PIII-800Mhz Laptop.
> Connected in a lab environment, zero noise.
>
> Mikrotik OS ver 2.9.28
>
> Test software 1: IPerf TCP running on both Laptops.
> Test software 2: Mikrotik Bandwidth test running on Mikrotiks.
>
> Test Method 1 (running test to/from Laptops): used about 80% CPU power on
> Mikrotik board to pass the traffic.
>
> Test Method 2 (running to.from MIkrotik): used about 100% CPU power on
> Mikrotik.
>
> However, interesting enough, the results of the speed tests, whichever
> method used, were just about identical, give or take 1 mbps.
>
> The results of tests were....
>
> Maximum speed transferable in one direction 20Mhz channel: 16.6 mbps.
> Maximum speed transferable in both direction simultaneously (adding
together
> the values) 20.8 mbps (13.8 mbps and 7 mbps in the other).
> Maximum speed transferable in one direction 10 mhz channel: 15.8 mbps.
> Maximum speed transferable in both directions 10 Mhz channel: 19 mbps
(10.4
> mbps and 9 mbps)
> Maximum speed transferable in one direction Turbo Mode speed: 18 mbps
> Maximum speed transferable in both direction simultaneously Turbo Mode
> (adding together the values): 22mbps.
>
> Note: Turbo mode tested in two configurations, (A) the lowest 5.8G channel
> send and highest 5.8G channel for receive, and (B) 5.8Ghz to send and
5.3Ghz
> receive.
> Note: All 5.8Ghz test results were at 54 mbps speed modulation, and
setting
> it to slower speed/modulation lowered the test speed results.
> Note: Test performed with RSSI somewhere between -60 and -68, without
> antennas, but w/ high quality pigtails w/Bulk head N, Pointing N
connectors
> to each other.
> Note: Re-tried tests with antennas used, to increase RSSI (-50 to -60 db),
> but it did not improve results.
> Note: All tests done when in NStreme2 mode, using two cards on each end.
> Note: Both boards mounted in Mikrotik Plastic Large Case (sweet cases) and
> using 18V (.8amp) via POE.
>
> One thing that was really odd...  Mikrotik has a value for TX rssi and RX
> rssi. The TX rssi was the exact RX rssi acheived at the otehr radio in all
> cases in any slot, in any configuration.
> However, the CM9 in the TOP Slot of the 532 board consistently showed an
> average of 10 db worse TX RSSI. (sometimes around -75 db).  Swapping TX
CM9s
> did not help. TX from the top slot on either of the Mikrotik CPEs showed
the
> same results.  The only way I was able to make the TX rssis the same on
both
> CPEs simultaneously was to set the BOTTOM port/CM9 on each Mikrotik to be
> the TX radio.  This indicated that the 532 board possibly might have a
power
> problem to the top slot.  In this configuration, at 54mbps, RSSI was about
> -65 TX and RX on both CPEs.
>
> My conclusion of this experiment was that the ideal configuration for a
> MIkrotik 532 board is with 10Mhz channels in NStreme2 mode.
> Because Spectrum efficiency is maximized, Interference avoidance
maximized,
> Cost low, and very little aggregate speed benefit acheived by using the
> larger channel sizes.
>
> My second conclusion was that the 532 router board is inadequate, based on
> processor bottlenecks, to acheive higher speeds than 20 mbps aggregate
> throughput. (LAB test is best case scenario!)
> And if using 20Mhz channels or higher, I don't see the point of using
> Nstreme2, as 1 CM9 in straight 802.11a mode on a 532 board has been tested
> to be able to pass about 14 mbps aggregate.
>
> Mikrotik's website claims that 35 mbps aggregate can be acheived with
> Celeron 700Mhz CPU PCs. Although that is a grand accomplishment at very
low
> cost, there are significant disadvantages of that configuration in real
> world deployments. Such as where do you put the PC in a shared Tenant
> building, so it is close enough to the roof, so the COAX to antenna is not
> going to loose valuable db, or where power is gotten from, or how is it
> going to be rebooted by a customer if the power input is not from
customer's
> suite? I'm sure there are many places that Full Size PCs could be
> appropriate to use, but its not going to be realistic for us, until there
is
> a 700Mhz Celeron able to be POE fed and mounted in an outdoor style CPE
box.
>
>
> What this has done is brought to my attention the value of products like
> Alvarion BH40/BH100s and Trango Atlas PtPs, that can be taken for granted.
> In single radio designs, BH40s usually can push 24 mbps with old 3.0
> firmware, BH100 reported by some in the greater than 40mbps ranges, and
> Trango Atlas PTP easilly pushes 36 mbps in most deployments, using the
same
> tests that I used above.  So Mikrotik 532s are not a replacement for my
> Trango backhauls yet!
>
> However, on a positive note, I liked the Mikrotik Full Size CPE case,
> costing only $45, allowing extra room for cable splicing boxes (to split
POE
> to other radios fed off the Mikrotik's 2nd and 3rd ports) plenty of places
> to tie down pigtails, and easy plastic to drill/make holes for
(non-circle)
> Bulk N-connectors that will not pivote when moving.  I also need to think
> hard that the Nstreme2 -10Mhz channel configuraton might become the
standard
> backhaul configuration to replace slower 10mbps backhauls, doubling
capacity
> in the same amount of spectrum as previous options.
>
> Feedback from others desired.
>
> Tom DeReggi
> RapidDSL & Wireless, Inc
> IntAirNet- Fixed Wireless Broadband
>
>
>
> ----- Original Message -----
> From: Travis Johnson
> To: WISPA General List
> Sent: Friday, August 11, 2006 9:23 AM
> Subject: Re: [WISPA] RouterBoard 532s
>
> Hi,
>
> I never received an email from their support group, John Tully or anyone
> else about this issue. My guess (after a month of no responses) is they
were
> not aware of the issue and are now trying to fix it. It still surprises me
> they have not publicly said anything.
>
> Travis
> Microserv
>
> Eric Rogers wrote:
> Does anyone know if there is a resolution on this issue? If you browse
> Mikrotik's site, the thread has been removed.
>
> Eric
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Sam Tetherow
> Sent: Thursday, July 13, 2006 6:18 PM
> To: WISPA General List
> Subject: Re: [WISPA] RouterBoard 532s
>
> Here is a thread from the MT forums on it.
>
> http://forum.mikrotik.com/viewtopic.php?t=9130
>
> Sam Tetherow
> Sandhills Wireless
>
>
> Mac Dearman wrote:
>
>
>
> Where did you get that info from Travis? Links, source...etc?
>
> Mac Dearman
>
>
>
> ------------------------------------------------------------------------
>
>
> *From:* [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
>
>
>
> *On Behalf Of *Travis Johnson
> *Sent:* Thursday, July 13, 2006 3:58 PM
> *To:* WISPA General List
> *Subject:* Re: [WISPA] RouterBoard 532s
>
> Maybe they pulled them off production due to the NOISE they are
> blowing all over the 50-450Mhz spectrum. :(
>
> Travis
> Microserv
>
> Kelly Shaw wrote:
>
> Anyone know of a source with RouterBoard 532s in stock?
>
> I normally can get them from WispRouter but they won't respond to my
> phone calls about them...
>
> Kelly Shaw
>
> Pure Internet
>
> www.pure.net <http://www.pure.net>
>
>
>
> __________ NOD32 1.1657 (20060713) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
> !DSPAM:16,44b6c32336811364511223!
>
>
>
>
>
>  ________________________________
>
>
> --
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>
> --
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>


-- 
Lonnie Nunweiler
Valemount Networks Corporation
http://www.star-os.com/
-- 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.9/416 - Release Date: 10/08/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.9/417 - Release Date: 11/08/2006
 

-- 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to