|
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
Stephen
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?
-Charles
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)
-------------------------------------------
CWLab
Technology
Architects
http://www.cwlab.com
| 
