Maybe this is the source for this:
#77

Possible workaround as implied by #518 (I used this instead of GetFrameTimeRemaining for my own use case): Use GetTimeSinceLastVsync in concert with a frame index tracker, where the frame index can be found with GetFrameTiming (m_nFrameIndex member) before and after a call to WaitGetPoses. Then if you can detect whether you're in running start or not (the frame index will change), you may be able to subtract a whole frame's worth of ms to get the value you expected.

Sorry if this is no help.

GetFrameTimeRemaining updates right before WaitGetPoses returns, so it includes the "running start" time and will never actually reach zero. If you have a large running start (e.g. if you enabled Always On Reprojection) you could see up to 22ms time remaining. Similarly, if you drop into Interleaved Reprojection mode, you get an extra frame to render which should be reflected in the reported time.

m_flClientFrameIntervalMs reports the amount of time that has passed since WaitGetPoses returns, and the application calls it again. In a healthy app, I would expect this to be around 3ms. Some Unreal apps take closer to 8ms. Anything over 11.1111ms will cause the application to start drifting behind and eventually start dropping frames once they've eaten through their running start buffer.

The problem is, I tried to use this value to calculate the headroom to submit the next frame. This might not be a standard case, but imagine for example a pathtracer having a valid frame all the time ready to submit. Having more time left would only result in better quality. So the default behavior was really bad, because f.e. the API reporting >11.1111ms when OpenVR assumes to be running in interleaved reprojection is the worst to happen. This lets my renderer think it still has plenty of time left, while it should better submit the frames immediately. Clamping the values or doing some modulo also had odd results. The method naming is not the best here, because it is not what it really does. My renderer can break at any time, but waiting vr::VRCompositor()->GetFrameTimeRemaining() - 1ms resulted in odd stuttering instead. The API simply was assuming to much by its own.

You might have better luck using GetTimeSinceLastVsync then and adding the frame interval yourself.

float flDisplayFrequency = pVRSystem->GetFloatTrackedDeviceProperty( 0, Prop_DisplayFrequency_Float, &errProp );
float flSecondsPerFrame = 1.0f / flDisplayFrequency;

Thank you, but no. This gives also nonsense values. Tried all possible variants but wanted to open only one bug on this.