Core i7-5820K
Core i7-5930K
Core i7-5960X
Corei 7-6950X

HardwareCanucks
http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/67240-intel-haswell-e-i7-5960x-review.html
Ananadtech
http://anandtech.com/show/8426/the-intel-haswell-e-cpu-review-core-i7-5960x-i7-5930k-i7-5820k-tested
Guru3d
http://www.guru3d.com/articles-pages/core-i7-5960x-5930k-and-5820k-processor-review,1.html
PCPer
http://www.pcper.com/reviews/Processors/Haswell-E-Intel-Core-i7-5960X-8-core-Processor-Review
Tom's Hardware
http://www.tomshardware.com/reviews/intel-core-i7-5960x-haswell-e-cpu,3918.html
Overclock3d
http://www.overclock3d.net/reviews/cpu_mainboard/intel_i7_5960x_review_with_asus_x99_deluxe/1
Digitalstorm
http://www.digitalstormonline.com/unlocked/intel-haswell-e-5960x-review-and-overclocking-benchmarks-idnum324/
Techreport
http://techreport.com/review/26977/intel-core-i7-5960x-processor-reviewed
HotHardware
http://hothardware.com/Reviews/Intel-Core-i75960X-CPU-Review-HaswellE-Debuts/#!bMl8ic
OverclockersClub
http://www.overclockersclub.com/reviews/iintel_core_i7_5960x_extreme_edition/
TweakTown
http://www.tweaktown.com/reviews/6620/intel-core-i7-5960x-ee-haswell-e-cpu-and-x99-chipset-review/index.html
Bit-Tech
http://www.bit-tech.net/hardware/2014/08/29/intel-core-i7-5960x-review/1
EuroGamer
http://www.eurogamer.net/articles/digitalfoundry-2014-intel-core-i7-5960x-review
Hexus
http://hexus.net/tech/reviews/cpu/73809-intel-core-i7-5960x-22nm-haswell/
MaximumPC
http://www.maximumpc.com/haswell-e_review_2014
Techpowerup
http://www.techpowerup.com/reviews/MSI/X99S_GAMING_7/1.html
wccftech
http://wccftech.com/review/x99-review-msi-x99s-gaming-9-ac-motherboard-review/

Thermalright Archon IB-E X2

#77 #77

Thermalright Silver Arrow IB-E

#77 #77

Noctua NH-D15S

#77 #77


DeepCool Captain 360

#77

Corsair Hydro H110i GT

#77

Alphacool NexXxoS Cool Answer 240 D5/UT

#77

Alphacool NexXxoS Cool Answer 360 D5/UT

#77

1. Скачать архив
для 64 битных ОС https://www.blend4web.com/blender/re...-windows64.zip
для 32 битных ОС https://www.blend4web.com/blender/re...-windows32.zip
2. Извлечь его содержание в любое место
3. Скачать сцену для рендеринга https://yadi.sk/d/ZnkIRjqk35zAkQ
4. Перезагрузить комп и выключить все процессы на фоне
5. Запустить блендер, открыть в нем файл RyzenGraphic_27.blend и запустить рендеринг.

Внимание - тест нужно прогнать 2 раза изза того, что AMD на презентации четко не указали параметры рендеринга, но профессионалы работы с Блендер и владельцы 6900К утверждают, что такие результаты как в тесте достигаются при параметре сэмплинга 100. При этом этот параметр по умолчанию 150. По этому следует сначала замерить время по умолчанию, а потом сделать второй прогон изменив параметр справа внизу на панели Samples-Render: 150 на Samples-Render: 100.

Что бы включить в AIDA 64 мониторинг температуры памяти нужно пройти в настройки -> Стабильность, поставить галочку в пункте -"Поддержка термодатчиков DIMM"

#77

#77

2696v4 - это низкочастотник - 2,8Ггц, а в нагрузке с avx он скидывает частоту согласно офсету -2 до 2,6Ггц.
анлокнутый 2696v3 - при серьезных многопоточных нагрузках становится нестабильным, отключение ядер еще больше усугубляет ситуацию - фризы, лаги и пр. прелести.
у 2699v3 - никогда не было и не будет частоты 3.7Ггц.
и отключать ядра в кластерных камнях с двумя кольцевыми шинами и с фрагментированным кэшем - это плохая идея.

видюхи 3080/4070 - максимум, что вытянут со скрипом зионы 26ХХv3/v4 и то в 2К, 4К.

топовый 22-и ядерник на платформе - это 2699Av4
топовый 20-и ядерник - 2679v4

для игрушек удачный 5960Х - будет интересен чем любой зион 26ХХv3/v4

Р.S. когда в Асрок Х99 вставляешь зион v4 - по систем агенту прилетает +300mV и этот офсет становится недоступным, исправить можно только модификацией биоса.

After few days of testing, here's what I've discovered:

The most essential thing is that the CPU is initialized WITHOUT a microcode. Allegedly it is possible to initialize the CPU with an extremely old microcode version, but so far I haven't been able to find such version (hence allegedly). Microcode version 0x1F (06/03/2014) is already too "new" to prevent this exploit from working. Since each and every motherboard bios is supplied with a microcode present (for obvious reasons), initializing the CPU without a microcode mandates that the microcode is completely removed from the bios binary. This naturally involves modifying the bios and updating it, which in some cases can be little tricky.

After testing all of the different microcodes I could find, I've found out that there are rather large differences between them. The most important thing is, that it appears that Intel has no direct or indirect means to completely prevent this exploit from working. Technically they can reduce the "yield" (clocks) in certain workloads, but not prevent it completely as it is too late when the CPU has already been initialized. Newer microcode builds generally contain workarounds for errata and because of that it is generally recommended to use the newest build available. When using this exploit you'll need to decide if you want to have the highest possible performance in all workloads, possibly at the expence of reliability or alternatively slightly lower performance at the best known reliability (i.e with the most recent microcode update).

Haswell was the first "wide" core from Intel (256-bit FP). In order to preserve power, the Power Management Unit (PMU) power gates the upper 128-bit of the FP when 256-bit instructions are not executed. In somewhere between August and September of 2014 Intel changed the behavior of the Turbo on Haswell. Previously the Turbo behavior was identical regardless if the upper 128-bit of the FP was executing or not (i.e same clocks for 128-bit and 256-bit workloads). In the microcode released in September 2014 the Turbo behavior was changed significantly, from static to workload dependant. In this microcode and all the newer ones the Turbo clocks are exactly the same for 128-bit workloads as before, but significantly lower for 256-bit workloads. On my CPU the difference is 400MHz.

The newest microcode version for the Haswell-E/EP/EX/EN production stepping (CPUID 0x306F2) is version 0x39 (10/07/2016). This microcode can be used for this exploit, however it will result in lower yield (clocks) than the earlier ones. This microcode is highly recommended if you are satisfied with a more modest boost, or require maximum reliability (professional use). This microcode also has an additional advantage on systems, which lack both the "Power Limit" or "CPU telemetry feature" (SVID) options in the bios. Version 0x39 microcode is one of the few versions, which doesn't feature the bug I call as the "LFM bug". The best way to describe the "LFM bug" is that when you use this exploit, load a newer microcode in flight and then try adjusting any of the CPU parameters (frequency, voltage, power limits, etc), the CPU will lock to the LFM state (typically 800MHz).

I personally ended up using microcode version 0x27 (08/08/2014), and this is the version which offers the best performance. This versions still features the static Turbo behavior (same for 128/256-bit workloads) and has some of the most critical Haswell-Ex erratas (such as TSX) already fixed.

Additionally there appears to be some Turbo rules, which appear to be core configuration dependant and completely fixed.

These apply on my Haswell-E HCC, but they might be different on other variants:

- >= 10 cores == Maximum Turbo Ratio available
- >= 12 cores == Maximum Turbo Ratio - 100MHz
- >= 14 cores == Maximum Turbo Ratio - 200MHz
- >= 16 cores == Maximum Turbo Ratio - 400MHz
- >= 18 cores == Maximum Turbo Ratio - 500MHz

This means that when 0x27 microcode is used, I can run my 2699 at 3.6GHz (1-10 cores), 3.5GHz (with 12 cores), 3.4GHz (with 14 cores), 3.2GHz (with 16 cores), 3.1GHz (with 18 cores), regardless of the workload.

Since the microcode can be updated in flight, controlling the microcode version in Windows might be slightly harder.
For Windows 7 - 8.1 (including their server variants) update KB3064209 must be uninstalled, in case it is found in the system. This is a microcode update, which contains microcode version 0x2E for Haswell-Ex.
Windows 10 meanwhile is distributed with microcode version 0x36. To remove it, file named "mcupdate_GenuineIntel.dll" found in System32 folder must be renamed so that the system no longer finds it. Note that I haven't tested this procedure personally, since I'm still using Windows 7.
For Linux using a specific microcode version should be quite well documented else where.

The microcode in Windows can be updated with a driver released by VMWare: https://labs.vmware.com/flings/vmware-c ... ate-driver

Here are version 0x27 & 0x39 microcodes for Haswell-Ex (0x306F2) in VMWare driver / Linux compatible format: https://1drv.ms/u/s!Ag6oE4SOsCmDhFnET3uw9wHeV4EA
Rename the desired version to microcode.dat, and proceed as instructed by VMWare.

Personally I gained around 28% of performance with this exploit.