If some bursty traffic comes in via a gigabit link on one port, and leaves via a 100 Mbps link on another port, the buffer inside the switch may become full and drop packets even if average traffic is below 100 Mbps. So, how much traffic can be queued by these switches before they start to drop packets? Would it be better to move the bottleneck to the upstream device by forcing 100FD link? For comparison, what is the ethernet buffer size in RouterOS (upstream device is RB911G-5HPacD, no queues configured, just default only-hardware-queue)? While wireless may not have more than 100Mbps average throughput, aggregated incoming wireless frames might come out as bursts on the ethernet side.

I am experiencing the same issue (fw version 1.14).

With 1G lan and 100Mbps port bursty traffic coming from 1G lan to 100Mbps port generates packetloss very quickly (even with flow control on). This is not a big problem when the link behind the 100Mbps has low RTT (i.e. it's really just a LAN), TCP performs more or less still on 100Mbps (because low RTT sort of compensates for the loss).

But if the link has few ms RTT (i.e. wireless link connected to the 100mbps port), it kill the TCP performance, because TCP backoff keeps the throughput around 40-50mbs.

What's even more strange is that neither Underrun nor Overflow counters seem to be incerementing in the statistics, but the loss is clearly present. Neither does PAUSE statistics increment (it stays at 0), although I'd very much expect it to increase when 1G -> 100M conversion is happening. So it seems like both buffers overflowing and flow control not triggering, but neither is reflected in the statistics.

marekm, have you received any response from Mikrotik support so far?

Thanks.

BTW this can be worked around by shaping the outgoing traffic that's going to end up on the 100Mbps port in case you have a router connected to 1G that can do traffic (and especially burst) shaping.

In my case of a linux router

tc qdisc replace dev eth0.187 root tbf rate 90mbit burst 16kb mtu 16kb latency 10ms

limits the bursts to a level that RB260GSP survives without packetloss that'd have negative impact on TCP throughput, and I get back to 100mbps throughput on the wireless link connected to 100mbps port.

Anyway, this really needs to be fixed in the RB260GSP software.