Не понятно к чему эти гипотетические раауждения о решениях про которых нет полной информации.
Это не гипотетические, а вполне практические рассуждения. Вот прямо то чем я занимаюсь. Гипотетические, и уж точно без вообще какой-либо информации по существу -- у вас.
Вам SIISII несколько раз объяснил что контроль сбоев аппаратуры МФ имелся с самых первых моделей, уверен, что и на компьютерах до МФ это тоже уже имелось. Имелись также и средства востановления от сбоев.
Перефразируя: "talk is cheap. show me your schematics" :)
Если не возможно восстановить выполнение пользовательской или системной задачи, то они завершаются аварийно с последущей обработкой возможности восстановления на уровне прикладной программы или системной.
Уже лучше. Не "всё супер надёжно, никаких сбоев, если что другой процессор впряжётся и продолжит с того же места", а оказывается и упасть может.
Я же в свою очередь продолжаю настаивать, что тотальный контроль сбоев (даже одиночных) невозможнен без +- дублирования всей логики. А это площадь кристалла, потребление.
Кстати, о том как именно программно реализованы откаты (что и когда снапшотится и т.д.) тоже рассказа по существу не было. Вы как специалист по ibm mainframe'ам, уверен, можете об этом замечательно и очень интересно рассказать.
С другой стороны что такое "рандомная логика" сегодня. Это твердотельная микросхема.
В которой 100 миллиардов транзисторов например.
Потом делают карты с многими микросхемами
Вы сейчас точно не про ЕС-1033?
И лишь после этого отгружают.
А потом прилетает ТЗЧ, которой похрену на все тестирования, и флипает состояние одного триггера.
А вот возьму как пример что-то сложнее, чем буфер но проще чем кеш: FIFO. Вот у нас данные, но они защищены чётностью например и мы их не трогаем. Вот сигналы наружу -- входы стробов чтения и записи, выходы сигналов 'full' и 'empty'. Если один из них сломается -- то в FIFO либо запишется чушь, либо прочитается чушь, либо не запишется что надо, либо не прочтётся что надо, либо (и т.д.). Нам их надо защитить, например дублированием (лучше когда сигнал и его инверсная копия). Ещё из блока управления FIFO торчат адреса в блок памяти, адрес чтения и записи. Их тоже хорошо бы защитить, минимум дублированием. Теперь есть собственно управляющая логика: она смотрит на те 4 сигнала выше и генерит адреса для блока памяти. Если эта логика сломается, будет опять см. выше что. Получается, нам ВЕСЬ блок управления памятью при FIFO надо продублировать. Далее ещё можно разобрать, как сделать чтобы в память не писали куда попало (вдруг провода от блока управления до памяти сломаются или в самой памяти дешифратор ряда) и чтоб не читало откуда попало. Тут тоже без некоторого увеличения логики и/или объёма памяти не обойтись.
И так можно рассказать почти обо всём. Откуда и моё утверждение про увеличение количества логики.
Ваши "управляющие сигналы" точно так же будут идти отдельными проводами на "проверку чётности" и другими -- собственно куда надо. И эти другие провода тоже могут сломаться, как и логика за ними. Получается, проверка чётности как у вас не обеспечивает полного контроля.
Если честно, я не знаю лучшего метода для рандомной логики, чем дублирование со сверкой -- если мы стремимся к 100% покрытию на детект одиночного сбоя.
Смотря в каких парах трения. В подшипниках коленвала в ДВС -- да, но актуальным отвод тепла становится на оборотах, близких к максимальным. На ХХ ДВС может без поддона работать длительное время. В трении поршня по цилиндру -- нет, там даже и гидродинамического режима не случается, полусухое трение всегда.
То-то же в ДВС ставят маслосъёмные кольца. Специально лишнее масло убирают, чтоб быстрее сломалось!
По факту, удельные нагрузки в узле поршень-цилиндр достаточно малы для того, чтобы хватало масла, не утёкшего за час, а может быть и за день. Масло липнет к металлу, просто так из узких мест не вытекает. Так что старт-стоп раз в 5 минут на смазанность поршня и его колец, елозящих по цилиндру, влияет примерно никак.
Для обнаружения в передаваемых данных - действительно. Но вот сама управляющая логика по сути кроме как дублированием (или dual rail) никак не защищается.
При обнаружении сбоя происходит прерывание от схем контроля
Обнаружить сбой действительно можно именно так. Но вот у нас есть суперскалярный процессор, в нём могут одновременно выполняться сотни команд. Обнаружен сбой. Если нет информации, где именно -- то довольно нетривиально провернуть весь этот фарш назад для того, чтобы понять, например, сбой произошёл ДО того, как сделали снапшот памяти/процесса/его IO или после. Если сбой примерно совпал по времени с деланием этого снапшота, например.
Наверное можно например сбои управляющей логики разделять на сегменты -- типа вот тут логика коммита команд, а вон там логика шедулера, если сбойнуло там то мы можем ещё дождаться коммита всех операций, иначе засада и т.д. Но собственно тут и происходит радикальное усложение дизайна, когда поверх и так нетривиальной архитектуры суперскалярного ядра ещё натягивается система восстановления (частичного) после сбоя. Ну и в общем это то, что было бы интересно узнать из первых рук, а не только размахивания руками "у нас всё надёжно мамой клянусь, можно шокером в плату и всё продолжит работaть"
Уже лет 15 как в OO/LO конверчу его родные файлы в pdf. А полную совместимость с проприетарными вендорлочными форматами ("просто конвертнуть word файл") вам никто не обещал либо вы её не оплатили.
Я же сюда пришёл не мифотворчеством заниматься а выражать здоровый скептицизм. Тем более что апологетам ибм moneyфреймов, как оказывается, мне ответить нечего, кроме "не убедительно" :)
В чипе CPU есть цепи контроля и используются избыточные коды. Это электроника.
Вот про неё я и спрашиваю. Зачем вы потом ещё 10 абзацев про "конторы саппорта" пишете?
Чтоб просто иметь возможность определить одиночный (не многократный) сбой, все сигналы управления (те, что не шины данных) и логику управления необходимо каким-либо образом дублировать с постоянным сравнением. Если хочется ещё и игнорировать сбой -- троировать с мажорированием. Возможность определения одиночного сбоя не даёт гарантии что заодно и точно узнаем место и момент сбоя и сможем определить, на что он повлиял. Чтоб и это тоже было -- кол-во логики ещё увеличивается. И т.д.
В результате получаем что эти ваши moneyфреймы оказываются неэффективными по площади и по потреблению, т.к. кол-во логики на те же вычисления больше. Но видимо либо богатые конторы имеют возможность платить и х2 прайс за электричество, или на самом деле "жырность" мейнфреймов преувеличена и любой традиционный датацентр средней величины запросто обойдёт по потреблению и производительности любой мейнфрейм.
На самом деле если эмиттер слабо легировать - то он не будет эмиттером и транзистор не будет транзистором.
Вполне себе будет, но плохим. Убедиться в этом можно, померяв мультиметром бету у инверсно включенного транзистора -- вместо сотен для какого-нить bc547 будут десятки. Но будут. Ну и в некоторых биполярных процессах, заточенных на npn-транзисторы, именно так иногда и делают плохие, но всё же pnp-транзисторы.
По поводу статьи -- без хотя бы рукоразмахивательного и "на пальцах" введения в зонную теорию полупроводников всё равно не сильно лучше чем с мексиканцами получилось.
Последний раз когда я проверял btrfs, она просто конско тормозила с образами дисков для виртуалок. И у неё ещё до сих пор проблемы с raid5 или 6, вроде как. в ZFS со всем этим проблем нет. С другой стороны, btrfs нативная для линукса и с неё тот замечательно бутится. С ZFS забутиться удастся только с помощью извратов в initramfs. Администрирование btrfs тоже по ощущениям как-то более нативно что ли, чем вычурные и многословные конструкции zfs. Понятия 'датасетов' тоже в zfs слишком абстрактны, в btrfs imho это сделано лучше. Наконец, zfs умеет в нативное шифрование, а в btrfs несмотря на как-то раз обещанное шифрование, до сих пор ничего. В btrfs есть дефрагментация всего чего только можно, в zfs ничего.
Поэтому приходится держать обе две.
А вообще очень показательно, как sun и далее сообщество смогли в zfs, линуксовое сообщество смогло в btrfs, а целый большущий микрософт в свой похожий велосипед -- не смог.
И единственнное, что может (и должен!) сделать уважающий себя разработчик
То есть если разработчик этого не делает (потому что ему нечем), то он себя не уважает, а что контора это не внесла в планы и не закупила оборудование (пушо например денег нет таких), так то всё равно разработчик виноват?
В моей практике неработающий (периодически срывающийся) HDMI выход был 1 раз, для его отладки у кого-то брали попользоваться какое-то астрономически дорогое барахло, а проблема оказалась в том, что программисты нагуевертили с настройкой PLL. И то оборудование никак не помогло это выявить, хотя показывало всякие красивые там глазковые диаграммы и проч.
И выше уже сказали, что куча народу на полулюбительском уровне (без проверки на "соответствия стандартам") вполне себе клепают PCIe и HDMI и что там ещё. И как-то работает. Вот пусть "соответствием стандартам" с осциллографами на 100 гигагерц упражняются богатые конторы.
Ну а про кабель смешно, я лично повыкидывал несколько таких кабелей. Не вижу тут проблем.
А ну да, давайте 120 герц возьмём, а потом ещё стерео, и даже 10 бит на цвет можно взять ради страшной циферки. Если кто-то (полу-)кустарно делает в своем девайсе fullHD hdmi выход, то это будет во-1 какая-нибудь микросхема HDMI передатчика, в которую входят просто 24 сигнала с RGB на частоте 148.5 МГц, во-2 там не будет никаких 120 Гц и 3д, в-3 длины собственно проводников с 1.5 гигабитами/c будут, очевидно, максимально короткими: микросхема рядом с разъёмом.
Это конечно верно, если цель -- сделать HDMI fullHD видеовыход. Если цель иная, например напугать кого-то гигабитами, то да, 13 Гб/с, даже и не мечтайте осциллографом потыкать или на коленке сделать.
PCIe, да хоть не четвертой, а третьей ревизии
О, вам, как любителю, перестало хватать скоростей PCIe gen.1 со своими 2.5 гигабитами/с на лейн?
Те, кому этого хватило бы, могут купить дешёвую девборду c FPGA.
Гонево какое-то. Это примерно чуть менее чем 150 МГц пикселклок, с учётом 3 линий передачи и кодирования 8->10 получается менее полутора гигабит в секунду в каждом канале из трёх.
Вот кстати да, почему автор рассказывает нам про RSA, а не про более современные методы на эллиптических кривых. Ну и его предложение про "перебор приватного ключа" тоже повеселило -- видимо он совсем не в курсе ну хотя бы про основы RSA. А ещё, как уже выше заметили, повеселил рассказ про кейлоггеры и офигенно надёжный незашифрованный приватный ключ там же, где у него кейлоггеры крадут пароли. Он точно безопасник, а не ИБДшник?
Это не гипотетические, а вполне практические рассуждения. Вот прямо то чем я занимаюсь. Гипотетические, и уж точно без вообще какой-либо информации по существу -- у вас.
Перефразируя: "talk is cheap. show me your schematics" :)
Уже лучше. Не "всё супер надёжно, никаких сбоев, если что другой процессор впряжётся и продолжит с того же места", а оказывается и упасть может.
Я же в свою очередь продолжаю настаивать, что тотальный контроль сбоев (даже одиночных) невозможнен без +- дублирования всей логики. А это площадь кристалла, потребление.
Кстати, о том как именно программно реализованы откаты (что и когда снапшотится и т.д.) тоже рассказа по существу не было. Вы как специалист по ibm mainframe'ам, уверен, можете об этом замечательно и очень интересно рассказать.
В которой 100 миллиардов транзисторов например.
Вы сейчас точно не про ЕС-1033?
А потом прилетает ТЗЧ, которой похрену на все тестирования, и флипает состояние одного триггера.
А вот возьму как пример что-то сложнее, чем буфер но проще чем кеш: FIFO. Вот у нас данные, но они защищены чётностью например и мы их не трогаем. Вот сигналы наружу -- входы стробов чтения и записи, выходы сигналов 'full' и 'empty'. Если один из них сломается -- то в FIFO либо запишется чушь, либо прочитается чушь, либо не запишется что надо, либо не прочтётся что надо, либо (и т.д.). Нам их надо защитить, например дублированием (лучше когда сигнал и его инверсная копия). Ещё из блока управления FIFO торчат адреса в блок памяти, адрес чтения и записи. Их тоже хорошо бы защитить, минимум дублированием. Теперь есть собственно управляющая логика: она смотрит на те 4 сигнала выше и генерит адреса для блока памяти. Если эта логика сломается, будет опять см. выше что. Получается, нам ВЕСЬ блок управления памятью при FIFO надо продублировать. Далее ещё можно разобрать, как сделать чтобы в память не писали куда попало (вдруг провода от блока управления до памяти сломаются или в самой памяти дешифратор ряда) и чтоб не читало откуда попало. Тут тоже без некоторого увеличения логики и/или объёма памяти не обойтись.
И так можно рассказать почти обо всём. Откуда и моё утверждение про увеличение количества логики.
Ваши "управляющие сигналы" точно так же будут идти отдельными проводами на "проверку чётности" и другими -- собственно куда надо. И эти другие провода тоже могут сломаться, как и логика за ними. Получается, проверка чётности как у вас не обеспечивает полного контроля.
Если честно, я не знаю лучшего метода для рандомной логики, чем дублирование со сверкой -- если мы стремимся к 100% покрытию на детект одиночного сбоя.
Смотря в каких парах трения. В подшипниках коленвала в ДВС -- да, но актуальным отвод тепла становится на оборотах, близких к максимальным. На ХХ ДВС может без поддона работать длительное время. В трении поршня по цилиндру -- нет, там даже и гидродинамического режима не случается, полусухое трение всегда.
То-то же в ДВС ставят маслосъёмные кольца. Специально лишнее масло убирают, чтоб быстрее сломалось!
По факту, удельные нагрузки в узле поршень-цилиндр достаточно малы для того, чтобы хватало масла, не утёкшего за час, а может быть и за день. Масло липнет к металлу, просто так из узких мест не вытекает. Так что старт-стоп раз в 5 минут на смазанность поршня и его колец, елозящих по цилиндру, влияет примерно никак.
Для обнаружения в передаваемых данных - действительно. Но вот сама управляющая логика по сути кроме как дублированием (или dual rail) никак не защищается.
Обнаружить сбой действительно можно именно так. Но вот у нас есть суперскалярный процессор, в нём могут одновременно выполняться сотни команд. Обнаружен сбой. Если нет информации, где именно -- то довольно нетривиально провернуть весь этот фарш назад для того, чтобы понять, например, сбой произошёл ДО того, как сделали снапшот памяти/процесса/его IO или после. Если сбой примерно совпал по времени с деланием этого снапшота, например.
Наверное можно например сбои управляющей логики разделять на сегменты -- типа вот тут логика коммита команд, а вон там логика шедулера, если сбойнуло там то мы можем ещё дождаться коммита всех операций, иначе засада и т.д. Но собственно тут и происходит радикальное усложение дизайна, когда поверх и так нетривиальной архитектуры суперскалярного ядра ещё натягивается система восстановления (частичного) после сбоя. Ну и в общем это то, что было бы интересно узнать из первых рук, а не только размахивания руками "у нас всё надёжно мамой клянусь, можно шокером в плату и всё продолжит работaть"
Естественно. Миф сам себя не поддержит, надо несогласных шпынять.
Уже лет 15 как в OO/LO конверчу его родные файлы в pdf. А полную совместимость с проприетарными вендорлочными форматами ("просто конвертнуть word файл") вам никто не обещал либо вы её не оплатили.
Я же сюда пришёл не мифотворчеством заниматься а выражать здоровый скептицизм. Тем более что апологетам ибм moneyфреймов, как оказывается, мне ответить нечего, кроме "не убедительно" :)
Вот про неё я и спрашиваю. Зачем вы потом ещё 10 абзацев про "конторы саппорта" пишете?
Чтоб просто иметь возможность определить одиночный (не многократный) сбой, все сигналы управления (те, что не шины данных) и логику управления необходимо каким-либо образом дублировать с постоянным сравнением. Если хочется ещё и игнорировать сбой -- троировать с мажорированием. Возможность определения одиночного сбоя не даёт гарантии что заодно и точно узнаем место и момент сбоя и сможем определить, на что он повлиял. Чтоб и это тоже было -- кол-во логики ещё увеличивается. И т.д.
В результате получаем что эти ваши moneyфреймы оказываются неэффективными по площади и по потреблению, т.к. кол-во логики на те же вычисления больше. Но видимо либо богатые конторы имеют возможность платить и х2 прайс за электричество, или на самом деле "жырность" мейнфреймов преувеличена и любой традиционный датацентр средней величины запросто обойдёт по потреблению и производительности любой мейнфрейм.
С какого перепоя дважды-то? В slog идут только синхронные записи.
Кто-то уже проверил?
Как определить что CPU отказал/сбойнул?
Если определили, как понять, с какого момента?
Что, и даже шокером в плату не убить?
А вот тут воспринимают, странно https://www.allaboutcircuits.com/textbook/designing-analog-chips/analog-devices/the-case-of-the-lateral-pnp-transistor/
Я даже и не хочу эту модель разбирать. Я сказал что сказал, причём тут "я не замечаю в мексиканской модели" -- не очень понял.
Вполне себе будет, но плохим. Убедиться в этом можно, померяв мультиметром бету у инверсно включенного транзистора -- вместо сотен для какого-нить bc547 будут десятки. Но будут. Ну и в некоторых биполярных процессах, заточенных на npn-транзисторы, именно так иногда и делают плохие, но всё же pnp-транзисторы.
По поводу статьи -- без хотя бы рукоразмахивательного и "на пальцах" введения в зонную теорию полупроводников всё равно не сильно лучше чем с мексиканцами получилось.
Последний раз когда я проверял btrfs, она просто конско тормозила с образами дисков для виртуалок. И у неё ещё до сих пор проблемы с raid5 или 6, вроде как. в ZFS со всем этим проблем нет. С другой стороны, btrfs нативная для линукса и с неё тот замечательно бутится. С ZFS забутиться удастся только с помощью извратов в initramfs. Администрирование btrfs тоже по ощущениям как-то более нативно что ли, чем вычурные и многословные конструкции zfs. Понятия 'датасетов' тоже в zfs слишком абстрактны, в btrfs imho это сделано лучше. Наконец, zfs умеет в нативное шифрование, а в btrfs несмотря на как-то раз обещанное шифрование, до сих пор ничего. В btrfs есть дефрагментация всего чего только можно, в zfs ничего.
Поэтому приходится держать обе две.
А вообще очень показательно, как sun и далее сообщество смогли в zfs, линуксовое сообщество смогло в btrfs, а целый большущий микрософт в свой похожий велосипед -- не смог.
То есть если разработчик этого не делает (потому что ему нечем), то он себя не уважает, а что контора это не внесла в планы и не закупила оборудование (пушо например денег нет таких), так то всё равно разработчик виноват?
В моей практике неработающий (периодически срывающийся) HDMI выход был 1 раз, для его отладки у кого-то брали попользоваться какое-то астрономически дорогое барахло, а проблема оказалась в том, что программисты нагуевертили с настройкой PLL. И то оборудование никак не помогло это выявить, хотя показывало всякие красивые там глазковые диаграммы и проч.
И выше уже сказали, что куча народу на полулюбительском уровне (без проверки на "соответствия стандартам") вполне себе клепают PCIe и HDMI и что там ещё. И как-то работает. Вот пусть "соответствием стандартам" с осциллографами на 100 гигагерц упражняются богатые конторы.
Ну а про кабель смешно, я лично повыкидывал несколько таких кабелей. Не вижу тут проблем.
А ну да, давайте 120 герц возьмём, а потом ещё стерео, и даже 10 бит на цвет можно взять ради страшной циферки. Если кто-то (полу-)кустарно делает в своем девайсе fullHD hdmi выход, то это будет во-1 какая-нибудь микросхема HDMI передатчика, в которую входят просто 24 сигнала с RGB на частоте 148.5 МГц, во-2 там не будет никаких 120 Гц и 3д, в-3 длины собственно проводников с 1.5 гигабитами/c будут, очевидно, максимально короткими: микросхема рядом с разъёмом.
Это конечно верно, если цель -- сделать HDMI fullHD видеовыход. Если цель иная, например напугать кого-то гигабитами, то да, 13 Гб/с, даже и не мечтайте осциллографом потыкать или на коленке сделать.
О, вам, как любителю, перестало хватать скоростей PCIe gen.1 со своими 2.5 гигабитами/с на лейн?
Те, кому этого хватило бы, могут купить дешёвую девборду c FPGA.
Гонево какое-то. Это примерно чуть менее чем 150 МГц пикселклок, с учётом 3 линий передачи и кодирования 8->10 получается менее полутора гигабит в секунду в каждом канале из трёх.
Вот кстати да, почему автор рассказывает нам про RSA, а не про более современные методы на эллиптических кривых. Ну и его предложение про "перебор приватного ключа" тоже повеселило -- видимо он совсем не в курсе ну хотя бы про основы RSA. А ещё, как уже выше заметили, повеселил рассказ про кейлоггеры и офигенно надёжный незашифрованный приватный ключ там же, где у него кейлоггеры крадут пароли. Он точно безопасник, а не ИБДшник?