So, 27th was Vega info, then siggraph info, August 10th is embargo date and TR on sale, August 14th is Vega sale and embargo date, August 31st is the 1900X release date. Hope that straightens it out for you.you could be right I don't know... there's a lot of dates flying around at the moment in regards to AMD products
No current plans I've seen.are there any mini ITX boards planned for TR?
are there any mini ITX boards planned for TR?
I really don't see the point. TR was all about more PCI-E lanes and memory channels, and oh, you need more VRM hardware too. So I doubt we'll see one. An ITX Ryzen rig was hard enough.are there any mini ITX boards planned for TR?
Don't think so.Will an EPYC processor work on a Threadripper motherboard?
When is this occurring? I thought this was sorted w/ the latest AGESA bios update...
Has anybody running Visual Studio using Microsoft's compiler or even Intel's compiler reported anything similar?*Snip*
This is a terribly annoying bug that does not seem to affect general day to day use if you run Windows. It does however cause issues if you compile large codebases or perform frequent compilations (which is the sort of use case you might imagine a Threadripper used for). There are a number of places this is documented, however the most authoritative source might be AMDs own forum.
https://community.amd.com/thread/215773
I don't want to make a big deal of it, but there doesn't seem to be a general awareness of this issue outside of people using a *nix variant. It has been reproduced on Windows using the "Windows Subsystem for Linux" and also in a VM, so it's certainly not a Linux specific issue as some would seem to believe (first really identified on a BSD variant anyway). If can affect random processes on a rare but day to day basis, but is most easily reproduced using either the programs built especially to reproduce the fault, or just building large codebases (a real-life use case that bit me in early May).
So I raised it here in a legitimate complaint that I'd *really* love to buy one of these setups, but as I can't even get a Ryzen stable (with AMDs help) for my specific stability testing I'm loathe to even contemplate putting a couple of extra grand down on what would normally be a very compelling purchase.
We're (the people who this bug affects in the AMD forum) all hoping AMD gets it sorted, and would dearly love anyone who buys one of these things to run some tests on it to demonstrate they have got these issues sorted. Until now, people have been disabling SMT, turning up voltages (at AMDs request), playing with kernel options to disable features like address space randomization to mixed success (usually it just makes the bug harder to hit and after 24 odd hours of testing it usually only bites about 30 seconds after the tester posts a "it worked, my problems are solved" message to the forum. The only thing that seemingly consistently makes it go away is disabling the OpCache, but very few BIOS seem to expose that option at the moment (like mine).
Anyway, I'll go back to lurking now and wait until this gets positively sorted before dropping > $2200 for another chip & motherboard. The Asus Prime X370 & 1800X that sits idle in the corner is punishment enough.
Can't believe people are building rigs with 16 core CPU's! Thanks AMD!
Well, they do perfectly with 28, so why not 32 ?Was just about to post the same. Insane computational power. Crazy thing is the individual cores aren't exactly weak cores either, they're pretty damn good all by themselves.
How well does Windows 10 handle 32 threads? PC's with cores of this number would usually be on a server OS
I really don't see the point. TR was all about more PCI-E lanes and memory channels, and oh, you need more VRM hardware too. So I doubt we'll see one. An ITX Ryzen rig was hard enough.
I've just proofed my setup (1700 w/ asrock gaming board) using a 4 pass memtest and prime95 run w/o issue. OS : ubuntu 17.04.
I will now run the famed compile test found at :
http://funks.ddns.net:8080/tools/ryzen/testRyzenGCC.sh
and report back
TBH, i have a funny feeling people aren't proofing their setup via stress test/memtest and some instability therein is causing the issue in the compile test.
We'll see shortly if I get a clean pass.
Just hit the Segfault for compilation 1hr 15min into testing...I tested both overclocked and completely stock settings and the segfault almost always happens when compiling large codebases (gentoo portage installs). 8+ hrs of prime95 (Windows 10) and about the same using Google stressapptest (Ubuntu 16.04LTS), 2+hrs testing ycruncher (Windows 10)... All passed with flying colors. After reading the topics at the AMD foruns and Gentoo foruns I tried to disable ASLR and it helped, at least for regular system updates (I did not test compilation loops/scripts).