[Перевод] Следует ли покупать память ECC?

Комментарии (9)

  • 11 мая 2017 в 20:32

    +3

    Intel, конечно, большая бяка, что не дает использовать ECC-память на десктопах (
    Даже с доплатой…
    • 11 мая 2017 в 21:24

      0

      Кажется дело сдвинулось с мертвой точки. http://ark.intel.com/products/97453/Intel-Pentium-Processor-G4600–3M-Cache-3_60-GHz
      Плюс еще пара моделей из нового поколения.
    • 11 мая 2017 в 21:39

      0

      Кстати, еще были i3–6xxx с поддержкой ecc.
    • 11 мая 2017 в 21:46

      +1

      А вот АМД райзен ЕЦЦ умеет и оно работает.
    • 11 мая 2017 в 22:53

      0

      Как это? Xeon на X99, например, — не десктоп? Или что имеется в виду?

      • 12 мая 2017 в 01:41

        0

        Скорее workstation

  • 11 мая 2017 в 21:05

    +2

    Это Google Translate так хорошо теперь переводит?
    Построение предложений совершенно нечеловеческое, как будто их в спешке набрали из разных кусков; в то же время, ошибок согласования и других признаков небрежного перевода практически нет.
  • 11 мая 2017 в 21:20

    0

    1. Одним из забавных примеров является (по крайней мере, для меня) магический самовосстанавливающийся плавкий предохранитель. Хотя реализаций много, представим себе плавкий предохранитель на чипе как некоторый резистор. Если вы пропускаете через него какой-то ток, то вы должны получить соединение. Если ток слишком большой, то резистор разогреется и, в конце концов, разрушится. Это обычно используется для отключения элементов на микросхемах или для таких действий, как задание тактовой частоты. Основной принцип состоит в том, что после сгорания предохранителя нет возможности вернуть его в исходное состояние.

    плавкий предохранитель → плавкая перемычка
  • 12 мая 2017 в 01:13 (комментарий был изменён)

    0

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

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

    И да, этот прокси тоже надо как то контролировать, но это другой вопрос и тут есть некоторая свобода в выборе реализации.

© Habrahabr.ru