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
— 8:38 PM on November 25, 2013

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

Download:
MP3 (61MB)

Subscribe:
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. - jdrake@techreport.com

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

Like what we're doing? Pay what you want to support TR and get nifty extra features.
Top contributors
1. GKey13 - $650 2. JohnC - $600 3. davidbowser - $501
4. cmpxchg - $500 5. DeadOfKnight - $400 6. danny e. - $375
7. the - $360 8. rbattle - $350 9. codinghorror - $326
10. Ryu Connor - $325
The TR Podcast 153: 4K ascendant, CodingHorror resplendentPlus, AMD's Radeon R9 295 X2, listener mail, and more 6
The TR Podcast 152: Intel's new desktop mojo, DX12, and TR does subscriptionsPlus lots of news from GDC, listener mail, and more 15
The TR Podcast 151: Key switch explosion, the new System Guide, and overclocked SSDsPlus, Jordan podcasts from the bathroom sink... #truestory 12
The TR Podcast 150: From Mantle to Maxwell, and beyondPlus listener mail, Jordan eats Chinese food, and Geoff plays with a keyboard 18
The TR Podcast 149: Kaveri ain't just a river in India Plus cheap(ish) 4K, hard drive reliability, and Cup Noodles 11
The TR Podcast 148: Not quite live from Las VegasCES... what else did you expect? 4
The TR Podcast 147: Amazon airlifts, 4K goes mainstream, and 290X goes wobbly Plus listener mail and cottage cheese 29
The TR Podcast 145: The mailbag and top-tier graphicsPlus an update on SSDs, and Jordan's tech woes 21

Tags: Podcast