Charles, I just wanted to make sure you disable connection tracking.
It is not required for a bridge or backhaul situation and you'll see a
few per cent better throughput.

Also, our routed performance exceeds the bridged throughput, so the
best is using routed without connection tracking.


On 6/22/06, Charles Wu <[EMAIL PROTECTED]> wrote:

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?

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

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:



Lonnie Nunweiler
Valemount Networks Corporation
WISPA Wireless List:



Reply via email to