AMD Ryzen Threadripper 1950X and 1920X: We’re Allowed To Show Pictures Now
by Ian Cutress on August 3, 2017 9:00 AM EST
One of the interesting things to come out of this Threadripper launch is the stack of embargos. Last week AMD revealed the launch date and pricing, which will incidentally also be the date for our review of both chips. AMD also inserted a small embargo in the middle for today, allowing media outlets to do unboxings.
We’re Allowed To Show Pictures Now
Rather than discuss each element of what AMD shipped the ~250 reviewers who have review kits, this article is going to be mainly a picture story with annotations. Starting with a pelican case that AMD shipped the CPUs in.
Mug for Scale
Inside the massive padded box were two CPUs in special cases, along with a paperweight.
Yes, that’s an actual CPU in the paperweight, printed with AnandTech’s logo. We got CPU 30 out of 250.
Who has #1 ?
Each of the CPUs was in this overly padded secondary box.
Vital Codes
The instructions were far from clear. I tried to record this on video. Some swearing was involved – you definitely need two hands for this.
The CPU is housed in its own secondary support system. Twist, unlock, pull, grip, fail, try again, use force, swear, then eventually get the latch off.
The CPU comes in this orange holder. The orange holder goes into the motherboard as well, so there’s no need to take the CPU out.
The box also contains a bracket for Asetek liquid coolers to fit, and a Torx Screwdriver. There are some stickers as well.
Putting it in the socket is fairly easy – three Torx screws and the mechanism pops open. Slide into the tray, close the screws. I had more issues with the CPU cooler mechanism than the CPU tray.
This last picture shows how thermal paste spreads across the CPU after a couple of days of testing with a tight liquid cooler. We can’t say much about temperatures at this point because of the embargo.
Paperweight. No idea if the CPU inside actually works.
Along with the CPUs, AMD supplied almost everything needed for the system: an ASUS X399 Zenith Extreme motherboard, 32GB of G.Skill Trident RGB DDR4-3200 C14 memory, a 512GB Samsung 960 Pro M.2 drive, a Thermaltake Toughpower Grand 1200W, and a Thermaltake Floe Riing 360 Premium liquid cooler (a 3x120 side radiator). The only thing missing was a Vega GPU (ed: you don't get everything).
What Does This Mean
I’ve never had a review sample come with quite so much kit in such extravagant packaging. Back with Ryzen they supplied a hardwood box with all the kit, and this one goes another stage up. AMD knows they can cause a stir on the social channels by being big and bright rather than staying understated, and to a certain extent, it works (as long as the company can afford it). It’s a corner of the product release cycle that AMD has honed in on, or one that its competitors have missed, although it is hard to gauge the return on investment and requires a marketing head to approve it nonetheless.
| AMD Ryzen SKUs | |||||||||
| Cores/ Threads |
Base/ Turbo |
XFR | L3 | DRAM 1DPC |
PCIe | TDP | Cost | Cooler | |
| TR 1950X | 16/32 | 3.4/4.0 | ? | 32 MB | 4x2666 | 60 | 180W | $999 | - |
| TR 1920X | 12/24 | 3.5/4.0 | ? | 32 MB | 4x2666 | 60 | 180W | $799 | - |
| TR 1900X | 8/16 | 3.8/4.0 | +200 | ? | 4-Ch | 60 | ? | $549 | - |
| Ryzen 7 1800X | 8/16 | 3.6/4.0 | +100 | 16 MB | 2x2666 | 16 | 95 W | $499 | - |
| Ryzen 7 1700X | 8/16 | 3.4/3.8 | +100 | 16 MB | 2x2666 | 16 | 95 W | $399 | - |
| Ryzen 7 1700 | 8/16 | 3.0/3.7 | +50 | 16 MB | 2x2666 | 16 | 65 W | $329 | Spire |
| Ryzen 5 1600X | 6/12 | 3.6/4.0 | +100 | 16 MB | 2x2666 | 16 | 95 W | $249 | - |
| Ryzen 5 1600 | 6/12 | 3.2/3.6 | +100 | 16 MB | 2x2666 | 16 | 65 W | $219 | Spire |
| Ryzen 5 1500X | 4/8 | 3.5/3.7 | +200 | 16 MB | 2x2666 | 16 | 65 W | $189 | Spire |
| Ryzen 5 1400 | 4/8 | 3.2/3.4 | +50 | 8 MB | 2x2666 | 16 | 65 W | $169 | Stealth |
| Ryzen 3 1300X | 4/4 | 3.5/3.7 | +200 | 8 MB | 2x2666 | 16 | 65 W | $129 | Stealth |
| Ryzen 3 1200 | 4/4 | 3.1/3.4 | +50 | 8 MB | 2x2666 | 16 | 65 W | $109 | Stealth |
What now? Time to get back to testing. Review next week.
The Change in NDA Philosophy: A Personal Commentary
This new ‘unboxing’ sort of embargo has been borne from a rapid change in how media approaches launches and NDAs.
In the past, from 2014 and before, when there was a product NDA in place it was expected that no media would even acknowledge that they had the product, let alone disclose the date of launch. In the advent of a more social media focused – and younger – technology press, skirting those NDA lines with product images has now become almost a standard: if you have the product, flaunt it, and generate hype for the review/video. Even when there is an NDA in place specifically barring certain types of content, such as unboxings, it seems that posting screenshots or gifs of the upcoming unboxing content being edited before the NDA is becoming the norm.
The reasoning stems from the fact that NDAs typically restrict product reviews and only mention performance and data analysis to be revealed at a certain date, and the argument is that the NDAs often say nothing about showcasing the product before the launch (or even if the NDA is itself under NDA). Depending on the company, this has had a mixed response: typically an incumbent market leader will come down hard if NDA rules are pushed, although PR teams and underdogs like to push the hype train as many times around the track as possible if the product is good.
AnandTech in this respect is fairly old-school: we’d rather spend more time testing the product to give more data for our analysis and reviews, making sure our readers have the sufficient knowledge at hand to invest in a product. Unboxings on AT are few and far between because there usually isn’t that much to show for our typical user base that know technology – it only really makes sense to us when something is unusual (like Threadripper), or to show to new users that may become enthusiasts. Ultimately, it’s that latter group that has spurned the tech media to invest in social media for this sort of content, especially around high-performance components or hardware where it actually makes sense, like monitors. Unboxing products like a CPU would usually take several seconds: CPU, manual, cooler, sticker, done.
Related Reading
- The AMD Zen and Ryzen 7 Review: A Deep Dive on 1800X, 1700X and 1700
- The AMD Ryzen 5 1600X vs Core i5 Review: Twelve Threads vs Four at $250
- The AMD Ryzen 3 1300X and Ryzen 3 1200 CPU Review: Zen on a Budget
- AMD Launches Ryzen PRO CPUs: Enhanced Security, Longer Warranty
- How To Get Ryzen Working on Windows 7 x64
- AMD Launches Ryzen: 52% More IPC, Eight Cores for Under $330
Facebook
Twitter
RSS
131 Comments
View All Comments
CityBlue - Friday, August 4, 2017 - link
"All processors have bugs" - totally agree with you, and that wouldn't be a problem if AMD hadn't gone into complete radio silence over the problem which has existed for months now and leaves CPUs incapable of performing the most basic tasks.I compile all day long on an FX-8350 which is solid as a rock and I'd like to replace it with a Threadripper but simply cannot unless these issues are addressed - there's no point replacing a slow but reliable CPU with a blazing fast monster that is incapable of finishing the job half of the time.
windows_reindeer - Friday, August 4, 2017 - link
https://fujii.github.io/2017/06/23/how-to-reproduc...Postmortem Examination
There is a particular pattern in some Ryzen’s crashes. According to Hideki EIRAKU’s investigation, Ryzen seems to execute 64 bytes ahead instructions than where RIP register is pointing.
Here is my coredump of bash. Let’s check the coredump.
Current program counter rip was 0x4370d0.
rip 0x4370d0 0x4370d0 <execute_builtin+720>
SIGSEGV was raised while copying [rsp+0x8] to eax immediately after returning from run_unwind_frame.
0x00000000004370cb <+715>: call 0x465ef0 <run_unwind_frame>
=> 0x00000000004370d0 <+720>: mov eax,DWORD PTR [rsp+0x8]
The stack pointer rsp was 0x7ffe79c8f4d0.
rsp 0x7ffe79c8f4d0 0x7ffe79c8f4d0
Here is the stack dump:
(gdb) x/32g 0x7ffe79c8f450
0x7ffe79c8f450: 0x0000000000000001 0xe375df75c9fcd400
0x7ffe79c8f460: 0x0000000000000000 0x00000000018da5c8
0x7ffe79c8f470: 0x00000000004659c0 0xe375df75c9fcd400
0x7ffe79c8f480: 0x0000000000000000 0x0000000000000000
0x7ffe79c8f490: 0x0000000000000001 0x0000000000000000
0x7ffe79c8f4a0: 0x0000000000000000 0x0000000000000000
0x7ffe79c8f4b0: 0x0000000000484d10 0x0000000000465f10
0x7ffe79c8f4c0: 0x0000000000000001 0x00000000004370d0
0x7ffe79c8f4d0: 0x00000000018dd548 0x0000000000000000
0x7ffe79c8f4e0: 0x0000000000000001 0x000000000180e5c8
0x7ffe79c8f4f0: 0x0000000000000000 0x000000000180e5c8
0x7ffe79c8f500: 0x0000000000484d10 0x0000000000000000
0x7ffe79c8f510: 0x0000000000000000 0x0000000000000000
0x7ffe79c8f520: 0x0000000000000000 0x0000000000439426
0x7ffe79c8f530: 0x0000000000000001 0x00000000ffffffff
0x7ffe79c8f540: 0x00000000018ddea8 0x00000001008dc8c8
[rsp-8] was 0x00000000004370d0. This was the return address which the preceding call pushed.
Here is the code of run_unwind_frame:
(gdb) disassemble run_unwind_frame
Dump of assembler code for function run_unwind_frame:
0x0000000000465ef0 <+0>: cmp QWORD PTR [rip+0x2a8a78],0x0 # 0x70e970 <unwind_protect_list>
0x0000000000465ef8 <+8>: je 0x465f17 <run_unwind_frame+39>
0x0000000000465efa <+10>: push rbx
0x0000000000465efb <+11>: mov ebx,DWORD PTR [rip+0x2a8a83] # 0x70e984 <interrupt_immediately>
0x0000000000465f01 <+17>: mov DWORD PTR [rip+0x2a8a79],0x0 # 0x70e984 <interrupt_immediately>
0x0000000000465f0b <+27>: call 0x465aa0 <unwind_frame_run_internal>
0x0000000000465f10 <+32>: mov DWORD PTR [rip+0x2a8a6e],ebx # 0x70e984 <interrupt_immediately>
0x0000000000465f16 <+38>: pop rbx
0x0000000000465f17 <+39>: repz ret
pop rbx was executed just before returning this function. This value has been recoded in the stack. [rsp-16] was 1. And rbx was 1.
rbx 0x1 0x1
The stack and th registers look consistent. But, SIGSEGV was raised. It’s a Mystery!
Let’s use the hypothesis here. The return address was 0x4370d0 and current rip was 0x4370d0. But, if Ryzen would execute 64byte ahead instructions, what would happen? The address was 0x437090. Here is the disassembled instruction.
(gdb) x/i 0x437090
0x437090 <execute_builtin+656>: add BYTE PTR [rax],al
rax was 0. If this instruction was really executed, 0 was the address where this SIGSEGV was occurred.
(gdb) p $_siginfo._sifields._sigfault.si_addr
$3 = (void *) 0x6dfb44
Unfortunately, It was 0x6dfb44. Surprisingly, no registers stores this value. I don’t know where this value came from.
Anyway, the hypothesis doesn’t seem to match in this case.
After writing above text, he posted his investigation of my coredump. He guesses rip was slipped to 0x465f10 which is in run_unwind_frame.
(gdb) disassemble run_unwind_frame
Dump of assembler code for function run_unwind_frame:
0x0000000000465ef0 <+0>: cmp QWORD PTR [rip+0x2a8a78],0x0 # 0x70e970 <unwind_protect_list>
0x0000000000465ef8 <+8>: je 0x465f17 <run_unwind_frame+39>
0x0000000000465efa <+10>: push rbx
0x0000000000465efb <+11>: mov ebx,DWORD PTR [rip+0x2a8a83] # 0x70e984 <interrupt_immediately>
0x0000000000465f01 <+17>: mov DWORD PTR [rip+0x2a8a79],0x0 # 0x70e984 <interrupt_immediately>
0x0000000000465f0b <+27>: call 0x465aa0 <unwind_frame_run_internal>
0x0000000000465f10 <+32>: mov DWORD PTR [rip+0x2a8a6e],ebx # 0x70e984 <interrupt_immediately>
0x0000000000465f16 <+38>: pop rbx
0x0000000000465f17 <+39>: repz ret
This mov instruction is about to copy ebx to [rip+0x2a8a6e]. rip was 0x4370d0, rip+0x2a8a6e is 0x6dfb3e, and this mov instruction size is 6, 0x6dfb3e + 6 is 0x6dfb44. Bingo!
Both least six significant bits of rip (0x4370d0) and slipped destination address (0x465f10) are equal.
## So, some overzealous cache prefetching gets accidentally executed *(?) when the instruction pointer loses track of where it's supposed to be? = a Ryzen bug. Microcode fix in weeks, done.
YazX_ - Friday, August 4, 2017 - link
hold on, aren't TR CPUs support 64 PCIEx lanes?! if yes, then why it is 60 in the table above?sohowsgoing - Friday, August 4, 2017 - link
I recall reading that 4 PCIe lanes are reserved for the chipset, leaving 60 available.Ian Cutress - Friday, August 4, 2017 - link
PCIe lanes supported by CPUs are historically quoted as those that can form PCIe slots for add-in cards. Four are for the chipset, as we have stated a dozen times here at AnandTech. We're not changing the way of quoting PCIe lanes, as it leads to confusion.silverblue - Friday, August 4, 2017 - link
I don't think anybody has mentioned this before, but there is a switch at the top of the case that, when activated, shines a light through the two Threadripper boxes, highlighting the Ryzen swirl. I'm not sure if it affects the paperweight.So, if nothing else, you now have an expensive case with a light in it so you can see its contents a little easier. :)
sebacorp - Friday, August 4, 2017 - link
Pease show me please WinRAR benchmark score for all 3 Threadrippers!! Thank youlakedude - Friday, August 4, 2017 - link
B3an that heatsink compound looks a bit fishy to me as well. I should think the entire top should be covered or at least the area over the dies which are evidently on the diagonal...https://www.extremetech.com/computing/253416-amd-e...
sor - Friday, August 4, 2017 - link
The heatsink itself doesn't cover the whole top of the processor. I'd like to see how the heatsink aligns with the die and the thermal compound pattern.haplo602 - Friday, August 4, 2017 - link
waiting for a 95W Zen APU ... I hope it will be a 4/8 CPU part with 30W of GPU ... even a 125W 65W/60W config would be great ...