This is how I explain the current issue that @DJSlanr is seeing:
pi_service seems to aggressively get out of 1/2 rate and into 1/3 rate upon spikes above the 1/2 frame rate threshold, while in fact the majority of frames are within acceptable timings for 1/2 rate.
What @DJSlanr played with earlier was clamping the frame times reported to pi_service to 26.666ms (and not 22.222ms as we previously miscalulated). This effectively completely cut-off all spikes, which forced to remain in 1/2, but it also had the negative effect to stay out of 1/3 even when falling back to 1/3 would have been appropriate.
The better suggestion here is to perhaps add a low-pass filter to smooth out the frame times reported by the SteamVR driver to pi_service and cut-off those small spikes to avoid the fall over. The length of such filter will determine how robust to frame time variations the heuristic will be. It should probably have a few presets, like “Aggressive” (no filter) or “Gentle” (long filter, perhaps 0.5 frame, ie 18 samples in the 75 Hz example above). In Aggressive, you have the behavior we see today, we often regress to 1/3 even for small glitches, in Gentle, the smoothing would remain in 1/2 for longer, but it might also make transitions to 1/3 more visible. This is a trade-off that I believe users on this thread are asking for.