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. Lonnie On 6/22/06, Charles Wu <[EMAIL PROTECTED]> wrote:
Screenshot of NMS from full-speed lab testing, 83Mbps UDP traffic with ~20% CPU load http://www.cablefreesolutions.com/radio/HPR%20lab%20testing%20UDP.png Screenshot of NMS from full-speed lab testing, 74Mbps TCP/IP traffic with ~20% CPU load http://www.cablefreesolutions.com/radio/HPR%20lab%20testing%20TCP.png 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 -- 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/
