Title: Message

Could you share retail pricing on your products? I don't see any pricing listed on your website. I'm sure many people (including myself) could be interested in getting more information, etc. but it's nice to see if the product is even close to the price range we are looking.


Stephen Patrick wrote:
Hi Charles,
Well I can't comment on what software Alvarion uses - they of course can.
Sure we can share more information with people on our solution.  It uses a passively-cooled, 1GHz CPU in outdoor grade housing with a powerful architecture capable of driving 5 radio cards with over 200Mbps bridged wireless-ethernet throughput demonstrated in P2MP configuration.
It has both 10/100 POE and Gig-E ports.  Several users tell us that's a pretty unique solution on the market just now.
The Routerboards are great, but are optimised for a completely different cost/performance point. Apples and Oranges.
You are right that on slower platforms, the "software overhead" of Nstreme actually reduces net throughput, i.e. CPU is limiting and the extra processing slows things down.  On our boxes the opposite is true, the radio cards are the limiting factor and we can extract the very last bps/pps from them.
Re: your comment about MT's documentation, we have our own user manuals for customers, to support our product range.
Nstreme "repackages" the data into frames, which with polling greatly improves P2MP performance as well as the huge improvements seen on P2P links.  This is reality not myth.  I'd strongly recommend trying the solution "for real" rather than "believing the vendor" (us in this case).
Coupled with a MT-based CPE (we have our own also, now at pretty aggressive prices in volume) you have major benefits in a P2MP environment and the security improvements that are inherent with the "proprietary extension" nature of Nstreme - you can't see or connect to it using a WiFi or "Brand X" client.
I am sure other users can comment on the latest StarOS versions, but AFAIK that uses "plain vanilla" 802.11a with the Atheros WiFi extensions.  That isn't the same, MT's Nstreme adds a completely new layer, with "small packet performance" being a major benefit, as other users commented.  I think Lonnie is on this list and can comment on the latest in StarOS/StarVX.
Best regards

-----Original Message-----
From: Charles Wu [mailto:[EMAIL PROTECTED]]
Sent: 23 June 2006 00:49
To: 'WISPA General List'
Subject: RE: [WISPA] frame size and fps - was OT: about 70Mbps for under $ 6K

Screenshot of NMS from full-speed lab testing, 83Mbps UDP traffic with ~20% CPU load
Screenshot of NMS from full-speed lab testing, 74Mbps TCP/IP traffic with ~20% CPU load
Hi Steven,
Wouldn't it be funny if the Alvarion product was actually Mikrotik Nstream? <ducking>
On or offlist, I am curious if you'd be willing to share your settings required to achieve this (both hardware and software)
38 Mbps TCP throughput on a 20 MHz channel w/ 54 Mb air rate is quite impressive, and I would like to try to duplicate these results if possible (I'd more than happy to share our testing scripts, platform, etc)
Thus far, our Mikrotik testing has been limited to routerboards, and it seems that the limited processing power on the routerboard prevents us from seeing the benefits Nstream (our current testing w/ Nstream has actually shown decreased performance as opposed to just straight WDS bridging, but we are by no means Mikrotik experts)
That said, compared to the rest of Mikrotik, the documentation surrounding Nstream is a bit sparse -- looking at what is available, it seems to me that most of the performance gains of Nstream are achieved through "fast-framing" -- e.g., it looks like Nstream utilizes combination of timing modications and frame concatenation to increase throughput by transmitting more data per frame and removing interframe pauses.  My understanding of this is that Nstream is bundling several frames (depending on settings, default of 3200 looks like it has enough space for 2 frames) together into a single larger frame; in the case of 2 for 1 bundling, this would essentially halve the amount SIFs and ACKs that the protocol has to transmit for a given payload
So a few observations/questions for either you (or maybe John will speak up?)
1. Nstream has the ability to set this framing concatenation mechanism (via framer-policy attribute) to none -- if this is set to 0, will there be any performance differences b/n Nstream and "standard WiFi"
2. What are the parameters for the framer-limit setting (if 3200 lets me concatenate 2 packets, wouldn't 5800 work even better as I would be able to concatenate 3 packets and eliminate additional overhead?)
3. While frame concatenation does improve throughput for low density situations -- in high density PtMP situations, we've seen multiple small packet streams basically bring polling-based systems to their knees -- is there any data, testing, experiences on this side w/ Nstream?
4. What about bursting? The DIF is another major point of "waste" in 802.11 systems.  Is the DIFs automagically eliminated due to the fact that a point coordinator is being implemented or is this done via the burst-time command under the wireless interface?  If so, is there a way to turn this off for point-to-point situations to achieve better performance?
P.S. -- Our testing of StarOS using WDS bridging on the 266 MHz IXP Boards is yielding ~36 Mb of TCP throughput on a single 20 Mhz channel (this is w/ bursting & frame concatenation turned on)

Technology Architects

WISPA Wireless List: wireless@wispa.org


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

Reply via email to