I want to make point-to-point link with two rb133 (not 133c) with RB52 mPCI cards. The distance is ~300m, the air is totally clean, no noise no other 5GHz link in the near. I’m using 16dBi antennas. The problem is only 10Mbit can transfer between the other side.
PC (2.8GHz-MT2.9.40)—RB133–(wireless)–RB133–PC(2.8GHz-with windows bandwith test)
I try all modes, nstreme, without nstreme, turbo-mode, no turbo-mode, small tx power, high tx power, mt2.9.41, mt3.0b6 etc, but all of time the maximum bandwith is only 10Mbit/s receiving.
I see this pdf and hope I make something wrong, because I see up to 50Mbit(!) on this document!
Have you ideas, what do I wrong?
10mb is the best I have been able to make using any combo with a RB112. The problem is always the cpu is at max usage. The easy fix for this was to use rb532’s instead on all backhauls.
document is real test under real conditions here in mikrotik, Uldis can post testing details when he reads this. bear in mind that this result will change once you use firewall, queues, nat, or do some kind of accounting/logging etc. for best results, disable connection tracking (if you don’t use firewall, mangle or nat).
I try all of possible things Switch off conntrack etc. No firewall, no queue, no mangle, only pure routing.
I see only one different thing between your and my test. I’m using 2 rb133’s and you used one rb122 and one PC. I don’t believe rb133 is not enough cpu power, because with a pc can up to 50Mbits transfer. Ok, I accept that the rb133 is not a power board, but why 10Mb is the limit all of case? The bus speed is enough, because your test approve more-more speed. The card is same as your test.
Unbelievable!
If you have a little time please make a test between 2 rb133 and document it I wondering your results.
you have to test PC–>RB–RB–>PC because to run bandwidth test, a lot of CPU power is required. you are wasting all your resources to start the bandwidth test.
Yes, PC->rb–rb->PC
The btest server run on the first strong pc (with mt2.9.41 now), not on rb! The btest client on the second strong pc (with windows btest client). The two rb is only “gateway”. What is different for the rb’s between real data flow and btest (tcp) data flow?
It really would be nice to see the configurations used when doing these tests… Maybe have it on the wiki? I would enjoy being able to reproduce the speeds you have reached, when i’m doing demos for my customers..
I have the same results when routing traffic from PC1 to PC2 with the RB133c and the R52
Eg 10 Mbit/s TCP traffic and CPU is at 100% on both RB133c
If I set the Radios up in WDS and create a bridge, I can get about 14Mbits/s from PC1 to PC2
While in a routed setup if I do a bandwidth test from the first RB133c to Wlans2 IP I get about 40Mbits/s which is closer to the documented through put, however this is just the radio performance.
It appears that this high speed radio performance is not usable as the CPU in the RB133c doesn’t have enough grunt to either bridge or route the traffic out an Ethernet port.
Can someone please confirm the MAX real throughput from the Ethernet out the Wlan interface, this should be documented on all of the routerboards, so people can make an informed decision about which product is going to suit their bandwidth requirements.
Take the 133 Board, 3 Ethernets and 3 MiniPCI slots, it seems if you want to route a total of more than 10Mbits/s across all the interfaces, you might want to consider I higher speced board.
Or in my case if you want to get higher threw put than 14Mbits/s bridged, out of a 133c in a Point to point setup, you will want to consider a higher spec board.
Very frustrating and annoying that this has to be found out by trial and error!
we are talking Ethernet here, Ethernet throughput can reach 100mbit no problem. it all depends on your configuration, turn off NAT,Firewall and Conntrack (important!) and this will increase your performance a LOT
no other 5GHz link in the near. I’m using 16dBi antennas. The problem is only 10Mbit can transfer between the other side.
I wondering your results.