А побыстрее нет DDR3 ECC? 1600 или 2133 ??

Александр Жабин "Вам шашечки или ехать?". ВОт побыстрее: http://www.memoryamerica.com/d3204872r10mwo.html Вы главное на цену внимание обратите. И да - официально 1600МГц не держит ни одна сервачная мамка.

Бывает. Такую даже обычные феномы от АМд хавают.

да у меня системник столько стоит! Вот и думай надо оно мне или нет ?

Для работы - определенно нет. Но при желании можно и 1333 ECC разогнать, вполне вероятно что 1600 выдержит.

Разгоняя память мы увеличивает вероятность ошибок, зачем брать ECC в этом случае, если оно для того чтобы уменьшить эту вероятность?

ECC разогнать обычно нельзя, материнка не дает. Во всяком случае все виденные в последние годы материнки, работающие с DDR3 ECC что registered, что unbuffered не позволяли выставлять частоту и тайминги, там все с этим было строго.

А можно программно сделать ECC ???

Александр Жабин Нет. ECC работает на уровне контроллера памяти, обрабатывать на более программном уровне было бы слишком медленно, надо полагать. На каждые 8 чипов на планке памяти есть 9-ый, и шина от планки памяти к контроллеру шире (72 бита у ECC с 9 чипами, без ECC с 8 чипами шина 64 бита, это цифры для DDR2 & DDR3 UDIMM) для доступа к дополнительному чипу. За счет дополнительной емкости контроллеру памяти есть куда складывать контрольные суммы. Т.е. нужна поддержка ECC и в самой памяти (дополнительный чип), и в материнке (больше линий от планок к контроллеру), и в контроллере памяти (более сложная логика), иначе ничего работать не будет.

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

А вам зачем, собственно? Если задачи серьезные, решение на unbuffered ECC нынче можно собрать совсем недорого, не сильно дороже решения без ECC.

Для создания модели роста опухоли, её взаимодействия с иммунной системой и цитостатиками. Расчет и предсказание. Получается, если мать поддерживает ECC, то программный эмулятор ECC мог бы взять на себя функцию 9 чипа, и можно было бы выделить целое ядро процессора для постоянного скрининга. Особенно на памяти 2133 Мхз

Мда, помойму это сложнее, чем моделирование ядерного взрыва ...

Но ИМХО в таких расчетах всякие ошибки надо сводить к минимуму, значит с ECC и никакого разгона.

Сложно добыть первичные данные. Нужен эксперимент. Снять параметры в динамике, фиксируя все параметры и варьируя одним. И так сделать с каждым из параметров. Ну и все: база данных, система, корреляционный анализ и тд и тп. В общем это выходит за рамки данного форума. Коплю на ЕСС...

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

И на все вариации есть база?

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

Александр Жабин Система на нормальной матери и Core i7-2600K стоит 20 т.р. Аналогичный по производительности сервер начального уровня на том же Sandy Bridge с зеонами, ECC-памятью, качественной материнкой с IPMI стоит 25 т.р. Т.е. для начальных конфигураций разница в ECC против не-ECC - всего ничего (а бонусом более качественная материнка и функции управления). Вопрос, зачем пытаться делать что-то софтварно (тем более что это невозможно)?..

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

Добавлено спустя 5 минут 17 секунд:
Просто логика такова, что если есть физический контроллер, то может быть и виртуальная копия, делающая тоже самое; частоты non-ECC превышают ECC на 533 Мхз, что может компенсировать отсутствие физического контроллера. А вносить изменения в программный код значительно легче чем в уже созданный модуль памяти (что реально невозможно, кроме как на этапе дизайн-проекта).

Александр Жабин Дело не в частоте. Реальная работа с памятью замедлится многократно из-за увеличения латентности; вместо операции "отправить записываемый блок памяти в контроллер" вам придется каждый блок памяти, отправляемый на запись вначале прочитывать, считая коды Хэмминга, потом дописывать результат к нему и только тогда записывать. Т.е. вместо операции "запись" у вас есть "чтение+запись". Но дальше будет совсем плохо, т.к. работа с памятью идет 64-х битными словами, а в случае ECC не просто так добавляют чип и используют 72-х битные слова - если вы попытаетесь записать 72 бита без дополнительного чипа, вам оставшиеся 8 бит придется отправлять вторым словом, так как вы вылезете в следующее слово и собьете выравнивание. Таким образом, в лучшем случае будет двухкратное замедление и емкость памяти упадет вдвое (если сохранять выравнивание), в худшем - замедление в несколько раз, если оставлять 8/9 исходной емкости и, как следствие, собьется выравнивание (боюсь даже предположить, во сколько - думаю, как минимум на порядок).
Это все не считая первого момента с рассчетом кодов и значительного возрастания нагрузки на процессор, которому придется постоянно считать коды и держать код для их вычисления в маленьком кэше первого уровня, а вычисляемые данные постоянно прогонять вхолостую через тот же кэш.

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

А зачем там изменения вносить, вообще непонятно. Кодам Хэмминга, используемым в ECC, уже 60 лет и они безумно просты, их проходят в школе на уроке информатики. Закодировать в железку вычислять 8 бит кода на 64 бита данных при записи и проверять при чтении проще простого - в контроллере это проходит "потоком", и вышеперечисленных проблем нет, замедление 2-3% максимум.
А ECC Chipkill, RAIM и прочие навороченные серверные технологии, защищающие от многобитовых ошибок, зависимых ошибок или позволяющих работать при полном выходе из строя планки памяти это уже высший пилотаж, оно и в железе-то обходится очень дорого, о софтварном применении таких штук и речи быть не может.

Хорошо. А возможно создать например PCI-E ECC контроллер ??

Собсно Mosga всё написал, правда длинно и не сразу понятно, но думаю верно. Лет 10 назад один старый компьютерщик мне сказал, что "аппаратная поддержка лучше программной", по истечении времени я понял, что аппаратная НАМНОГО лучше программной, поскольку освобождает центральный процессор от ненужных расчетов, аппарат (устройство) сам берет на себя вычисления соответствующих функций и выдает центральному процессору "готовый результат".

В частности в памяти с ECC осуществлена аппаратная поддержка коррекции ошибок. Модули памяти сами занимаются соответствующими вычислениями и выдают готовый результат.

Другой вопрос регистровая или не регистровая (buffered & unbuffered). Как и ECC, Регистр так же призван аппаратно облегчить работу контроллера памяти:

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

Еще пример аппаратной поддержки - RAID-контроллеры.
Некоторым для формирования RAID-массива требуется участие центрального процессора (как правило дешевым), а другие самостоятельно "аппаратно" его формируют (как правило дорогие). Обычно в дорогих RAID-контроллерах применяется ECC ... так же ECC применяется в некоторых SSD-накопителях, и даже флэшках-SD.

Если не ошибаюсь, пропускная способность PCI-E 1x в 4 раза меньше DDR3-1333.

Александр Жабин Можно, если речь идет про ECC на собственной памяти этого контроллера. Так как у него своя память и на плате есть чип, реализующий контроллер памяти для доступа к этой памяти, то не проблема реализовать в этом контроллере памяти ECC. Более того, все серверные RAID-контроллеры и другие, имеющие кэш обязательно используют ECC; косвенно подтвердить это легко по нечетному числу чипов (по причине, описанной выше - выравнивание). Не обязательно 8+1, иногда 4+1 (тогда половина последнего чипа пустует).

Конечно, напрямую доступ к памяти контроллера будет иметь только процессор на контроллере, который в свою очередь будет иметь pci-e шину до системного процессора; т.е. напрямую доступ к этой памяти из системного процессора невозможен.

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

Добавлено спустя 11 минут 6 секунд:

Нет. Регистр, конечно, не имеет отношения к коррекции ошибок, только к снижению нагрузки на контроллер, но отказываться пока никто не собирается. Точнее, интел пытался несколько лет назад заменить регистр на последовательный интерфейс (FBDIMM), но вышло "не очень". Текущий DDR3 на серверах почти всегда регистровый - например, 16 Гб планок нерегистровых не бывает, а 8 Гб стоят очень дорого, а регистровые - пожалуйста, 8 Гб стоят дешевле, 16 Гб не такие дешевые, но легко доступны, и уже есть тестовые образцы 32 Гб модулей. Хотя серверы с небольшим количеством памяти можно набрать и на нерегистровой памяти, может выйти чуть дешевле.

Что касается скорости, то регистр, конечно, увеличивает латентность, но в силу других причин с регистровой памятью бывает быстрее - возможность большей емкости позволяет так же использовать другую огранизацию памяти, что при использовании большого числа емких модулей позволяет сохранять высокую частоту; на нерегистровой памяти максимально совместимая частота быстрее падает при использовании большого числа емких планок. Так как регистровой памяти по емкости можно поставить в 4 раза больше, чем нерегистровой, ни о каком отказе от регистра не может быть и речи Наращивать емкость нерегистровой памяти стоит очень дорого - и по цене, и в плане удара по производительности, а регистровая легко масштабируется на любые объемы, доступные в данный момент технологически.

Да, точно, как-то просматривал прайс на сервера, где был указан нереальный объем 192GB для ECC REG, а для просто ECC - "жалкие" 16GB.