jit.phys.world physics frame rate, response, maxsubsteps, and fixedtimestep

I request insight into jit.phys.world maxsubsteps and fixedtimestep so that I can get a super responsive simulation.

I have a ragdoll simulation and while debugging use jit.phys.picker to throw it around. I have noticed a very discernible difference in the responsiveness of the visible framerate and the perky/sluggishness of the picker manipulating the ragdoll.

I am unable to match observed behaviors against the max reference documentation. Here are my questions/observations.

I have my qmetro driving my jit.gl.render at 34ms.

At jit.phys.world defaults of fixedtimestep=60 and maxsubsteps=1, the gl frames remain near 34ms but the responsiveness of the ragdoll to my mouse movements via jit.phys.picker is sluggish.

If I change the fixedtimestep=200, the ragdoll is more sluggish. This would be opposite my expectation given the Max documentation which writes "decreasing this value increases the resolution of the simulation". Instead, it seems that now the physics engine is internally calculating many 60->200 more simulation steps. This seems to be increased resolution with increased fixedtimestep.

If I change the fixedtimestep=2, then the ragdoll tends to fall apart and I can easily see there are very few (2) frames of position data being updated. There is some curious interaction of this low fixedtimestep where gravity seems to be pulling the ragdoll apart but the hinges are not keeping it together in a similar way.

These two observations lead me to believe that the documentation is self-conflicting. Is this true? I think that the fixedtimestep value represents a Hz and that decreasing this value DECREASES the resolution of the simulation

Next, is curious the interaction of maxsubsteps. If I understand the docs and my observations, this value is a mechanism which allows the OpenGL bodies position/rotation updates (manual via bang or automatic via jit.gl.render) due to the physical world calculations to be tightly bound (maxsubsteps=1) or loosely bound (maxsubsteps>1). It seems to sip over or discard these physical world calculation snapshots happening by default 60Hz. It is similar in how qmetro will help keep up the GL framerate by discarding work.

Is this paragraph above correct? What is curious to me is what I observed. If I set fixedtimestep=30 and maxsubsteps=29 I do get a more responsive ragdoll to my mouse interaction. Even better, is to set fixedtimestamp=60 and maxsubsteps=59. Then I get a really great super happy responsive ragdoll. But I don't know why and therefore am still guessing at how to optimize.

Here's my inquiry: I would think with fewer physics calculations (only 30 in the first case) the Max would have less work to do and therefore always have a physics world ready every 30Hz (which is exactly the same as the 34ms of the jit.gl.render asks).

Insight?