RB 850Gx2 v.6.46.5
Default factory config.
Fasttrack is Active but does not counting packets.
My take is that if counters on rule for enabling fasttrack in /ip firewall filter count traffic, then fasttrack is enabled and is working. BTW, /ip settings print show zero fasttrack packets as well.
For checking the cause of high CPU load you should run profile (/tool profile cpu=all) and check which process actually consumes most of CPU cycles. Non-wokring fasttrack will increase CPU usage of “firewall” process.
First thing I need to turn off is Fasttrack to get QoS and other stuff to work 
This is test setup with default config only.
I just want to test how much traffic 850Gx2 can route.
I have 1Gbps WAN link and with current setup I can only get ~400/400Mbps.
Official test results indicate, that this device can’t reach much more … around 530 Mbps. Without working fast-track it can’t do anything near this speed.
Accordng to official test ~400/400Mbps could indicate that FastTrack is working?
Strange that ipv4-fasttrack-packets: 0 and ipv4-fasttrack-bytes: 0 does not count any FastTrack packets…
Official test results are done on optimally configured devices which includes (working) fast-track. So if in your real-life scenario you’re getting throughput of same order of magnitude as test result, then it means fast-track works.
So yes, it seems that there’s a minor bug in counters you’re referring to …
If you made some changes to /ip firewall filter rule set, then it may ended in a slightly un-optimal state.
Firewall rules are executed against a packet sequentually from top to bottom (until one matches) and it is vital that fast-track rule gets hit first for any packet you want to be accepted. At the same time it is vital to have rules which deal with lots of packets higher on the list. Both rules I just described help to keep CPU load lower and consequentially allow for higher firewall performance. The third rule to keep in mind when ordering firewall rules is that rule with more speciffic selection criteria has to be higher than the rule with less specific selection criteria when both rules match against same packet, otherwise the more specific rule doesn’t get hit at all.
Today I have done some more tests.
With FastTrack OFF I have same results ~400/400Mbps.
From this result I made conclusion that FastTrack is not working.
I gues with FastTrack ON it should deliver much more…
I tried to disable all Default config rules (except 2 rules for FastTrack) but result was the same.
Received answer from support:
Unfortunately, 850Gx2 doesn’t support Fast Path, and in turn, Fast Track is not supported for it as well.
I presume that the fasttrack traffic was not defined at all. The MT documentation (esp. the wiki) lacks/hides this fine print… 
I myself am currently testing/learning the fasttrack thing here and unfortunately encounter some similar illogical problems
I didn’t know this thread already exists, so I had opened another similar thread: http://forum.mikrotik.com/t/fasttrack-wiki-page-lacks-real-world-example-with-filter-and-or-mangle-rules/138983/1
@mutluit how many posts have you opened for Fasttrack ? 
Just 1. Why are you asking?
At least 2… 
Are you trolling? I opened just 1 thread about fasttrack. Just show us the supposedly “at least 2”.
Fasttrack wiki page lacks real world example with filter and/or mangle rules http://forum.mikrotik.com/t/fasttrack-wiki-page-lacks-real-world-example-with-filter-and-or-mangle-rules/138983/14
Also here http://forum.mikrotik.com/t/configuring-the-firewall-in-routeros/138927/39 Configuring the Firewall in RouterOS again there is a discussion of fasttrack…
Ofcorse open as many as you want, i just made a comment and thats it…
The second thread has the title “Configuring the Firewall in RouterOS”. It’s a different thread, even if some postings therein do mention fasttrack.
Hey, man, don’t you have nothing else interesting to do but “nerving” people with such IMO childish nitpickings?
You posted to this thread cross-referencing your other thread. They have similar topics, but otherwise are completely unrelated. Before posting here you even failed to notice that the original poster has already reported that his problem is resolved, and explained what was the problem. You are effectively spamming the forum. And this is not the first time you do that. Please stop.
Case resolved, case closed.