When routing traffic across two interfaces, I am seeing better performance with fast path off vs on, which seems backwards to me.
iperf results:
With "/ip settings set allow-fast-path=no"
787+790=1570Mbps
With "/ip settings set allow-fast-path=yes"
862+199=1061Mbps

pathtest results:
With "/ip settings set allow-fast-path=no"
911+911=1822Mbps
With "/ip settings set allow-fast-path=yes"
813+542=1355Mbps

I also see this behavior if I leave fast path on and use an incompatible feature like firewall rules (disabling fast path indirectly).

Export compact shows IP addresses on the two interfaces I am using, plus some things that were never changed like interface names (basically default config).

I have used this same setup for benchmarking other routers, so I have a controlled testing environment. I also noticed similar behavior when I downgraded to rc6

Deleted because not related.

seams like the egress side is not == the ingress side when fastpath turned on so there are packet drops with fastpath on

do you see any drops in statistics?

could you try to test throughput with different MTU sizes using fastpath on/off?

Did you recognized it?
RC9 is out!

http://forum.mikrotik.com/viewtopic.php?f=3&t=69728

Note for Cloud Core Router users: after upgrading, please also upgrade the RouterBOOT with the console command "/system routerboard upgrade"
This is a highly recommended upgrade for all CCR series users.

his post is from two days ago so perfectly valid

I actually wonder how fastpath is implemented without using ASIC chips. Mikrotik added fastpath to almost all currently produced models by a software change. The wiki states that the packets are forwarded without additional processing in the kernel. That would basically mean that:

a) the cpu`s (old MIPSes also) are already IP-aware and can handle forwarding of streams only with little instrumentation from the kernel. I`m not an embedded developer to know the features of chips in detail so please help me out

b) mikrotik uses invisible ASIC or implanted them into each sold RB over the chistmas (</joke>)

c) they use the switch-chip features like src and dst matching and vlans (internally)

For me, c) looks about the most prospective.

But sincerely, if its like that, there are far more limitations (like number of streams, and diferent targets in streams) which apply and these are not the same for all devices.

The CCR could have fastpath done quite nicely maybe as CCR shouldn`t have a switchchip so maybe tile has alredy an ASIC part.

But what about fast-path on older MIPSes? Just an marketing gag or ist it really usable under the documented conditions from here http://wiki.mikrotik.com/wiki/Manual:Fast_Path without any additional restrictions?

I would like to hear a word from MikroTik on that.

When routing traffic across two interfaces, I am seeing better performance with fast path off vs on, which seems backwards to me.
iperf results:
With "/ip settings set allow-fast-path=no"
787+790=1570Mbps
With "/ip settings set allow-fast-path=yes"
862+199=1061Mbps

pathtest results:
With "/ip settings set allow-fast-path=no"
911+911=1822Mbps
With "/ip settings set allow-fast-path=yes"
813+542=1355Mbps

I also see this behavior if I leave fast path on and use an incompatible feature like firewall rules (disabling fast path indirectly).

Export compact shows IP addresses on the two interfaces I am using, plus some things that were never changed like interface names (basically default config).

I have used this same setup for benchmarking other routers, so I have a controlled testing environment. I also noticed similar behavior when I downgraded to rc6

care to give details on config of iperf and anything special about port config on CCR (like being part of bridge, etc)

I actually wonder how fastpath is implemented without using ASIC chips.

http://info.iet.unipi.it/~luigi/netmap/

I am nearly sure mikrotik is most porbably benefiting from this

When routing traffic across two interfaces, I am seeing better performance with fast path off vs on, which seems backwards to me.
iperf results:
With "/ip settings set allow-fast-path=no"
787+790=1570Mbps
With "/ip settings set allow-fast-path=yes"
862+199=1061Mbps

pathtest results:
With "/ip settings set allow-fast-path=no"
911+911=1822Mbps
With "/ip settings set allow-fast-path=yes"
813+542=1355Mbps

I also see this behavior if I leave fast path on and use an incompatible feature like firewall rules (disabling fast path indirectly).

Export compact shows IP addresses on the two interfaces I am using, plus some things that were never changed like interface names (basically default config).

I have used this same setup for benchmarking other routers, so I have a controlled testing environment. I also noticed similar behavior when I downgraded to rc6

care to give details on config of iperf and anything special about port config on CCR (like being part of bridge, etc)

Like I said, very basic setup (only changes made from factory settings were ip addresses on the interfaces), so no bridges involved. The same iperf settings were used with fast path on and off, so I don't see why that matters. I also saw the same results when testing throughput with bandwidth test and pathtest. I did this test with multiple devices across the interfaces. Always slower and less consistent with fast path set to no (demonstrated in the attached graph). I was using TCP with window size of around 256K (bidirectional).

This is in production now and has firewall rules on it. It is running fine since it is such a powerful router, but I just wanted to pass this information along. I figured if I was able to so easily reproduce it, you would be able to too. I can't really take it out of production now to further test or try a new firmware (sorry).