One link (dual mimo antennas, 3km, on each side 20 networks), throghoutput 80Mbit/s.
Second link(one polarized antennas, 2km, on each side 20 networks)

rb433ah(1)----wireless---(one linke)---rb912--ethernet--rb433ah(2)----wireless(second link)----rb711(3)

when I do test from 1 to 2 throughoutput 20 tcp down is 80mbit/s...
when I do test from 2 to 3 throughooutput 20 tcp down is 40mbit/s

when I do test from 1 to 3 throughoutput 20 tcp down is only 20Mbit/s...

why? on all routers are N cards, 6.15 firmware with wireless-fp

..is it possible they are interferring each other in the middle when they try working full speed at the same time ?

one is on channel 5600mhz, another 5320mhz...they are 15cm distance between...

Hi,

check the ethernet connections between routerboards, if the link speed is 1Gbps between Routerboard 1 and 2 , and 100Mbps between 2 and 3 then you could have this problem.

Just to try : force all ethernet connections to 100Mbps FD

Let us know!

Menno

check the ethernet connections between routerboards, if the link speed is 1Gbps between Routerboard 1 and 2 , and 100Mbps between 2 and 3 then you could have this problem.

good hint! ..I've had a similar issue on uplink between Giga Switches (one driving a 100M fiber connection)

I fight this problem for a long time now. It is not ethernet in my case. It is nv2 and queuing. Nstreme was better but do no longer work good with newer versions.

I fight this problem for a long time now. It is not ethernet in my case. It is nv2 and queuing. Nstreme was better but do no longer work good with newer versions.

no solutions by tuning the interfaces queue type? (maybe more queue size..)

I fight this problem for a long time now. It is not ethernet in my case. It is nv2 and queuing. Nstreme was better but do no longer work good with newer versions.

no solutions by tuning the interfaces queue type? (maybe more queue size..)

I tried every queing method and different queue sizes. May be it is how small tcp acks are grouped in nv2 packets.
It adds up with every hop and it is different in up and downlink.

I tried every queing method and different queue sizes. May be it is how small tcp acks are grouped in nv2 packets.
It adds up with every hop and it is different in up and downlink.

If you leave all the rest unchanged and set (e.g.) nstream the problem disappears ?

I tried every queing method and different queue sizes. May be it is how small tcp acks are grouped in nv2 packets.
It adds up with every hop and it is different in up and downlink.

If you leave all the rest unchanged and set (e.g.) nstream the problem disappears ?

No. As I have newer ROS installed nstreme does not work well. I see disconnects. The same
hardware had no problem with nstreme and an older version of ROS. I see good speeds with
nv2 and UDP bandwidth tests. So the capacity and reliability of the links are better now but the
tcp-bandwidth is way below what would be possible.

.. capacity and reliability of the links are better now but the
tcp-bandwidth is way below what would be possible.

wireless-fp pkg have not helped .. thus

I tried every queing method and different queue sizes. May be it is how small tcp acks are grouped in nv2 packets.
It adds up with every hop and it is different in up and downlink.

If you leave all the rest unchanged and set (e.g.) nstream the problem disappears ?

No. As I have newer ROS installed nstreme does not work well. I see disconnects. The same
hardware had no problem with nstreme and an older version of ROS. I see good speeds with
nv2 and UDP bandwidth tests. So the capacity and reliability of the links are better now but the
tcp-bandwidth is way below what would be possible.

did you tried v6.15 firmware?

I would suspect that the difference will be noticed in the wireless connections. What are your modulation and CCQ on the connections?


Joshaven Potter
http://joshaven.com
Sent from my iPhone using Tapatalk

@ste, @rado3105;

Did you guys solve your issues now? Did v6.15 give salvation? How is the situation now? Speeds ok? Or went for other solution?

The problem still persists, I tryed v6.17, v6.18. If traffic goes over more than one router(connected with ethernet cable) throughoutput is abou half....also tryed turn off auto negotiation and fixed 100FD...without success...

can anybody try it and confirm?

@ste, @rado3105;

Did you guys solve your issues now? Did v6.15 give salvation? How is the situation now? Speeds ok? Or went for other solution?

Same situation with 6.15 on some links. Some links are a bit better.

I've ordered some more SAF Links. It feels sane when you install a link
and know exactly what will happen and if something goes wrong you know
it is your fault.
Ordered a test link of a quantenna based equipment.