I've had a technician in another market of our's complaining about throughput speeds on the 433GL boards. Such as wireless bridge, slave side, out the ethernet interface.

I just witnessed the same thing, even after upgrading to 5.20.

I have (2) RB/433's at a tower. Once receiving PtP, and another re-sending out to another tower. Both connected directly connected to each in the cabinet via cat5 ethernet.

I just had to replace an RB/433AH, and replaced it with a RB/433GL.

I can push 70Mbps TCP to it, OVER WIRELESS. However, the minute it goes out Eth1 to the other RB/433AH, the throughput DROPS down to 17-20Mbps.

Verified issue, more than one case, easily replicatable. Please fix!

I've had a technician in another market of our's complaining about throughput speeds on the 433GL boards. Such as wireless bridge, slave side, out the ethernet interface.

I just witnessed the same thing, even after upgrading to 5.20.

I have (2) RB/433's at a tower. Once receiving PtP, and another re-sending out to another tower. Both connected directly connected to each in the cabinet via cat5 ethernet.

I just had to replace an RB/433AH, and replaced it with a RB/433GL.

I can push 70Mbps TCP to it, OVER WIRELESS. However, the minute it goes out Eth1 to the other RB/433AH, the throughput DROPS down to 17-20Mbps.

Verified issue, more than one case, easily replicatable. Please fix!

did you try BW test between the boxes? (i.e BW test through the ethernet).

looks like a duplex mismatch.

yep, I lose almost 50% bandwidth or more going just from ethernet to ethernet! this issue reported twice on 2 different setups. definitely something to do with the board..

I can get 89mbps TCP over the wireless link to the 433GL. Pushing the same test THROUGH the GL over the wireless, to another Mikrotik directly connected, TCP drops to 17-20Mbps!!

Running 5.20 didn't help, routeboard F/W is upgraded, not sure what else to think. I will head there in the morning, and put another GL in so they are connected together via GB instead of 100Mb Full. Obviously something is wrong though, this issue was reported in 2 instances on different setups, both having to do with the 433GL.

UPDATE:

BUG FOUND. Switched to Nstreme, I can push 70TCP over the link and out the ether1 port at the tower. NV2, I can push 90TCP over the link but only 17Mb out Ether1!!! Same thing at our location in Ohio!!!

Problem and solution replicated TWICE on 2 setups! Mikrotik, please fix so NV2 bandwidth will go out Eth interface properly!

UPDATE2: Switching from NV2 to Nstreme only "helped", I still don't get full throughput out the eth interface. I can push 70Mb to the GL, but out the eth port to 2nd MIkrotik it slows to 39Mbps, better than 17 though with NV2... I should get the same throughput through the Eth interface as I'm pushing to it over WLAN.

UPDATE:

BUG FOUND. Switched to Nstreme, I can push 70TCP over the link and out the ether1 port at the tower. NV2, I can push 90TCP over the link but only 17Mb out Ether1!!! Same thing at our location in Ohio!!!

Problem and solution replicated TWICE on 2 setups! Mikrotik, please fix so NV2 bandwidth will go out Eth interface properly!

UPDATE2: Switching from NV2 to Nstreme only "helped", I still don't get full throughput out the eth interface. I can push 70Mb to the GL, but out the eth port to 2nd Mikrotik it slows to 39Mbps, better than 17 though with NV2... I should get the same throughput through the Eth interface as I'm pushing to it over WLAN.

1) we do not know details about your setup.
Do you use EoIP (or other) tunnels to achieve transparent bridging? Or are you using only routing?
Do you use any firewall rule? Do you have connection tracking enabled on boxes?

2) again - what is BW test speed from box to box (i.e. ethernet to ethernet throughput)? The would be to know TCP and UDP throughput.

3) what is CPU usage level on both boxes when your problem with low througput appears?

Mikrotik A (bridge) > wireless > Mikoritk B (station WDS) > patch cable > Mikrotik C (bridge) = wireless PtP to next tower

Between A and B, I can push 80Mbps.
Between A anc C, I lose throughput and only get about 17-20 Mbps with NV2, and 40Mbps with Nstreme. It seems to be losing throughput the minute it goes OUT Mikrotik B (RB/411GL).

This ONLY happened since I replaced Mikoritk B from an 433Ah to a 433GL.

I'm going back to the tower site today to:

1. Replace Mikrotik C also with GL, so they together link up at GB
2. If option1 doesn't work, I'm just going to replace Mikrotik B back with a 433AH and bring the GL back and wait for Mikrotik to fix the issue in the next release.

Mikrotik A (bridge) > wireless > Mikoritk B (station WDS) > patch cable > Mikrotik C (bridge) = wireless PtP to next tower

Between A and B, I can push 80Mbps.
Between A anc C, I lose throughput and only get about 17-20 Mbps with NV2, and 40Mbps with Nstreme. It seems to be losing throughput the minute it goes OUT Mikrotik B (RB/411GL).

This ONLY happened since I replaced Mikoritk B from an 433Ah to a 433GL.

I'm going back to the tower site today to:

1. Replace Mikrotik C also with GL, so they together link up at GB
2. If option1 doesn't work, I'm just going to replace Mikrotik B back with a 433AH and bring the GL back and wait for Mikrotik to fix the issue in the next release.

try the ethernet BW test (between B & C). Check the CPU usage level. If the speed is OK then there is no ethernet problem probably.

Note: We don't use WDS - instead we are using EoIP tunel (and pure station mode). The tunnel consumes some CPU cycles and requires some additional config but it allows to create really transparent bridge. If you don't like EoIP use 'station bridge' (Available on ROS 5.X) - if you don't need to read RX signal via SNMP.

try the ethernet BW test (between B & C). Check the CPU usage level. If the speed is OK then there is no ethernet problem probably.

Note: We don't use WDS - instead we are using EoIP tunel (and pure station mode). The tunnel consumes some CPU cycles and requires some additional config but it allows to create really transparent bridge. If you don't like EoIP use 'station bridge' (Available on ROS 5.X) - if you don't need to read RX signal via SNMP.

Between B and C = 60Mb TCP, and 95Mb UDP.
Between A and B = 75Mb TCP, and 101Mb UPD (faster over wireless!?!?)

Also, is there a reason you don't use WDS Bridge > WDS Station? That creates a true transparent bridge. I can push almost 200Mbps on RB/800 boards using it! Your method also requires more CPU, I don't see any advantage..

UPDATE:

Just got back from the tower. Here is what I tried, and found out. Definitely an issue with the GL's and I'll be sending all of mine back unless Mikrotik can release a fix for this ASAP! Sucks to see such a good product not work properly. I really liked the GB ports...

1. Tried swapping Mikrotik C with 433GL, so that B and C were both connected via GB. NO CHANGE.
2. Connected the 2 Mikrtotiks B and C together with Ether2, instead of the POE ports. NO CHANGE.
3. Replaced Mikrotik B back with an RB/433AH. PERFECT. I'm now seeing 40Mbps when I run a speedtest on my laptop. GL's only 20-25Mbps.

DEFINITELY a problem with the 433GL boards. For some reason, you lose a lot of throughput, doesn't matter if its linked at 100 or 1000. I've been slowly upgrading all my PtP's with these, but I'll be sending all of them back, and replace them with 433AH's or 800's if I need the GB ports.

Fair warning, 433GL's even though they have GB ports and same 680Mhz CPU, will give you LESS throughput than a 433AH, for now unless hopefully Mikrotik can find a fix for this, and its at the software level not hardware!

conn track?

I have this same issue with a rb800.

Link is: rb800 fibre connection via ethernet switch plugged into ether1 bridged to wireless nv2 linking to a remote SXT bridged to ethernet.

I can do 97mbps tcp from the rb800 to my laptop behind the SXT

I can do 97mbps from the internet to the rb800

But only 20mbps TCP from internet to my laptop.

That means that the throughput problem is happening in the data passing through the rb800, not to and from it! I am not using connection tracking and have tried all different queue types as a test. I'm actaully running v2.20 on the rb800 because I found nv2 was not freezing on that version. I will probably upgrade to 6.1 tonight and see if it helps.

If your laptop at the end link had GB port then you would be fine. Its only when the setup is like GB>NV2>100mb that the through put takes a crap. Stream handles a little better.

Mikrotik really needs to solve this issue as its effecting everyone's performance that use PtP mikrotiks.

I'm not sure. If I btest tcp from the rb800 itself I get just under 100mbps. Only when I btest through the rb800 do i get 20mbps. Also I didn't mention to keep it simple but it actually goes via two wireless hops over 3 sxt's and they obviously don't have the issue. Just the rb800. And don't forget the rb800 itself can get the full 100mbps. On this particular setup all ethernets are 100mbps btw.

http://forum.mikrotik.com/viewtopic.php?f=7&t=70129

There IS a problem with NV2 when the traffic source on ethernet side changed from GigE to FastE.

If Your ethernet type is same on all devices on a wired segment, it will work.
Like:
Internet feed (GigE) router (GigE) switch (GigE) wireless <~> wireless (FastE) wireless <~> CPE

It will not work, if you connect FE wireless AP to GigE switch.
It will not work, if you have a switch has a gigE uplink.

but if you have a local server (with FastE) what originates the traffic to wireless AP connected with FastE it will work.
(internet will be slow, but speed from local server would be OK)

So keep everything on FastE or replace everything to GigE. Or kick Mikrotik's ass to fix that.

I can confirm this same problem with the RB/411GL. Had to switch back to using nstreme from nv2. My customers about killed me during the process...after recovering from a lightning strike on a backhaul site. Most unfortunate that this information was hidden from those of us trying to improve our networks by jumping to GigE. Not very happy customer for 13 years.

I can confirm this same problem with the RB/411GL. Had to switch back to using nstreme from nv2. My customers about killed me during the process...after recovering from a lightning strike on a backhaul site. Most unfortunate that this information was hidden from those of us trying to improve our networks by jumping to GigE. Not very happy customer for 13 years.

Try setting tdma-period-size=1 (instead of default 2).

not helped. the problem definitely related between NV2 and ethernet PHY (maybe backpressure)

not helped. the problem definitely related between NV2 and ethernet PHY (maybe backpressure)

I see. My setup is like this:

A --nv2-- B --ether-- C
..................\--ether-- D
..................\--ether-- E

A:433, B:433GL, C:SXT, D:Omnitik, E:433AH all of them ROS 6.2. Wireless is 2x2 RB52nM-RB52Hn 40 Mhz only-N.

Results with tdma-period-size=2 were:
UDP throughput A->B is ~60 Mbps but A->C or D or E is no more than 17 Mbps, while B->C/D/E gives full ethernet speed around 96 Mbps.

With tdma-period-size=1 A->C/D/E went to 60 Mbps.

- Measuring from "A" gives incorrect speed, since CPU is overloaded with btest
- thruput for 2x2 - 40mhz should give you ~180mbps

lookup my related posts in the forum, it explains the problem and measurements very well.

Thanks for the tip, but tried setting tdma-period-size down to 1 from 2 ms. Not much change in throughput.

- Measuring from "A" gives incorrect speed, since CPU is overloaded with btest
- thruput for 2x2 - 40mhz should give you ~180mbps

lookup my related posts in the forum, it explains the problem and measurements very well.

I think this is not the case here... A-B PtP is 7 km long. The best I could get on similar links is ~130 Mbps.
That particular tops at ~80 Mbps. During btest CPU is at 50%, btest taking ~5%, wireless ~30% (/tools profile).
Forum is full of posts about correct/incorrect throughput measuring. I've read many of them. But this
does not explain A->C throughput drop. I'm curious if/when Mikrotik support acknowledges the problem.

I have a link in the following setup:

PC Based Mikrotik RB600 -(MIMO 2x2, 40mhz, 15km)- RB433AH -RB493AH-Multiple RB433AHs

measuring from PC to remote RB433AHs (3 in one time) total thruput was ~150mbps
(~90mbps in one direction and ~60mbps on another) - bottleneck was fast ethernet on remote side.

Hello,

Same problem here with a 711G and RB750. do you solved or found a workaround?

Hello,

Same problem here with a 711G and RB750. do you solved or found a workaround?

Is the fully model numbers of 711 and RB750?

RB711G-5HnD and RB750

RB711G-5HnD and RB750

RB711G-5HnD has Gigabit interface while RB750 has 10/100 ethernet ports, so If you read other posts above

http://forum.mikrotik.com/viewtopic.php?f=7&t=70129

There IS a problem with NV2 when the traffic source on ethernet side changed from GigE to FastE.

If Your ethernet type is same on all devices on a wired segment, it will work.
Like:
Internet feed (GigE) router (GigE) switch (GigE) wireless <~> wireless (FastE) wireless <~> CPE

It will not work, if you connect FE wireless AP to GigE switch.
It will not work, if you have a switch has a gigE uplink.

but if you have a local server (with FastE) what originates the traffic to wireless AP connected with FastE it will work.
(internet will be slow, but speed from local server would be OK)

So keep everything on FastE or replace everything to GigE. Or kick Mikrotik's ass to fix that.

Yes, I read the posts. I mean if there is a solution other than replace the hardware..

and what happens if on CPE side i have only FE devices (like laptops or switchs) and from CPE to the interned feed is GigE?

and what happens if on CPE side i have only FE devices (like laptops or switchs) and from CPE to the interned feed is GigE?

For me the more important factor is the network throughput from AP back.... the solution is to have all devices running GigE or until all are GigE, set devices to run at FE setting, I don't like the idea or cost involved to swap all devices to GigE, the vast majority of my CPE installations will not reach or require gigabit speeds.

thank you. So i need to force all GigE to auto-negotiation=disabled speed=100Mbps ?

thank you. So i need to force all GigE to auto-negotiation=disabled speed=100Mbps ?

That is exactly what I am currently doing until complete network sections are fully swapped to GigE.

So here we are, almost 2015 and this issue is still present. Anyone found a workaround?

I'm still having the same issue, and believe I have it narrowed down, @normis @mikrotik

The problem seems to only be when using NV2, and GB interfaces, going over multiple hops from the core. I can push very fast speedtests using the Mikrotik hardware, but REAL throughput is less.

Example: Mikrotik PtP's spanning out over 100 miles, all linked at GB, all using NV2, I can push over 100Mb TCP 150Mb UDP all the way out to the last hop using Mikrotik B/W tests from the core. However, after it leaves the RB1200 at the last tower, linking at the AP's at only 100Mb instead of 1Gb, THAT is where the drop is. GB all the way out then going from GB WAN to 100MB LAN, see only 20-30% of actual throughput.

In short short: GB > NV2 > 100Mb = 50-80% Loss in TCP throughput

Yes Wispwest, that is the source of the problem. And it's there since 2012. But hey, it seems that we are just a few who do not provide gigabit ethernet from the core straight to our end customers. Or maybe the other ones are using different vendors?

Hi @ all,

I think we have the same issues.

So we have a RB711G-5HnD with OS 6.25.

And the connection from AP to Client is 300/300Mbps and CCQ @ 100/99.

But the speed from one station to another station is very pur and highly 50%.

Our technican from the company "meconet" configured the Bridge using NV2.

How do I get a reasonable speed.

So it is unreasonable.

Our employees constantly complain and the workflow will cost too much time.