This article is like our research/whitepaper piece that presents some experiments and possible representations for animation error in benchmarks

The Highlights

• Benchmarking has long had a problem of ensuring numbers relate back to the reality of what players feel when gaming
• Game stutters have sometimes been misattributed to frametime pacing issues rather than the actual problem, which was animation error, aka simulation time error
• The issue mostly comes to explaining precisely why stutters and hitching are happening in games, not just that they exist

Table of Contents

• AutoTOC

Intro

We have a new benchmark metric that exposes a limitation with current GPU and CPU game testing.

Editor's note: This was originally published on October 13, 2025 as a video. This content has been adapted to written format for this article and is unchanged from the original publication.

Credits

Test Lead, Host, Writing

Steve Burke

Testing, Writing, Research

Patrick Lathan

Camera, Video Editing

Vitalii Makhnovets

Video Editing

Tim Phetdara

3D Animation, Editing

Andrew Coleman

Writing, Web Editing

Jimmy Thang

This is that limitation: Frames are displayed at an even pace in this example, but something is still wrong with it. The thing that’s wrong is why we have the new measurement methodology that we’re debuting today: Animation error.

Animation error is the difference between the pacing of animation and display. Putting "animation" in the name might be confusing: Intel called it Simulation Time Error at one point. 

And this is a sample chart illustrating what we’re talking about, where you can see the animation error timing sometimes in alignment with frametime spikes, sometimes out of alignment with it, showing that it’s a different thing. 

Here’s another chart showing the percent animation error during a test pass. 

Or this one, where we show the CPUStartTime versus animation time delta.

These are all new types of benchmark charts that haven’t been shown before. Tom Petersen first pitched the idea of animation error a couple years ago, something he arguably began on about 14 years ago.

The problem with GPU, CPU, and new game benchmarks has always been that it’s tough to accurately capture the actual player experience. Framerate was a good start, and frame-to-frame interval testing (or "frametime testing") was a great expansion on that -- but neither perfectly captures the real experience.

This is what we’re unveiling and detailing today. Consider this a whitepaper, like a research piece that’s intended to put information out to the community for people to start trying to experiment with. None of this is perfect yet, but we think we have a good foundation for viewers and other reviewers to build upon and advance our understanding of game behavior. If you’re a reviewer and this is useful, please point back to this story as it was over a month of work for us to wrap our heads around.

Let’s get into it.

This methodological deep-dive lays the foundation for new testing. It’s exploratory.

We rolled-out 1% low and 0.1% lows in our testing back in 2014, eventually popularizing their presentation on bar charts alongside average framerate. These are the metrics we use today to point us toward a problem with frametime pacing. The industry has relied on frametimes, 1%, and 0.1% averages for over a decade now with few new metrics in between. 

The history to that is all important, and it’s important that those who did the groundwork before us are known: Tom Petersen, PC Per’s Ryan Shrout, and Tech Report’s Scott Wasson all advanced this metric, with Petersen doing heavy lifting on providing software tools and early insights to frametime analysis. His engineering work has continued with the open source tool PresentMon, which gets us to animation error today.

Animation Error should be thought of in a more traditional sense: Like a flipbook with perfectly animated drawings, but without the execution of flipping through the pages at a constant tempo. That's just one specific scenario for animation error; you could extend the metaphor, like flipping through the pages perfectly but messing up the drawing (or you could do a combination of both).

We're talking about animation in the dictionary sense, "a movie, scene, or sequence that simulates movement from a series of still frames," so animation error applies to entire frames. Think of it like frames of drawings on an animation lamp, in a flipbook, or on a reel of film. We're NOT talking about errors in animation of individual models, objects, NPCs, or sprites within the frames, and we’re also not talking about games that just have bad animation from the artists. 

You could technically have animation error even staring at a blank wall in-game without any movement whatsoever, though it might be impossible to notice.

This all comes down to two things: Smoothness and acceleration. When we were talking to Tom Petersen about this concept, he made some good points about this. Showing frames faster allows the brain to interpolate and generate an illusion of smooth motion, which is the illusion of TV and movies. But the brain also knows how to identify acceleration, something Tom equated back to “monkey times like running away from lions and shit.”

This is an example of animation error that we created in 3D space. It’s very smooth and accurate as a rate, but it’s slow. Every now and then, you’ll see an error in it despite the smoothness of the frames, and that’s stutter. When the brain sees even subtle acceleration or deceleration, we pick it up quick. That’s what makes it feel so bad when we see stutter in gaming. Stutter is what you’re seeing here: Something accelerates or decelerates quickly and the body is overreacting because, to quote Tom, “we don’t want to be eaten by a lion, or some shit like that.” He really has a gift with words.

But it would be great if we could measure smoothness and acceleration separately, because they’re different problems: Framerate and frame-to-frame interval evaluate smoothness, but acceleration is something we haven’t done a good job at quantifying in this industry. That’s characterized by animation error, which we’re introducing with its first full charts today.

This chart is from our Dragon’s Dogma 2 testing at launch, where we were quietly beginning to farm data for this eventual piece. You can see where the animation error blips often align with the frametime spikes, but not always.

AnimationError can also be positive or negative. When a frame is displayed "too late" (relative to its correct placement) that's a negative error, and when it's shown "too soon" that's a positive error. Neither is good. At a macro level, it doesn't matter which is which: further away from 0 is always worse. 

The idea is that if frames are created at a certain pace, you should see those frames displayed at the same pace. There are differences between animation error and frametime pacing, though. 

If there's a mismatch, that's where the animation part comes in: movement depicted in the frames will appear jerky and wrong, even if frametimes are perfectly consistent. 

For a real-world demonstration, the simplest, most reliable way we found to directly induce animation error was with SLI. 

Yeah, we know.

We can take one card and get a normal result, then add a second and get a result with higher animation error. 

That limits us to older hardware, and it also limits us to GPUs that we own in pairs. We selected two 1080 Tis (read our revisit) since they're our newest cards that still use regular old SLI, and (as of now) they're still supported in the most recent NVIDIA driver package. We also had to select a game that supported SLI.

We’re getting into benchmarks. We’ll break these down starting at the most abstracted metric, which is this chart. 

This is framerate represented as bars, abstracting away from time. Next, we’ll look at the frametimes that create this framerate average, and last, we’ll look at the new animation error metric.

These are averaged results for 30 second logs of Far Cry 5's baked-in benchmark, one using a single 1080 Ti and one using two 1080 Tis in SLI. The 1% and 0.1% lows indicate that there weren't huge frametime spikes, and it’s these metrics that tell us when we should inspect a frametime plot closer for major problems. Average FPS smooths over problems, 1% and 0.1% are still averages and can still smooth over them, but are more likely to draw our attention toward a problem because they’re averaging the worst 1% and worst .1% of data.

As a reminder, we aren't using percentiles, which is a different way of approaching this. We explained that in our video where we did JayztwoCents' lab overhaul.

The average with SLI is higher, as expected; however, beyond that, there’s no dramatic change between how these numbers manifest. The single GTX 1080 Ti appears to have closer frametime pacing to its average, which is what we’ve been preaching for years as a good result, but the dual 1080 Tis still look good overall.

Data Presentation: Frametimes

The frametime plot helps us see deeper into those bars. 

This still isn’t animation error, though, and it’s still not new.

This plot of frametimes is for two individual passes. As we know based on the last chart, the SLI run’s gap between the average and its 1% and 0.1% metrics is wider. Here, that materializes in the form of spiky behavior (particularly in the 500-1000 frame range) for the SLI configuration. The experience is far less consistent, with more sporadic frametime excursions from baseline. Most users begin to notice these around 8ms, according to an interview we conducted with Scott Wasson years ago, but only if they frequently occur. 

The single-card run has more consistent frametimes, despite its lower average. It’s not so bad that it’s a ruinous experience, as the SLI configuration is ultimately still within the range of 2-4 ms of the baseline, but the relative distance from baseline is larger. It’s not like we’re seeing 100ms spikes where you’d stare at one frame for 1/10 of a second, as we’ve seen in other tests on modern single cards.

Data Presentation: Animation Error

Here’s the new stuff.

The left axis shows animation error in ms, with deviations away from zero depending on whether frames showed up too soon or too late. 0 is perfect and 0 does occur. The X-axis represents frames, the same as the frametime plot we just showed. The animation errors could also be taken as absolute values for a lower-is-better representation, but this is a plot of the raw data as logged by PresentMon. 

There are many ways this data could be plotted. A scatterplot lets us judge the data points individually, but still keeps the points in order so we can see how behavior changes over the course of the test. Lines between the points wouldn't mean much here.

By plotting the animation error, we can get rid of frametimes as a variable and just compare that relative spikeyness as a player would truly feel it interacting with the game itself. This is closer to the real experience, in the same way end-to-end latency can be but for different reasons. The further the deviation from zero in either direction, the worse. The cards in SLI frequently had 2-3ms of animation error per frame, while the single card typically had well under 1ms animation error. The SLI configuration is significantly worse for animation error in a relative sense, despite even the frametime data looking not that dramatic.

The single card is clearly far better in terms of animation error, although we need more data to judge whether the SLI result is "bad."

Strange Brigade Animation Error

This is another test. This time, we’re using Strange Brigade. Our goal today is exploratory, so we’re choosing games based on usefulness to explore the concept, not on their popularity. That’ll come later.

The main advantage of a plot like this is that we don't have to insert our own calculations or conclusions: we can simply show the data. The single 1080 Ti sticks even closer to zero animation error per frame than it did in Far Cry, while the SLI 1080 Tis continue to generate 2-3ms of positive or negative error on nearly every frame, only rarely approaching zero. 

SLI outperforms the single-card so heavily in this title that the red line is significantly shorter, which is a downside of using frames as an X-axis. Even though both its average framerate and its 1% and 0.1% lows are overall good here, the animation error is far superior on the single GPU. There is a possibility that it feels better to a player, but not for the reasons everyone in this community has said for years: It’s not due to frametimes, on a technicality, but animation error, which is a metric that has been under the surface this whole time.

Animation Error Bar Chart

This is an “Error Per Frame” chart we attempted, which puts the data back into bars for denser comparison of more cards. Maybe this could work better as a visualization: for those two individual passes in Far Cry from earlier, the total animation error (taken as absolute values) divided by the total number of frames was 0.13ms per frame for the single 1080 Ti and 2.31ms per frame for the SLI 1080 Tis. These are basically single-number summaries for the plots we just showed. But now we’re doing the bad thing again: We’re abstracting away from the base metric over time (shown as frames) and converting it into a bar, because that’s easier to read. This isn’t ideal for a lot of reasons.

First of all, this could obscure individual big error spikes (if that's something we want to track), and secondly, it also adds framerate back in as a variable. The SLI setup generates more frames, which lowers the end result for this calculation, arguably making the SLI cards look unfairly good; then again, maybe it’s not “unfairly” because more frames going by quicker could help disguise animation error.

This is getting complicated, but you can see why we’ve had to think about this for weeks.

Far Cry 5 Animation Error Percent

So we don’t like the prior chart for those reasons, and the scatter plot doesn’t accommodate more than two or three GPUs before it’s illegible. Maybe this will help.

This alternative was suggested by Tom last year. It divides the total animation error absolute values by the total frametimes (the length of the test run) to get a ratio or percentage. 

This is equivalent to comparing those average error-per-frame numbers from the last chart to average frametimes. 

However, in order to make this chart we’re showing accurate and not misleading, we had to use two times the total frametimes for the calculation because otherwise, the implication is that 100% is the maximum value, and it wouldn’t be if we hadn’t corrected for that, and that’s because in the absolute worst case scenario and assuming that latency doesn't accumulate over the course of the test run (which is a different subject entirely), the maximum total animation error would be twice total frametime. 

THIS diagram makes that abundantly clear by showing that alternating between infinitely small frametimes rounded to zero and 10ms frametimes, and inversing the display times, we can get 10ms or -10ms of animation error per frame, where adding up all frametimes gives us 30ms yet adding up absolute values of the animation error gives us 60ms.

OK, this graphic really isn’t helping make it less confusing. The point is, we already corrected for this in our percent chart and any other reviewers planning to use such a chart will need to do the same.

We used the same two Far Cry passes for this example: for the single 1080 Ti, the result is 0.7%, and for the SLI setup the result is 17.3%. This potentially cancels out or reverses the high-framerate advantage from the last chart: more frames equals more (total) error.

Real-World Uses

Let’s talk potential real-world use cases. Maybe this will give other reviewers some ideas.

Animation error is theoretically decoupled from framerate and frametime consistency, although in reality poor performance correlates across all of those categories. 

In this mockup from Intel, the bar marked "CPU Stutter" marks a frametime spike, while the mismatch between the sizes of the bars in the top and bottom rows is the animation error (F1 versus F1 = error for F2, F2 versus F2 = error for F3), so we'd see similar spikes in both metrics.

Animation error is also separate from latency: it's about how the frames are spaced, not whether they're all showing up ten seconds late.

Frame generation has interesting implications for animation error, but unfortunately there's no animation time for fake frames, so there's no reference point for calculating error. That makes this whole thing even more challenging to quantify.

We'd like to check on NVIDIA MFG in particular, since that comes along with flip metering that shuffles frame timings around at the end of the pipeline, which has the potential to actually induce animation error (as we mentioned with the SLI example).

Animation error could shine a light on shortcomings of flip metered frame generation that are currently masked with existing testing methods, but we won’t know until the software works on it, which may at least partially rely on NVIDIA’s willingness to play ball.

Dragon’s Dogma 2 Animation Error

Because we expect AnimationError to correlate with frametime spikes most of the time, its most common usages for us will be similar to 0.1% lows and frametime plots, but with a more direct representation of how the game feels. 

For example, this is a chart that Tom helped us generate during the early stages of troubleshooting Dragon's Dogma 2's performance back when it launched -- that’s how long we’ve been thinking about this data. 

The spikes in both metrics line up exactly, but animation error adds depth by telling us why the stuttering was so noticeable and unpleasant. The positive and negative animation error dots that correspond to the frametime spike toward 60ms around frame 500 shows a potential for 45ms of animation error. That’s potentially a lot more noticeable than even the already noticeable frametime hitch of 58ms.

Borderlands 2 Animation Error

Here’s Borderlands 2. Yes, we know there are newer ones. But this is a better demonstration.

Since animation error effectively cancels out framerate differences, we can use it to compare two completely different pieces of hardware and get more nuance out of it.

These two results are from our piece about the death of 32-bit PhysX. These two particular results were fairly close together both in terms of average FPS and lows: the GTX 980 with GPU PhysX averaged 101 FPS across multiple passes and the RTX 5080 (read our review) with CPU PhysX averaged 95 FPS. These are real results and we explained them in our piece about NVIDIA killing 32-bit PhysX support this year.

In spite of that, there's a clear difference in behavior, and animation error is much higher with the GTX 980. Using the percentage math we mentioned earlier, that's an error-to-frametime ratio of 11.9% for the 980 and 1.8% for the 5080, which allows us to identify a problem without having to generate frametime plots for every single result.

Percentile Limitations

We probably wouldn't use a test scene that resulted in a graph like the GDC 2015 one shown above by NVIDIA, but as it points out, there are scenarios like this where frametime spikes could be artificially masked and not show up in 1% and 0.1% low calculations. 

NVIDIA is using percentiles here instead, which we don’t use, but the idea is similar. 

Assuming these frametime spikes were accompanied by animation error, calculating animation error would do a much better job of summarizing the problem (in this instance). That said, our approach to lows already helps to control for some of this, but it still requires knowledgeable testers to know when to look into the 0.1% and 1% low results. 

Microstutter & Multi-GPU

Animation error has been associated with microstutter in the past, but it's not quite the same thing. If anything, animation error is a way to measure microstutter, but not microstutter itself, depending on the definition. Microstuttering was frequently brought up in the context of multi-GPU rendering, so we'll go back in time and start there by referencing materials from GDC 2015.

This simplified timeline establishes our foundation: each block is a frame, and frame N gets displayed while the computer works on frame N + 1 behind the scenes. CPU work isn't represented here, but we'll ignore that for now. The frame times are perfectly consistent, which is ideal. 

This next slide shows how Alternate Frame Rendering (AFR) multi-GPU operates, or at least operated back when anyone actually supported it. Each of the GPUs takes turns rendering frames, and the output is combined and displayed in order. The blue boxes are still uniform sizes, indicating consistent display times, and they're smaller than the previous diagram, indicating a higher framerate.

One of the major difficulties with AFR is trying to synchronize GPUs. Here, GPU0 and GPU1 are taking the same amount of time to complete individual frames, but they're poorly synced so that some frames get little display time and are effectively wasted. 

These are also known as “runt frames,” where fractions of frames are shown in a way that elevates the average FPS, but creates an awful experience with bad tearing. The average framerate is higher because more frames were technically shown, but the additional frame is useless and the actual experience can look lower in framerate, which is one definition of microstutter.

Again, we can't see the CPU stage of the pipeline here, but we'll assume it's being completely consistent. 

In this example, the rhythm of animation matches the rhythm of display, so there is no animation error. The framerate is stuttery, but all the moving stuff in the frames shows up in the right place at the right time. After each short frametime, objects move a little; after each long frametime, objects move a lot.

You can avoid that microstutter by forcing the pacing into alignment. Ideally this happens by manipulating delays early in the pipeline (on the CPU), in which case you return to a clean result like this one.

However, if you were to meter those frames out at the END of the pipeline, that would directly contribute to animation error (or "animation stutter," as NVIDIA put it back then). We've created and rendered an edited diagram to show what that would look like. If you just take the "short" frames and hold onto them longer before flipping, then there's a mismatch between the pacing of the frames as they're displayed versus the animations depicted in those frames. That leads to perceived stuttering and rubberbanding.

Back to our earlier animation, that’s seen when comparing the red and green indicators below the scene, where the imperfect ball stalls and then gets dragged forward in uneven intervals.

We aren't exploring which method NVIDIA or AMD used to deal with microstutter; that's a subject for another time, and that time was 12 years ago. Today, we're just showing a real world example of a situation where animation error was a risk.

Animated Examples

Andrew on the team made some 3D mockups of simulated animation error. We started by rendering out a scene at 120 frames per second. This could have been any arbitrary number, but picking a high framerate allowed us to downsample and play around with the spare frames.

Here's what that looks like. The top row of squares represents our 120 FPS source video, and we'll pretend that our simulated game has an impossibly low latency of zero, meaning that this row represents in-game reality. The bottom row of squares represents frames that we pulled out of the original sequence to create our 60 FPS video. Because we pulled exactly every other frame, we still have smooth playback with zero frametime spikes and zero animation error. Because we display the frames in sync with their original placement, we have zero latency as well.

Since we're pulling frames every 16.67ms from the source video, our AnimationTimes are always 16.67ms. And since we're also displaying those frames every 16.67ms, our DisplayedTimes are always 16.67ms. Therefore, AnimationError is always zero.

The green circle represents "reality" as determined by our source video, while the red circle represents what we're actually seeing. Again, these match perfectly in this control example.

By taking some of the spare frames from the source video, we can create animation error, but we need to be specific. The diagonal lines mean that we're taking the original frames and displaying them later than "reality," which introduces latency. Latency itself is not animation error. That’s a different problem. 

As we play through the big lump of diagonal lines at the start of this clip, the red circle falls behind the green circle, but the animation of the video remains smooth. Animation error is when the red circle jerks around, skipping to catch up with the green circle at an uneven pace. If you watch the video clip when this happens, you can see the interruptions. This is what we mean when we say animation error is a measurement of jitteryness.

Here's an extreme example of our point about latency: we're displaying every frame 41.67ms "late," so the red circle lags behind the green, but the resulting video is identical to the control. AnimationTimes and DisplayedTimes are still perfectly matched 16.67ms intervals every time, so there's zero animation error.

We can do this multiple times during the clip to intensify that feeling of rubber-banding. We're creating a lot of variation in our simulated AnimationTimes here: if we take two back-to-back frames from the 120 FPS source video, that's an 8.33ms AnimationTime. If we pull two frames that were spaced four apart in the original video, that's a 33.3ms AnimationTime. Meanwhile, our DisplayedTimes remain constant, because we're still displaying fresh new frames exactly 16.67ms apart. That's the mismatch in pacing that animation error quantifies.

As Tom told us before, our challenge is to "make people understand that you can take frames and show them with an even cadence on display and still have it look like shit." He has a real way with words. It’s like poetry.

We can also create an inverse example. Think about a flip book. Here we've pulled frames from the source video at even intervals for constant simulated AnimationTimes of 33.33ms, but by displaying those frames at uneven intervals, we still create animation error. This is like drawing a perfect flipbook animation and then failing to flip through the pages at a constant tempo. This is a weird theoretical example, because if we assume this is a case where frametimes equal animation times, PresentMon would report a completely steady 30FPS based on MsBetweenAppStart.

That's not the only way for animation error to manifest, though—in fact, it's pretty unlikely that you'd naturally encounter perfectly consistent DisplayedTimes with inconsistent AnimationTimes, or vice versa. A more realistic scenario is this one, which simulates CPU-based stuttering, like the diagram Intel shared with us.

Here, rather than displaying a unique frame every 16.67ms, we freeze on individual frames. These are DisplayedTime spikes, which usually correlate to FrameTime spikes under the hood.

For each spike, we get two animation errors: after a frozen frame, the next frame is judged to be too late, and the frame after that is judged to be too soon.

This is closer to what we've observed in games, but just like with latency, it's important to remember that the frametime spikes are not the same thing as animation error: you could theoretically keep freezing on frames while maintaining zero animation error. 

To help explain, let's cover a real-world example.

Capture Demonstrations

For easier discussion, we're mostly ignoring VSYNC and variable refresh so that the monitor is not a factor in any way. 

When we say frames are "displayed," we mean that a flip has been signalled to the operating system, and without VSYNC, that flip can happen even if the monitor is in the middle of a refresh (leading to tearing). 

That pushes numbers logged without VSYNC towards the theoretical realm, but no more so than usual: for example, in our launch review, the RTX 5090 averaged a ridiculous 407 FPS in the Dawntrail benchmark at 1080p. That's a comparable performance number, independent of whatever monitor we used, and in that context, that's what we wanted because we want percent scaling between devices.

Separately, higher framerates do correlate with lower latency, so there’s value from that side as well. Today though, we’re also ignoring latency for purposes of focusing discussion.

All of that said, the easiest way to actually show animation error in captured footage is with VSYNC to avoid tearing. If you ignore the overall drops in framerate and focus on the movement of objects that should be smoothly traveling across the screen, you'll see them appear to change speed and jump around: that's animation error.

It's most noticeable in fast panning shots with smooth tracking: the camera should be moving at a steady rate even when the framerate drops, but it appears to hitch and rubber-band, especially when played back at half speed. Animation error is separate from frametime spikes, but the two things are frequently associated, and they're both bad.

We want to be careful here, because animation error is uniquely bad when VSYNC is enabled, and this footage isn't representative of the non-VSYNCed test passes that we're about to discuss.

One of the only ways we can represent those test passes in fixed-framerate capture is with an FCAT-style overlay, which adds a visual indicator of where torn frames begin and end. This helps illustrate runt frames as well, and was used in VirtualDub back in the day. That gives us an indicator of each individual frame that we're discussing without adding the complication of VSYNC, but it does also mean that frames may only show up as a tiny sliver of pixels.

If we play back this footage slowly, you can frequently see the pattern of tearing: a new color shows up at the bottom of the bar in one frame of the capture, then it continues from the top of the bar in the next frame of capture. It's kind of a mess, and it's difficult to focus on one sliver of frame at a time, hence using VSYNC for visualization in spite of the downsides. The FCAT functionality would be more useful as part of the PresentMon overlay, which can simultaneously show a live graph of animation error.

Advanced Definitions

Here are the PresentMon CPU metrics.

PresentMon CPU Metrics:

CPUStartTimeInMs: The moment where a new frame is born, expressed as a timestamp (relative to the beginning of the PresentMon session).

AnimationTime: This is PresentMon's best estimate of the frozen moment in game time that's depicted by a frame. As a player, you're always seeing rendered images of a game several milliseconds after the in-game reality that they depict. AnimationTime is the timestamp for that reality. 

According to Tom Petersen last year, "Today people are mostly using CPUStart as the AnimationTime, which is a pretty good proxy, and that's what we're going to be doing initially. There are explicit APIs, both from NVIDIA and from us [Intel] and others that are allowing game engines or games to tell you that AnimationTime. And so as that becomes more available, we'll be building that into PresentMon." 

Logically, AnimationTime should be the same as the moment the frame was born (CPUStartTimeInMs), but games can pull tricks to smooth animations so that AnimationTime for a frame doesn't line up with wall-clock time. Under normal circumstances it should be close enough, though.

As an example of an exception, PresentMon can monitor SimStart events when using Intel XeLL (and soon NVIDIA Reflex) and base AnimationTime on that instead. That's valuable because Reflex and XeLL clear the render queue and keep the CPU sitting around waiting for input until the last possible second, so there's a higher potential for differences between CPUStart and the true animation time.

Here we have a PresentMon capture of Cyberpunk 2077. The X-axis shows individual, logged frames, and the Y-axis is the delta between CPUStartTimeInMs and AnimationTime for each frame. Normally, this would result in a perfectly flat line at zero, but since we have XeLL enabled, AnimationTime is based on SimStart instead. With XeLL there's a significant delta between the two values on nearly every frame, which shows that AnimationError would be incorrect if it were based on CPUStartTimeInMs when low-latency modes like XeLL, Reflex, and Anti-Lag 2 are enabled. AMD's Anti-Lag 2 doesn't generate SimStart events that PresentMon can grab, so (for now) we won't be able to accurately score AnimationError with that feature enabled.

MsCPUBusy: This period begins at CPUStartTimeInMS and includes steps that Intel labels as Game and Render. "Game" is the time spent handling game logic and calculations for the frame, and "Render" is the time spent converting the results into API calls (DirectX, Vulkan, etc.).

The end of these CPU-specific tasks is marked by the Present() call, which signals to the GPU that it has everything it needs for rendering. Future versions of PresentMon may break this down further because CPU work is complex.

TimeInMs: This is the timestamp of the Present() call we just mentioned. It's important to remember that this call doesn't mark the beginning of the GPU rendering step, because the GPU can get a head start before the CPU is done generating API calls. 

Usually the end of the Present() call is the CPUStartTimeInMS of the next frame.

MsBetweenPresents: The delta between this frame's Present() call (TimeInMs) and the previous frame's. In the old days, time between Present() calls was used as a (fairly good) approximation for frametimes, but it's technically a different thing. For that reason, MsBetweenPresents is unusable for per-frame calculations like animation error.

MsInPresentAPI: This is the same as MsCPUWait. This is the period between the Present() call and the moment when the CPU begins working on a new frame, meaning that there's nothing blocking further CPU work. 

MsBetweenAppStart: PresentMon's best representation of the literal time taken to create an individual frame start-to-finish (an improvement over MsBetweenPresents). It's the delta between the CPU starting work on one frame and the next, so the difference between CPUStartTimeInMs for the current frame and CPUStartTimeInMs for the next frame (or MsCPUBusy plus MsCPUWait).

MsBetweenSimulationStart: This column would depend on SimStart events from Reflex or XeLL. In the current version of PresentMon, MsBetweenSimulationStart is "disabled until underlying event support is enabled."

PresentMon GPU Metrics: We don't need these numbers in order to calculate AnimationError, but we'll go over them briefly. They include:

MsGPUTime: The total GPU render period, comprising GPUBusy and GPUWait periods. This was formerly called msGPUActive.

MsGPUBusy: The portion of the render period "during which at least one GPU engine is executing work from the target process."

MsGPUWait: The portion of the GPU render period where the GPU was idle, potentially due to some codependency on CPU resources.

PresentMon Display Metrics: 

MsUntilDisplayed: The time between the Present() call for the frame (TimeInMs) and the time at which the frame is displayed. You can calculate the timestamp at which the frame is displayed by adding these numbers, but it isn't logged directly. "Displayed" here means that a flip (pointing to a new frame buffer) is signalled to the operating system. This is different from new pixels literally showing up on the physical monitor, although the timing should be very close.

MsBetweenDisplayChange: How long the previous frame was displayed before the current frame started to be displayed. There's an argument to be made that this reflects the user experience more directly than MsBetweenAppStart, but MsBetweenAppStart is directly tied to performance, so that metric is still better for testing hardware. However, since display happens at the end of the pipeline, MsBetweenDisplayChange is the only way to include post-processing stuff like generated frames and RTX 5000 frame metering in results (if you want that). 

Combined Metrics:

MsGPULatency: The period between the absolute start of work on the frame (CPUStartTimeInMs) and the point at which the GPU started working on it. The start of the GPU render period can be inferred from this.

MsRenderPresentLatency: This is the period from the Present() call at the end of CPU rendering to the end of GPU rendering. This is equal to MsUntilDisplayed unless VSYNC is enabled.

MsAnimationError: Here's how Intel represents the animation error formula for frame N:

(AnimationTime_N – AnimationTime_N-1) – MsBetweenDisplayChange_N

Again, the result of the formula can be positive or negative, but further away from zero is always worse. Adding together all the positive and negative animation errors for a logging period will typically cancel out, so to get a useful total we need to take absolute values.

In the words of Tom Petersen, "The animation step is basically equal to the frametime, mostly. There's some times where it's a little different. But what you need that for is to be correlated with the DisplayedTime step. Because if the DisplayedTime step is different from the animation time step, you'll get a simulation time error, which is measuring stutter directly for the first time."

We've established that AnimationTime is the in-game point in time that a given frame depicts. The delta between animation times for consecutive frames is the amount of in-game time that has passed between them.

We've also established that MsBetweenDisplayChange is the time that a frame is displayed before the next one shows up.

If a long time passes between taking snapshots of the game state, a long time should pass between displaying the snapshots. Even if the AnimationTimes are spiky and uneven, the DisplayedTimes should be matched exactly, or else you get AnimationError.

Conclusion

This doesn’t replace current testing or run instead of it. It’s another tool -- similar to frametime charts -- to help better understand what’s happening in a game. There’s also a lot of theoretical situations here, so it isn’t always practical.

1% and 0.1% lows as bars on a chart took on a life of their own over the last decade. They are still the fastest “glanceability,” and we’re glad we introduced them to our charts now 11 years ago, and we’re going to continue to use them. But it’s time to try and find new metrics, and we hope animation error can supplement the 1% and 0.1% average bar representations of frametime pacing as another means to determine why a game just feels bad sometimes.

But we don't want to oversell what this number actually means. In Tom Petersen’s words: this is a "how jittery am I" metric. Our work here on and off over the past couple years, and more seriously over the past month, has been trying to prove the concept and find a way to put it on a chart that makes sense to anybody. 

We devoted a lot of time to explaining how and why it's different from the numbers that we already measure, but in practice and in most cases, we expect it to complement those numbers, not contradict them. 

That also means we aren't necessarily expecting any huge upsets versus what we've already concluded in existing reviews.

That said, this is a valuable new tool that can do several other things for us: it can show us when we need to make a frametime plot more easily, it can show us when stuttering happens independently from frametime spikes (although that may be unlikely), it can (sort of) normalize for frametimes in a way that makes comparisons between different hardware easier, and it can deal with up-and-down frametime trends across test passes effectively.

Most importantly, animation error forces us to think about why we measure the things we do. We're now closer to discussing why stuttering feels bad, not just the fact that it exists. 

We're still experimenting with ways to make it useful. 

If you want to try it out for yourself, PresentMon is free and open-source, and it now has a GUI version available as well. If you’re a reviewer and you find this useful in developing your own methods, we’d appreciate you pointing back here.

We’ve been using PresentMon for years, and actually, most people who’ve tested game performance have -- they just often don’t know it. 

PresentMon is wrapped by half a dozen other tools that reskin it or use it in some capacity and it’s an open source project with contributions from around the hardware community.

We use the command line version, but there’s also a user interface tool that you can see in our video where we introduced Jay to it previously. They sometimes have different features.

Because of that, a quick security warning first: do not visit PresentMon dot com or download anything from that site. PresentMon is hosted on GitHub and Intel.com and is an open source utility. Usually when someone pretends PresentMon is their own project and reskins it with an interface, they at least come up with a new name. For security purposes, we’d advise only downloading PresentMon itself from GitHub or the Intel site.

Testing animation error like this is exciting because we can finally directly score stuttering instead of simply deducing it. Big picture, this is similar to when PresentMon moved away from MsBetweenPresents: the numbers and conclusions may not change much, but the measurements are closer to what we're really talking about. 

This isn’t the endgame of benchmarking. Hopefully there won’t be one, because that’d be boring. There’s a lot more to learn and this is exploratory and just us putting research out to the internet to experiment with. It’s also up to the vendors to play ball with open source tools like PresentMon. Experiment with the new ideas and point back to us if you find our work helpful as a foundation, and credit to Tom Petersen for opening up the tools to measure these metrics.

A permanent reference guide for common warranty refusal tactics and their responses

The Highlights

• Includes references to US Law, but has guidance applicable everywhere
• Warranties can be rejected for invalid or even illegal reasons
• This content informs you of your rights and makes preventative recommendations

Table of Contents

• AutoTOC

Intro

This guide is designed to maximize your protection as a consumer in the event of a warranty claim. This does not constitute legal advice; however, it does include legal references that will help reinforce your claims if they are rejected.

Our specialization is in computer and gaming hardware, so that will be our focus; however, aspects of this could be applied to nearly any warranty claim.

We are writing this following our ASUS RMA Investigation Pt 1 (“ASUS Scammed Us”) and our ASUS Response Pt 2 (“ASUS Called Us Confused”). The experience was a great learning exercise that we can apply to any manufacturer which either unlawfully rejects a warranty claim or which rejects a claim without proper foundation. We have been communicating with lawyers and experts in Right to Repair/the Magnuson-Moss Warranty Act to better understand the advocacy around these deeply important consumer rights issues and how to self-advocate in a scenario where you feel a manufacturer is unfair or unlawful in its conduct.

Credits

Writing

Steve Burke

Enough is Enough

A personal note: We have covered many warranty issues over the years. At this stage, GN has grown enough, and I have grown dissatisfied enough, that we are starting the process of taking our findings to lawmakers. We have begun the process of connecting with Congressional and Senatorial representatives, are contacting the Federal Trade Commission, and have begun interviews with experts and advocates for consumers on these matters. This is not just an ASUS issue. We hope to educate ourselves enough on the legal specifics of both Right to Repair and acts like Magnuson-Moss so that we can take up the fight for consumers to politicians to push for action. Although some smaller companies may act in the interest of consumers, large corporations are often calculating when it comes to which consumer rights they respect. 

Laws can change the outcome of this calculation.

Our focus is on the US because that’s what we know and that’s where we live. But many of these self-advocacy concepts can apply globally.

Warranty claims are frequently met with what we’d consider to be BS responses, such as claims of “customer-induced damaged” (CID) that are unfounded or irrelevant. Our video component accompanying this article will address many of those situations with expert Nathan Proctor of the Public Interest Research Group (PIRG), which is an advocate of public interest matters like Right to Repair. You can find that discussion in the video component only.

Warranty Fraud: How to File a Report

FTC Warranty & Consumer Reports

Let’s start with the easiest thing: If you’ve already been screwed in a warranty process and you believe it to be unfair and potentially illegal, it is easy to file an FTC Report. THESE ARE IMPORTANT. The more consumers are aware of these, the more likely it is that the FTC gets involved to straighten-out companies internally and compel change through fines and action.

You can file a report here: https://reportfraud.ftc.gov/form/main?TC=RightToRepair

Fill in the details pertaining to the charges (if you paid anything for the claim or were requested to pay, but didn't). Choose the form of contact you used to engage with the company.

Enter their email address or support address.

Most likely, you will leave all the checkboxes blank. The issue is a Warranty issue, not one of these.

Enter the date of correspondence.

In the Comments box, provide a brief description of the events and a timeline. We would recommend starting with:

“This pertains to a warranty claim which I believe was unfairly rejected by the Manufacturer. The claim was for a defective electronics device called [NAME] made by [MANUFACTURER]. The claim was rejected on grounds of [REASON] by the manufacturer, which I believe to be invalid. I have collected documentation and evidence to support my claims. The timeline of the events is below. Please contact me for further information. Thank you.”

The two fields pertaining being requested to send money are important. Fill those in truthfully.

These reports matter. The more there are, the more likely it is the FTC gets involved to slap corporations.

Finalize your report and submit it.

Warranty Claim Self-Advocacy Kit

This kit contains:

• Examples on how to open a ticket and minimize time spent in “RMA hell”
• Examples of documentation to best protect yourself from false claims
• Example responses, including pushback responses
• Examples of how to read warranty language

Simple Steps: Successfully Claiming a Warranty

Live by the mantra “document everything” for your claims. We’ll start with the steps broadly, then drill-down. This is assuming you have a valid claim. Remember that not all damage is covered by warranties.

1. Before filing your claim, check the date of purchase
   • Even in the US, if you purchased from a retailer, you may be covered by the retailer. Most retailers have a 30-60 day window where you can return an item directly. We always recommend this path if a new device is defective. Check the retailer’s return policy. If it is not merchantable (it ships defective), you have a LEGAL RIGHT to return the device. This is always easier.
2. Before filing your claim, check the duration of the warranty period and get a basic understanding of what might be covered
3. If you have it, find your original purchase receipt and have it saved in case the representative requires proof of purchase. This is somewhat common.
4. Determine in as few words as possible how to explain the details of the claim. We have examples below
5. File your claim via email if possible or chat (and save the logs) if not. If you use phone support, we recommend writing down all agreements reached on the call and then reading them back to the representative at the end of the call. Ask the representative to confirm that your understanding of the next steps is correct. Ask the representative for their email address, then email them the call notes. Start the email with,
   
   “Hello [name],
   
   As you confirmed on the call, my next steps are as follows:
   
   [paste notes]
   
   Thank you,”
   
   This will give you something in writing. If they do not reply to dispute your claim that they confirmed this, you likely have created standing for a dispute later. If they dispute it, get on the same page and proceed.
   
6. Document the device in detail before returning it. Take photos of all angles and record serial numbers. Examples below. Fragile items like motherboard sockets should be documented specifically
7. Before shipping a device, ask for packing instructions or look them up from the manufacturer. Following packing to the spec removes their ability to claim you were at fault for improper shipping. 
8. Document the packed device with photos. Follow the shipping spec provided so that it becomes the manufacturer's liability
9. Ship the device. Follow tracking and save a screenshot of the tracking information once it is marked as delivered so that you have proof of delivery. These tracking pages are often deleted within 14-60 days.
10. Check regularly for responses so that you do not miss a short window for response
11. Following the examples below, do not accept any unnecessary repairs and advocate for your rights
12. Escalation is an option. Described below.
13. When you receive the new device back, IMMEDIATELY photograph the package, including the exterior and interior packing, before disturbing it. Open the package and inspect the device. Look for new damage or a possible replacement.
14. Document (photograph) the device in its new state
15. Thoroughly test the device for its old issue and for base functionality to ensure no new issues. A refurbished part may have new problems (for example, we received a refurb laptop once to fix a hinge problem and the new device had a broken Bluetooth module that we didn't discover until it was too late to return again).
16. That should be it

Returning to Stores

We always recommend returning a device to a retailer if it has broken (or arrived broken) within the return policy window. Steps:

1. Navigate to your retailer’s website or email them and check the time window for returns. Most are 30-60 days. Some are longer.
2. Advocate for a pre-paid shipping label if the item sold to you was already broken or defective.
3. Take photographs of the device (if it was opened) and its box (if it was unopened, showing the seal)
4. Ask the retailer for return packaging instructions and document them. This protects you from a counter claim of improper shipping protection causing damage
5. Take photographs of the packaging and the package, then ship it
6. Save the tracking report once it marks as delivered
7. Know your rights (below)

Legal Right to a Functioning Product

You have a legal right to a functioning product on purchase. If the product develops a defect over time, that may fall under the manufacturer’s warranty rather than the store’s legal requirements to sell you a functioning product. 

Recommended reading: The Business Guidance from the Federal Trade Commission on “Implied Warranties.” It is written in clear language, not legalese. The below is written by the FTC to business owners (emphasis ours):

“Implied warranties are unspoken, unwritten promises, created by state law, that go from you, as a seller or merchant, to your customers. Implied warranties are based upon the common law principle of ‘fair value for money spent,’ There are two types of implied warranties that occur in consumer product transactions. They are the implied warranty of merchantability and the implied warranty of fitness for a particular purpose.

The implied warranty of merchantability is a merchant's basic promise that the goods sold will do what they are supposed to do and that there is nothing significantly wrong with them. In other words, it is an implied promise that the goods are fit to be sold. The law says that merchants make this promise automatically every time they sell a product they are in business to sell. For example, if you, as an appliance retailer, sell an oven, you are promising that the oven is in proper condition for sale because it will do what ovens are supposed to do—bake food at controlled temperatures selected by the buyer. If the oven does not heat, or if it heats without proper temperature control, then the oven is not fit for sale as an oven, and your implied warranty of merchantability would be breached. In such a case, the law requires you to provide a remedy so that the buyer gets a working oven.” - FTC.gov

This material is useful if you need to defend a case for a retail return/exchange for an item sold broken.

Retailers have valid reasons to reject returns (such as the customer destroying the product) or to force the customer to eat costs (such as return shipping). Examples might include purchasing a product, realizing you bought the wrong thing, and sending it back. That would be the customer’s fault. In instances of a defective product being sold, however, US retailers are compelled under US law to accept the return and either exchange the item or refund you. This will be the path of least resistance if within the return window.

Fight for a pre-paid shipping label if the product is defective through no fault of your own. If they sold you a broken item, you should not have to pay any shipping costs.

Filing a Manufacturer Warranty Claim

When filing a warranty claim, we recommend contacting the company exclusively via email if possible. Live chat windows are also OK; however, make sure you save a record of the conversation. Not all chat windows will offer a log download option at the end, so we recommend taking regular screenshots of the entire chat. Email is preferable as it is easier to store and timeline.

Approach

Approach the support representative professionally and calmly. Although frustration has its place in the RMA process, it’s better to save that as an escalation step.

State to the representative in clear, plain language what has failed. Do not elaborate until they ask for elaboration. Typically, representatives will ignore additional detail until they ask you some questions, so you will grow frustrated repeating yourself -- best to just keep it simple at first.

Let’s take an example. If you have a failed microSD card slot reader on a device, you might write the below:

“Hello,

My ASUS ROG Ally cannot read microSD cards. My serial number is ABC123. I bought the device 6 months ago. I would like to start a repair process under the warranty. My order number is 0123456 and I purchased it directly from ASUS. 

Thank you.”

That’s it. This is clear, concise, states the timelines they need, but doesn’t overburden them with information that will likely be ignored until they ask follow-up questions. There is no need to explain all of the troubleshooting steps. They will prompt you with those, and as they arise, you can inform them professionally, clearly, and plainly, but politely, that you have taken (or are taking) each step as it arises. Dragging a representative off-script will only cause more frustration. Remember, our end goal is to get the device fixed.

Let’s turn this into a series of templates.

(Template) Initial Correspondence

We spoke with a few (good-intentioned) industry warranty centers and asked them what email would most effectively produce a quick path to answers. The below is a combination of this guidance and our own experience.

For your first contact, try an adapted variation of the below:

Hello,

My [DEVICE NAME] is exhibiting a problem with the [COMPONENT]. The serial number is [S/N NUMBER] and the model or part number is [PART NUMBER]. I bought this device on [DATE]. I would like to start a repair process under the warranty. My original order number is [ORDER NUMBER] from [MANUFACTURER OR RETAILER]. Please advise.

Thank you,

This is polite, clear, and professional. Providing the dates and order numbers early will accelerate your process, especially if it is email. We find email to be less frustrating than chat, as there is often less repetition.

When the representative responds, they will likely ask you to perform some troubleshooting tasks. Rather than listing everything you have done, instead allow them to tell you what to do. If you’ve already completed that step, tell them and note whether it worked or not. This will save frustration by not providing unnecessary or unhelpful information. Remember that most representatives follow a script.

Ask the representative to confirm that the defect is covered under the warranty. Get this in writing and save it.

Once this phase is done, they will likely begin the process of starting a repair. 

(Template) If the initial response is positive:

You will begin the process of the repair. Send this to the support representative after reading and responding to any of their questions:

Hello,

I will begin packing the device to return it. Can you please help with a few questions?

1: Should I include any of the device accessories with the device? Will I get them back if they are included?

2: If I still have it, should I pack the device in its original packaging? Will I get it back if I do?

3: Can you please provide detailed packaging instructions to protect the product in shipping?

4: Can you please provide a shipping label for the defect?

[if the device has storage] 5: For security purposes, I am going to remove my SSD or storage device to protect my data. Please note this in my ticket.

Thank you,

This is designed to create some legal standing and ammunition for a pushback later.

GN strongly recommends removing your storage devices. In the US, a manufacturer should not use this against you, and if they do and you are in the US, you may cite the Magnuson-Moss Warranty Act and state to the agent that you will file an FTC report if a warranty claim is rejected for an unrelated modification. If your device has internal (soldered) storage that cannot be removed, we recommend BACKING UP THE DEVICE. If the manufacturer replaces your device, YOU WILL LIKELY NOT GET YOUR DATA BACK. We would also recommend removing any sensitive information from the device prior to dispatch.

Save the answer to the above questions. Follow the packing instructions precisely and document this.

(Template) If the initial response is negative:

“Respectfully, it is my understanding that the Warranty included with the product covers defects of material quality, workmanship, and design for a period of [YEARS WARRANTED]. I would like to send my device in for inspection and would appreciate you helping me to do that. Are you saying that this product is not covered by the Warranty? If so, please state your reasons why.”

If the response is still negative and if you disagree:

“Between the written Warranty of the product and the Warranty provisions by the FTC, I believe that my claim should be covered. Can you please escalate me to a supervisor? Thank you.”

At this point, your goal is to get a ticket generated and get the device in front of them. Because the device is not even there yet, this should be achievable.

Progress will be easier once it is there as the path of least resistance then would be to just fix it or send you a replacement.

Possible Rejection Reasons & Responses

Once the device is received, remember it is possible that you have in fact caused some damage to the device. In such an instance, you should have ample documentation from prior to sending the device in. Always remember to check your own documentation and photos before pushing back.

Having this documentation is for two reasons:

1. To check that your own memory of events is correct and prevent from being gaslit by a manufacturer
2. To check that, perhaps, you did cause some damage. In this event, check next that the damage is relevant to the claim. If it is not, it is not a valid reason to reject the claim

The manufacturer’s most likely reasons for rejection will be:

• Liquid damage
• Customer-induced damage
• Tamper seal or “Warranty Void” sticker punctured, or a makeshift interpretation of this
• Unwarranted failure
• Unwarranted use of product
• Wear and tear

Let’s go through this:

Liquid Damage: This is a very common counterclaim and is almost used as a blanket statement. If you know the device has never been exposed to liquid, the only remaining explanation for a liquid sensor tripping would be from a humidity sensor. Assert with the manufacturer that the device has never been exposed to liquid and demand evidence of their claim. If they indicate a humidity sensor, state that this does not constitute liquid damage and that the device has never been exposed to liquid (if this is the truth).

Customer-Induced Damage: Ask for photos of the claimed “CID.” Compare that photo with your own documentation. If indeed the damage existed and was caused by you, next determine if it is relevant to the repair. If it is not relevant to the repair, state that you would like to ignore the “damage” and proceed with the repair of the [failed component]. If there is pushback, we’d recommend watching our video (embedded above) with Nathan Proctor to learn about your consumer rights in this regard.

Tamper Seal or Warranty Void Sticker: Warranty Void stickers are not enforceable. The FTC has stated, and now has cases reinforcing (see: Harley-Davidson, Weber Grills), that consumers and third-party service providers have a right to repair a device without the manufacturer’s involvement. Puncturing a sticker is not sufficient to reject a claim. 

Unwarranted Failure: This is trickier. You would have to ask more questions about why the failure is not covered. If, ultimately, it has nothing to do with your use and is not a consumable item, then push back.

Unwarranted Use of the Product: First, we’d recommend against telling the manufacturer how you use(d) the product. There’s no real reason to give them that information. If the manufacturer claims your use is not covered, ask them to show you where in the Warranty it is stated that your use is explicitly not covered. Maybe that’s true -- but ask for proof.

Wear & Tear: This can be reasonable. As an example, a T-shirt that develops a hole over a period of years or a tire that has its tread worn. In electronics, this might be reasonable battery wear from excessive use: For instance, a 3-year-old phone would reasonably be expected to have severely reduced daily battery life by nature of how a battery works; however, a 3-month-old phone would be reasonably expected to bear similar life (capacity) to its original state. There is nuance in a wear & tear rejection. If you believe your claim to be reasonable, calmly explain why and ask for an explanation.

Ask for photographs of any claims from the warranty center pertaining to damage and check them against your own.

Examples of Documentation

When documenting your device prior to sending it in, we would recommend taking photos of:

• All sides of the device (in as high a resolution as you have available)
• Serial number stickers
• A brief video (cell phone is fine) of the defect itself. This will give you evidence of your original claim
• If the device is being opened anyway, photos of the internals. If you have no need to open the device, we would recommend against doing so if it’d only be for this step
• If the claim is something you can log in software, such as overheating, save a log file of the issue. You can use HWINFO and GPU-Z for most PC or handheld components. Worst case, take a photo of an overlay illustrating the issue
• Take photos of the packed device and the packed box itself

Example Device Documentation

For motherboards, it's very important that you also photograph the socket as closely as you can.

You should also document chat logs:

The point of all of this documentation is to only use it in the event you need to disprove a statement by the manufacturer. The goal is never to escalate to an actual court. That’s an option (and you can get Attorneys Fees in some situations under Magnuson-Moss), but no one realistically wants to do that. The best use case is to use this material to appeal to reason of a supervisor -- even if that means a reminder that you are protected under Federal law for a valid claim with a flourish of evidence.

Understanding Warranty Language

For this, we're including two videos featuring Attorney Vincent Agosta where we had discussions pertaining to ASUS' warranty processes. Although we spoke of ASUS, these apply broadly and can also help inform as to how to interpret certain language:

Contacting the Media

Finally, a last path of escalation is contacting the media. There are many outlets that may be happy to help you. We can only speak for ours, but normally the biggest limiter is just the volume of viewer emails. We can't read them all.

But it's worth contacting various members of the media for help if you do have a problem. Because responses aren't guaranteed, we'd recommend keeping them short and to the point (mostly so you don't sink a ton of time into something that may not be read).

When we do happen to land on one, we do our best to expedite our viewers’ claims through PR channels (rather than support channels) when we can. It’s almost always a guaranteed resolution: PR’s job is to stop problems before they happen, so there is a motive to rectify it.

However, for many reasons, we can’t help in every case. Those reasons include:

• Time and volume: We probably get hundreds of warranty support requests per year. To familiarize ourselves with them enough to help is time-intensive
• Scammers. There are legitimate reasons for companies to reject claims
• Not enough evidence. If the viewer doesn’t have enough supporting documentation, we may not be able to assist

We have learned over the years how to better vet these claims from viewers. Unfortunately, the few who seek to scam companies are those who ruin it for everyone. We do still try to help whenever possible, though.

Getting Media Attention

The best way to get our attention is:

• Write us a clear and concise email. Don’t dump pages of text and backstory on us -- just the facts
• Up front, tell us if anything potentially illegal happened, like a demand for money in exchange for a warranted repair
• Attach supporting evidence or documentation, such as screenshots of the manufacturer emails/rejections and photos of the device issue
• Tell us in plain, clear language what the current status of the warranty is and what you think should have been done
• Let us know if you still have the device in your possession and if it is unfixed

We somewhat regularly buy broken devices from viewers to send them in for warranty tests. We can't do this for everyone, but if we're interested and feel like there's enough documentation to prove the viewer didn't cause the damage, we will respond and ask to buy the device outright to assume ownership of the warranty.

Although media outlets may not publish your story, even just forwarding it to a PR rep can often get it resolved. It doesn't fix anything in the company, but at least on an individual level, it helps someone.

Chargebacks & Financial Protection

One important resource many people are unfamiliar with is a chargeback. If a device has failed within a reasonable time since purchase, and if the company is refusing assistance, your next avenue (after communicating with the company) could be a chargeback.

This is a tool that is provided by most credit card vendors. Chargebacks create a financial incentive (fines) and provide strong consumer protections in the event your case is well documented.

The steps would be:

1. Contact the company first and seek a refund or replacement
2. Document this contact and their refusal (if it is refused)
3. If the company does not assist, contact your credit card provider and ask about the process of filing a chargeback
4. Provide documentation to the credit card vendor to reinforce that you have already contacted the company. They will (in our experience) always ask you to contact the company first
5. If resolved in your favor with evidence, the matter should be closed and your funds returned

Additional Resources

For some additional resources, particularly for our US-based audience, we would recommend looking into these groups. These organizations can help keep you informed with goings-on in consumer rights, Right to Repair, and warranties:

• Public Interest Research Group (PIRG). They regularly send out newsletter updates and post blog entries about action, lobbying, and lawmaking pertaining to Right to Repair and Warranty laws
• The Electronic Frontier Foundation (EFF): The EFF fights corporate (and other) surveillance and pushes for free and open access to information. The EFF is also involved in consumer rights topics related to these
• Federal Trade Commission - Consumer Protection: This sub-page of the FTC website keeps tabs on published Acts that relate to consumer rights and protection
• Report Fraud FTC Page: This page is for reporting all kinds of fraud, including warranty and right to repair.

We will update this page if we think of more examples to add.

GamersNexus responds to Linus Sebastian's WAN Show segment

Evidence Included

• PLAGIARISM: Receipt #1 - History of Failure to Resolve Issues
• DATA ERRORS: Receipt #2 - History of Failure to Resolve Issues
• EDITORIAL DISPUTE: Receipt #3 - Unprofessionalism in Prior Communications

Table of Contents

• AutoTOC

Intro

On January 17, 2025, Linus Sebastian, Founder/CVO of Linus Media Groups and property Linus Tech Tips, explicitly requested that we produce “receipts” relating to comments we have previously made. The quote is below:

“I would also be very curious to see receipts for the claims that we have a ‘history of failure to resolve issues or unprofessionalism in prior communications.” - Linus Sebastian

Sebastian on multiple occasions insinuated that we were defaming him and his company and suggested that we are dishonest. In our publication on this page, upon explicit request by Linus Sebastian, we will be providing the requested evidence. We will also provide corrections to his additional errors. 

This evidence provided highlights the following, all of which occurred prior to GamersNexus’ 2023 video: 

• Plagiarism by Linus Tech Tips of GamersNexus content wherein we previously privately reached out without resolution
• Unprofessional and aggressive communications in private
• History of failure to resolve data accuracy issues that were privately raised

We have spent several years keeping all of this information private as a courtesy. However, with recent demands from Linus Sebastian to produce “receipts,” and with his segment containing numerous factual errors, we are now providing the details below.

Additional history of Linus Sebastian’s failure to resolve issues or unprofessionalism in prior communications are available; however, as a continued ongoing and professional courtesy, only the minimum amount of interactions are presented below that are needed to prove the claims that were made and provide the requested evidence.

Credits

Writing

Steve Burke

Context

In this publication by Linus Media Group on the WAN Show and LMG Clips, the latter of which was originally entitled “Is GamersNexus Ethical Journalism?” later renamed to “Linus emailed Gamers Nexus,” and most recently renamed to “Can Linus & Gamers Nexus Ever be Friends Again?,” Sebastian stated the following:

“Since we’re at this: I would also be very curious to see receipts for the claims that we have a ‘history of failure to resolve issues or unprofessionalism in prior communications.’ OK. GN further writes, ‘we previously had non-public contact with this organization’ (LMG here) ‘about similar matters that were not resolved satisfactorily or wherein we sometimes were the recipients of aggressive messaging pertaining to review topics.’ That is an extraordinary claim that I believe requires extraordinary evidence.”

For the full context of this clip, you may watch from approximately 10:22 until approximately 12:38. This is what we believe contextualizes the request for “receipts.” Of course, you may watch the entire video if you like and decide what you believe the context is. It is linked above.

On the screen during the above quote, Linus Sebastian reads from a Gamers.Nexus mini-site post (click the “Problem with Linus Tech Tips” accordion), wherein we shared our reasoning for not contacting Linus Sebastian or Linus Media Group in advance of publication of our video entitled “The Problem with Linus Tech Tips: Accuracy, Ethics, & Responsibility,” published on August 14, 2023. The criteria being discussed is included in full below. 6 different criteria were met, of which this is one of them:

“Criteria Met [for no contact]: History of Failure to Resolve Issues or Unprofessionalism in prior Communications (we previously had non-public contact with the organization about similar matters that were not resolved satisfactorily or wherein we sometimes were the recipients of aggressive messaging pertaining to review topics).” - Gamers.Nexus

All criteria that were met can be found here.

PLAGIARISM: Receipt #1 - History of Failure to Resolve Issues

Context:

In a September 16, 2022 publication of the WAN Show with over 2,000,000 views (“The Biggest Tech Divorce”), Linus Sebastian read from a script about the EVGA / NVIDIA split. The script nearly identically matched the order, topics, and words of a GamersNexus report with 1,800,000 views, and yet at no time in the segment did Linus Sebastian cite GamersNexus or its author. 

As additional context, this incident closely followed a GamersNexus video published on August 12, 2022, one month prior to this EVGA WAN show segment, where GamersNexus publicly criticized Linus Media Group relating to LMG’s warranty policies. 

In regards to the plagiarism, Linus Media Group never satisfactorily resolved this issue or publicly acknowledged this theft of content or lack of citation. GamersNexus did not previously bring this issue publicly.

EVGA Coverage Context:

GamersNexus was one of three members of the media with access to the story that EVGA would quit manufacturing video cards; further, GamersNexus was the only party of the three which was familiar with several matters of the EVGA / NVIDIA split. GamersNexus was the only party privy to this additional information as the conversation was held in Mandarin Chinese between this author, Steve Burke, and EVGA CEO Andrew Han. No other parties to the conversation spoke Mandarin, and as a result, GamersNexus had exclusive access to several pieces of information.

Evidence:

View full-size image here.

This email was sent to the following individuals:

• Linus Sebastian, then CEO
• Luke Lafreniere, CTO
• Nick Light, COO

Result

As of January 20, 2025, nearly 3 years later, there has been no public acknowledgement of the plagiarism, nor retraction of the content in the WAN Show upload with 2,000,000 views. The WAN Show upload and LMG Clips videos do not reference or cite GamersNexus either verbally or on screen at any point for the EVGA story. 

• In the LMG Clips subsequent upload with an additional 107,000 views, as of this publication, there has still been no attribution to GamersNexus in any form, including pinned comments.
• On the WAN Show 2,000,000 view upload, as of this publication, there has still been no attribution to GamersNexus in any form, including pinned comments. The only change made, after responding to our email, was a pinned comment stating “shoutout to Jayztwocents and Steve,” which is not the same as a citation, without ever acknowledging GamersNexus or the plagiarism or naming the author in full. This does not adequately cite the author and does not resolve the issue. Jayztwocents had already been cited verbally in the piece.

GamersNexus reached out privately and in good faith to inform Linus Tech Tips of this serious issue. The expectation was that LTT/LMG would resolve it satisfactorily and inform the public of any wrongdoing. The public was never informed, and GamersNexus was never attributed.

DATA ERRORS: Receipt #2 - History of Failure to Resolve Issues

Context

In this thread, which was cordial by all parties, we privately addressed a number of errors made in the video “Delidding a $1000 CPU - Worth the RISK??” These errors contributed to the presented platform instability and poor thermal results shown at various points in the video. These were not publicly corrected by LTT/LMG, and this predates our 2023 publication (“The Problem with Linus Tech Tips”).

Evidence

Ordered left-to-right.

We reached out privately and alerted Linus Sebastian to the issues. Sebastian copied a staff writer. We felt the communication was cordial; however, Linus Tech Tips never posted a pinned comment, never updated its description, and never otherwise publicly noted the numerous test setup errors on the video in question, as of the date of this publication, which is around 7 years later. The video has 2,292,280 views as of January 20, 2025. This was not included in our August 2023 coverage, as it was from several years prior and we only focused on the most recent year of errors, as disclosed in that video.

EDITORIAL DISPUTE: Receipt #3 - Unprofessionalism in Prior Communications

Context

On June 2, 2021, GamersNexus both replied to and tweeted about a reddit thread relating to the pricing of the RTX 3080 Ti cards, preceding the launch of the 3070 Ti. The full conversation is included below and occurred on June 11th, 2021, following the launch of the 3070 Ti. As it is from an ongoing text thread which may contain discussions from earlier or following events, and does not have clear start and stop points, if Linus Sebastian publicly requests for any prior or following text messages to be published, then we will amend this article with additional evidence.

We later privately followed-up via email providing the reddit thread and timeline to further assure Sebastian that the matter was not related to him. We are also prepared to release these emails if publicly requested by Sebastian.

We also allege that there were derogatory comments made by Linus Sebastian in a conversation with Steve Burke on a private phone call on August 31, 2021 at 7:31 PM Eastern lasting 9m 43s, where Sebastian referred to Burke as being “less autistic than you used to be;” however, with no recording of said call, this can only be alleged and there is no additional evidence to provide. Ultimately, these examples, among others still being kept private as a courtesy, made me personally uncomfortable engaging in private communications with Linus Sebastian when relating to editorial differences, perceived or actual.

Additional Evidence

GamersNexus believes that these “receipts” answer the demand to provide them to support our statements that Sebastian has a history of unprofessionalism in prior communications while still maintaining the maximum possible integrity of the privacy of the conversations. If publicly requested by Linus Sebastian to produce further evidence, GamersNexus is prepared to publicly do so.

Additional Errors and Misrepresentations

The WAN show publication (January 17, 2025) and LMG Clips segment (January 18, 2025) further included several wholly and provably inaccurate statements and misrepresentations. In interest of brevity, we are listing only a few of them below.

ERRORS AND MISREPRESENTATION: Example #1 - “Special Treatment”

Linus Sebastian, in his WAN Show segment (03:18), used a previously published video clip from Ian Cutress containing errors. This advanced inaccurate statements and was used as evidence for Sebastian’s own erroneous claims. In the time since his video went up, we publicly addressed these timelines, which we will detail again below. 

We believe Linus Sebastian’s reliance upon these incorrect statements is used as evidence that GamersNexus treats Linus Sebastian and Linus Media Group unfairly and that GamersNexus reaches out to other companies in advance, but not Sebastian or LMG. The relevant quote from that clip, which Sebastian included in his recent WAN show addressing GamersNexus, is as follows:

“One part of ethical investigative journalism is, unless it’s covering an explicit crime or breaking the law, reaching out to get a formal response in advance. GamersNexus did it with Principled Technologies and that blew up. GamersNexus did it with Newegg and that blew up. Somehow, those companies got special treatment, but Linus Media Group did not.”

This quote occurs around 3:29 in the LMG Clips upload and can be watched in full for further background information.

These statements relating to Principled Technologies and Newegg are factually incorrect. The facts of these two examples, as published on our site, are as follows:

Principled Technologies: “Our first story (in the ‘Mix’ column) involved outreach from Intel and no contact to Principled Technologies. In that story, we stated that we’d be driving over to their offices as that video went live. While possible they had about 10 minutes heads-up if they saw that video, we did not contact before the content, because they were the content.”

Newegg: “We did not contact Newegg in a non-public fashion in this piece. In the first piece, we publicly blasted Newegg on Twitter as the first entry (after anonymously contacting customer support — which was part of the review as a consumer) and then published our video. Newegg actually replied to our tweet and asked us to talk. We told them: ‘We can talk after our video goes up. I'm not a big fan of disingenuous attempts to fix an issue after it's revealed that the mistreated customer has a following.’ We ran the video without their comment because it had become a true customer service investigation — normal customers don’t get PR channels, so we refused those channels and also we publicly exposed them before they even attempted them. It wasn’t until we visited them that Newegg had a real chance to comment (see: ‘Contact’ to the right).”

These errors could have been avoided by Linus Sebastian had proper research been conducted before making irresponsible and false statements. Further errors have also been documented but have been held for brevity. 

MISREPRESENTATION: Example #2 - “I never got a response” - Linus Sebastian

Linus Sebastian in his WAN show segment on January 17, 2025, timestamped at 14:35, stated that he sent a text message to Steve Burke of GamersNexus following the August, 2023 “The Problem with Linus Tech Tips” video. 

Sebastian states: “My last message to him was on the day he published the exposé and I never got a response.” However, Sebastian did not text Steve Burke’s current phone number, yet he has previously been in frequent contact via the current, correct number. 

Here is a timeline:

• In approx. August, 2021, Steve changed phone numbers due to his prior number leaking publicly
• Steve contacted Nick Light, COO of Linus Media Group, and Linus Sebastian, then-CEO, to inform them of the change
• Several conversations ensued over the following 2 years between Linus Sebastian and Steve Burke on this phone number, an already-public example that proves this as follows:
• At approximately 05:00 AM on March 23, 2023 and from his current and correct phone number, Steve repeatedly called and texted Linus Sebastian’s personal number to awaken and alert Sebastian to a channel hack wherein Linus Tech Tips had been compromised and taken over by hackers. Sebastian has publicly acknowledged and shown these texts in this video (“My Channel Was Deleted Last Night”). Sebastian and Steve continued to text via this correct and current phone number numerous times in relation to the hacking event.
• On the date of publishing our August, 2023 “The Problem with Linus Tech Tips” video, Sebastian claims to have texted Steve a lengthy message. Sebastian did not, in fact, text this to Steve’s correct phone number. After investigation, we found that he sent it to Steve’s prior phone number -- one which Sebastian had not sent any texts to since approx. July 9, 2021, years prior.
• On January 17, 2025, Linus Sebastian claims he “never got a response” from a 2023 message sent to a number no longer actively monitored by Steve (but still held in storage for security reasons)

Substantial evidence exists, and we are prepared to provide more upon Sebastian’s public request, to demonstrate that Linus Sebastian has been aware of and has actively engaged with Steve’s correct phone number for at least two years preceding the message shared on January 17, 2025. This is a mischaracterization of the actual events and publicly unfairly depicts GamersNexus, and in particular Steve Burke, in a negative light. 

Additional Errors / Conclusion

If Linus Sebastian would like to make a public video requesting our further elaboration, he can do so and then provide us with a full transcript of his WAN show segment. We will proceed to go line-by-line and dispute all false timelines, inaccuracies, and omissions from his WAN show segment, of which there are many more. Short of that, we have provided the above examples of some of the critical errors from his video, and provided the requested and sufficient receipts to evidence our claims.

Email to Linus Media Group

Upon publication of this article, we sent an email to Linus Media Group’s executive team. The email is enclosed below.

--

Terren, Linus, Luke, Nick:

In LMG’s WAN Show segment, Linus Sebastian stated the following:

“I think it is undeniable that these omissions and errors are significant and that they've done significant, possibly irreparable damage to my reputation, to my company, and to my finances. To be clear, I'm only pointing out the finances because it's such an important factor in cases of libel and defamation.”

This statement escalates tensions to the highest severity and necessitates our response.

Sebastian also stated:

“I would also be very curious to see receipts for the claims that we have a ‘history of failure to resolve issues or unprofessionalism in prior communications.’”

Given the severity of these accusations and what we perceive to be veiled threats, and given the direct request of “receipts” by Linus Sebastian on the show, please find the following information:

We have published our official response to the WAN Show segment on our website. In our publication, upon explicit request by Linus Sebastian, we provided “receipts” / evidence in regards to Linus Sebastian’s, and as a result, Linus Media Group’s and Linus Tech Tips’ “history of failure to resolve issues or unprofessionalism in prior communications,” as well as corrections to several of Sebastian’s inaccuracies, false statements, and misleading representations. 

We unequivocally deny and reject your statements and false claims of defamation. In contrast, we assert that the provably false and misleading statements that have been distributed by Linus Media Group as a company, and Linus Sebastian in his own personal capacity, have caused extensive and significant harm to GamersNexus, LLC and the owner, Steve Burke, in both a direct financial manner, as well as a significant reputational manner, that continues to be unmitigated and accrue additional damages with each passing day that the content is allowed to propagate knowingly false information, including, but not limited to, Linus Media Group’s continued profiting off of content plagiarized from GamersNexus, LLC. We view your coverage as irresponsible, negligent, and damaging. 

Frankly speaking: I feel Linus Sebastian has provided a manipulative and deceptive offer to try to “bury the hatchet,” create a “team media,” and encourage a “brotherhood” as if it is a personal spat between friends. I believe Sebastian’s statements are intended to diminish the seriousness and impact of any criticism by any creator toward Linus Sebastian or Linus Media Group, and suppress current and future coverage. Sebastian’s recent calls for friendship were accompanied by serious legal allegations and claims regarding the ethics and motives behind our entire business. We believe this is a play on parasocial relationships, reinforced by Linus Media Group’s decision to re-title the LMG Clip “Can Linus & Gamers Nexus Ever be Friends Again?”, where it paints GamersNexus as a friend who just needs to make up with LTT so things can “get back to normal.” This suppresses dissenting views by pretending to be everyone’s friend, so a legitimate critique seems like a personal attack to onlooking viewers. At this stage, Linus Media Group and GamersNexus have both made statements which are extremely serious. This is far beyond presenting a front of friendliness, and I am respectfully requesting that Linus Sebastian drops that facade publicly, as well as ceases the repeated personal emails requesting as much, as it is personally making me extremely uncomfortable.

That said, I think Linus Media Group has some well-intentioned and extremely intelligent people, including Luke Lafreniere, and I feel there could still be benefit to open discussions relating to his efforts in LMG’s Labs, the industry, or coverage types. At Computex, if Luke wishes to, or if Luke and Linus Sebastian (collectively only), wish to speak privately, please feel free to let me know and we can talk. Given the legal nature of Linus Sebastian’s allegations though and on advice of our attorneys, we are neither willing nor able to discuss this specific topic further, and any further contact related to this matter will instead be forwarded to GamersNexus, LLC’s attorneys if a response is necessary. 

We will be at Computex and available on Friday, May 23 and can book a meeting room for a private discussion such as testing, hardware, the industry, or other topics unrelated to this matter, if Luke wishes to do so. 

Regards,

--

Steve Burke

Editor-in-Chief

GamersNexus

This page catalogs GamersNexus' errors and corrections going forward

The Highlights

• The list will include scope of the error, how the error was handled, and process improvements
• This page will be permanently available and updated as necessary
• We will use this to evaluate our own performance and keep ourselves accountable
• Initial dataset was created in October 2024, dating back one year from creation

Table of Contents

• AutoTOC

Intro

This page will catalog errors and corrections in our video content. We have a page detailing our error handling and quality control processes on the gamers.nexus ethics website, which you can find here. That linked page includes further details on what we classify as an error, how we judge its severity, and our processes for resolving it. It establishes the severity of errors by rank and defines the rank (No Impact, Low Impact, Moderate Impact, and High Impact), our responses for these, and thoughts on errors and corrections. 

This page will be used only for cataloging the errors, not for explaining the processes of identifying or ranking them (that’s linked above, along with details on what constitutes removal vs. an update). The errors process is reserved for errors only, not for disagreements of opinion.

Objectives

This page will be permanently available at this exact URL. The intent is that it is easy for anyone to see post-publication updates or corrections without having to locate and revisit videos. Centralizing these will help us not only ensure the audience has a central location for checking if anything important has changed, but also help us with tracking our error rates. It’ll let us see if we need to tighten things up at any point. We want this page to be easy to find and are endeavoring to make it highly accessible. As part of that, we will put it in the topnav or some other easily-found menu item on this website and will create an overlay graphic to insert into the beginning of most videos going forward that directs people to this page. As the URL is fixed, you may bookmark the page for updates.

Credits

Writing

Steve Burke

What Lands Here

• Data errors, such as test data that was later determined to be incorrect
• Typographical errors that could affect understanding of a product or chart, such as a data entry error resulting in a part being listed at “120 FPS” instead of “102 FPS,” as an example
• Major data or testing errors that result in the removal of videos on rare occurrences they happen (even after its removal)
• Moderate errors that may affect the understanding of a sub-topic
• Mislabeled charts or data that could affect the understanding of the information

What Doesn’t Land Here

• Errors made by manufacturers in their own specification materials, even if we reported on them. Those are not our errors. This page is intended for taking accountability of errors we make alone, so a CPU manufacturer getting its own USB IO spec wrong would not be here
• Typographical errors and other errors which have no impact on anything, e.g. “NVIDIIA” or “Phantex" and other similar examples

As we are starting this catalog page in October of 2024, we have decided to set an arbitrary start time by crawling back through our videos dating back to October of 2023 for inclusion. This is a slow and manual process. It is possible we have missed something, as there was no process for adding errors to this page until October of 2024. Older content with errors we’re aware of will already have the corrections and should have been addressed, but may not get reflected here if older than October of 2023, as we needed to choose a start date. Our process for going back through old videos mostly relied upon searching the YouTube back-end for descriptions including words like "error" and "corrections." If we missed any in 2024, you may email us at team at gamersnexus dot net. New additions will be maintained as they happen, so this will not be a challenge going forward.

Writing from first-person for a moment here: Although different people take responsibility for reviews and testing at different points in the process, ultimately, anything that makes it all the way to publication is my fault, as I still look at everything for sign-off. The upside of this is that, regardless of how the error was made originally and who made it, I am the one tasked with establishing processes to prevent similar errors in the future and help the team root-cause faults to improve as a team. I take accountability and responsibility for errors that make it to publication and am committed to the resolution process.

Going forward, any corrections we issue will now also include a standardized step to add them here. Please note that there may be a latency adding them, but we will try to do so immediately. Dates will be for the date that the content was originally published.

2025 Errors & Corrections

2025, November 29

Content Title: Best CPU Coolers We've Tested (2025): Thermals, Noise Levels, & Value | 26 Coolers Tested

Error: There is one labeling error in the 9950X3D "Full Speed" chart seen at 18:01. The test data is correct; however, the "Arctic Liquid Freezer III 360 Black" appears twice. One is 56.4C and one is 61.2C. The 56.4 degree result is the directly comparable 'normal' result and is the one that should be used in this comparison. The other result is a real result (61.2 degrees), but was for a one-off test with a modification to the test process, as this is a new test methodology and we do exploratory tests as a part of that process; however, these experimentations need to be labeled, and this is our error that it was not. This is unlabeled on this chart. This was part of experimentation for alternate test processes as we explored methodological choices. We will talk about some of these in the future methodology piece. Because both sets of data are present, this is a low impact severity.

Correction: We made the following changes: We added an in-video "correction card" pop-out on YouTube, updated the description, updated the pinned comment, and left a record of this change and error here and in the correction card in the description.

2025, October 13

Content Title: The Problem with GPU Benchmarks | Reality vs. Numbers, Animation Error Methodology White Paper

Error: The custom animation b-roll clip shown from 30:42 until 31:42 was misplaced and is a repeat of the clip preceding it, so it is not adding to the understanding of what we're explaining. The language is accurate and the script is correct, but the b-roll is mismatched.

Correction: We made the following changes: We added an in-video "correction card" pop-out on YouTube, updated the description, updated the pinned comment, and left a record of this change and error here and in the correction card in the description. The article has also been posted to include webm videos that are playable in-page to show the missing footage (which is a custom animation we made to ease the understanding of the topic, but only included half of the first time).

2025, August 12

Content Title: HW News - Arrests Over GPUs, Silicon Tariffs, 9950X3DX2 Rumor, Windows XP, & Dell Vulnerability

Error: In the video, we misspoke and appended "XT" to one mention of the RX 9060 (non-XT). The intent was to mention the announcement of the RX 9060, which is new, not the RX 9060 XT, which has already been out.

Correction: Immediately after publishing and a viewer noticing, we made the following changes: We added an in-video "correction card" pop-out on YouTube, updated the description, and applied a trim to remove the misspoken "XT" part (less than a 1-second cut), and left a record of this change and error here and in the correction card in the description.

2025, June 24

Content Title: NVIDIA RTX PRO 6000 Blackwell Benchmarks & Tear-Down | Thermals, Gaming, LLM, & Acoustic Tests

Error: In the video, we stated that the connector under the cover plate at the top of the card was an NVLink connector. This is incorrect and an error. These connectors are "NVIDIA Sync" and VESA 3D connectors.

Determination: We determine this as moderate impact as someone looking for NVLink information would be given incorrect information on this connector and the statement is simply factually wrong.

Correction: Shortly after publishing when viewers noticed this comment in our tear-down of the card, we made the following changes: We added an in-video "correction card" pop-out on YouTube, updated the description, applied a trim to remove the erroneous information, pinned a top comment, and left a record of this change and error here and in the video description & pop-out card.

2025, June 1

Content Title: Best PC Cases for 2025 So Far | Computex Round-Up & New Designs

Error: In the video, we stated that the Turbo Button back in the "old days" would often increase the CPU frequency. In the more famous cases, it actually would decrease the frequency from baseline (although there are instances online detailing both increases and decreases). This statement doesn't actually matter for the content, as we're discussing a modern case that uses the button for fan PWM control, but it did require more nuance and was, in at least one aspect, wrong.

Determination: We determine this as no impact to the content: (1) This is a video about the best cases from Computex and this statement has nothing to do with them; (2) the statement was commentary on why the Turbo Button exists, but not critical to the content itself.

Correction: We added an in-video "correction card" pop-out on YouTube, updated the description, applied a trim to remove the comment since it is lacking nuance, have updated the (pending, at time of this posting) article, and left a record of this change and error here and in the video description & pop-out card.

2025, April 17

Content Title: Insecure Code vs. the Entire RGB Industry | WinRing 0 Driver, ft. Wendell of Level1 Techs

Error/Clarification: The script reads: "And the list of software using this [WinRing 0] is huge, and that means the attack vectors are everywhere. EVGA Precision X1, Crucial Mod, HP Touchpoint Analytics, SignalRGB, OpenRGB, and many more are on that list."

Determination: We consider this Low Impact for the following reasons: (1) there is no impact on accuracy of the rest of the content; (2) the rest of the video provides context elsewhere that these tools have either already been updated to resolve CVEs years ago or no longer work due to quarantines. However, we do think the language used was not clear enough and used the wrong choice of tense. To assure absolute clarity with all listeners, past tense was not the right choice for this sentence. The sentence more clearly should read "and the list of software having used this [...]" rather than "using this." The intent, in the surrounding context of the video stating that these solutions had already moved past WinRing 0 in earlier and later sections alike, was to show that these solutions had used WinRing 0 at some point and were therefore vulnerable. The way this particular standalone sentence reads, however, is in the present tense. Listening back to it without context of the rest of the video, this is the incorrect tense to use and could lead to an incorrect understanding of the current situation. It would have been more accurate to use past tense or past perfect tense to communicate the current situation clearly or stick to only communicating the recent past situation.

Correction: We added an in-video "correction card" pop-out on YouTube, updated the description, and pinned a comment. The article will be updated to use the correct tense prior to publication and will not have the unclear sentence published. There is no impact on the greater content of the piece.

2024 Errors & Corrections

2024, November 17

Content Title: Intel At Its Best: Revisiting the i9-12900K, i7-12700K, i5-12600K, 12400, & i3-12100F in 2024

Error: The 12400 is listed as "i5-12400 (6P/6E/12T) [10/24]." It should be listed as "i5-12400 (6P/0E/12T) [10/24]." This is a specification listing error (name entry error) that has no impact on performance or results.

Determination: We consider this Low Impact. It affected multiple charts and could lead to a misunderstanding of the spec. We are frustrated at this getting through though and are elevating it to Low Impact. It is a typo, but of a spec, and is objectively wrong. Immediately following this, we made changes to our data export process to stop this from happening.

Correction: We added an in-video “correction card” pop-out on YouTube, pinned a comment, and updated our chart labels for the article adaptation. We have made changes to future processes, including an extra QC step from Steve at the end of future exports to sign-off on data labels.

2024, November 6

Content Title: RIP Intel: AMD Ryzen 7 9800X3D CPU Review & Benchmarks vs. 7800X3D, 285K, 14900K, & More

Error: In the video, due to a combination of an unexpected BIOS behavior and a gap in our process, we missed a BIOS setting that changes based on which CPU is installed and caused low performance unique to the 7950X3D data. 7950X3D CPU data is low for this round. No other data is affected. There is no impact to conclusions in the 9800X3D content or to any other CPUs. This does not affect the prior 7950X3D review content, as this was not an issue then.

Determination: We consider this Moderate Impact for the following reasons: (1) the error affects multiple charts; (2) the affected CPU was not central to the story or comparisons, as we generally advise either going for a non-3D 16-core (for workstation) or an X3D 8-core (for gaming). It does not escalate because it has no impact on the core of the content, which was analysis of the 9800X3D, primarily against the 7800X3D, 5700X3D or 5800X3D, and Intel competition.

Diagnosis: We ran extensive additional testing on this to fully understand the issue and leave nothing to speculation. If you would like to learn more about precisely what happened (and it would be useful for people potentially upgrading to a 7950X3D), then you can find the entire diagnostic report in our HW News episode which goes over the specific settings and what we ultimately feel is our own testing oversight.

Correction: To correct this error, we posted a Hardware News (HW News) episode entry (as it was an educational mix of issues that could help inform users) explaining the issue in-depth, provided new charts with updated numbers, updated the charts on the written review article to contain the new data, pinned a comment, updated the description, and added a YouTube in-video "correction card" pop-out. (Update 10/11/24: Changed sentence structure to past tense, as all changes have now been made).

2024, October 10

Content Title: Intel Core Ultra 285K, 265K, & 245K CPU Specs: Bending Fix, Power Reduction, & Prices

Error: At 01:03, an Intel slide presented the differences between the Ultra 265K and the 14900K as being down 5% (or -5%). We misread this slide as the Ultra 285K and misreported that it was down 5%. Intel instead claimed the 285K is down 1.1% (-1.1%) from the 14900K.

Determination: We consider this Low Impact for the following reasons: (1) -5% and -1.1% are not meaningfully different in the scope of a news report on performance; (2) the error could be cut cleanly with the YouTube trim tool; (3) there is no impact to conclusions, especially as this was a news report.

Correction: To correct this error, we trimmed about 5 seconds out of the video with the YouTube trim tool, added a YouTube in-video “correction card” pop-out at the affected timestamp, updated the description, sent a tweet, and pinned a comment. For transparency and historical accountability, all of the updates listed remain in-place, despite the error no longer being present in the video.

2024, August 24

Content Title: Actually Good: $2400 Starforge Pre-Built Gaming PC Review (Lowkey Fractal Terra ITX)

Error: At 23:50, the frequency spectrum chart X-axis label was truncated due to software charting settings and limitations. It truncates the X-axis frequency to a single 0. 

Determination: We consider this No Impact for the following reasons: (1) there is no incorrect interpretation by a user capable of using the data that would make sense; (2) all of the writing and scripting is completely accurate to the chart; (3) the testing is accurate. As such, this is a typographical error on a chart label (technically, it was typed correctly, but truncated by proximity of the axis line) with no impact to the data itself.

Correction: We updated the description with information on this and pinned a comment. There is no impact to interpretation (especially not for anyone who’d know what to do with the information). The script is correct and completely accurate. The chart label is incorrect. 

Improvement: We have fixed our chart templates for frequency spectrum plots to resolve this going forward.

2024, May 9

Content Title: HW News - Intel is a Cluster, NVIDIA Blackwell Boosts Production, Sony "Still Learning"

Error: At 07:56, a story discussing Sony “still learning with Helldivers 2” brought-up a series of breaches and hacks of Sony’s systems. We at one point misspoke the company name and transposed it with another company’s name (Intel) that was also on this list of corporate breaches. We made an error. The intent was to say “Sony.” 

Determination: We consider this No Impact for the following reasons: (1) it was clear to listeners that this was a misread, as any other word other than “Sony” would not make sense; (2) it was easily trimmed, with a fully transparent update left in place and an in-video correction card at the timestamp.

Correction: To correct this error, we trimmed about 2-3 seconds out of the video (removing the reference to the company name, allowing the rest of the sentence to remain in-tact and accurate), we added an in-video YouTube “correction card” pop-out at the affected timestamps, updated the description, and pinned a comment. For transparency and historical accountability, all of the updates listed remain in-place, despite the error no longer being present in the video.

That brings us to the end of the 2024 list. If we missed anything in our crawl back through time, you may email us at team at gamersnexus dot net. We only endeavor to add errors which had an impact on the content. Errors with no impact, such as no-impact typos, will not be added.

2023 Errors & Corrections

2023, November 20

Content Title: Crazy Efficient: AMD Threadripper 7980X & 7970X CPU Review & Benchmarks

Error: Various charts within the review contain an incorrect product name label for the older Threadripper 3960X. Only the label is wrong. No data is affected by this error.

Determination: We consider this Low Impact. It affected multiple charts and could lead to a misunderstanding of the spec and is a frustrating error that we should have caught, and so we are elevating this to Low Impact as a result, despite technically being a ‘typo.’ Fortunately, it was not for one of the parts being reviewed directly and was of a discontinued CPU.

Correction: We added an in-video “correction card” pop-out on YouTube, pinned a comment, and updated our chart labels in the immediately ensuing review. 

Improvement: After this, we added a new QC pass in reviews where a Writer / Technician performs QC on only the product labels (and nothing else) to ensure at least one person is always checking those.

2023, October 19

Content Title: New AMD Threadripper 7980X, 7970X, 7960X, & Threadripper Pro CPUs Announced

Error: At 07:17, the voice-over erroneously stated that the CPU in discussion has “68 cores,” which obviously doesn’t make sense. It should read “64 cores.” This was a misread of the script, which wrote the correct line but was vocally read incorrectly. This is an error.

Determination: We consider this Low Impact. The on-screen material contradicted the voice over and later references to the same spec were correct, helping make clear that this was an error.

Correction: To correct this error, we added an in-video “corrections card” pop-out at the timestamp, updated the description, and pinned a comment. This got by two people and we should have caught this. 

Improvement: Following this, we created a formal internal QC SOP for news videos specifically to add one additional layer of review in most cases. We have no illusions that this will catch everything forever, but it will catch most errors.

2023, October 8

Content Title: [Outdated - New Tests] Counter-Strike 2 CPU Benchmarks: E-Core Challenges & X3D Benefits

Error: During testing, we did not remove the forced 400 FPS limit. Removing the FPS limit (at that time) required a console command to be manually entered at game launch. We did not use this command. There is room for debate as to whether it should be expected to use console commands to override framerate limits (400 FPS) in benchmarking; however, the simple fact is that if we had been aware of this command, we would have unlocked the framerate to verify. As a result, we considered this a test oversight, despite technically not being “wrong” (meaning: it was accurate as tested, but we would have preferred to test it without the engine limit). This still lands on the errors table because we prefer unrestricted tests.

Determination: We consider this Moderate Impact, as it affected multiple top-performing parts, but uniquely was still true to performance under the restricted conditions. Because we did not intend to test under those conditions, though, it gets “Moderate Impact” as the rank.

Correction: This particular issue accurately represented performance under conditions without console commands, but did not represent conditions as we’d like to see (uncapped). This involved subjective judgment, as it was questioning the test philosophy of using console commands to remove limits vs. what most users would do. We removed ourselves from that judgment process as much as possible by polling the community, which voted with 83% favor to leave the video in place but publish updated charts for the most restrained CPUs when running the command. This gave us the most data: Both engine-capped and uncapped. We followed the community’s vote.

We published updated benchmarks here and here. We determined that the vast majority of results for low & mid-tier CPUs were not affected, but that the top-ranked CPUs had truncated scaling due to the limiter. Because we still felt this was a test oversight, we decided to rename the original video to [Outdated - New Tests] to further highlight the limitations of the content; we also pinned a comment and updated the description to explain the limitations of the testing, explained the technical accuracy vs. the theoretical unrestrained results, ran a lengthy and dedicated HW News segment further elaborating (which gets higher views than follow-ups do to maximize audience awareness), and posted multiple YT Community posts about the matter. We also updated Cards and End Slate links to point to the HW News episode.

Closing Notes

This page was created in October of 2024. When we created it, we went back one year for inclusion of errors. We needed a starting point and one year made sense as a semi-arbitrary timescale. We have not yet gone back before October of 2023, though of course there are errors that pre-date this list. The ones we’re aware of are logged on the videos in which they occurred. We will continue adding to this list going forward. We also plan to use it to evaluate our total error rates over time to serve as a gauge of performance. This will be an ongoing maintenance project that will stay at this URL.

The everlasting objective is zero errors. We do pretty well with most videos. Errors are, however, inevitable at any publishing volume. We firmly believe that it is the handling of those errors that matters. That’s what this page is for.

Update Log

• November 9, 2024: Added a new entry for November 6, 2024.
• October 14, 2024: Initial creation of this errors & corrections page and initial data set dating back one year. Established internal processes for maintaining and updating the page.

Inspired by the Baldur's Gate team, we wanted to publish our own patch notes for the site this month

The Highlights

• Mega Charts are the next big implementation for the GN site
• We also improved some site functionality and speed, especially mobile legibility
• The table of contents overhaul delivers on a common point of user feedback

Table of Contents

• AutoTOC

Intro

We’ve been hugely inspired by the Larian Studios team developing Baldur’s Gate 3 and their impressive communication with the community for each major game patch. Although we can’t boast the 1000 improvements, features, and fixes they published for Patch 4, we did want to compile our recent change log for the site for those of you who want to know all the new details.

Our biggest change this past week came in the form of GN Mega Charts, which introduces our take on a years-old community request to publish a singular location for our most up-to-date information and benchmarks on certain component categories. There were other updates in addition to that, but we’ll embed the video for that one below.

Credits

Writing

Steve Burke

Camera, Video Editing

Vitalii mAkhnovets

Publishing Log

The past few weeks, we have published a number of articles to the website. These include dense, special feature pieces that are heavy on images and history (like the Voodoo / 3dfx retrospective), reviews and revisits (like the Ryzen 2700X in 2023 tests), and the Mega Charts that’ll get their own discussion section.

Because we are backdating a lot of articles to their original publishing date, they may not show up on the front page when converted to web format. To help you catch up on what’s been published lately, we’ll list it all below -- the team has been busy fulfilling this years-old promise to bring back the written content!

Mega Charts

• GN Mega Charts: CPU Cooler Benchmarks & Comparisons (permanently maintained/ongoing updates)
• GN Mega Charts: CPU Power Consumption (permanently maintained/ongoing updates)

Special Features

• Back from the Dead: 3dfx's Unreleased Voodoo5 6000 Quad-GPU Card (original video publish date: April 7, 2023)
• They Changed Everything: Valve Steam Deck OLED vs. LCD Tear-Down (November 11, 2023)

Round-Ups

• Best CPUs of 2023 (Intel vs. AMD): Gaming, Video Editing, Budget, & Biggest Disappointment (original video publish date: November 22, 2023)
• Best & Worst GPUs of 2023 for Gaming: $100 to $2000 Video Cards (original video publish date: November 23, 2023)
• Best Cases of 2023 So Far (original publish date: July 14, 2023)

Reviews

• Noctua NH-P1 Passive CPU Cooler Review: Benchmarks, Schlieren Photography, & Mechanics (original video publish date: June 29, 2021)
• AMD Radeon RX 7900 XT vs. RTX 4070 Ti Revisit in 2023: Benchmarks & Price Drops (original video publish date: October 31, 2023)
• AMD Ryzen 7 2700X in 2023: Benchmarks vs. 5800X3D, 7800X3D, & CPU Upgrades (original video publish date: November 16, 2023)
• Intel Core i9-14900K CPU Review & Benchmarks (original video publish date: October 18, 2023)
• Intel is Desperate: i7-14700K CPU Review, Benchmarks, Gaming, & Power (October 17, 2023)

Reasoning

Just to share our reasons for each of these:

The 3dfx / Voodoo piece is just plain cool. You all loved the video, especially for its historical and retrospective elements. That preserves well as text. We also wanted to get all the resource links and citations in one place for anyone who wants to study 3dfx further.

The Noctua NH-P1 remains an extremely relevant cooler even today, despite its 2021 release. We recently named it as one of the best coolers in our 2023 round-up, showing how relevant it is even today. It deserved an article conversion.

The Best Of round-ups were just obvious choices. They’ll perform well, from a business standpoint, but they’re also useful. A lot of people searching Google for that kind of information will land on spammy comparison sites without any actual data, so hopefully we can reach some of those people.

As for the more recent reviews, those are just keeping with the promise to deliver reviews to written format as soon as we can for long-term reference.

Site Improvements

In addition to what our team has done for article content, Wendell’s team has been busy patching and improving the website. They’ve made a number of large and small improvements based on emails from our readers (thank you for those!), including the below:

• A table of contents has been added (more below)
• Site speed has been improved even more. It was already fast, but we did some header image optimization to reduce image size of the feature / article hero image
• Some improvements to UI and layout for mobile and tablet devices, mostly related to usability
• Some improvements to font and text spacing in certain scaled viewing conditions

Table of Contents

The Table of Contents addition has been impressive. Krista on Wendell’s team (both at Level1 Techs) did all the styling work and, without any input at all from us, was able to execute on an awesome-looking navigational and UI improvement.

The ToC also works great on mobile. 

This table of contents uses a separate drop-down from the site main menu nav to give you headings to jump to for quick navigation. You can also use it at the top of the page. We love how it came together visually and functionally. For those curious about the back-end, implementation basically just relies on anchors and headings.

The Level1 team also added a progress bar to articles that is thematically matched with our chart timer sidebars in the review videos. It’ll help you keep track of your place and how far along you are in case returning later.

Both of these features were added as a result of our choice to try and keep everything to a single page format. The multi-page format of reviews largely exists to extract as many pageviews as possible from a single visitor which, on advertising-heavy sites, multiplies the revenue somewhat linearly per page visit. It also makes the site appear more “valuable” because it inflates the pageview count. For us, being ad-free and independent (not seeking acquisition or trade between big publishers), neither of these matters. The single-page layout is faster to navigate -- but not if it’s too text and image dense. The ToC helps fix a lot of these navigational limitations of single-page layout.

Note that, for organizational purposes, it’s possible we integrate a pagination system for long-term Mega Charts pages (to host older methodologies at the same URL) in the future, but we’re not sure how we’ll handle that yet.

GN Mega Charts

As for the mega charts, that’s largely explained in the video -- but some of the script is below:

We’re introducing a new series called GN Mega Charts, where we’re publishing all of our directly comparable data in full format. This is the amalgamation of literally tens of thousands of test passes over the last couple years, all in just a handful of charts that get perpetually updated.

One of the biggest community requests for the last 4 years has been publishing charts in a place where you can know it has our full dataset. We dedicated this entire year to catching up on community requests and backburner projects like the website, which we wanted to rebuild years ago but finally did recently with Wendell, and now we’re knocking out another of those big community requests.

We’re super excited about this. The Mega Charts page will exist at permanent URLs, so you can always visit those pages to get the full dataset for each component category we review.

The biggest reason we can’t do full charts in videos is because of the 16:9 limitation of video format, where taller charts become completely illegible. There are other reasons too, like just trimming expired data for game tests, but the main one is commonly vertical limitations.

But we’re going to walk you through some of the detail we published today and the vision for the next round of them.

Here’s what we’ve got so far:

We introduced a Mega Charts page for CPU power consumption, which includes charts for over a decade of CPUs that we’ve tested for power consumption, plus our latest efficiency chart and some notes on the methods. We also just made this mega charts page for the CPU cooler reviews, which compiles all of our validated cooler tests from the last several years on the same comparable platform.

The CPU power consumption test page also features these huge tables of CPUs by name, so you can easily ctrl+F the CPU name and know if it’s in one of these charts. This also lets you find our original review or other coverage all in one quick-launch place. All the video reviews are linked there, so if you can’t find a particular chart you wanted, you can probably find it in the table on the page.

All of these Mega Charts pages will also feature update logs so you can see when it was last maintained and updated. This helps with data transparency but also just from a historical and usability standpoint.

Plans for Mega Charts

Here’s the vision for where these are going.

We plan to update these a couple times a year, so they won’t necessarily have the absolute latest data (you’ll find that in the video reviews, as always, and the articles as they go up), but they will have the most data.

Our current project here is to build out the craziest acoustics data page you’ll find on coolers. Mike has been working in the hemi-anechoic chamber for weeks now to collect and log noise samples, frequency spectrum data, and noise levels for CPU coolers. I basically wrote the standard operating procedure, figured out the methodology and the scientific approach we want to take, and then set Mike loose on it, and he’s been burning through coolers in there fast.

The plan for the cooler acoustics mega charts page will require some more custom website coding work from Wendell’s team. The dream is that you’ll have a big table of cooler noise levels with sample noise files, so you can actually just click an embedded play button to hear the audio sample. We’re also hoping to have a function where when you click the cooler line item, it’ll drop down and show you a frequency spectrum plot.

All of this will take some time to build and code, and to parse the data, but that’s the next big vision for the site. It’ll also all land on YouTube first-and-foremost, where we’ll be publishing updates as we go and as we collect everything. 

In addition to all of this, we’re planning to add the CPU and GPU gaming benchmarks to these same types of pages.

We’re also working on this for cases. Our case test bench has been out of commission for most of this year because we’re finally replacing it with a new bench and methodology, but with hundreds upon hundreds of lines of tested cases, we want to archive that permanently before we move on -- it’s about 7 years of data! 

The cooler benches are also getting updated this year. As these get updated, the mega charts pages will remain and keep the prior generation of cooler data -- but we’ll either move them to a different URL (like an archive) or just push them way down on the page. This might be an actually useful situation for pagination or something.

Using These Pages

Each of the mega charts pages puts the charts up at the top in galleries, but we’ve included detailed methodological information, testing background, and some notes on how we think the pages should be used. But the first goal is to just make a dataset and page that’s as useful as possible, so all of it was put up at the top despite having a lot of important nuance behind the data.

Our hope is that people will bookmark these pages any time they need to learn something about a particular product. We’ll still run into chart size limitations, just in terms of what’s reasonable to put on a screen (and what’s searchable/scannable by eye), so we’ll sometimes break charts up into pieces. The CPU power page is a great example of this.

We recently went back through over 6 years of power testing data to put the power charts together. We still have more that’s not on here yet, but this is just everything that we were able to vet in the last couple days.

For these, everything is directly comparable from one chart to the next (and the usage guidelines on the page will always explain this for you, in case that changes), but we split them up to make them easier to navigate. They’re mostly split generationally or by year, so there’s power data for Ryzen 7000 alongside Intel 13th & 14th series CPUs, Ryzen 5000 with Intel 10, 11, and 12 series, 3000 with 8th and 9th, Ryzen 1000 and 2000 with Intel 7th Gen, and a miscellaneous and legacy chart for everything where we didn’t know what to do with it.

The awesome thing is that all of this is directly comparable. We even kept the X axis the same on as many as possible so you can more easily visually check the differences. We had one note for the legacy chart since it’s going so far back in time that we didn’t have any official guidance from AMD or Intel back then, but you can read that note on the website if you want.

The whole point of all of this though is that we’re trying to offer as much as possible while also offering all the caveats and explainers in writing. There is some responsibility required with navigating all this data since we have nuances, such as the nuance of legacy component testing being done with fewer controls (since we were brand new to all of this back then), but the data is there if someone might need it as a launching point. The newer the data, the more controlled it is too. 

But since all of that was done with the same methodological approach on the data capture side, all the numbers are grouped together.

Future Ideas

A couple notes on future improvements:

First, we could go with javascript charts or something at some point, or text-based ones, some kind of Anandtech-like bench, but for now, we’re keeping everything as simple and lean as possible. Wendell is the only person we trust to develop this site, and likewise, we need processes that mesh well with our current workflow so we don’t just become so slow as to be useless. We’ll clean up and improve as we go on, but our belief is that this is an iterative process. We’re starting with function-first, as we always have. Also, speaking frankly, we’re concerned about data scraping from bots and LLMs that could rip us off.

The table of contents was probably the biggest improvement. A lot of you have been asking for that. We still have to retroactively add it to some of the other articles, but at least going forward, we’re slowly beginning to add it to the denser material.

This has been an awesome year for our processes at GN. We’ve been quieter than in years past in some ways, like in our case reviews, because we’ve been totally overhauling every test bench this year. But it’s felt good to get the website done. Like I said last time, this is something I promised even before the fan tester -- years before -- and it took us until this year to do it. Sometimes, we move really slowly -- but that’s because we’re trying our hardest to do things right, or at least our version of “right.” Even still, perfect is the enemy of good, so now we’re in an awesome place to just start putting things out in the fastest, most function-first way possible.

We’ve been lining them up and knocking them down. We’ve been making small tweaks and corrections, as has Wendell, as viewers have emailed us with requests or notes.

We’re really trying to make this a permanently referential resource to provide long-term value and accessibility. It’s not as good from an advertising or views standpoint to do this, but the community support makes it possible. We want this to be treated as a lookup engine for whatever you need. And since all that data is collected on our own controlled platforms and not less controlled user platforms, you know the data quality is high and that comparability is also present.

More patch notes soon!

The new "5.0" version of the GamersNexus website is now live, ad-free, and function-focused.

The Highlights

• Our new website will get regular updates with imported content, both written and video
• We're still working to improve. This is a work in progress.
• The site is ultra-fast and provides easy-to-consume content and charts.

Hey everyone,

Although most of what I wanted to say is in the announcement video for this website (ironically), I wanted to write a message welcoming everyone to our new home for written reviews content. This will also provide some additional information. Before we even get started, a note: This is a work in progress! We are still actively working on adding content to and improving bugs on the website. The image comparison tool in particular is one where we’re actively improving the behavior. But this is a strong start, and certainly a far cry from where we were in 2008. And 2022. And basically any time that I was the one responsible for building the website.

Fortunately, this one was built by Wendell from Level1Techs. You should check out his YouTube channel here!

Overview

The Features

Ad-Free

This website is AD-FREE. It will stay ad-free. To help us make that possible, especially as we’ve hired specifically to maintain this site and get old & new content alike imported, and if you find this helpful, please grab a Modmat, Solder Mat, piece of commemorative glassware, or a T-shirt from our store! Or chip-in on Patreon.

Being ad-free also means we are maintaining our video-first approach (as the ads will remain there, and they pay the bills), however, with additional staffing power to bring content to the website. The awesome upside of this video-first approach is that it means we have a TON of assets and stills we can grab to really build image-heavy pages (that load fast) to provide looks at all angles of products, clear installation instructions, and guidance for PC builders.

Function-First

This website is FUNCTION-FIRST. That means our objective is simplicity, both from a maintenance perspective (for a very small team) and from a usability / bloat perspective. We will mostly be focusing on text, images, charts, and tables for web content. 

FAST

This website is FAST AF. Because of Wendell’s engineering work, and because there are no ads, the website loads very fast. The only places we have some slower loading are pages with graphics quality comparisons due to the additional javascript, but the featureset is worth it for those.

Community Service & Searchability

This website is ARCHIVAL. Our goal is to not only get old content ported over to the new layout, but to continue adding our video content in written format. That includes interviews, features like the Artesian piece, and benchmarks alike. We have noticed a sharp decline in viable technical publications in written format, and we are growing concerned about the lack of preservation of technical knowledge in a more permanent, searchable, and discoverable format than just video. We love YouTube and working on it; however, especially for people not as directly engaged with this niche, it is still easier to find things on the web. And less often frustrating, as ctrl+F is so much easier.

Image Comparisons

This website has IMAGE COMPARISONS. As we continue to increase coverage of graphics quality differences and game graphics optimization, we will be making use of side-by-side and split-screen image comparisons. The bottom corner of these comparisons even allows you to choose which screenshot is visible, as we sometimes have more than just 2. Try it out in our Starfield Optimization Guide or our Ray Reconstruction Explainer.

Methodology ‘Storage’

This website contains CONSOLIDATED METHODOLOGY. That starts here. But see below for information.

The Plans

As we continually add content to this site, our main immediate plans are as below:

1. Implement a floating table of contents for easier article navigation. We have bits and pieces of this in place, but we’re working on getting it to follow (in an un-obnoxious way) as you scroll.
2. Improve loading speed and ‘jumpy’ behavior of image comparison pages.
3. Add more test benches to our new Test Bench page, but also port-in the public-facing part of our test methodologies and SOPs.
4. Import factory tours in written format for educational use.

A Personal Message

To use a tired phrase, this has been a “labor of love” from our team. I had been the only one maintaining the website for over a decade, and eventually had to stop updates as it became too cumbersome with the time demands of running the business, benchmarks, and YouTube channel. We had to focus on just one thing, and that was YouTube. It’s the only place we made enough to actually operate. 

Wendell approached me in 2022 and wanted to rebuild the site. That’s because, sometime around maybe 2020, I noted in a video that we wanted to rebuild it (and it never went anywhere), and he really wanted to preserve our benchmark content permanently in the most accessible format possible. I agreed, so we started working on this upfit. I’ve always been slow with executing the ambitions, but we do eventually get there. 3 years later, we finally made it -- thanks, Wendell.

Wendell has been enormously patient with me in this time. My web skillset is prehistoric by today’s standards, and so there was a lot of learning. We both wanted this to be a consumer-first effort to make it easier to learn about PC hardware, how the factories work (those conversions are coming!), and component performance. We offer that in video, but it’s not going to reach people just getting into the industry.

It’ll be good for business. But it’s also just something we both wanted to do.

But half of this website is sentimental. As I said in the video above, I have felt bad for abandoning the website updates since the ~2018-2020 era when we slowed publication. Selfishly, that’s not because we got emails nearly weekly with people asking us to publish our content written again, but because the website was the last facet of the business that my dad, before his unexpected passing in 2015, had been personally familiar with. He saw the videos, but the website was where I spent all my time (and the reason I dropped out of school). He was the one who signed me up for a Microsoft Front Page class when I was about 12, so I have him to thank for the early HTML experience. And I suppose I also have him to thank for getting me started on what was probably the world’s worst web-building tool, but maybe he wanted to “build character.”

I grew up building GamersNexus and he got to watch the process and was unbelievably supportive. I’d publish a (probably very poorly done, by today’s standards) review of something like a Tuniq cooler I’d saved for, and he’d read it and talk to me about it. He was probably one of two people who’d read those. He actually made the original version of this logo in 2008, too. He made it in Microsoft Word. He told me that (whatever version it was) saved vector files -- I never fact-checked that, but it appeared to have been true. The logo has been maintained and updated, but uses his original G/N design. I take accountability for the awful font choice (and I also added the Photoshop CS3 blend modes to the logo).

Without getting much further into it than that, the point is that at least half of this effort is because I wanted to preserve this aspect of the business as a means of preserving those memories. Although the videos had started earlier, the big push didn’t happen until 2015 -- and the reason is because it was no longer optional to have the business work. It had to work, and it had to suddenly become a means of supporting the family. Video was the way forward.

I don’t want to linger on the topic because you’re all here for technology, but I did want to share it in a rare personal message just to give some visibility into what drives this site. And last time I shared anything close to this, we had a lot of you email me to say thanks as you’d connected with the loss and the perseverance. So to those of you who needed it: Look ahead and push on, but there’s no shame with finding ways to remain connected with those memories to continue the life and memory of those before us.

But we never intended to leave the website behind, and now we’re back. I’m excited about that. The website works better than it ever did. It’s also nice to have a place to write some thoughts and updates directly and more personally for once, as I often keep that out of videos to focus on the product.

This site loads fast and it has a highly qualified team maintaining it. Patrick, Jeremy, and Jimmy did the bulk of the work pre-loading the content into the site for launch. A big thanks to the team for pushing on that, and to Wendell and Krista of Level1Techs for, as Wendell calls it, “computer janitorial” work.

Publishing Plans

We’re adding more content nearly daily. We will be balancing a mix of pulling old, still-relevant content forward first, alongside importing new content. The current plan is to publish written versions of our videos on a one-week delay, sometimes it might be faster.

The conversion process for scripts is mostly straight-forward; however, some things work better spoken than written. For those sections, we are trying to keep a sharp eye to strip things like directional words (here, this, that, these) that don’t make sense without some pointing, and also trying to clean-up the colloquialisms that don’t transfer well to writing. That means you’ll find some word choice differences, but for the most part, they’re a fairly close 1:1 representation.

We also regularly cut content from videos for time. Our Cities Skylines 2 piece had a whole section written about advanced graphics, but we cut it as we were running too long already (the video target length is ~30 minutes). This is an algorithmic decision, not a content decision. Because we don’t have to fight an algorithm here, we hope to bring this cutting floor content to the written version of the reviews and tests.

Thanks for the support, everyone. Go explore the site. Oh, and all the old content is still here - it just doesn’t look as good. You can find it with a Google search if you need something specific.

Try these pages that we spent some extra time on:

• Inside the Collapse of Artesian Builds (featured story - uses ‘fancy’ page elements)
• Dan Case A4-H2O Review
• Intel Arc A580 Review
• Cities Skylines 2 Benchmarks & Graphics Optimization (uses the image comparison tool - but we’re still working on page loading for this)

Oh, and some fun history. Here’s what the old website looked like:

2008 (Launch)

~2011 Era

~2014 Era

~2015 Era

2016-2023

I’d say it’s a good thing that Wendell and Krista stepped-in for this one.

- Steve