Urgent Review of a Thermal Throttling Regression before the Nova Tab Launch

Thanks for joining, everyone. I'll keep this tight. I'm Irene, launch program manager for Nova Tab S. We launch on Friday, August 21st, and the review units ship to journalists this Friday, the fourteenth, with an embargo that lifts on the twentieth. Yesterday, SQE flagged a performance regression in the launch candidate that could end up in every review. That's why we're here.

Jaemin, SQE performance lead. My team found the regression in our sustained performance runs.

Nina, SQE. I ran the thermal chamber tests overnight, so I have the temperature data.

Taeho Lim, Kernel and BSP. I own thermal management and the CPU frequency policies on Nova Tab.

Chris, also Kernel and BSP. I'm here as Taeho's backup and because I approved some of the thermal changes that went in last week.

Brian, Platform Framework. Our game performance service may be involved, so I wanted to hear the details first-hand.

Jaemin, what exactly did you see?

In our thirty-minute sustained gaming test, the average frame rate on the launch candidate is eighteen percent lower than on the build from two weeks ago. The first ten minutes are identical. After that, the launch candidate starts reducing CPU and GPU frequencies earlier and more aggressively. By minute twenty, it's running the GPU at about sixty percent of its maximum frequency, where the older build was still at eighty-five percent.

Eighteen percent is the kind of number reviewers notice. Most of them run exactly this type of benchmark. Nina, what does the thermal data say?

The interesting part is that the device isn't actually hotter. On both builds, the back surface temperature after thirty minutes is about forty-one degrees Celsius. But on the launch candidate, throttling starts when the internal skin temperature sensor reads thirty-nine degrees. On the older build, it started at forty-two. So the device is throttling earlier without any real thermal need.

That points straight at the thermal configuration. Last week, the hardware team asked us to update the thermal thresholds after they changed the thermal pad between the display and the battery for the final production units. The new pad conducts heat differently, so the relationship between the internal sensor reading and the actual surface temperature changed.

So was the threshold change wrong, or was it right for the new hardware?

That's what I've been trying to figure out since last night. The hardware team gave us a correlation table: for each internal sensor reading, the expected surface temperature. They measured it on five early production units. According to their table, an internal reading of thirty-nine corresponds to a surface temperature of forty-four degrees, which is close to our forty-five-degree safety limit. That's why they lowered the threshold.

But that's not what I measured. With thermocouples attached to the back of three production units in the chamber, an internal reading of thirty-nine corresponded to a surface temperature of about forty degrees, not forty-four. That's a four-degree difference from the hardware team's table.

Four degrees is a lot. Is it possible we're measuring different things? Surface temperature can vary quite a bit depending on where you put the probe. The hottest spot on a tablet is usually right above the processor, not in the middle of the back panel.

Good question. I placed probes at five points, including directly above the processor, and I'm quoting the hottest one. So I'm fairly confident in forty degrees. But I can't rule out that the hardware team used a different ambient temperature or different units.

I called the hardware team this morning. It turns out their correlation table was measured on early units that still had the old thermal pad, with a modified back cover. So the table doesn't reflect the final hardware. They agree that Nina's measurements on real production units should take priority, but they want to repeat the measurement themselves before signing off.

That's progress. So part of the regression is a threshold based on the wrong measurements. Is that the whole eighteen percent?

I don't think so. We built a test image with the old thresholds restored on the launch candidate, and it recovered about eleven of the eighteen points. There's still a seven percent gap we can't explain with thresholds alone.

I may be able to explain the other seven percent. When I saw the invite, I checked our game performance service logs on Jaemin's test device. The service is supposed to recognize the benchmark game and apply a game profile that relaxes some background limits and prioritizes the render threads. On the launch candidate, it doesn't recognize the game at all.

Why not?

The game publisher released an update ten days ago that changed the app's package name for their new store listing. Our profile list matches games by package name, and the list in the launch candidate was frozen before that update. So the game runs without a profile. It's not a code bug; it's stale data.

So two independent changes landed in the same week and stacked on top of each other. That's frustrating, but at least it's explainable.

That would also explain why the first ten minutes look the same. Before the device gets warm, the profile doesn't make much difference. It matters most when the system has to share a limited thermal budget between the game and everything else.

Can the profile list be updated without a new system build? If it's data, it shouldn't need a full release.

Yes, that's the good news. The list can be updated from our server through the game service's own update channel, which doesn't require carrier approval. I can push an updated list today. Longer term, we should match games by a more stable identifier than the package name, but that's a code change for later.

Good. Now the thresholds. Taeho, can we just restore the old values?

I'd be careful about simply reverting. The old values were tuned for the old thermal pad. With the new pad, Nina's data suggests they're probably safe, but 'probably' isn't good enough when we're talking about the surface temperature limit. Forty-five degrees on the surface isn't a performance target; it's a safety requirement, and it's in our certification documents.

I completely agree. Under no circumstances do we ship something that could exceed the safety limit to get a better benchmark score. So what's the right approach?

I'd derive new thresholds from Nina's measurements on production units, with a safety margin. If thirty-nine internal corresponds to forty surface, then the old threshold of forty-two internal should give us about forty-three surface, which leaves a two-degree margin under the limit. I'd propose forty-one point five as a compromise, to leave a slightly larger margin.

Before we commit to that, I want to validate it in the worst case, not just the typical case. That means thirty-five degrees ambient, maximum screen brightness, charging while gaming, which is what some users actually do. If the surface stays under forty-five with a margin in that scenario, I'll be comfortable.

Agreed. And charging is important, because the charging circuit adds its own heat near the battery. That's exactly the area where the new pad changed the heat flow.

If the worst-case test passes with forty-one point five, and Brian's profile update goes out, I'd expect us to be within two or three percent of the older build. That's within normal variation, so reviewers wouldn't see a meaningful difference.

Here's my scheduling problem. Review units ship on Friday with whatever software is on them. Can a threshold change still make it into the factory image?

Not safely. The factory image for review units was finalized yesterday, and changing it now would mean reflashing hundreds of units by hand. But the thermal configuration is part of the day-one update, which reviewers will be asked to install before testing.

Reviewers don't always follow instructions, though. Some will run benchmarks the minute they unbox the device.

Then the update should be available before the units arrive. If the update server goes live on Thursday, the thirteenth, the review units will download it during the initial setup. Most reviewers connect to Wi-Fi during setup, so they'll get it automatically before they even reach the home screen.

That means the day-one update has to be validated by Thursday. Nina, Jaemin, is that feasible?

The worst-case thermal test takes about four hours per run, and I'd want three runs on three units. If Taeho gives me the new configuration by 2 p.m. today, I can finish tonight. The rest of the day-one update has already passed regression, so we're only validating the delta.

And I'll run the sustained gaming test in parallel on the same build, so by tomorrow morning we know both the safety margin and the performance recovery.

One risk I want to name explicitly. If the worst-case test fails tonight, we're out of time to tune further before Thursday. What's the fallback?

The fallback is to keep the current conservative thresholds and ship only Brian's profile fix. We'd recover about seven of the eighteen points. Reviewers would see roughly an eleven percent drop compared to what they might expect, which isn't great, but it's safe. Then we'd retune properly for the first monthly update.

I can live with that as a fallback. A slightly lower benchmark score is a marketing problem. A device that gets too hot is a safety problem and a recall risk. Those are not in the same category.

I'd also suggest we prepare a short technical note for the press team, just in case. If a reviewer asks about sustained performance, the team should be able to explain that the device is tuned to keep the surface comfortable, and that an update will optimize it further.

Good idea. I'll ask Jaemin to give me the numbers for both scenarios, and I'll draft the note with the communications team. I'd rather prepare an answer we never need than be caught without one when the first review goes live.

I also need to understand how this got all the way to the launch candidate. The threshold change went in last week. Why didn't our regular performance tests catch it before yesterday?

Our nightly performance suite runs short benchmarks, each about three minutes long, so the device never gets warm enough for thermal limits to matter. The thirty-minute sustained tests only run on release candidates, because they tie up the thermal chamber. So a change that only affects behavior after ten minutes is invisible to the nightly suite by design.

And on our side, the threshold change was reviewed as a configuration update requested by the hardware team, with their measurement table attached. I approved it because the numbers looked reasonable, but I didn't ask how the table was produced. In hindsight, I should have asked which units they measured.

I appreciate the honesty, Chris. What would you change so it doesn't happen again?

Two things. First, any change to thermal configuration should automatically trigger a sustained test, even outside the release candidate cycle. We can reserve one chamber slot per day for that. Second, the thermal configuration file should require a sign-off from SQE performance, not just from kernel.

I'd support both. And for hardware-driven changes, the request should state the hardware revision the measurements were taken on. That one line would have caught this immediately.

Good. Let's capture all three in the launch retrospective, and I'll make sure they become actual process changes, not just notes in a document.

Let me summarize. One: Brian pushes the updated game profile list from the server today. Two: Taeho delivers a day-one update candidate with the threshold at forty-one point five degrees by 2 p.m. Three: Nina runs the worst-case thermal test tonight on three units, and Jaemin runs sustained gaming in parallel. Four: we decide tomorrow at 9 a.m. whether the new threshold ships in the day-one update or we use the fallback. Five: the update server goes live on Thursday. Did I miss anything?

One more: I'll ask the hardware team to repeat their correlation measurement on production units this week, so the next tuning cycle starts from correct data. I don't want us to rely only on our own chamber.

And I'll open a ticket to match games by a stable identifier, targeted for the first monthly update. Package names will change again; it's only a matter of time.

Thank you all. I appreciate how quickly this came together. We'll meet tomorrow, Thursday, August 13th, at 9 a.m. Korea time, for the go or fallback decision. If the test results come in overnight, please post them in the launch channel so we can all read them before the call.

Will do. I'll post the chamber results as each run finishes, including the peak surface temperature at each of the five probe points, so nobody has to guess where the hottest spot was.

Same for the gaming numbers. I'll include a side-by-side chart of frequency over time for the old build, the launch candidate, and the new candidate, so the decision tomorrow can be made at a glance.

And I'll be online until the first chamber run finishes, in case Nina needs a quick configuration tweak. It's better to lose a little sleep tonight than to lose the fallback window tomorrow.