I've been seeing this topic repeated several times on the forum with no sufficciently good explanation or solution, so don't blame me for reposting, I just want this working.
The problem is the TCP performance over various mikrotik routers.
I've already been solving this once, when I saw that our rb1100's can't really support TCP connection faster than around 5Mbit (UDP went well), it got solved by enabling the correct interface queueing method, as seen here: http://forum.mikrotik.com/viewtopic.php?f=2&t=62377
Some other is here: http://forum.mikrotik.com/viewtopic.php?f=2&t=59830
Our problem is that the same is now happening on slower/simpler machines, especially rb711's and rb433(AHs), where the fix with queue limits doesn't work or even apply (as there's no multiqueue).
For example, we have this setup:
rb433AH ~cable~ rb711 ~wifi~ rb711 ~cable~ rb433AH
UDP bandwidth test between the rb433s measures around 80Mbit (matches the actual wifi performance), single-connection TCP stays at around 15Mbit.
I wanted to rule out the problem with CPU on the bandwidth-measuring machine going 100%, so I connected:
linux box ~cable~ rb711 ~wifi~ rb711 ~cable~ linux box
and again measured only around 15Mbit of single-connection TCP.
I also successfully recreated the problem without any actual WiFi in the way (only a rb433AH forwarding the stuff). Also noticed that when more routers are added to the chain, performance gradually decreases to around 4Mbit.
Fixing and setting the Interface Queues to either sane or anyhow extreme values doesn't help in this case, no matter how it helped with rb1100's and similars.
For the questions:
- Is there some good way to have good TCP single-connection performance on such routers?
Does it look like a regression in v5 only for me, or others also see similar thing?
Is there any good explanation of what is happening that the TCP congestion mechanisms get triggered?
Is there any good debug info I can provide so this can finally get solved&closed&buried?
EDIT: ofcourse everything that would hog CPU is turned off, no bridge, no firewall, no conntrack. No queues except for interface queues. No other traffic. Low route count (only those necessary for testing).