The TR Podcast 146: Cyril gets cranked on cold medicine and talks AMD

Plus Geoff and Google are on the ropes, listener mail, and more

The Tech Report Podcast

Date: November 25, 2013
Duration: 1:24:49

Hosted by: Jordan Drake

Co-Hosts: Scott Wasson, Geoff Gasior, and Cyril Kowaliski

MP3 (61MB)

RSS (MP3) | RSS (M4A)
iTunes (MP3) | iTunes (M4A)


Show notes
We're back with another episode of the TR Podcast. After a slew of listener mail questions and a live reading of our "Dear Diary" contest winner's winning entry, we dive straight into Cyril's field report from AMD's APU13 event. Our coverage includes discussion of AMD's upcoming Kaveri APU, the company's 2014 mobile roadmap, the new Mantle API, and a lot more. Before bringing our episode to a close, Geoff shares his frustration with Google, Cyril talks about his review of the Radeon R9 270, and we explain how you can win a copy of Battlefield 4, courtesy of AMD.

Send in listener mail, and we'll answer on the podcast. -

Follow us on Twitter - Scott - Jordan - Geoff - Cyril - The Tech Report

Listener mail/tweets:

R9 290X fix(es)? - from Nalty:

"Hey guys, after hearing the discussion about the R9 290X's woes with bumping up against a fan speed limit, acoustics, and thermal headroom, I was surprised that you guys didn't cover an article over at Semiaccurate, that tested a mod to the 290X done by Codinghorror, on Techreport. In effect, Codinghorror chopped out much of the stabilizer bracket, opening up a lot of room for airflow, and while, according to Semiaccurate, this did not help temperatures, it *did* help acoustics, significantly. Wouldn't it be a gas if all AMD needed to improve their reference blowers was to get rid of the DVI outputs (since we're all going to be on DP soon anyways) and then perforate the rest of the bracket with an airflow-transparent latticework instead?

Followup email:

Seems Tom's Hardware took theirs apart, and found it to be heavily over-thermal compound-ed, and a terrible finish on the contact surface of the heatsink. Could Scott take apart his review sample and see if there's the same problems there?"

Crashplan - from Chris:

"I was listening to the podcast on the way in to work this morning and was disappointed to hear about your massive data loss. You might want to check out CrashPlan as a cloud backup. They have unlimited backup, HDD based seeds, etc. Every Black Friday for the past few years they have had large savings for new users; it is how I started using it. You can also encrypt the files with your own private key. In the post-Snowden era that's pretty cool. May be worth a look. Don't mean to sound like a shill, but I've been pleased with their service and thought I'd give you a recommendation. Losing 3TB of data sucks."

MS Office? - from Jay:

"I am looking at upgrading from windows 7 to windows 8.1. I still use Office 2003 on my computer. I was wondering what I should upgrade to or should I go with another office program?"

eFPS? - from Matt:

"I am a newer listener and your discussion on the last podcast regarding a new way to rate the performance that you get out of a gpu has really intrigued me. I see that some websites are still doing the "old fashioned" fps measurement, while other are doing frametime and FCAT methods, and I was wondering if there would be a good way to combine these. I was thinking that, given the right equipment and software, you could create a new eFPS score for gpus (effective frames per second) by measuring the actual number of full frames that are displayed on the screen on average through a benchmark. This would start with the regular fps number, but then subtract off frames that aren't fully rendered on the display (like the tearing and runt frames that FCAT finds) and ones that are too close together to be displayed on a 60hz screen (i.e. a frame time of less than 0.017 seconds). As for implementation, I would think that you could use current frame capture tech to look at the displayed image, and either write software to find these incomplete frames (comparing buffered frames it displayed ones) or go frame by frame for shorter duration benchmarks. The frame time and fps data would be collected using your current methods. I believe this would give an accurate representation of the performance a user might see while using a certain card and be easily quantifiable since we're already used to the fps measurement unit. For example, if a card is displaying 100fps most of the time and occasionally dips down to 30fps, this benchmark would show that run as not being as fast as a run that was at a constant 60fps even though the average fps is less."

Tech discussion:

That's all, folks! We'll see you on the next episode.TR

Tags: Podcast

Scaling Raven Ridge with David Kanter: The TR Podcast 191We dive into Ryzen Mobile 12
A moment of Zen with David Kanter: The TR Podcast 190Digging into the whys of Ryzen 39
Talking Soft Machines with David Kanter: The TR Podcast 189We go deep on the VISC architecture 13
Apple's A9 impresses and the Nexus strikes back: The TR Podcast 188Plus a look at the state of AMD in 2015 7
The TR Podcast 187: Opening the Zbox and a bunch of new ApplesBig things happen in small packages 10
The TR Podcast 186: Talking Skylake architecture with David KanterDigging deep on Intel's latest CPUs 10
The TR Podcast 185: Honey, I shrunk the FuryFiji gives us more bounce to the ounce 1
The TR Podcast 184: Streaming to the Shield and overrunning VRAMOur textures runneth over 0