Up the physics update rate until it works, it doesn't have to coincide with the framerate. I'd always do my timing like:

physicsStep=10
nextUpdate=currentTime()
while(1){
    while(nextUpdate<currentTime()){
        doPhysics()
        nextUpdate+=physicsStep
    }
    doRender()
}

Even on a mobile phone you'll probably get away with a pretty high update rate.

Up the physics update rate until it works, it doesn't have to coincide with the framerate. I'd always do my timing like:

physicsStep=25
physicsdivider=3
nextUpdate=currentTime()*physicsdivider
while(1){
    while(nextUpdate<currentTime()*physicsdivider){
        doPhysics()
        nextUpdate+=physicsStep
    }
    doRender()
}

Edit: Updated the code to do 120 rather than 100 Hz as that will be a little smoother on screens running 60 Hz.

What happens is that the inner loop repeats until the physics have caught up with the current time, only then is frame rendered. With v-Sync enabled on a 60 Hz monitor the result should be this:

render   00 ms
physics
physics
render   17 ms
physics
physics
render   33 ms
...

With exactly 120 physics updates per second, and 60 render updates per second

If the video card is too slow to do 60 Hz some of the render updates will be dropped, but the physics will still be exactly the same with 120 updates per second.

This only works well as long as the physics can stay comfortably within the allotted time of 8 1/3 ms per updated. You should try timing a physics update to get an idea of how close to being a problem this is.

By the way, I can't find the render and flip commands in your code. In any case, simply calling a sleep 16 ms once for every update is a very poor method of timing, that way you are invariably going to drop frames.