Analysing frametime consistency and 1% Low FPS using NVIDIA FrameView

Introduction

NVIDIA FrameView can record average FPS, 1% Low FPS, 0.1% Low FPS and detailed per-frame timing data. These measurements can help you investigate stuttering and compare system configurations, performance profiles and graphics settings.

This guide explains how to configure NVIDIA FrameView, record comparable benchmark runs and perform a basic analysis of the generated CSV files. It is intended for beginners, but the resulting logs also contain detailed data suitable for more advanced analysis.

What is 1% Low FPS?

Average FPS describes how many frames were produced per second across the complete test period. However, it does not show whether those frames were delivered at consistent intervals.

Each frame has a frametime, measured in milliseconds. A longer frametime means that the corresponding frame took longer to appear.

Reference table:

NVIDIA calculates 1% Low FPS by taking the slowest 1% of frames and averaging their performance.

The closer the 1% Low result is to the average FPS, the more consistent the frame delivery generally was. A large gap between average FPS and 1% Low FPS can indicate recurring slow frames or visible stuttering.

The 0.1% Low value focuses on an even smaller group of particularly slow frames. It can help identify severe but infrequent interruptions, although it is also more sensitive to isolated events and short test durations.

1% Low performance can be affected by many parts of the system, including CPU performance and cache, system-memory latency and bandwidth, shader compilation, asset streaming, storage activity, graphics drivers, background applications and the game engine itself. GPU limitations can also affect the result, particularly when the GPU is operating near full utilisation.

Should I worry about 1% Lows?

A certain amount of frametime variation is normal. No game delivers perfectly consistent frames at all times, and occasional short stutters can occur due to scene changes, asset streaming, shader compilation or background activity. A single frametime spike or an isolated low result is therefore not necessarily cause for concern.

The purpose of this method is not to over-interpret individual measurements, but to compare repeatable runs and identify whether specific settings, performance profiles or system configurations have a meaningful and consistent effect on frame pacing.

Where to find NVIDIA FrameView

NVIDIA FrameView is located here:

• https://www.nvidia.com/en-us/geforce/technologies/frameview/

NVIDIA FrameView used to be only available as a stand-alone app for expert users, but it is now also integrated into the customer-facing NVIDIA App. The standalone app might have some more advanced features, so we will continue to refer to the dedicated version of NVIDIA FrameView.

Compatibility

Despite its name, NVIDIA FrameView is not limited to NVIDIA graphics hardware. It can be used on any laptop or PC with GPUs from NVIDIA, AMD or Intel.

Some GPU telemetry, such as GPU power and temperature are only logged on supported NVIDIA hardware. However, all the core functions, such as FPS, 1% Low FPS and frametime logging are broadly compatible across all systems with NVIDIA FrameView.

Tool comparison

NVIDIA FrameView is not the only software solution to measure frametimes and 1% Lows.

For ease of use and best compatibility with the latest NVIDIA features, we recommend NVIDIA FrameView.

How to produce comparable results

Capture the same scene

If you plan to compare different configurations, profiles or settings, then every run must cover the same game sequence. Use the same camera path, route or built-in benchmark and keep the capture duration consistent.

Do not include loading screens, menus, cutscenes or transitions unless those are specifically part of the issue you want to investigate. Even a few seconds of unrelated content can significantly affect 1% Low and 0.1% Low results.

Perform a warm-up run

For each configuration, we recommend performing two runs without closing the game in between.

Use the first run as a warm-up. This allows the game to perform shader compilation, load assets into memory and initialise other resources. Ignore this run when comparing final results.

Use the second run for the actual measurement.

After confirming that the first and second runs produce practically identical results in a particular game, you may decide that a separate warm-up run is no longer necessary. However, this should not be assumed without checking.

Notes on presentation-related graphics settings

Before adjusting in-game graphics options such as texture quality, lighting or shadows, first review the global settings that affect frame presentation. These settings can have a major impact on the validity of your test and may even make the results unsuitable for performance comparisons.

The most obvious example is V-Sync. It limits the frame rate to the display's refresh rate or, if the system cannot sustain that rate, to a lower fraction of it.

For example, on a 240 Hz display, a configuration that can sustain only around 200 FPS may be limited to 120 FPS when V-Sync is enabled.

This artificial frame-rate limit can produce very stable 1% Low results, but it does not reveal the actual performance differences between configurations or graphics settings.

Please refer to the following table for guidance on the relevant presentation-related settings.

Special case: DLSS Dynamic Multi Frame Generation

NVIDIA currently states that DLSS Dynamic Multi Frame Generation is not compatible with V-Sync or external frame-rate limiters. When using this mode, configure its target frame rate through the NVIDIA App and keep the same target throughout the comparison.

Change only one variable at a time

When comparing configurations, change only the setting you intend to test. Keep the game version, save game, graphics settings, display mode, resolution, driver version, Windows power mode and laptop performance profile unchanged.

Record these details together with the results. A benchmark value without its corresponding configuration is difficult to interpret later.

How to record a benchmark

Follow these step-by-step instructions:

Setup:

• Download and install the standalone NVIDIA FrameView application.
• Start FrameView and select the folder in which the benchmark logs should be stored.
• Select a benchmark hotkey. FrameView supports F10 and Scroll Lock. We recommend F10, provided you don't need that key for any vital in-game function.

Run:

1. Start the game or benchmark
2. Load the scene you want to measure. You will see an overlay in the top-left corner of the screen.
3. Wait until loading has finished and the interactive 3D scene is running.
4. Press the benchmark hotkey immediately after the intended starting point.
5. FrameView plays a notification sound. The overlay disappears during the capture to reduce measurement overhead.
6. Play or observe the predefined benchmark without interrupting the sequence.
7. Press the benchmark hotkey again immediately before the sequence ends or before the game returns to a menu or loading screen.
8. If this was your first run (your warmup run), go back to Step 2 and repeat.
9. Exit your game and open the selected benchmark folder to access the results.

FrameView creates a timestamped log for the individual capture and adds the run to its summary file. If you made two runs, disregard the log of the first capture.

Advanced capture options

Capture duration

If the benchmark has a fixed and reproducible duration, enter a capture-duration limit in FrameView.

You must still press the benchmark hotkey to begin the capture, but FrameView will stop logging automatically after the configured number of seconds. This avoids small timing differences caused by manually ending each run.

To make use of this feature, use a stopwatch during a trial run and determine exactly how many minutes and seconds the benchmark sequence runs for.

Capture delay

Capture delay postpones the start of data collection after you press the hotkey.

A delay of approximately 3 to 10 seconds can be useful when you intentionally want to measure steady-state performance and the beginning of the scene always contains an unrelated transition or one-time hitch.

This feature can also be used to automate benchmarking. Assuming loading a benchmark or save state always takes the same amount of time, you can trigger the capture and loading at the same time, and the capture will only begin after the predetermined delay, by which time the benchmark sequence should already be running.

Reviewing and analysing the results

Overview

FrameView creates two types of CSV file. Both can be opened in applications such as Microsoft Excel, LibreOffice Calc or Google Sheets.

FrameView_Summary.csv

FrameView_<Application>
_<Date_Time>_Log.csv

The summary file is usually sufficient for an initial comparison. However, aggregate values cannot show when a slowdown occurred or whether slow frames appeared as isolated spikes, repeated interruptions or a longer period of reduced performance.

For this more detailed analysis, use the corresponding per-frame log.

How to organise the results

Think about how you plan to organize your data before collecting a large number of runs. Tips:

• Create one folder for each configuration and move the corresponding summary copy and detailed logs into it. Name the folders according to the tested profile or setting.
• Maintain a separate spreadsheet containing the timestamp, configuration and relevant results from each run. This is the safest method for larger comparisons.
• Create a working copy of FrameView_Summary.csv (save as new file in your spreadsheet software's native format) and add a column containing your own notes, such as the performance profile, graphics preset or test scenario. Avoid relying on memory or file order alone.

At minimum, ensure that every log can later be matched to the exact configuration that produced it.

Besides the granular documentation of compared settings, you should also write down global parameters such as:

• BIOS and EC version
• NVIDIA driver version
• In laptops: whether NVIDIA Optimus is enabled or not (MSHybrid vs. dGPU-only)
• Selected performance profile
• Game version or patch/build date
• Presentation-related settings such as resolution, display mode, G-SYNC, FPS limits, etc.

How to open the CSV files

Please see instructions in this separate FAQ article:

• Analyse logfiles in Microsoft Excel (for experts)

Besides Microsoft Excel, the same procedure can also be followed in Google Sheets or any other spreadsheet software.

Reviewing summary files

Beginning with the summary file, compare the following values:

Here, the differences in "1% Low" and "0.1% Low" between different runs should already correlate with the settings you chose.

Analysing individual capture logs

When analysing the logs of individual captures, please take note of these key data points:

MsBetweenDisplayChange

MsBetweenPresents

We recommend looking at "MsBetweenDisplayChange" first, as it most closely reflects the frame pacing experienced by the user. "MsBetweenPresents" can then be used for comparison to determine whether irregular frame delivery is already visible in the application's frame-submission cadence.

If "MsBetweenPresents" is smooth while "MsBetweenDisplayChange" shows stutters, the irregularity was likely introduced after the application submitted the frames. Possible causes include GPU rendering delays, driver-side frame pacing, frame queues, the Windows compositor, V-Sync or VRR behaviour, and Frame Generation. This comparison can therefore help narrow down the affected part of the graphics pipeline, but it does not identify the exact root cause on its own.

Creating a frametime graph

A frametime graph can reveal information that is hidden by the summary values. For example, two runs may have similar 1% Low FPS while one contains a few severe spikes and the other contains smaller but more frequent fluctuations.

Lower and more consistent frametimes are better. Large upward spikes represent frames that took longer to display.

Instructions

How to generally build graphs from CSV logdata is detailed in the "Analyse logfiles" article linked above. Here is a short run-down for frametimes:

1. Open the detailed log and save a working copy as an .xlsx file.
2. Delete all columns except MsBetweenDisplayChange, and (optional) MsBetweenPresents and TimeInSeconds
3. Select the relevant column(s).
4. Use the "Insert" menu to create a line chart from the selected data.

If you wish to compare frametimes from multiple runs, copy the "MsBetweenDisplayChange" column from the other logfiles, insert them into your worksheet and make sure to rename the column headers to indicate the data origin (i.e. what setting was different between these runs).

The "TimeInSeconds" does not need to be selected, as Excel may use it as an additional line, instead of using it as base for the horizontal axis. If you do not select TimeInSeconds, the horizontal axis will be labelled with the number of each data point (i.e. the number of each generated frame.

Example graph

This is an analysis from 2022 where we compared the frametimes of CS:GO on an RTX 3080 Laptop GPU in three fundamentally different settings:

• MSHybrid without CASO
• MSHybrid with CASO
• dGPU-only

Basically, we compare the frametimes between NVIDIA Optimus enabled and disabled. See also:

• In which XMG laptops can NVIDIA Optimus be disabled?

"CASO" (Cross Adapter Scan-Out) was a new driver feature for NVIDIA Optimus, a development driven by Microsoft. CASO promised to improve performance with MSHybrid, to close the gap between Optimus on and off.

Our tests indeed showed improvements in frametimes and consistency with CASO enabled. However, Discrete mode (dGPU-only) was still clearly superior.

CASO sits in the iGPU driver (not the NVIDIA driver). Back then, CASO was introduced in Intel Graphics driver 30.0.101.1960, the Non-CASO result was with Intel driver 30.0.101.1340. NVIDIA driver was 512.59 for all results. System was set to maximum performance with "Fan Boost" enabled to avoid any potential thermal bottlenecks. Memory integrity (VBS/HVCI) was intentionally set to "Off" - again, to maximize raw performance as much as possible.

We intentionally chose CS:GO for this test as a worst-case scenario, because CS:GO can achieve extremely high framerates on modern systems and is thus especially affected by CPU, driver or display pipeline bottlenecks. Average FPS were at 470 in MSHybrid without CASO, 478 with CASO and 560 FPS in Discrete mode. CASO improved "1% Low" by only 3 percent, but the line diagram shows a much greater improvement in frametime consistency.

Test parameters:

• CSGO / FPS Benchmark by uLLeticaL
• 2560 x 1440 / 165Hz / Fullscreen
• High / AA+AF OFF / Multi-Core Rendering

Overview diagram:

Video comparison:

• nvidia-frameview-frametime-diagram-comparison-video.mp4

The video shows all three scenarios superimposed over each other (as seen above), and then each scenario individually. You can look at these individual slides by clicking on these links:

• 1_Overview.png
• 2_MSHybrid-without-CASO.png
• 3_MSHybrid-with-CASO.png
• 4_dGPU-only.png

The original FrameView logfiles and the Excel table used to generate this graph can be downloaded here:

• nvidia-frameview-logs-and-analysis-examples.zip

Can you use these example files to familiarize yourself with how to organize FrameView logfiles and how to best visualize them with a spreadsheet application.

Quantifying frametime consistency

A frametime graph is useful for showing when fluctuations occur, but we can also verify these visual impressions with hard numbers.

The main values that represents the difference in frametime consistency are "standard deviation" and "coefficient of variation". They express how strongly the frametimes fluctuate relative to their average. Formula:

Coefficient of variation = standard deviation / average frametime

The result should is formatted as a percentage. A lower percentage generally indicates more consistent frame pacing.

To calculate the coefficient of variation, we first need its two components, then combine them into the target value:

Let's assume that your worksheet is named "Frametimes" and it already contains several columns with "MsBetweenDisplayChange" side by side, with "TimeInSeconds" in column A and "MsBetweenDisplayChange" in column B and following columns. Now, follow these steps:

• Create a new worksheet and name it "Statistics".
• Recreate the example table below.
• Format cell B4 as a percentage.
• Select cells B1 to B6 and drag or copy them to the right for the remaining configurations. Excel automatically changes the source reference from column A to column B, column C and so on.

Example table:

=Frametimes!B1

=AVERAGE(Frametimes!B:B)

=STDEV.P(Frametimes!B:B)

=B3/B2

=MEDIAN(Frametimes!B:B)

You can find an implementation of this approach in the example ZIP file linked above.

Notes:

• No single number provides a complete assessment. These metrics do not show when fluctuations occurred or whether several slow frames appeared consecutively. They should therefore be interpreted together with average FPS, 1% Low FPS and the frametime graph.
• For meaningful statistical comparisons, each data series must represent the same section of the benchmark. Ideally, start and stop every capture at consistent points. Each row represents one frame, not a fixed amount of time. A faster configuration therefore covers less benchmark time within the same number of rows than a slower configuration.
• To make this easier, it is advised to use the "Capture duration" function of NVIDIA FrameView, to automatically stop logging after a fixed amount of time has passed. This way, you only have to worry about starting the capture at consistent times.
• Do not truncate all frametime columns to the same number of rows merely to make the graph look cleaner. Instead, use the "Select data" function in the chart properties to visually truncate the diagram to length that is easier to visually digest (see screenshot).
• If manual trimming is necessary, use "TimeInSeconds" or clearly identifiable transitions, such as the benchmark returning to a menu, to align the beginning and end of each sequence. Otherwise, later heavy or light sections of the benchmark may be included in some runs but excluded from others, distorting the average, standard deviation, coefficient of variation and percentile results.

Further reading

Related NVIDIA documents:

• NVIDIA blog post about FrameView: originally posted in 2020, last updated in 2022. Slightly outdated by now, but good introduction into core concepts.
• FrameView User Guide: up to date, but very long. Not strictly needed if you already read and understood our article here.

Related articles in our knowledgebase:

• Creating a HWiNFO64 sensor log (CSV file) to provide hard data for tech support
• How can I tell if my system's performance and temperatures are within expectations?
• What tuning and monitoring software is recommended by XMG?