AMD's Future Chips & SoC's: News, Info & Rumours.

[jdwii]

Yeah, you proved your point. They're going to side step the argument and go on about how TDP is a marketing scheme. AMD just wanted to maximize performance when Ryzen 7 launched.

Again i posted links of linus sebastian, i posted links to definitions used by Intel and Amd and i posted the link(which is being used by the counter argument too) which states that true power consumption can be 1.5 times the amount listed by TDP.

Nvidia+Intel+Amd do not follow TDP=Power consumption and things such as TIM can affect temperature transfer between the heatspreader making these ratings messed up a bit.

Not a single user here is saying the 1800X is capped at 95 watts and it doesn't use anymore power we are saying its dissipating 95 watts of heat on average when at load.

https://www.intel.com/content/dam/doc/white-paper/resources-xeon-measuring-processor-power-paper.pdf

 

[goldstone77]

Look at the max power Stilt had the 1800X in stock configurations with XFR, and if we used this magical 85% to the 111W peak power The Stilt had in his graph that you want to apply to Intel processors, the answer would be 94.35W TDP. The Stilt had the 1800X pulling ~124W peak power when overclocking the 1800X on all cores to 3.9GHz. And again his statement said this is 30% more power than normally would be drawn.

Peak power (i.e. worst-case) figures were measured during Firestarter FMA/AVX binary execution. On average the resulting power consumption is around 30% higher than the power consumption resulting from any other real world consumer, fully multithreaded workload.

HFR review is just a bad review when compared to all the other reviews.

Edit: Hold on look at the core voltage! And this review was made on release day of the R7 line!
AMD Ryzen 7 1800X in test, the return of AMD?

For this test, AMD provided us with a copy of Ryzen 7 1800X, the fastest reference launched today.

1.439V@3,699.14MHZ HAHAHA The motherboard is pushing the voltage limit at base clock!
2nd Edit: Hey look I can insert this now! HFR is absolutely exceeding voltage limits in their test with 128W!!!! HAHAHA

According to AMD, "TDP is essentially the maximum sustained power a processor can draw with “real world” software while operating under defined temperature and voltage limits.

 

[juanrga]

Look at the max power Stilt had the 1800X in stock configurations with XFR, and if we used this magical 85% to the 111W peak power The Stilt had in his graph that you want to apply to Intel processors, the answer would be 94.35W TDP.

There is nothing "magical" on the 85% correction factor. It is the factor that accounts for conduction loses at the mobo level. The 85% factor applies only to the HFR review, because HFR gives sustained power on the ATX12v channel. The Stilt already gives sustained power for the CPU package (#) and thus applying the 85% factor to its CPU numbers is plain wrong. It is so incorrect as taking the 129W measured by HFR in the 12v channel for the AMD RyZen system, applying the mobo losses factor to obtain 110W for the R7-1800X CPU alone, and then applying the same 85% factor again to the R7-1800X CPU power to obtain a meaningless 93W. The procedure is plain nonsense and not only because one would be counting the same losses twice...

(#) From The Stilt review:

The power consumption

All of the power consumption measurements have been made with DCR method. The figures represent the total combined power consumed by the CPU cores (VDDCR_CPU, Plane 1) and the data fabric / the peripherals (VDDCR_SOC, Plane 2). These figures do not include switching or conduction losses.

 

[juanrga]

From the AMD reddit: The empire strikes back: Full Coffee Lake availability catapults Intel back to No 1.

 

[goldstone77]

Look at the max power Stilt had the 1800X in stock configurations with XFR, and if we used this magical 85% to the 111W peak power The Stilt had in his graph that you want to apply to Intel processors, the answer would be 94.35W TDP.

There is nothing "magical" on the 85% correction factor. It is the factor that accounts for conduction loses at the mobo level. The 85% factor applies only to the HFR review, because HFR gives sustained power on the ATX12v channel. The Stilt already gives sustained power for the CPU package (#) and thus applying the 85% factor to its CPU numbers is plain wrong. It is so incorrect as taking the 129W measured by HFR in the 12v channel for the AMD RyZen system, applying the mobo losses factor to obtain 110W for the R7-1800X CPU alone, and then applying the same 85% factor again to the R7-1800X CPU power to obtain a meaningless 93W. The procedure is plain nonsense and not only because one would be counting the same losses twice...

(#) From The Stilt review:

The power consumption

All of the power consumption measurements have been made with DCR method. The figures represent the total combined power consumed by the CPU cores (VDDCR_CPU, Plane 1) and the data fabric / the peripherals (VDDCR_SOC, Plane 2). These figures do not include switching or conduction losses.

But what about HFR's 128W after looking at this? The test setup a base frequency is approaching CPU voltage safety levels! And as The Stilt's graph shows ~124W is a 3.9GHz overclock on all cores! HFR's motherboard settings are clearly dangerous for the CPU, and represent voltages that are associated with overclocking a Ryzen CPU, and are not representing normal CPU operation. The review is invalid to the point of finding TDP under normal operations!

Hold on look at the core voltage! And this review was made on release day of the R7 line!
AMD Ryzen 7 1800X in test, the return of AMD?

For this test, AMD provided us with a copy of Ryzen 7 1800X, the fastest reference launched today.

1.439V@3,699.14MHZ HAHAHA The motherboard is pushing the voltage limit at base clock!
2nd Edit: Hey look I can insert this now! HFR is absolutely exceeding voltage limits in their test with 128W!!!! HAHAHA

According to AMD, "TDP is essentially the maximum sustained power a processor can draw with “real world” software while operating under defined temperature and voltage limits.

 

[juanrga]

But what about HFR's 128W after looking at this? The test setup a base frequency is approaching CPU voltage safety levels! And as The Stilt's graph shows ~124W is a 3.9GHz overclock on all cores!

Apples and oranges. The 124W measured by The Stilt are for the CPU alone. The 128.9W measured by HFR aren't for the CPU. The CPU alone was 110W.

HFR's motherboard settings are clearly dangerous for the CPU, and represent voltages that are associated with overclocking a Ryzen CPU, and are not representing normal CPU operation. The review is invalid to the point of finding TDP under normal operations!

Hold on look at the core voltage! And this review was made on release day of the R7 line!
AMD Ryzen 7 1800X in test, the return of AMD?

Reading the review, we can easily check that the voltage was set up to 1.350V in the BIOS, but the working voltage was only 1.2V (as reported by CPU-Z) during the x264 workload used to measure TDP and efficiencies of the R7-1800X

So the review is completely valid.

 

[goldstone77]

But what about HFR's 128W after looking at this? The test setup a base frequency is approaching CPU voltage safety levels! And as The Stilt's graph shows ~124W is a 3.9GHz overclock on all cores!

The 124W measured by The Stilt are CPU power alone. The 129W measured by HFR aren't for the CPU. The CPU alone was 110W. Moreover, we cannot compare directly power measurements using different workloads.

HFR's motherboard settings are clearly dangerous for the CPU, and represent voltages that are associated with overclocking a Ryzen CPU, and are not representing normal CPU operation. The review is invalid to the point of finding TDP under normal operations!

Hold on look at the core voltage! And this review was made on release day of the R7 line!
AMD Ryzen 7 1800X in test, the return of AMD?

Reading the review, we can easily check that the voltage was set up to 1.350V in the BIOS, but the working voltage was only 1.2V (as reported by CPU-Z) during the x264 workload used to measure TDPs and efficiencies

So the review is completely valid.

There is something wrong with the test! Other reviews find similar result to Tom's Hardware on release day. HFR power consumption is closer to an overclocked power consumption not power consumption under typical operation!

Power Consumption
We measure voltages and currents directly on the motherboard using the existing sensors and calculate the power consumption based on them. To achieve valid results, we take the average of the two-minute measurements for each of our scenarios and use our low-pass filter and analysis software to get rid of any extreme peaks or valleys.

These aggregated results are a lot more telling than extremely short peaks due to the latter’s very brief nature. We took a look at a total of eight different scenarios.

Some of the applications consume more power over time. This is due to the CPU heating up. We found that the difference between a cold and fully warmed up CPU can be up to 3W. If these 3W are interpreted as leakage currents, then this is actually a very good result.

We took the average of the power consumption curves after the CPU had reached its full operating temperature and put the results in a bar graph to provide a summary.

The 1800X ~95W TDP during Blender!

 

[juanrga]

Yeah, you proved your point. They're going to side step the argument and go on about how TDP is a marketing scheme. AMD just wanted to maximize performance when Ryzen 7 launched.

Yes. That is just what happened.

 

[goldstone77]

Yeah, you proved your point. They're going to side step the argument and go on about how TDP is a marketing scheme. AMD just wanted to maximize performance when Ryzen 7 launched.

Yes. That is just what happened.

What is happening is that the review from HFR is an outlier, and not representative of normal operation! It's closer to an overclocked Ryzen in power consumption!
AMD Ryzen 7 1800X CPU Review
by Paul Alcorn March 2, 2017 at 6:00 AM

Blender satisfies the stated 95W TDP.

 

[juanrga]

There is something wrong with the test! Other reviews find similar result to Tom's Hardware on release day. HFR power consumption is closer to an overclocked power consumption not power consumption under typical operation!

Power Consumption
We measure voltages and currents directly on the motherboard using the existing sensors and calculate the power consumption based on them. To achieve valid results, we take the average of the two-minute measurements for each of our scenarios and use our low-pass filter and analysis software to get rid of any extreme peaks or valleys.

These aggregated results are a lot more telling than extremely short peaks due to the latter’s very brief nature. We took a look at a total of eight different scenarios.

Some of the applications consume more power over time. This is due to the CPU heating up. We found that the difference between a cold and fully warmed up CPU can be up to 3W. If these 3W are interpreted as leakage currents, then this is actually a very good result.

We took the average of the power consumption curves after the CPU had reached its full operating temperature and put the results in a bar graph to provide a summary.

LuxRender is the workload more similar to the AVX-enabled workload used by HFR review, because both workloads load the CPU fully.

Evidently the 111.8W measured by Toms for the "CPU only" agree very well with the 110W--112W measured by HFR for the CPU only. So I find amazing this insistence on pretending that there is something wrong with the HFR review.

I stop here.

 

[adamsleath]

From the AMD reddit: The empire strikes back: Full Coffee Lake availability catapults Intel back to No 1.

"This is not Intel vs AMD" :lol:

Typical Intel fanboi post. again. repeatedly.

 

[goldstone77]

There is something wrong with the test! Other reviews find similar result to Tom's Hardware on release day. HFR power consumption is closer to an overclocked power consumption not power consumption under typical operation!

Power Consumption
We measure voltages and currents directly on the motherboard using the existing sensors and calculate the power consumption based on them. To achieve valid results, we take the average of the two-minute measurements for each of our scenarios and use our low-pass filter and analysis software to get rid of any extreme peaks or valleys.

These aggregated results are a lot more telling than extremely short peaks due to the latter’s very brief nature. We took a look at a total of eight different scenarios.

Some of the applications consume more power over time. This is due to the CPU heating up. We found that the difference between a cold and fully warmed up CPU can be up to 3W. If these 3W are interpreted as leakage currents, then this is actually a very good result.

We took the average of the power consumption curves after the CPU had reached its full operating temperature and put the results in a bar graph to provide a summary.

LuxRender is the workload more similar to the AVX-enabled workload used by HFR review, because both workloads load the CPU fully.

Evidently the 111.8W measured by Toms for the "CPU only" agree very well with the 110W--112W measured by HFR for the CPU only. So I find amazing this insistence on pretending that there is something wrong with the HFR review.

I stop here.

And The Stilt agrees with similar numbers to Tom's Hardware in the ~110W "peak power", which is The Stilt has defined as follows:

The power consumption

All of the power consumption measurements have been made with DCR method. The figures represent the total combined power consumed by the CPU cores (VDDCR_CPU, Plane 1) and the data fabric / the peripherals (VDDCR_SOC, Plane 2). These figures do not include switching or conduction losses.

Peak power (i.e. worst-case) figures were measured during Firestarter FMA/AVX binary execution. On average the resulting power consumption is around 30% higher than the power consumption resulting from any other real world consumer, fully multithreaded workload.

Blender satisfies the 95W TDP and the Stilt's 30% higher than the power consumption resulting from any other real world consumer, fully multithreaded workload!

 

[jdwii]

http://www.game-debate.com/news/24293/rumour-major-intel-cpu-hardware-vulnerability-found-could-cost-35-performance

"Rumour: Major Intel CPU Hardware Vulnerability Found, Could Cost 35% Performance"

Don't worry it doesn't affect Amd users so no issue here also i found this part interesting and IMO worth a law suite.
"According to numerous sources, the security bug is currently embargoed, with Intel trying to keep a lid on it lest it is exploited for an attack."

 

[randomizer]

Don't worry it doesn't affect Amd users so no issue here...

The patch to the Linux kernel affects all x86 processors so the performance impact will occur across the board (though not necessarily to the same extent). Naturally I have no idea about what Microsoft or Apple have done.

 

[jdwii]

Don't worry it doesn't affect Amd users so no issue here...

The patch to the Linux kernel affects all x86 processors so the performance impact will occur across the board (though not necessarily to the same extent). Naturally I have no idea about what Microsoft or Apple have done.

The patch does not affect Amd processors

https://lkml.org/lkml/2017/12/27/2

"AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault."

Also this is not just for linux its windows and mac too

https://hothardware.com/news/intel-cpu-bug-kernel-memory-isolation-linux-windows-macos

 

[randomizer]

That was a proposed patch but it hasn't been merged. Here is the actual commit that was merged: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/cpu/common.c?id=a89f040fa34ec9cd682aed98b8f04e3c47d998bd

 

[jdwii]

That was a proposed patch but it hasn't been merged. Here is the actual commit that was merged: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/cpu/common.c?id=a89f040fa34ec9cd682aed98b8f04e3c47d998bd

That's more a flaw from the developers they said they can add exceptions later, maybe they were rushing this patch out

 

[goldstone77]

I also, found the same message:

AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

https://lkml.org/lkml/2017/12/27/2

 

[goldstone77]

Also,
python sweetness
The mysterious case of the Linux Page Table Isolation patches

 

[randomizer]

That's more a flaw from the developers they said they can add exceptions later, maybe they were rushing this patch out

Of course they were rushing it out (well, as much as you can rush a patch to a core kernel subsystem). That doesn't change the fact that the patch as it stands affects all x86 processors (but it can be disabled via a kernel command line switch). This is a serious bug and it's much better to safeguard all processors against exploits until there is evidence that they're immune. Hopefully a better solution is merged soon. Fortunately the performance impact isn't significant across the board. If you're running I/O heavy applications you'll feel lots of pain though.

 

[goldstone77]

I posted more information in the coffee lake thread
http://www.tomshardware.com/forum/id-3529443/intel-coffee-lake-8th-generation-megathread-faq-resources/page-9.html#20552617

 

[aldaia]

Shareholders have certainly noticed the issue:

 

[juanrga]

It is not demonstrated that the bug doesn't affect AMD CPUs. One AMD dev saying in a comment that it doesn't affect is not a proof. His message in LKLM had a response that did remark the obvious:

This is a rather wide class of issues and I would rather not just hard-code it in a way that we say one vendor has never and will never be affected.

Indeed, there is no proof that AMD is unaffected and so linux kernel developers are assuming that all x86 CPUs are vulnerable.

/* Assume for now that ALL x86 CPUs are insecure */

If tomorrow it is demonstrated that some CPUs aren't affected devs can write exceptions for those CPUs in future kernel versions.

Performance penalty is up to 50% on EPYC system running the newest kernel.

 

[-Fran-]

I'll take an AMD engy word over yours, Juan. But it is true they are doing defensive coding now, thanks to Intel's screw up.

Overall, this will be a PR disaster for Intel if AMD is proven to be unaffected. But then again, the Pentium bug didn't make a dent and people forgot very fast about it in the coming years.

Cheers!

 

[goldstone77]

The patch absolutely affects all X86 including AMD, but it's a hardware bug affecting Intel, and AMD doesn't use the same speculation engine that is causing the issue. So, one can reasonably assume with the information so far, especially since AMD hardware is not affected, that this will just take a later patch to fix.