Цілісність даних при розгоні MCE з високим числом ядер E5 Xeon?

Довічний

Потік Xeons і MCE змусив мене замислитися, що станеться з цілісністю даних, якщо розгін MCE справді виявиться можливим на різних Haswell E5 Xeons?

У разі включення MCE на E5-2699 v3 (18 ядер/36 потоків з турбонаддувом 3,6 ГГц та базовим тактовим сигналом 2,3 ГГц) це може становити 56% розгону для роботи з усіма ядрами

У разі включення MCE на E5-2690 v3 (12 ядер/24 потоки з турбонаддувом 3,5 ГГц і базовим тактовим частотою 2,6 ГГц) це може становити 35% розгону для роботи з усіма ядрами

Якби охолодження процесора було достатнім, то наскільки більш поширеними можуть бути різні типи помилок? Чи можна використовувати оперативну пам'ять ECC з таким розігнаним MCE E5 Xeon?

Припустимо, головним завданням є редагування відео, але мені дуже цікаво вислуховувати думки щодо інших типів завдань, класичних для високої кількості ядер Server Xeons?

Idontcare

Елітний член

Цільова аудиторія не може відповісти на це питання.

Тільки Intel може повноцінно, належним чином і достатньо відповісти на ваші проблеми.

Якщо ви дійсно хочете знати відповідь на своє запитання, вибірка випадкових людей на форумі не замінить вас.

Якщо ви, однак, ви просто шукали розмову, подібну до філософствування 12-ї ночі бару, ви потрапили в потрібне місце!

Довічний

Цільова аудиторія не може відповісти на це питання.

Тільки Intel може повноцінно, належним чином і достатньо відповісти на ваші проблеми.

Якщо вам справді потрібна відповідь на ваше запитання, вибірка випадкових людей на форумі не замінить вас.

Idontcare

Елітний член

Ну в такому випадку!

За умови, що випадкова (щоденна, щотижнева) помилка не призведе до того, що ви без фотографій для медового місяця чи без грошей і без роботи, про що турбуватися? Дій!

SOFTengCOMPelec

Платиновий член

Голова

Алмазний член

У разі включення MCE на E5-2699 v3 (18 ядер/36 потоків з турбонаддувом 3,6 ГГц і базовим тактовим сигналом 2,3 ГГц) це може становити 56% розгону для роботи з усіма ядрами

Йовець

Старший член

Я думаю, що основна передумова неправильна. Я не думаю, що ви досягнете +13 мульти на 18 ядрах при будь-якій розумній напрузі та температурі при майже 100% навантаженні, навіть якщо MCE працював над цим. + 2/+ 4 може бути можливим, але є причина, чому Intel скидає годинник, додаючи ядра.

Як сказав IDC, у вас практично немає методу перевірки корупції, хоча це може не мати значення для кодування відео. ECC не збирається допомагати помилкам центрального процесора - ECC захищатиме від перегортання бітів пам'яті або пошкодження даних, але нічого не робитиме, якщо сам процесор надсилає неправильні дані в оперативну пам'ять (ECC просто гарантує, що неправильні дані не змінюються мовчки, поки це в пам'яті).

Редагування може бути завданням у реальному часі, але більшість кодування - ні. Двоядерний целерон може ефективно працювати настільки ж швидко, як і 18-ядерний Xeon, якщо вони обидва виконують завдання перед наступним використанням (кодують протягом ночі, у фоновому режимі тощо). Щось на зразок 4790k на 4,4 ГГц (запас, одноядерний турбо) може бути навіть кращим, якщо завдання редагування однопотокові, забезпечуючи більшу продуктивність, поки ви фактично використовуєте систему для редагування.

DrMrLordX

Довічний

Якщо ви говорите про пошкодження даних у значенні: "Я намагався зберегти x до і замість цього отримав y, що не те, що я передбачав", то я б сказав + 0%. Те, про що ви говорите, насправді стане можливим лише в тому випадку, якщо контролер (и) зберігання даних включає помилкові дії (операції) запису, що НЕ ЗБІРАЄТЬСЯ, але знову ж таки, це на контролері сховища.

Отже, якщо ви не виштовхуєте контролер зберігання з-за специфікації (а ви не з MCE), то вам нема про що турбуватися в цьому відділі.

Так, машина, що працює "поза специфікацією", може десь перевернути неправильний біт із процесора або розгону пам'яті, що робить можливим, що (наведемо наведений вище приклад) у вас буде один піксель неправильно забарвлений на одному кадрі відео або. . . щось Але я зробив різницю між пошкодженням пам'яті та пошкодженням пам'яті з причини: якщо ви перевернете неправильний біт у пам'яті, існує велика ймовірність того, що це нетривіальним чином призведе до помилки або просто виведе з ладу всю машину. Імовірність того, що ви перевернете неправильний біт І перевернете біт, який не є важливим для поточної стабільної роботи машини, насправді досить низька.

На відміну від цього, контролер сховища, що тихо перемикає десь 0 на 1, ні до чого не призведе, оскільки система не залежить від цього записаного біта для роботи, якщо випадково не пошкоджує всю таблицю файлів або щось інше.

Будь-яка потенційна проблема розгону процесора або оперативної пам'яті, мабуть, виявиться як нестабільність системи, перш ніж дійти до того, що ви ненавмисно пишете сміття на диск/SSD/SAN/що завгодно.