Thoughts on Bandwidth testing and Mikrotik.
Using mikrotik you can get two very different results depending on if you use TCP or UDP... basically:
UDP will give faster result because it ignores any smaller packet loss and just keep stuffing packets down the link until it is full.. Not a very useful test in my opinion.
TCP has a default settings of 20 individual TCP connections, so its like several PCs working together on the same link, good to see what you may expect from say an office connection with several users (combined usage).
For end user testing I like to use TCP with just two Individual TCP connections, this gives a good indication what a single end user will experience, and will give much the same result as a good speedtest.net server.
Another note, TCP bandwidth testing put more strain on the Mikrotik routers/CPU, and can give a false slow result.
UDP us a fire and forget protocol.
TCP is a fire and wait for an answer that the packet(s) was properly received.
I believe then when a Mikrotik is performing a btest (UDP or TCP), the remote device being tested to is also sending summary packets to the originator of the Mikrotik btest device. The summary packets may include drops, good & bandwidth during the test.
When performing a UDP (receive) btest, look at the "Lost Packets:" count. If it constant changing/increasing number, then your UDP receive btest session is slightly outrunning the throughput capability of the total end-to-end network between both Mikrotik devices. At this point, set your local Mikrotik "Remote Tx Speed:" to a slightly slower speed than what you are actually measuring (about 75 percent) and run the test again. If you still see drops on the UDP receive btest, then try 70 percent. Raise or lower your "Remote Tx Speed:" until you no longer see any errors. This is your clean error-free maximum UDP receive bandwidth rate.
Note: It is normal to see some "Lost Packets:" on the Mikrotik originating the UDP receive btest.
Note: If you see "Lost Packets:" on the Mikrotik originating a UDP send test, or a TCP send-or-receive test, then you may be experiencing some possible network problems.
Note: TCP uses RED (Random Early Detect). When a packet is lost/dropped during transmission and a response was never received, the TCP sending device performs some brief random timeouts and resumes sending TCP traffic at a slightly slower rate. You might want to google "RED -aka- Random Early Detect" and also google "TCP ACK" and google "Delayed ACK".
North Idaho Tom Jones
EDIT: additional notes -
With UDP (fire and forget), it is possible to have more-than-one/several/many UDP packets in transit going through the network at the same time. Example, a UDP packet could be 10 percent through the network and another UDP packet at 50 percent and another UDP packet at 85 percent through the network.
There is no guarantee a UDP packet made it through the network to the remote device.
With TCP (fire and wait for a received ACKnowledgement), (((Not using delayed ACK))), the TCP sending device fires one TCP packet (through the network) then waits for the ACKnowledgement packet before sending the next TCP packet.
There is a guarantee a TCP packet made it through the network to the remote device. If the device sending the TCP packet does not receive a ACKnowledgement packet, then it assumed the packet was lost and may wait a random amount of time and possibly slow down the sending of TCP packets. When all/many ACKnowledgement packets are properly received by the TCP sending device, the TCP sending device may start to increase the speed at which TCP packets are sent.
FYI - most ISP bandwidth governing devices (such as Mikrotik simple-queues for example), start automatically dropping packets when a certain bandwidth is reached. This causes bandwidth to/from an ISP customer to conform to the speed the ISP has the customer set to (RED).
North Idaho Tom Jones