For starters limiting the framerate can cause some pretty stupid microstutter just by how fps limiting and Vsync work.
So you can get around the physics thing by adjusting how often it updates them. Basically, reducing the maxTime seems to allow higher framerates.
I was playing with this quite a bit for ***** and giggles and yes, it correlates and causes the physics issue when a frame happens before an update, meaning more updates has the downside of more CPU load on those havok threads.
I doubt people have hit the limit for the havok threads though.
I have a gsync monitor, two actually. When I adjust the max time to update more often then the framerate of the monitor, the physics behave as expected.
The highest refresh monitor I have a 200Hz panel and it did fine.
Here is the tweak.
The value is basically the reciprocal(1/X) of the maximum refresh rate of the monitor. I'd pad the refresh rate by a little because the only downside that I can imagine is a higher CPU load for those threads.
If people want the method I used I basically left vsync on(gsync FTW), I tested various refresh rates(15, 30, 45, 60, 100, 200) and I played with the value to make a truth table, but the values I used were (0.066, 0.033, 0.022, 0.016, 0.01, 0.005).
If the delay time between updates was too long, I got the whole flickering water/sun/swimming, flying animals, constant jump thing.
I suggest you try it out yourself and draw your own conclusions from this.
Havok is pretty much just in the runtime so I doubt any damage to a save can happen. Although, the position of any objects will be added and recorded of course.
Also removing or increasing the framerate of the loading screens definitely helps with load times. For some reason bethsoft ties loading to framerate, I wonder why this is...