Comments 32
TLDR: производителям просто очень хочется денег.
Согласен. Пояснения в большинстве своём "натянутая сова на глобус" с маркетинговыми увиливаниями. Как будто под видом реальной конторы это писал маркетолог из нвидиа.
Точка для сравнения в виде последнего поколения тоже подобрана наиболее удачно для выводов. Попробуйте объяснить такую же дикую разницу в цене между про и обычными картами 3-4 поколения назад, когда память была одинаковой + были ещё и "младшие модели", медленнее топов, но дороже. Тогда никаких ЛЛМ не было и отсутствие ЕСС таких "ужасных" ошибок не давало (граф. дизайнеры, например, зачем покупали втридорога?). Вот тогда половина приведённых в статье "аргументов" сразу же испаряется. Да и +5% производительности из-за последнего отключенного блока на чипе - это тоже "мимо кассы". Можно было даже и не вспоминать про это (явно добавили для "полноты аргументов").
Далее: надежность. Компонентная база у про и не про карт вся та же. Я вас умоляю, никаких "в разы дольше служит" там нет при сопоставимых настройках с у аналогичной карты с массмаркета.
Остаются драйвера, на 90+% одинаковые и просто "искуственная сегментация рынка" через другой форм-фактор, какие-то там лицензии/разрешения и прочая "лапша на уши", потому что "хочу и могу" (много денег).
у меня вопрос по ECC... вот все пишут что ошибки исправляются прямо на лету.. небось и лог возникновения таких ошибок существует.. и поглядеть в него можно. так вот вопрос такой: ну а вообще с какой переодичностью возникают такие ошибки которые есс восстанавливает? ну хотя бы порядок.. ну раз в 8 часов? или там раз в месяц? или может быть "за все время эксплуатации мы ни разу не видили такую ошибку но если бы она возникла мы бы точно были к ней готовы"
Есть nvidia-smi, а в ней куча всего веселого, например "nvidia-smi -q -d ROW_REMAPPER", так можно посмотреть что там по памяти, есть ли ремапнутые в связи ошибками строки. Вот так "nvidia-smi -q -d ECC" посмотреть статистику ECC. А так "nvidia-smi -q -d PAGE_RETIREMENT" посмотреть что там с отключенными страницами памяти.
Ну и с установкой hwinfo на проф сериях карт завезли показ ошибок PCIE линии.
вот я и прошу назвать цифру людей у которых есть карты с есс.. ну хоть примерные значения. не теоретические умозаключения а практику
Было крупное исследование ECC ОЗУ -- 8% модулей памяти исправляли ошибки, среднее количество ошибок в год на такой модуль -- многие тысячи. Скрытый брак, начало проявления особо не предсказать.
эээээ... спасибо за цифру... но....
>среднее количество ошибок в год на такой модуль -- многие тысячи.
разве при таком количестве ошибок будут какие то сомнения что модуль мертвый? ну у тебя же буквально НИХЕРА работать не будет с ним. что бы ты не запустил - все будет падать...
я легко могу поверить что 8% есс модулей за свою жизнь исправляли хотя бы одну ошибку. но что бы тысячи в год.... это явный брак. давайте его не будем обсуждать.. я про живые вещи...
Что у вас не будет работать? Одна ошибка в памяти - это переворот одного бита. Для видеокарты, используемой по прямому назначению, это, фактически, значит, что раз в несколько минут/часов на одном случайном кадре один случайный пиксель у вас поменяет цвет. Сможете вы обнаружить без специального оборудования, что у вас «модуль мёртвый»?
Однобитовые ошибки вызываются, в основном, космическим излучением, а никак не заводским браком. Частица с достаточной энергией может перевернуть случайный бит в памяти. Вы можете сами за копейки собрать или купить детектор и оценить частоту их прилёта. Вот, даже на Хабре есть полезная статья: https://habr.com/ru/companies/ruvds/articles/557522/
>Что у вас не будет работать? Одна ошибка в памяти - это переворот одного бита. Для видеокарты, используемой по прямому назначению
а при чем тут видюха то?
>Было крупное исследование ECC ОЗУ -- 8% модулей памяти исправляли ошибки,
ниче что мы в ЭТОМ треде обсуждаем ОПЕРАТИВУ? и мой комент о падениях есесно про оперативу
>Сможете вы обнаружить без специального оборудования, что у вас «модуль мёртвый»?
конечно. никакого специального оборудования.. 8 процентов ошибок в оперативе - у тебя все проги будут падать при попытке работать с этой планкой - это ТОЧНО мертвый модуль оперативы.
8 процентов ошибок в оперативе - это ТОЧНО мертвый модуль оперативы
Вы совершенно точно неправильно прочитали то, что вам написали. 8 процентов модулей исправляли ошибки (возможно, всего одну ошибку в модуле за время подсчёта). 8 процентов ошибок - это сотни миллионов ошибок в секунду на один модуль.
ниче что мы в ЭТОМ треде обсуждаем ОПЕРАТИВУ? и мой комент о падениях есесно про оперативу
Один перевёрнутый бит в оперативной памяти в большинстве случаев вы точно так же не заметите: с вероятностью 95 процентов он придётся на никак не используемый мусор, который создаёт Chromium в ОЗУ. На сервере ОЗУ обычно не заполнена мусором, поэтому там однобитовые ошибки могут действительно портить жизнь, и их надо исправлять.
а давай ты все же прочитаешь внимательно что мы обсуждаем... хорошо. я сделаю это за тебя.
>Вы совершенно точно неправильно прочитали то, что вам написали. 8 процентов модулей исправляли ошибки
именно это я и написал:
>я легко могу поверить что 8% есс модулей за свою жизнь исправляли хотя бы одну ошибку. но что бы тысячи в год.... это явный брак. давайте его не будем обсуждать.. я про живые вещи...
>Один перевёрнутый бит в оперативной памяти в большинстве случаев вы точно так же не заметите:
да с чего вы блин берете что речь про ОДИН бит????? если в этом треде обсуждение идет про видимо бракованный модуль с ТЫСЯЧАМИ ошибок (тысячи это есесно сильно приуменьшено - если мы говорим про 8%) - и мы ТОЧНО увидим что все что пытается работать на этом видимо бракованном модуле падает.
да с чего вы блин берете что речь про ОДИН бит?????
С того, что ECC исправляет однобитовые ошибки, которые вообще никак не связаны с заводским браком. Это не волшебная палочка, которая превращает бракованный модуль в рабочий.
бракованный модуль с ТЫСЯЧАМИ ошибок
Тысяча ошибок в год - это один случайный перевёрнутый бит за 8 часов. На десктопе вы его почти никогда не заметите, по уже написанной мной выше причине. Однобитовые ошибки - одноразовые, они не возникают в одних и тех же ячейках памяти постоянно, они не возникают согласованными группами. Это единичные совершенно случайные события. Более того, аппаратные генераторы случайных чисел примерно на этом и построены.
>Вы можете сами за копейки собрать или купить детектор и оценить частоту их прилёта.
и что мне даст знание о частоте прилета? ну прилетело допустим 1к частиц в час.. и ЧТО? это же не значит что будет 1к флипов бита. может для одного флипа надо 1триллион прилетов.. или у тебя есть данные как перевести частоту прилета в частоту флипа? есть? делись. ;)
У меня для вас готового числового ответа нет. Однако спектр (распределение по энергиям) космических частиц вы можете найти в открытых источниках. Энергию, необходимую для переворота бита, тоже. Вы же на Хабре сидите, предполагается, что вы обладаете базовыми навыками поиска и обработки информации. А сейчас за вас это всё может сделать Gemini/ChatGPT/DeepSeek и так далее. Более того, они вам помогут даже найти готовые статьи с готовыми расчётами и ответами.
И тем не менее, ECC память позволяет вовремя обнаружить этот брак и не испортить данные. Модулей памяти в сервере немало -- шанс совсем не иллюзорный.
Раз уж тут такие спецы по памяти собрались. Не знаете ? Почему до сих пор не придумали что то типа BAD блоков на памяти. Заремапленных. По типу винчестеров и ссд. А то не правильно это и не экологично выбрасывать рабочий модуль памяти из за одной битой ячейки или микросхемы. Может на Линуксе есть ремап тест памяти?
карта может быть изначально с битой памятью и в случае ecc есть возможность это сразу заметить и повод сдать карту продавцу/по гарантии, а в случае обычной будет сюрприз.
вот карта, приехавшая из магазина "(PCI:0000:ce:00): 48, An uncorrectable double bit error (DBE) has been detected on GPU in the framebuffer at physAddr 0x2c72d480 partition 17, subpartition 1"
ну все же давайте не будем рассматривать пограничные случаи с заводским браком..
предположим карта полностью исправна с завода. работает в нормальном ДЦ (питание и охлад как нуна) - как часто бывают ошибки в ЕСС? (ну если у вас конечно есть такая инфа)
у меня слишком маленькая выборка, чтобы говорить о какой-то статистике по gpu. Штучные ошибки есть. Наверное в категориях "много-мало" можно сказать, что "мало". По серверной оперативке информации больше, но в статистику не сводил. ECC ошибки имеют место бывать, наверное что-то типа от десятых долей до единиц процентов хостов в год в мониторинге отмечаются со сработавшим edac. Иногда случайные ошибки - появилась и не повторяется, иногда ячейки бьются и начинает постоянно спотыкаться на одном и том же месте.
Сейчас погуглил, оказывается есть достаточно статей на эту тему. А можно просто как аналогию: один может десять лет проездить и не разу запаску не поставить, только место в машине занимала, а второй может раз в месяц её использовать. Вот вы как предпочитаете, ездить с запаской или без?
э нет. если эти машины ездят по ОДИНАКОВОМУ пути то и проколы у них будут почти одинаковые. мы же все же говорим про ДЦ где все в порядке со стабильностью питания и охлаждения. если все говорят что за 10 лет езды по этой дороге тут не было проколов.. и шиномонтажек тоже тут нет (почему то быстро закрываются (может потому что клиентов нету)).. то я не буду возить запаску. тем более если эта запаска стоит как 10 раз вызвать эвакуаторщика. ;))
Согласен, что всё зависит от того где применяется. Про те же ДЦ пишут, что сбои могут зависеть даже от высоты над уровнем моря.
Да и задачи у всех разные. Например на моей Tesla P40 отключена проверка ошибок, так как она съедает память и притормаживает карточку. Но мне и не критично, если модель где-нибудь ошибётся. А в том же ДЦ, если будет ошибка, то наверно у неё будут более ощутимы последствия.
Так что по городу можно гонять и без запаски. А вот куда-нибудь в горы ехать без неё, уже рисковано.
Я буквально неделю назад делал расчеты на 2000 GPU-часов на обычных видеокартах с проверками корректности (не совсем double check, когда каждая подзадача считается 2 раза, но близко к нему). Из ~2000 подзадач один раз словил расхождение. Условно говоря - если время расчета идет на месяцы, проверка на сбои вроде флипнутого рандомного бита обязательна. В идеале double check. К расчетам на обычных CPU это тоже относится.
Хороший, кстати, вопрос. Разверну по-другому: во многих отраслях прайс enterprise = прайс consumer Х4 (за +/- то же самое) - вполне себе норма, но если у consumer что-то не так пошло, то он ССЗБ, а enterpise’у производитель за базар ответить готов. Деньгами, оттого и X4. И вот отсюда возникает смутное ощущение, что тут вместо гарантий за X4 прайса тебе в уголок бесплатно огнетушитель ставят. Пердак, простите, тушить, после подрыва пакгауза.
Про повреждение данных и нужность ECC на хабре была статья: https://habr.com/ru/companies/first/articles/667208/
А можно подробнее про лицензионное соглашение в драйверах? Драйвер умеет определять что он в датацентре запущен и блокирует карту? Или еще что-то блокирует?
Технического запрета, который бы блокировал работу видеокарты, нет. RTX 5090 будет прекрасно считать тензоры и в домашнем ПК, и в серверном шасси.
Тут два момента:
1) Ограничение носит лицензионный (юридический) характер. Если вы частное лицо с тремя картами в стойке, то NVIDIA о вас вряд ли узнает. Если вы крупный enterprise, то вы подставляете компанию под судебный иск за нарушение EULA.
2) Профессиональные драйверы (например, для серии RTX Enterprise или A-серии), которых нет на игровых GPU, дают поддержку vGPU (Virtual GPU), возможность разделить одну физическую карту на несколько виртуальных машин с QoS (гарантированное качество обслуживания). В GeForce это реализовано более примитивно.
Они также заточены под стабильность при нагрузке 24/7 и работу с огромными массивами данных, и сами GPU имеют расширенную поддержку NVIDIA.
Т.е. это просто юридический риск и отсутствие доступа к «корпоративному уровню».
Что точно известно, это то, что если собирать на карте Nvidia сервер виртуализации с пробросом ресурсов GPU, то потребуется лицензия. На видеокарта будет работать в холостую
Спасибо за нейрослоп.
Про дрова - глупость. Ставится все прекрасно и без хаков + есть oss дрова. Специальные дрова нужны только если хочется VGPU.
Однако блокеры и правда есть.
Самый слабый: конденсаторы и все с этим связанное. В первую очередь выходят из строя от времени именно они. В теслах стоит обычно тантал, а не электролит.
Сильные:
Питание. Заход питания в Теслу сзади карты, в geforce сверху. Geforce в 3 юнитовый сервер просто не поместить - будет мешать питание. Только 4u сервер. В 2u с райзером соответственно тоже.
Питание опять. Geforce питаются через pcie, tesla через cpu разъем. Конструктивно похожи, распиновка разная (нет не засунуть даже с такой то матерью) - нужно покупать на озоне переходники по 300р. В серверных БП обычно pcie шнуры отсутствуют.
Самое главное - охлаждение. Geforce сконструирован с радиаторами "сверху вниз" и боковым потоком воздуха на вентилятор. Тесла : вообще без вентиляторов, а радиаторы - спереди назад. Сервера охлаждаются "продувом" - воздух подаётся на переднюю панель сервера и выгоняется назад. Без замены радиатора geforce просто не сможет нормально охлаждаться в северном корпусе. Отсюда вывод что и тесла в десктопе будет так себе охлаждаться.
Зачем тебе видеокарта без монитора? GeForce бывает не запускаются если к ней не подключен монитор. Решается обманкой за 500р с озона.
Софтово-драйверные мелочи: VGPU как уже писал только на тесле. Насколько потоков nvenc/nvdec только на тесле - домашнему пользователю нет нужды кодировать одновременно 100 видеопотоков (мнение нвидии). RDMA/GPUDirect тоже скорее всего требует только теслу (ну и сетевуху mellanox)
Почему профессиональная GPU стоит впятеро дороже игровой с той же начинкой