In my company we are using bullet (obviously

We are using really long chain of RB-s with big mass ratios connected with 6dofs.
One of my first problem was that when I pull one side of the chain it takes N steps before the last element starts to move. Where N is the length of the chain.
So I forcefully activated all of the joints, but because of that I have lost the freedoms.
I solved this by calculating two type of errors one for the lo limit and one for the hi limit.
During solving (in resolveSingleConstraintRowGeneric) if the deltaVel1Dotn+deltaVel2Dotn (actualimpulse) is between the two errors then I don't change the constratint (deltaImpulse:=0) otherwise I set the deltaImpulse to "compensate" the actualimpulse up to the point where it reach the limit.
(for exmaple: if (actualImpulse>c.m_rhsHi) deltaImpulse = c.m_rhsHi - actualImpulse;)
With this little modification I could achieve a big step towards stability.
It is clear that the average performance became worse, but the worst case is slower only a tiny bit. (and that matters for us)
Another comment: obviously increasing the iteration count in the solver should make everything more stable, but actually it explodes the simulation (even with doubles).
The reason of that: the compensation impulses became so big for one frame at the beginning that one of the RB moves through not just the neighbor body, but even the next to that and the penetration compensation makes everything super crazy.
This trick solves this problems automatically, because when every RB moves from the beginning the relative speeds became much smaller.
so I can now increase the iteration count wildly. (though the final solution became the NNCG)
I have checked a lot of paper, but I couldn't find similar solution.
Is it something very trivial that is why nobody mention it or It is just me who didn't find a good paper from this?
Best Regards
Gabor