Over using the orginal ones?

-Michael

Higher maximum throughput, you can push more packets through it.

cheaper, faster, smaller, more integrated (no need for additional RAM and CF modules), ...

有人使用无线conne的新董事会吗ction yet? Anyone know what the maximum throughput is that it can handle for wireless as it has always been the CPU that has been the bottle neck in the past.

A pair of 220's in a p2p link using WDS over a 802.11a link can handle about 23Mbit in a bandwidth test on my desk. I've seen one report so far that said a pair of 532's (333Mhz) increased that to the low 30Mbit range, but it didn't specify the type of link.

What type of tests gets 23Mb? Is this UDP or using some highly compressable data?

Using the bandwidth test tool built into the O/S. The station doing the testing is an external 1.8Ghz machine and the station being tested is the far end of the p2p link, the near end is wired to 100Mbit lan containing the testing machine. I usually do a UDP receive, then a send, and get roughly the same speed in each direction. Doing a "both" test, I get about half the one way test in each direction.

I should also note that if I use an EoIP tunnel between the two p2p boxes instead of WDS, the speed drops to about 12Mbit. The L3 routing of that traffic really does drag the box down instead of leaving it as L2 bridging with WDS.

The routing does add a penalty.
However with EoIP which is ethernet packets encapsulated over GRE IP packets.
The maximum sized Ethernet packet is 1514 (not including vlan header).
And you have to send this over a protocol that can have a maximum payload of 1460 (that's not counting the GRE header).
This will result in that you need to send two IP packets for a single ethernet fullsized frame. These packets must then be put in their own ethernet frame pr. hop. The fragments are then sent across and the receiving end has to wait for both frames before it can reassemble the single ethernet frame. This incurrs both latency AND it increases your packet count. To top this 802.11 protocol (be it A,B or G) has to ack each frame sent adding more latency (and the odd occurring retransmissions).

BUT it is quite efficient for it's own use (combining two ethernet lans into one over IP).

WDS does add some overhead but this overhead is very little compared to EoIP. First off it's ethernet inside ethernet (so no added IP headers and subprotocol headers). The payload does not need to be fragmented (you can send pretty large ethernet frames over 802.11).

And this is quite efficient for this exact use.

I am currently hoping mikrotik will add oversized frame support for their ethernet cards (and my favourite brand Intel). Intel cards atleast can send ethernet frames up to 2000 bytes in size (and so can many others too). Most mid-level to high-level switches support forwarding over ethernet frames up to atleast 1600 or even more.
If this support was added to Mikrotik RouterOS we could run networks where EoIP would be even more efficient.
Most carriers (around here atleast) support larger frames so they can use technologies like QinQ, MPLS or EoIP like protocols.

The routing does add a penalty.
I am currently hoping mikrotik will add oversized frame support for their ethernet cards (and my favourite brand Intel). Intel cards atleast can send ethernet frames up to 2000 bytes in size (and so can many others too). Most mid-level to high-level switches support forwarding over ethernet frames up to atleast 1600 or even more.
If this support was added to Mikrotik RouterOS we could run networks where EoIP would be even more efficient.
Most carriers (around here atleast) support larger frames so they can use technologies like QinQ, MPLS or EoIP like protocols.

Next beta version will have ability to set higher MTU for ethernet card that support such feature, for example, some Intel Gigabit cards.