LINUX.ORG.RU
ФорумTalks

ECC-память не нужна

 , ,


0

4

1) Допустим, вы хотите собрать скромный сервер под БД. Ну, у вас есть 1000 новых записей за день, а каждый год вы начинаете заполнять новую базу. Итого у вас в каждой базе всего ~300000 записей.
2) Даже если каждая из них по 100000 байт (ну куда, куда столько?) то вся база влезет в 32 GB памяти.
3) 8-ми гиговые модули для десктопных машин это уже не экзотика.
С конца 2011 года уже почти все производители выпустили ассортимент таких продуктов.
4) и стоит недорого - к примеру Kingston обойдется в 3000 рублей за модуль = 12 тыр за 32 GB
5) основное отличие серверных модулей в том, что они Registred. Т.е. на планку памяти ставится дополнительная микросхема-регистр, назначение которой заключается в том, чтобы уменьшить электрическую нагрузку на контроллер и позволить устанавливать больше модулей памяти в одном канале.
понятно, что у нас всего 4 модуля и поэтому Registred память не обязательна
6) к тому же Registred-память слегка медленнее - из-за использования регистров возникает дополнительная задержка на один такт при работе с памятью.

Есть возможность собрать десктопный комп с поддержкой ECC, но не registred памяти:
7) Модули с ECC и без него по формфактору, пинам и напряжению одинаковые (там 72 линии)
8) С тех пор как контроллер памяти разместили в кристалле к процессора,
совместимость материнки с памятью осталась только механическая и электрическая, но не функциональная.
в каких процах появился интегрированный контроллер памяти?
у AMD - в K8 ~ с апреля 2003
у Intel - в Nehalem ~ 4 квартал 2008
процессоры на базе ARM - примерно с 2010-го ()
9) бывают модули памяти с ECC, но не Registred
10) существуют десктопные процессоры, поддерживающие ECC (i7-660UE, i7-610E, i5-520E, i3-330E, Celeron P4505, Celeron U3405 )
11) существуют десктопные материнские платы с поддержкой ECC
(и стоить он будет дешевле серверного раза в два-три).

Но мысль на этом не останавливается.
12) ECC нужна для защиты от повреждения данных в памяти, повреждения могут возникнуть от ионизирующего-излучения и космических лучей.
Счетчик Гейгера - газоразрядный прибор, в котором ионизация газа излучением превращается в электрический ток между электродами.
Приблизительная норма в помещении - до 20 мкР/час
защита
от альфа-излучения — лист бумаги, резиновые перчатки, респиратор;
от бета-излучения — плексиглас, тонкий слой алюминия, стекло, противогаз;
от гамма-излучения — тяжёлые металлы (вольфрам, свинец, сталь, чугун и пр.). 10 сантиметров плотно слежавшегося грунта ослабляют гамма-излучение вполовину;
от нейтронов — вода, полиэтилен, другие полимеры (например наполненные водородом борные нанотрубки), бериллий - металлический бериллий относительно мало реакционноспособен при комнатной температуре (стоит 500 долл./кг);
13) Я не осилил пересчет естественного радиационного фона через зиверты и размер планок памяти
в частоту возникновения ошибок, поэтому «сошлюсь на ученых LORа»:
4000 ошибок за год на планку
3751 ошибка на планку в год
планок 4-ре, в году 365 дней => 1 ошибка раз в три часа
14) не вся память используется под хранение данных, часть пустует
15) суммарный оверхед при аппаратной защите составляет 12% стоимости системы (потому что +1 микросхема для проверки на 8 микросхем для хранения)
16) значит можно сэкономить часть стоимости аппаратных средств, заменив аппаратную проверку целостности данных в памяти на программную проверку целостности объектов.
17) маловероятно, что ошибка возникнет именно в коде проверке ошибок (его объем мал по сравнению с размером всей памяти), кроме того, этот объем можно уменьшить до нескольких десятков байт, проверяя целостность кода проверки (что по сравнению с 32-мя гигабайтами на 9-10 порядков ниже ~= 1 ошибка раз в 60 тысяч лет).
18) Особенно это удобно сделать в управляемой среде типа mono или jvm.
19) Учитывая наличие моно под ARM (там уже всё есть: и тулчейн на C#, и ядро, и шелл, и прикладные программы), где не сильно распространена ECC-память, мне это кажется хорошей идеей



Последнее исправление: StrongDollar (всего исправлений: 3)

заменив

Хорошо, меняй.

Я никогда не сталкивался с искажением данных в памяти. Но я и редко хранил в памяти больше 500-600 МиБ данных.
В общем — мне насрать. Делай что хочешь.
Или ты хотел что-то спросить?

Stahl ★★☆
()

значит можно сэкономить часть стоимости аппаратных средств, заменив аппаратную проверку целостности данных в памяти на программную проверку целостности объектов.

Медленно и не слишком надежно.

маловероятно, что ошибка возникнет именно в коде проверке ошибок

Ошибка возникнет где угодно в коде вашей виртуальной машины.

Deleted
()

Стой, а как же производиителии железа рынок сегментировать будут?

DNA_Seq ★★☆☆☆
()

Ну, у вас есть 1000 новых записей за день

Какой-то уж черезчур скромный сервер.

ziemin ★★
()
Ответ на: комментарий от Deleted

не слишком надежно

а вот это ещё надо доказать. Программно-то можно обнаруживать и больше ошибок и исправлять тоже больше. А аппаратно - только 1 бит исправлять и два обнаруживать.

Медленно

и это тоже надо доказать, что требуемая дополнительная мощность процессора будет дороже, чем стоимость аппаратной проверки

StrongDollar
() автор топика
Ответ на: комментарий от Stahl

Я никогда не сталкивался с искажением данных в памяти.

Все сталкивались. Множество глюков и случайных сбоев обусловлены именно этим. Редко удается поймать битовую ошибку «с поличным».

Deleted
()
Ответ на: комментарий от Deleted

где угодно в коде вашей виртуальной машины

кстати, часто вы проектируете машины со сроком службы >60 тысяч лет?

StrongDollar
() автор топика
Ответ на: комментарий от StrongDollar

Программно-то можно обнаруживать и больше ошибок и исправлять тоже больше. А аппаратно - только 1 бит исправлять и два обнаруживать.

Возьмите код посложнее, и будет вам счастье. Аппаратное всегда будет дешевле программного.

надо доказать, что требуемая дополнительная мощность процессора будет дороже, чем стоимость аппаратной проверки

А что тут доказывать? Буквально сегодня с коллегами раскуривали одну такую ситуацию. Простая проверка целостности структурки добавляет множество инструкций к простому коду.

К тому же, кроме данных, вам надо проверять и целостность самого кода. Это дурная тема, сильно нагружает процессор и ухудшает процент попадания в кэш. Плавали, знаем. Если уж так нужно, лучше реализовать аппаратно.

Deleted
()
Ответ на: комментарий от StrongDollar

кстати, часто вы проектируете машины со сроком службы >60 тысяч лет?

А кто вам гарантирует, что ошибка случится в следующую минуту, а не через тысячу лет? Это же случайный процесс. Лишние глюки нам ни к чему.

Deleted
()
Ответ на: комментарий от Deleted

А кто вам гарантирует, что ошибка НЕ случится в следующую минуту, а не через тысячу лет?

ну так у HDD/SSD MTBF гораздо ниже - миллионы часов, они среднестатичстически откажут раньше, чем испортится код в памяти.

StrongDollar
() автор топика
Последнее исправление: StrongDollar (всего исправлений: 1)
Ответ на: комментарий от Deleted

проверка целостности структурки добавляет множество инструкций к простому коду.

Есть такая штука как вызов подпрограмм. Код проверки целостности структурки будет в считаном числе экземпляров на всю OS

StrongDollar
() автор топика
Последнее исправление: StrongDollar (всего исправлений: 1)
Ответ на: комментарий от StrongDollar

ну так у HDD/SSD MTBF гораздо ниже - миллионы часов, они среднестатичстически откажут раньше, чем испортится код в памяти.

Код в памяти портится намного чаще, чем дохнут харды. Были разные исследования. По памяти точные цифры не помню. Для этого и придумали RAID и ECC.

Deleted
()
Ответ на: комментарий от StrongDollar

Есть такая штука как вызов подпрограмм.

Время вызова!

Код проверки целостности структурки будет в считаном числе экземпляров на всю OS

Время выполнения!

Deleted
()
Ответ на: комментарий от Deleted

Код в памяти портится намного чаще, чем дохнут харды.
По памяти точные цифры не помню.

сходи по ссылкам в исходном сообщении темы, там исследования гугла и какого-то университета. И цифры прямо в посте написаны.

И вероятность повреждения маленького кода проверки я тебе посчитал. Опровергни конкретно.

StrongDollar
() автор топика
Ответ на: комментарий от Deleted

Время выполнения!

да пофигу - боттлнеком всегда было и будет чтение с дисковой подсистемы.

А ещё сеть между компьютерами медленнее шины процессор-память

StrongDollar
() автор топика
Последнее исправление: StrongDollar (всего исправлений: 1)
Ответ на: комментарий от Stahl

Хорошо, меняй.

ну там же всё равно сборщик мусора все объекты обходит (и копирует с места на место). Ну будет ещё периодически контрольные суммы обсчитывать.

Причем можно попробовать вести контроль с учетом важности операции для бизнеса, но это уже другая тема (для допиливания языка и компилятора).

StrongDollar
() автор топика
Последнее исправление: StrongDollar (всего исправлений: 1)

Вот смотри, я полез в свои старые серера с продуктивным SAP... И о боже... Там обычная десктопная память samsung, это в серверах класса Itanium RX 3xxx. - Вот как оно работает? - А хрен его знает, но похоже твоя теория верна.

В ECC памяти тоже могут быть я думаю ошибки... И ОС и другое распространённое ПО скорее всего умеют бороться так или иначе с такими вещами. Стало быть ты дважды прав. ИМХО.

DALDON ★★★★★
()
Ответ на: комментарий от StrongDollar

боттлнеком всегда было и будет чтение с дисковой подсистемы

Чем дальше к ночи тем ближе мы приходим к выводу, что на серверы можно ставить медленную память и слабый процессор

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)

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

Lordwind ★★★★★
()

повреждения могут возникнуть от ионизирующего-излучения и космических лучей.

А также плохого питания и просто изначально бракованных чипов памяти. ECC не помешает.

Suigintou ★★★★★
()
Ответ на: комментарий от StrongDollar

И вероятность повреждения маленького кода проверки я тебе посчитал. Опровергни конкретно.

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

Deleted
()
Ответ на: комментарий от DALDON

Ты хочешь сказать, что на ECC памяти глюков никогда не бывает внезапных?

Бывает, но крайне редко.

Deleted
()

Ээээ. У вас бизнес или хобби? Если бизнес, то стоимость сервера наименьшая затрата в долгосрочной перспективе. Денег на воду, бумагу, ручки, кофе и чай уйдет в пару раз больше :)

gh0stwizard ★★★★★
()

суммарный оверхед при аппаратной защите составляет 12% стоимости системы (потому что +1 микросхема для проверки на 8 микросхем для хранения)

Я не уверен что эта микросхема стоит столько же как и остальные. Там же, вроде, один бит на 64. Т.е. оверхед 1/64 дополнительной памяти, не?

В цене всего сервера себестоимость ECC несущественна, имхо. Другое дело что производители имеют тенденцию увеличивать навар с ынтырпрайз-решений.

true_admin ★★★★★
()
Последнее исправление: true_admin (всего исправлений: 1)

Только вот маркетолухи решили, что болше 64гб не поставить на !ЕСС :)

dk-
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.