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 и этот офсет становится недоступным, исправить можно только модификацией биоса.

http://www.nirsoft.net/utils/blue_screen_view.html
BSOD коды:

0x101 = увеличить vcore
0x124 = увеличить vcore
0x0A = нестабильна RAM, иногда нужно и увеличить vcore
0x1E = увеличить vcore
0x3B = увеличить vcore
0x3D = увеличить vcore
0xD1 = нестабильна RAM, иногда нужно увеличить vcore и/или vring
0x9C = нестабильна RAM, иногда нужно увеличить vcore и/или vring
0x50 = нестабильна RAM и/или увеличть vring
0x109 = много или мало напряжения на RAM.
0x116 = Напряжения на южном и/или северном мосту низкое, переразгон встроенного iGPU.
0x7E = Повреждены системные файлы, возможно от разгона. Запустить sfc /scannow и chkdsk /r


Описание ошибок BSOD
0x101 = increase vcore
0x124 = increase/decrease vcore
0x0A = unstable RAM/IMC
0x1E = increase vcore
0x3B = increase vcore
0x3D = increase vcore
0x50 = RAM timings/Frequency unstable
0x109 = Not enough or too Much memory voltage
0x116 = Low IOH (NB) voltage, GPU issue
0x7E = Corrupted OS file

ps. если не успеваете читать номер ошибки можно скачать программу Blue Screen View http://rghost.ru/40560166 которая прочитает дамп.
Описание ошибок BSOD
0x101 = увеличение Vcore
0x124 = увеличение / уменьшение напряжении
0x0A = неустойчивым RAM / ИМК
0x1E = увеличение Vcore
0x3B = увеличение Vcore
0x3D = увеличение Vcore
0x50 = RAM тайминги / частота неустойчивых
0x109 = не достаточно или слишком много напряжения памяти
0x116 = Low IOH (NB) напряжения, GPU вопрос
0x7E = поврежденных файлов OS
вроде так

BSOD Codes for SandyBridge:
0x124 = увеличить или уменьшить VccIO и/или VccSA , если не помогло увеличить Vcore.
0x101 = необходимо увеличить Vcore.
0x50 = неверно подобраны тайминги или множитель памяти, увеличить/уменьшить Vddr, если не помогло VccIO и/или VccSA.
0x1E = необходимо увеличить Vcore.
0x3B = необходимо увеличить Vcore.
0xD1 = увеличить VccIO /или VccSA.
0x9C = увеличить или уменьшить VccIO и/или VccSA, если не помогло увеличить Vcore.
0X109 = увеличить/уменьшить Vddr.
0x0A = увеличить VccIO и/или VccSA

BlueScreenView – утилита для определения драйвера, вызвавшего BSOD
Посетителей: 106744 | Просмотров: 146102 (сегодня 99) Шрифт:

Ко мне обратилось сразу несколько человек с вопросом, стоит ли вместо Debugging Tools for Windows использовать для анализа дампов памяти относительно недавно вышедшую утилиту BlueScreenView. Бесплатные утилитыNirSoft (автор – Nir Sofer) хорошо известны своей полезностью, удобством и продуманностью функционала. И BlueScreenView действительно очень удобна для определения проблемного драйвера.
По умолчанию она ищет дампы в папке %systemroot%\Minidump, но можно настроить и собственную папку (Options –> Advanced). Для найденных драйверов утилита отображает:
• В верхней панели – название файла, дату создания, название стоп-ошибки, код ошибки, параметры, а также драйвер, предположительно вызвавший проблему (Caused By Driver).
• В нижней панели – (в зависимости от настроек в Options –> Lower Pane Mode) все драйверы, загруженные во время ошибки, или только драйверы, найденные в стеке. Среди всех драйверов - на розовом фоне отображаются предположительно вызвавшие проблему драйверы. Также, утилита может отображать синий экран, очень похожий на тот, который все так любят.
Важно! Я должен отметить, что при определении драйвера не нужно полагаться только на имя файла в столбце Caused by Driver. Следует рассмотреть драйверы в нижней панели (или только выделенные розовым цветом, если включено отображение всех драйверов), в первую очередь обращая внимание на несистемные драйверы.
Утилита очень быстро работает, а также обладает дополнительными возможностями по копированию отдельных строк и созданию HTML-отчетов.
BlueScreenView vs. kdfe.cmd / WinDbg
В приведенном выше скриншоте виновником проблемы являлся не USBPORT.SYS (системный драйвер), aclaudsl.sys (драйвер модема). Именно на последний указал анализ kdfe, полагающeгося на Debugging Tools for Windows. И тут я перехожу к вопросу, насколько корректен анализ утилиты по сравнению с kdfe / WinDbg.
Честно говоря, я не являюсь экспертом по отладке, но одно очевидно сразу: в отличие от WinDbg, BlueScreenView не использует для анализа символы, загружаемые с сайта Microsoft. Я поинтересовался у автора программы, насколько корректным считает он анализ в этих условиях. И вот что он ответил (в сокращении):
Вне зависимости от того, используете вы BlueScreenView или WinDbg с символами, невозможно достичь абсолютной точности в определении драйвера.
Я не думаю, что символы помогли бы моей утилите произвести более точный анализ. В символах содержится дополнительная информация, которая может помочь профессионалам определить точную причину - например, функцию внутри драйвера, вызвавшую ошибку. Однако определение драйверов, вовлеченных в ошибку, может быть выполнено на основе адресов памяти без всяких символов.
Я решил проверить, насколько результаты BlueScreenView совпадают с kdfe. Поскольку в материале нет недостатка, я взял навскидку полтора десятка дампов с наиболее распространенными кодами (0x8E, 0x50, 0xD1 и 0x0A). Лишь в одном случае результаты отличались – BlueScreenView указала на системный драйвер, а kdfe – на драйвер Outpost Firewall. Тестирование также выявило, что далеко не всегда BlueScreenView верно указывает на проблемный драйвер в верхней панели, но во всех случаях кроме одного, оговоренного выше, проблемный драйвер был обозначен в нижней панели. Таким образом, kdfe понятнее указывает на проблемный драйвер. Однако наблюдалась и обратная картина – иногда kdfe однозначно указывает на системный драйвер, в то время как BlueScreenView выделяет еще и несистемные, которые также могут оказаться причиной проблемы.
Резюме
Я вполне могу порекомендовать BlueScreenView для быстрого анализа дампов памяти, создающихся при BSOD. Однако утилита не всегда однозначно указывает на проблемный драйвер в верхней панели. Поэтому, вместо того чтобы любоваться в нижней панели картинкой синего экрана, лучше включить для нее отображение драйверов и изучить их список. В неочевидных случаях лучше также провести анализ с kdfe, а для глубокого анализа без WinDbg все равно не обойтись.

Автор: Вадим Стеркин • Иcточник: Блог • Опубликована: 21.09.2009