Hi Ste,
I had a search for what you're referencing - presumably you're talking about issues like this:
http://forum.mikrotik.com/viewtopic.php?f=7&t=91134
Obviously there's an issue with some variant of configuration, but have to say I haven't experienced this myself. Maybe it only occurs with 3+ hops, but I have tried this out just today on a 2 hop NV2 to NV2 link and had no issues with throughput using 1 TCP stream. Tested with both bridged and routed setup on v6.22 throughout. Admittedly I only had RB's to test with and (as expected) CPU maxed out when running a TCP bandwidth test, but I was happily passing circa 80mbps when the CPU hit 100% over a 2 hop path that I know can only achieve 95mbps max (one device is a SXT Lite5 with 100mbps ethernet). Exact setup was SXT ~~wireless~~ SXT --wired-- SXT ~~wireless~~ SXT
This said, I have the two SXT's in the middle connected via an RB260GSP and for a while I was seeing collisions on a supposedly full duplex link along with the expected poor performance under load. A reboot of the RB260 fixed that and afterwards all ran at full speed. TBH, there seems to be a lot of instability in the low-end switch products when it comes to mixed 100mbps/1gbps environments, so this doesn't surprise me too much.
Like I say, there's obviously a variant of config that is problematic (as you've experienced), but I don't think there's an automatic blame on NV2. Andy should still run through a proper diagnostic process, and if it does turn out to be NV2, then maybe an analysis of the config would be in order to see how it differs from users who don't have any issues.
Andy, FWIW I've also had this running with good speeds with much the same setup - OSPF+MPLS+VPLS and running PPPoE over the top. Only 2 wireless hops, both running NV2. No WDS (don't believe you need it if you're running MPLS or routing).
There was some talk about NV2 not being "tuned" for AC yet - not sure of the status on that. My setup has some AC's, but connected to SXT-N's so everything running in N-only mode. I think you need to at least find the first place where the speed starts to drop - it will reduce the number of parts you need to debug.
Rich