Could you post the versions of your firmware/bootloader please?
(btw. it’s most probably not about RouterOS version, I had the latest 5.21 on everything)
Thanks,
-exa
I’ve tested it with firmware version 3.0.
So have anyone new information about this?
No, and never will be, becouse in “The Lab” everything is ok. So there is no problem. Subject closed. Back off.
OK so that Lab results show in numbers, please!
First of all - DO NOT run traffic to or from RouterOS devices, - routers are all about throughput.
IF you wanna test single TCP connection performance - easy.
Take 2 linux x86 boxes with SSD and fast HDD and configure on one FTP client and on other FTP server, take large enough file and try to download it.
I had to make similar setup that involved chain of RB1100Ahx2 routed like this -
My laptop with Linux ←
← ether1 RB1100AHx2 ether10 ←
← ether1 RB1100AHx2 ether10 ←
← ether1 RB1100AHx2 ether10 ←
← ether1 RB1100AHx2 ether10 ←
<–Linux FTP server
One 4,2GB file was downloaded via single FTP data connection with ~850Mbps average speed
same file, from same server only with ftp client on windows7 running on the same laptop ~420Mbps!!!
It is easy to try it yourself!
OK and where is wireless on RB1100AHx2 (802.11 - halfduplex), discuse begin here tell about wireless behind wireless, what i seen, yes?
Powerfull source and destination? Yes, of course.
We are talking about wireless TCP problems.
Wireless or not - you can’t get proper results if you run test to or from router - you need to run it trough.
That was the point i was trying to get across.
I do not have test setup handy, but im also pretty sure that our clients have high speed TCP connections all the time - i had to make special qos for that.
Problem solved. The problem caused a switch at the top left in the picture. Gigo transition to fast ethernet. TL-SG1016 exchanged for RB250GS. Maybe flow control that could not be turned off and maybe small buffer in a switch that mishandled tcp window size in burst.
If the connections on the switch were not negotiating correctly you have have had one side of the connection running half duplex and the other side running full duplex. That will kill throughput. That condition usually shows up as a spike in late collisions and poor throughput under load.
OK that’s mean is recomended set autonegotating OFF?
I would only set it off if it was regularly failing or causing problems. If an interface sets itself to half-duplex you can usually see that and it is worth checking.
e.g. if two devices negotiate 100 Mbps and full duplex then all is well, but if the negotiation fails and one side senses the other side using 100 Mbps it may well configure itself at 100 Mbps half-duplex. If the other end is running full-duplex then misery will ensue…
More info here:
http://en.wikipedia.org/wiki/Duplex_mismatch
although I don’t think it mentions the condition leading to a mismatch that I outlined above but it does happen. e.g. Cisco switches will select half duplex on 100 Mbps ports if the auto-negotiation failed and they sense the line speed.
I did not write anything about the half-duplex connection!! Do not twist my words.
I did not twist your words. I was pointing out that a Gigabit interface which ends up running at 100 Mbps because it senses that speed rather than negotiates it may well set itself to half-duplex. I have no idea if that actually happened in your case but it is a useful possibility to bear in mind.
Hey guys! this is not solved, I don’t have any badly configured switches in the way (particularly, absolutely no switches!) 
Anyway, I’m also starting to think that this is at all times a weird combination of several unpleasant issues (signal, configuration, bad weather, switches, cables, slower routerboard, …) than a general error. It just still “triggers” this much annoyingly, and the explanation doesn’t really fit the lab setup… Any general point where to start debugging such stuff would be great.
What we have here performs great:
Linux machine →
Netgear managed switch →
*Juniper SRX210 router →
Netgear managed switch →
*x86 machine with RouterOS 6.0rc6 and AR9380 wifi →
(wireless)
*RB600A with RouterOS 5.22 and AR9220 wifi →
*RB450G with RouterOS 5.1x–>
RB250GS →
Linux server →
Linux VM
*=routing through OSPF.
We get speeds of 185mbit/s single TCP session using iperf.
And with Windows filesharing about the same speeds.
Hi,
i have same problem on 3 x RB433L. can’t pass over 10 mbps TCP single connection over ethernet. UDP is 100 Mbps. Any solution?
All Mikrotik customers waiting for new wireless drivers for routeros included in new version MT? 
I had a very similar problem: UDP Bandwith test was super, but TCP test quite bad. Problem was a poor network cable connection. Check the statistics-page of the 100MBit FDS (the right RB711G). This was mine:
/interface ethernet print stats
name: ether1-local
rx-fcs-error: 234
rx-align-error: 37
rx-fragment: 1
rx-length-error:8
rx-jabber: 306
rx-drop: 579
tx-too-short: 16 466
Leo.