Комментарии 25
1) Приводить к тому, что какие-то биты в памяти изменятся. В кэше, в оперативной памяти или в регистрах процессора.
2) Из-за тиристорного эффекта будет инициирована экстренная перезагрузка процессора.
«Устойчивый к спецфакторам софт» — такой софт, который позволяет преодолеть последствия подобных событий. Например, я встречал статьи про компилятор, который повторяет некоторые команды и сравнивает результат их выполнения друг с другом, инициируя прерывания, если результаты не сошлись. Идея набросить какой-то софт на коммерческие чипы вместо использования дорогих и медленных специальных радстойких процессоров не нова)
преодолеть последствия подобных событий.
Преодолеть — это значит что? Чтобы программа спокойно выполнялась дальше, как ни в чем не бывало?
Преодолеть — это значит что?Как определите термин, так и будет. Главное, чтобы после стало лучше, чем было до.
Ошибка детектируется либо этим компьютером, либо системой голосования и данный компьютер «маркируется» как поломанный и его результаты больше не принимаются во внимание.
Система продолжает работать на оставшихся двух без остановок или пропуска циклов. В это время поломанный компьютер перезагружается и синхронизируется с двумя другими. Он также может делать и более быстрое восстановление — например прогнать быстрый BIST тест, определить и изолировать проблемы, а затем опять засинхронизироваться. Если после этого его результаты начинают совпадать с исправными компьютерами, он опять «маркируется» здоровым.
Система не может просто так продолжать работать на оставшихся двух т.к. случись снова ошибка, голосовать будет некому. Надо как можно скорее восстановить кворум. Если отпустить те два компа в работу, возможно, догнать будет непросто и не быстро, всё это время система будет нестабильна.
Засинхронизоваться — как вы себе это представляете?
Пока один продолжает работать, другой из под него страницы выдёргивает?
Кто должен определять какие результаты должны совпасть?
Засинхронизоваться — как вы себе это представляете?
Пока один продолжает работать, другой из под него страницы выдёргивает?
Кто должен определять какие результаты должны совпасть?
Ну, если знать, как это все устроено в резервируемых системах, то все вопросы отпадут сами собой.
Кто должен определять какие результаты должны совпасть?
Определяете некоторый набор данных и его гоняете между комплектами. Сбойный комплект упал, поднялся, засинхронизировался — все.
Понятно, что вы тут заодно дискутируете на тему «а как синхронизироваться, если надо быстрее», «а если надо еще быстрее» и «а если надо совсем быстро», но тут говорить просто не о чем — надо смотреть конкретные характеристики быстроты синхронизации и частоты сбоев.
ое определение — чтобы программа выполнялась дальше в реальном времениМне кажется, что это очень сильное требование. То есть да, в идеале так и должно быть, но стать иммунными к вообще всем событиям невозможно, зато можно разумно минимизировать частоту вызванных ими сбоев. Начать можно с чего-то более простого и разумного. А главное — измеримого.
Например, с того, чтобы после аварийного ребута программа выполнялась заново не с начала, а с какой-то промежуточной контрольной точки. Или чтобы софт умел заниматься синхронизацией перезагруженного процессора с двумя оставшимися нормальными. Или чтобы программа компилировалась таким образом, чтобы снизить вероятность нештатной реакции на сбои.
У меня глупый вопрос. А зачем делать компьютер устойчивым? Может, лучше, сделать его маленьким и напихать сотню маленьких компьютеров в кластер? Вот у меня тут в хозяйстве есть кластер, в котором я могу выключить пять любых компьютеров (из 11) — и оставшиеся продолжат работать. Более того, если очень докопаться, то оставшиеся 6 могут попытаться починить первые 5 посредством внешней перезагрузки и проверки (условный cputest/memtest). Как только узел войдёт обратно в кластер, он сможет заменить любой из умерших компьютеров из этих 6.
Т.е. вопрос: а стоит ли синхронизировать всё на уровне инструкций? Может, кворум на прикладном уровне посредством общей шины более масштабируемое решение?
А зачем делать компьютер устойчивым? Может, лучше, сделать его маленьким и напихать сотню маленьких компьютеров в кластер?Стоимость вывода единицы массы на орбиту, особенно на высокую, очень велика.
Но критическая задача для космического компьютера чаще всего лежит в области системы управления и принятия критических решений. Т.е. вот у вас решают 11 компьютеров задачу управления двигателем космического аппарата, причем решают одновременно. И в определенный момент 7 из них говорят — надо включить двигатель, а 4 говорят — нет, нифига. И это совершенно не то же самое, что выключить 4 любых компьютера. Нет, эти компьютеры прекрасно работают, но выдают неправильный результат.
Вот и настает вопрос — как это диагностировать и обработать до того, как ваш аппарат разобьется о поверхность Луны, как несчастный Берешит? А еще лучше диагностировать и исправить это в следующую миллисекунду, так как даже это время во многих процессах является критичным.
Ведь если бы у нас в запасе был вагон и маленькая тележка времени, тот же Берешит и восстановился и перезагрузился бы спокойно, как ни в чем не бывало.
Realtime — это не про скорость, а про ответ за заданное время. Условная милисекунда — это миллион тиков для гигагерцового процессора. Компьютеры могут честно пытаться прийти к консенсусу (тот же paxos). Победит большинство. Не на уровне "результат сложения 2+2", т.е. инструкции процессора, а на уровне результата (т.е. сигнала в шину).
Время перезагрузки комьютера не существенно (в разумных пределах) — важно время прихода к консенсусу.
Поискал: Fast Paxos allows 2 message delays, but requires that (1) the system be comprised by 3f+ 1 acceptors to tolerate up to f faults.
В условиях дециметровых дистанций время прохождения сообщения может быть близким к десяткам наносекунд (пусть сотне), т.е. за милисекунду можно пропустить порядка десятка тысяч раундов.
Да. Проблема устойчивости брокера — открытая.
Хотя, с высоты диванного полёта мне кажется, что брокера можно реализовать как "голосование электричеством" — если достаточное количество проводов подали сигнал, то устройство срабатывает. Если не достаточно — не срабатывает. От пролетающих космических факапов защищает то, что никакая частица не может вызвать достаточно длительный по времени ток.
Т.е. каждая data line даёт, например, 0.5мА тока, а для срабатывания зажигания у двигателя надо 2мА в течение 1мс. Соответственно, пока 4 участника не выдадут этот ток, зажигания не произойдёт (вне зависимости от пролетающих частиц).
Хотя, с высоты диванного полёта мне кажется, что брокера можно реализовать как «голосование электричеством» — если достаточное количество проводов подали сигнал, то устройство срабатывает
Это один из вариантов для некоторых случаев (называется еще «накачкой команды», хотя этот термин больше употребляется в телемеханике), однако системно он проблему не решает.
Ну и потом — ну вот идут три процессора в ногу, а один нет. Положим «токового сигнала» от трех достаточно, ок полетели куда надо. И эти три как-то должны понять, что четвертый охренел, да и сбросить его (иначе на следующем шаге будет уже два несогласных). А он берет — и блокирует сброс, либо у него с обработчиком NMI что-то не то случилось, либо он сам остальных сбрасывать начинает… Тут конечно помогает мажорированный сброс, но в целом это тоже все такое.
с высоты диванного полёта мне кажется, что брокера можно реализовать как «голосование электричеством»Схемы голосования так и организованы обычно. Если двое тянут выход в одну сторону, а третий в другую — победят
никакая частица не может вызвать достаточно длительный по времени токЭто касается только цифровых схем. В аналоговых запросто могут быть очень длинные импульсы от ТЗЧ, и это может быть важно как раз для актюаторов, а также для сенсоров, на основе показаний которых процессор принимает решения.
А вы начинаете рассказывать какие-то сказки про то, что можно что-то сохранить на флеш и потом прочесть, когбуд-то там не может быть ошибок, да ещё и совпадением контрольной суммы, а падать будет программа при исполнении, и опять читать ту же дичь.
Нерушимая память, нерушимые процессы