Vsync can do a lot of weird stuff, especially in moments when you are way over or way under the refresh rate of your monitor.

Firstly I would suggest a solid test with Vsync disabled.

Secondly I would turn Vsync on and then see if you can enable triple buffering.

Triple buffering is fairly simple for a driver to do, you can force it in D3D using dxtweaker aswell.

To use Triple buffering in D3D you only need to set up a 3 buffer swapchain using swapChainDesc.BufferCount = 3, after that you can forget about it. Render Targets are not needed for this.

When you swap the buffers the driver shouldn't have to copy the content of the backbuffer to the frontbuffer, it should simply switch it so that the backbuffer becomes the frontbuffer and do rendering in the old frontbuffer. (If you run in Windowed mode there has to be a copy though)

Basically with double buffering you have:

Buffer1 (front)
Buffer2 (back)

You'll render your first frame to buffer2 and when you call present it will stall until the rendering is complete and then wait for a vblank, when it hits it will switch so that Buffer2 becomes the frontbuffer and is displayed while Buffer1 becomes the new backbuffer and your rendering will be done there.

With triple buffering you'll instead have:

Buffer1 (front)
Buffer2 (back)
Buffer3 (back)

There are basically 2 ways these 3 buffers can be used:

1) a swapchain where rendering is done to the 3 buffers in a fixed order and swaps will stall if both current backbuffers contain undisplayed frames. (Less GPU usage, higher percieved input latency(since you'll be displaying the frame you rendered 2 swaps ago instead of 1 swap ago it will take ~33.3ms for the player to see the results of his actions instead of 16.6ms) but you shouldn't get the spikes you might get with doublebuffering since a frame should always be ready and dropping below 60fps won't automatically result in 30fps but can allow you to sit at a stable 55 fps)
2) instant swaps between the 2 backbuffers overwriting undisplayed frames if necessary and swaps the inactive backbuffer(which contains the latest completed frame) with the frontbuffer when a vblank occurs. (Very high GPU usage (unless you're cpu bound), no extra input lag and no freezes, framerates can become higher than the monitors refreshrate even with v-sync enabled (extra frames are just tossed away though))

Source - http://www.gamedev.net/topic/614066-...-time-to-time/

More info on how Vsync and Triple Buffering interact

http://forums.whirlpool.net.au/archive/1717786

Key points to note from the above article.

VSync and Triple Buffering

- VSync eliminates screen tearing.

- VSync caps your framerate to your monitor's refresh rate. Most monitors are 60hz, which means a framerate of 60 FPS.

- Your framerate being capped to your refresh rate does not automatically result in a reduction in smoothness. Without VSync, any excess frames that cannot be displayed by your monitor are simply discarded.
- Enabling VSync by itself can result in drastic framerate dips. If your PC cannot sustain 60 FPS it will drop down to 30 FPS with nothing in between. If your PC cannot sustain 30 FPS it will drop to 15 FPS, and so on.

- Triple Buffering exists to eliminate these framerate dips.

- The Triple Buffering tickbox in GPU driver settings only works with OpenGL games. The vast majority of modern games use Direct3D.

- In order to enable Triple Buffering in Direct3D games that don't support it natively you will need to use a third party program; either D3DOverrider or RadeonPro.

- If you're using VSync with Triple Buffering and a game has an option to cap the framerate, it's best to set the game to render at 60 FPS. This can solve some rendering bugs with some (badly designed) game engines.

I have messed around with triple buffering in the past, but not in BF3, with interesting results. Something to try when you have eliminated other potential bottlenecks etc.