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: [email protected] > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > > > -- > WISPA Wireless List: [email protected] > > 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: [email protected] 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: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
