OVR Metrics Tool is used to measure performance of any application running on your Quest hardware. In its basic form, you’ll be using it to determine the frame rate of your apps with respect to VRCs. The tool also offers advanced tracking to allow developers to better pinpoint and troubleshoot performance issues for their apps.

Under the Settings tab, select Enable Persistent Overlay to allow the performance graph to be displayed on top of the app you’re testing.

There are three available tracking presets under Quick-set Enabled Stats: None, Basic, and Advanced. When tracking metrics, avoid enabling Advanced and use Basic. Advanced adds more overhead and could misrepresent final performance results. It’s used to find GPU bottlenecks in isolated cases. Advanced is unnecessary when checking for performance with respect to VRCs.

Key metrics are:

The App T metric tells you the average time it takes between timestamps for the app to process the graphics work to generate a frame.

OVR Metrics Tool can output data in CSV file format. If you want to save the data, toggle Record all captured metrics to CSV file in the tool, and after a play session, transfer the file to your PC.

You can also record to multiple CSV files in one sitting. For example, if you boot into three games in a single sitting, expect to see three separate CSV files for each of those boot-ups when you connect the Quest to your PC. You can run Excel to plot a scatter graph of “average_frame_rate” against “timestamp” as illustrated below.

The X-axis is the timestamp measured in milliseconds (divide the number by 1000 to convert to seconds). The above example shows slightly over a 10 minute session. Each dot represents an average frame rate from the previous timestamp to the target timestamp.

If the app is still in development, it is advised to run through a level once after a fresh install before judging the performance of that section of content. Shaders are compiled once when you run the app for the first time. Therefore, it can add a one-time overhead that can skew your results. Once it’s compiled, it’s saved on your device until you reinstall. In short, you’ll play the same level twice with the second run offering the most accurate results.

Try and note in your head when levels are loading initially as this will typically show as bad framerate in your CSV file.

On a similar note, an engineer can actually set up the tool to output custom developer data to the CSV to mark key scene transitions. The developer can then accurately track performance around desired events. See “Append CSV Debug String” at Monitor Performance with OVR Metrics Tool for more information.

VRC.Quest.Performance.1 states that: “The app must run at the specified refresh rates.

The application should not experience extended periods of framerate below the requested refresh rate of the display. Exceptions include when there’s a black screen or loading scenes.”

For an app running on Quest (which has a requested refresh rate of 72 Hz), during normal gameplay, a couple seconds of a small ( > 65 fps) dip in performance with a quick recovery that is a one-off incident and not systemic is acceptable. They shouldn’t be cyclical/repetitive in nature.

There’s a one second delay between the overlay result and what the user is seeing on-screen in real-time. Hence, the moment you see a dip in red on the graph, it’ll be useful to note what’s happening on screen from the previous second, and not the exact moment it dipped.

The time is reported as an integer in microseconds, so if you see 6000 it means you are completing work in 6ms. A frame takes 13.8 milliseconds at 72 frames per second (1000/72). If you see App GPU Time go above 13800 you’ll know that part of the frame is bottlenecked on graphics processing (and possibly CPU processing). If the App GPU Time metric is below 13.8 milliseconds (under budget) and frame rate is still less than 72 fps, then you know you have a CPU bottleneck. Noting where the bottleneck is in certain situations can be a huge help.

In short: