Мощный компьютер (64 Гб RAM)- на чем строить?

[landscape]

[member="multiformat amateur"],

Ну а размеры? Объективно, у меня для Мака дублирующая система на SSD, Мак сам тоже. Буфаловский диск. Я за него столько денег уплатил, что самому к вечеру страшно становится

[multiformat amateur]

[oft]

Ну а размеры?

А какие проблемы с размерами? Сколько весит проект, с которым за день работаем? Пусть 20 картинок, пусть по 10Гб на картинку... Итого 200 Гб нетто. Значит SSD размером 400-500Гб вполне потянет. Остальное - на внешнем хранилище, как и договаривались. И сохранением версионности изменений, на всякий случай (у меня стоит на глубину 7-ми версий файла). Или на банальнейшем RAID1 из пары медленных но больших жестких дисков, если нужен бюджетный вариант. Но,снова же, повторюсь,дело это индивидуальное. Кто к чему привык, к какой реакции системы на действия пользователя. В свое время меня сильно напрягала именно скорость записи по сохранению работы в процессе (привык это делать довольно часто). Но это мой частный опыт.[/oft]

[searcher]

Если мои SSD в течение 5-ти (пяти!) лет эксплуатации окажутся ненадежными - так будет даже лучше для меня, и для моего кошелька. Поскольку в таком ужасном случае из попросту бесплатно заменят на более свежие, и, к тому времени, еще и более лучшие по характеристикам.

Да, но надо будет бодаться, что это по вине изготовителя, а не естественного износа. Да и все-таки для Ваших 10-гбайтовых файлов объем у них маловат. Использовать их как промежуточный буфер - бекап на нормальные диски делать. При этом всегда в голове будет сидеть тревога, а не сбойный ли файл пойдет в основное хранилище с них ? Но для файлового кэша сойдет.

[SPU]

При этом всегда в голове будет сидеть тревога, а не сбойный ли файл пойдет в основное хранилище с них ?

[oft]Многоуровневые контрольные суммы уже отменили? Если где-то что-то нарушится, то файл просто нельзя будет прочитать с диска.[/oft]

[searcher]

[oft]Многоуровневые контрольные суммы уже отменили? Если где-то что-то нарушится, то файл просто нельзя будет прочитать с диска.[/oft]

Это где такие, на уровне NTFS ? С предварительным просчетом CRC ?

У Вас файлы никогда разве не "портились" после перезаписи по неизвестным причинам ?

[multiformat amateur]

[oft]

Да, но надо будет бодаться, что это по вине изготовителя, а не естественного износа.

Интел, насколько помню, публикует спеки, сколько раз можно перезаписать. То есть максимальный объем записи за время жизни SSD. Даже если у меня 10 Гб файлы, и я их буду сохранять 100 раз в день (итого 1 Тб в день) то для того, чтобы исчерпать ресурс в 10 тыс записей для SSD объемом в 500Гб, после чего последует отказ от гарантий, мне нужно будет стараться 13 лет каждый божий день, без перерывов на выходные, на праздники и на отпуск. Данные давно опубликованы, и в соседней теме, где долго препирались в отношении надежности SSD я давал ссылку на реальные опыты по попытке убить SSD непрерывной записью. Поэтому, полагаю, при десктопном использовании мне ничего доказывать никому не нужно будет. Коллеги, давайте закроем вопрос "ненадежности SSD" по крайней мере в этой теме. Это уже неинтересно. Тут каждый сам для себя при необходимости решит, что ему уютнее. Исходя из своего понимания вопроса. У меня понимания вопроса давно сформировано. Методы защиты от сбоев SSD и HDD также сформированы.

При этом всегда в голове будет сидеть тревога, а не сбойный ли файл пойдет в основное хранилище с них ?

А у Вас в отношении обычного HDD такое тревоги не наблюдается? А почему?

Вот у меня сейчас контроллер сообщает, что у моего жесткого диска bad stripe (в RAID1) Мне уже пора тревожится или поблагодушничать в отношении жесткого диска? Это же не SSD... На мой взгляд, и у SSD и у HDD одинаковые возможные проблемы. Поэтому все те методы защиты, которые призваны их предотвратить, одинаково хорошо будут работать в обоих случаях. И тревога должна быть практически одинаковой в обоих случаях. Иначе - это просто формирование двойных стандартов и некоей мифологии "в пользу жестких дисков". Но, рассматриваю это просто как мифологию, корни которой лежат в несовершенстве SSD лет этак пять назад. И возможно еще нежеланию понимания какие траблы можно ожидать от "старого доброго HDD".



Мой взгляд на эту проблематику вполне кардинален, и закрывает скопом любые страхи и тревоги:

любые носители информации ненадежны. Любые! Поэтому - бэкап с историей версий файлов спасет отцов русской демократии. Дешево и сердито, без тревоги в голове. Почему же народ так носится с этими "проблемами у SSD" и игнорирует вероятности таких же проблем с сегодняшними высокоемкими HDD, в которых вероятность ошибки тоже очень ненулевая - мне лично непонятно. Хотя, подозрения есть.

[/oft]

[multiformat amateur]

Есть предложение завершить обсуждение абстрактной "ненадежности SSD в сравнении с традиционными жесткими дисками", а сосредоточиться на основном: на обсуждении стоимости сопоставимых платформ "матплата-процессор-память", и выбора именно платформы.

Поскольку это ключевое.



Основных вопросов для меня сейчас два:



Ценовой фактор:

Насколько будет дороже строить на сокете 2011 и i7 (в сравнении с традиционным вариантом мейнстрима с 32 Гб максимум) И насколько будет дороже строить на ксеоне и есс-памяти. То есть, "стоит ли овчинка выделки", грубо говоря. В сравнении с такого же уровня затратами на менйстримовый вариант. Обладая некоей суммой можем вбухать ее в сокет 1150 и максимально мощный процессор на этом сокете (какой?). Или ориентироваться на 2011 и такой же мощный процессор, и все это удорожает... на сколько? или ориентироваться на 2011 и послабже процессор, за возможность добавить памяти в дальнейшем.



Фактор надежности:

ECC и его влияние на надежность системы в случае реально больших объемов памяти. Тут хотелось бы оценку вероятностей возникновения ошибки в рамках массива 64 гб... желательно численно, а не интуитивно. Чтобы отсечь вариант с ксеонами и есс-памятью или наоборот, утвердиться в нем. Вот тут мне написали в личной переписке про наличие IBM-овского исследования, которое обычно цитируют когда речь заходит о необходимости есс: (1 ошибка на 256Mb RAM в месяц). Но, это старое исследование, когда память была иной структурно.

[SPU]

Это где такие, на уровне NTFS ? С предварительным просчетом CRC ?

У Вас файлы никогда разве не "портились" после перезаписи по неизвестным причинам ?

[oft]На уровне файловой системы и на уровне носителя (там еще и коррекция ошибок используется). Кругом контрольные суммы. Если у Вас портятся файлы, то проверяйте память (в исключительных случаях мат.плату/процессор), это единственное место, где на обычных компьютерах не проверяются контрольные суммы.[/oft]

ECC и его влияние на надежность системы в случае реально больших объемов памяти.

Очень трудно такие оценки найти, особенно актуальные. Самой ECC памяти тьма разновидностей, да и сравнивать ее с обычно некорректно, т.к. там сами ячейки памяти другие. Единственное, что могу сказать - это то, что серверные мат. платы ведут лог ошибок памяти. Возможно, кто-то поделится своей статистикой.



Что касается надежности вообще, то это довольно бессмысленный вопрос, т.к. объем кода по сравнению с объемом данных чрезвычайно мал, а ошибка в данных ни к каким фатальным последствиям как правило не приводит и даже остается незамеченной. Тот же индиз сам по себе падает и виснет по 100 раз в день на ровном месте, хорошо хоть проект всегда сохраняет. Поэтому чаще всего абсолютная стабильность аппаратной части никакого реального вклада не вносит, кроме психологического.

[multiformat amateur]

Тот же индиз сам по себе падает и виснет по 100 раз в день на ровном месте, хорошо хоть проект всегда сохраняет. Поэтому чаще всего абсолютная стабильность аппаратной части никакого реального вклада не вносит, кроме психологического.

По здравому рассуждению, тут может быть индуцированный эффект. Аппаратные ошибки могут быть незаметны на данных (типа пиксель в картинке будет немного другого цвета). Но, могут быть заметны для кода, который, условно говоря, столкнется с делением на нуль, вместо единицы (пример условный). Если оценивать, что 1 Гб RAM дает 4 ошибки в месяц, то 32 Гб RAM даст 120 ошибок в месяц, что может влиять также и на зависания кода программ в части случаев (улыбка). Хотя, повторюсь, это сугубо гипотеза. Текущих данных о вероятностях ошибок RAM у меня нет, и влияния на софт - тем более. Мы тут вступаем в область предположений или интуитивностей. Просто ECC исключает эти вероятности. Это примерно также, как народ покупает топовые фотокамеры, чтобы потом не гнать пургу на сами камеры, а не на свои кривые руки. Даже если эти топовые камеры для него избыточны, просто ликвидируется сама вероятность оправдывания проблем вопросами железа, а не рук или софта.

[SPU]

Просто ECC исключает эти вероятности.

Ничего не исключает. ECC глючит точно так же как и обычная память. Другое дело, что именно за счет ECC можно оперативно определить причину проблемы.

Тут нужно отделить проблемы самой памяти (брак, плавающий глюк и т.п.) и внешние факторы. В первом случае компьютер будет работать нестабильно с хаотично возникающими проблемами. Во втором случае (высокоэнергетическая частица пролетела ) ECC, конечно, окажет помощь.

Ну и, конечно, логично оценивать рост вероятности ошибки с увеличением количества памяти, но с увеличением памяти очень сильно растет соотношение код/данные. Если, например, на 4 ГБ приходилось, например, 10% кода, то на 64 ГБ выйдет 0.25%, т.е. вероятность критического сбоя на самом деле ни сколько не изменится. Я уж не говорю про то, что повреждение далеко не всякого кода вообще приведет к чему-либо, бОльшая часть его просто висит в памяти мертвым грузом.



[oft]Индиз везде так работает, в т.ч. разных версий. Так что это не проблема конкретного компьютера.[/oft]