Comments 39
Вы пробовали выключить и снова включить?
Смотреть с 0:45
С Boeing 787 Dreamliner те 248 с небольшим дней — это (внезапно) близко к 2^31 сотым долям секунды. Signed vs. unsigned? Хотя даже если сделали бы его unsigned, пришлось бы через 496 дней перезагружать, что не решает проблему в корне.
А 149 часов это 2^29 милисекунд, куда-то ещё 3 бита ушли.
Наверно в математику, яб в высоко-ответственной системе делал перезагрузку ПЕРЕД каждым полетом — подготовка к полету начинается с перезагрузки всего и самотестирования.
Это не спасёт от буфера, переполняющегося за 6 часов полёта. Тут скорее нужно именно в архитектуре софта и железа закладывать необходимость максимально сокращать длительность любого рабочего цикла и принудительно сбрасываться в нули. Проектировать так, чтобы периодический запланированный «горячий» сброс был естественной рабочей процедурой, а не чем-то экстраординарным, что нужно делать только в исключительных ситуациях, которые по идее никогда не должны происходить.
Но и у этого подхода есть минус — он маскирует ошибки. Допустим, что в софте/железе есть баг, который через 6 часов приведёт к переполнению, но модуль архитектурно устроен так, что сбрасывается каждые 500мс и всё работает как надо. Т.е. баг в коде есть, но сброс спасает. А если считать, что баги так или иначе нужно искать не полагаясь ни на какую страховку, то эта логика горячего сброса должна сыграть всё же положительную роль.
Но и у этого подхода есть минус — он маскирует ошибки. Допустим, что в софте/железе есть баг, который через 6 часов приведёт к переполнению, но модуль архитектурно устроен так, что сбрасывается каждые 500мс и всё работает как надо. Т.е. баг в коде есть, но сброс спасает. А если считать, что баги так или иначе нужно искать не полагаясь ни на какую страховку, то эта логика горячего сброса должна сыграть всё же положительную роль.
Спасет от большинства проблем возникающих через 149 — 1193 часов после загрузки.
Но само собой не освобождает от нормальной проектировки оборудования.
Если есть циклы и абсолютно безопасные периоды для перезагрузки то почему этим не воспользоваться.
В авиации, даже в пассажирской, почему-то не приняты меры резервирования как в нормальной космической технике.
Но само собой не освобождает от нормальной проектировки оборудования.
Если есть циклы и абсолютно безопасные периоды для перезагрузки то почему этим не воспользоваться.
В авиации, даже в пассажирской, почему-то не приняты меры резервирования как в нормальной космической технике.
А пользы от резервирования, если одновременно перезагрузятся все три резервированных компьютера? :)
UFO just landed and posted this here
Ага, особенно заметно по www.svoboda.org/a/29863429.html есть 2 датчика и 2 компьютера но они работают ПО ОЧЕРЕДИ! один полет левый, следующий правый…
И раз попеременность работы компьютеров, очевидно, не помогает — переполнение счётчиков, возможно, происходит не в них, а в промежуточных контроллерах.
Много глупее — на основании данных 1го датчика 1 компьютер(второй датчик и компьютер исправно работали, грели воздух) поборол пилота и разбил самолет, и так 2 раза, погибло 346 человек.
habr.com/ru/post/449564
habr.com/ru/post/449564
Может, fixed-point number с шагом 1/8 секунды.
А может, в битовом пакете выделили 29 бит, чтобы хватило на какое-нибудь взятое с потолка требование. В таких системах всё часто очень консервативно и низкоуровнево.
А может, в битовом пакете выделили 29 бит, чтобы хватило на какое-нибудь взятое с потолка требование. В таких системах всё часто очень консервативно и низкоуровнево.
вообще тик в милисекунду, имхо, — это очень много для самолета. Должно быть ближе к микросекундам. Хотя кто из знает…
Конвертация. Реальный счетчик может считать быстрее, а нам надо в милисекундах, функция GetMs() внутри делает конвертацию. Самое поганое, что даже если есть проверка на переполнение — она не сработает. Потому что при конвертации переполнение происходит раньше, до реального переполнения типа данных.
Например при таймере типа uint32 и интервале 1 us и счетчик в ms будет обунляться каждые 4294967 ms, когда вы будете ожидать переполнение на 4294967295.
Например при таймере типа uint32 и интервале 1 us и счетчик в ms будет обунляться каждые 4294967 ms, когда вы будете ожидать переполнение на 4294967295.
В ARINC 429 3 служебных бита в каждом слове
Назначение служебных битов
Бит 32 является паритетным битом, и используется для проверки того, что слово не было повреждено или искажено во время передачи. Бит чётности.
Биты 30 — 31 являются «Матрицей Признака» или статуса, или SSM (Sign/Status Matrix), и часто указывают, действительны ли данные в слове.
Биты 30 — 31 являются «Матрицей Признака» или статуса, или SSM (Sign/Status Matrix), и часто указывают, действительны ли данные в слове.
- Рабочее состояние — данные в этом слове, как полагают, являются правильными данными.
- Тестовое состояние — данные предоставляются для тестовых целей.
- Отказ — Отказ аппаратных средств, связанных с выдачей этого слова.
- Отсутствуют — Данные отсутствуют, неточные или устаревшие по некоторым причинам кроме отказа аппаратных средств. Например, команды автопилота покажут это состояние, когда автопилот не будет включён.
У меня один вопрос — почему в сетевом оборудовании ещё XX века нет таких косяков? Почему Ethernet-хаб за $5 не надо перезагружать каждый месяц, а у роутера аптайм в год?
UFO just landed and posted this here
В добавление к предыдущему комментарию: по той же причине их проще протестировать и отладить.
Потому что роутер проще.
И что значит "не надо", достаточно на каком-нибудь TP-Link запустить большое число потоков с суммарной скоростью мегабит в 80 и переполнит какую-то таблицу внутри и перестанет пропускать трафик, любой (но к нему можно приконнектиться и рестартовать). Не каждые 149 часов, конечно, но если трафик появится снова, то они и 49 секунд не проживёт (считая время, необходимое для повторных соединений и роста скорости соединения). ASUS в той же ситуации перегреется, начнёт глючить и даже свой интерфейс отдавать кусками (вместо содержимого фрейма — содержимое вложенного в него, например, вообще не понятно как такое получается).
Ethernet Hub перегружать действительно не надо — это же тупой повторитель. А вот Ethernet Switch — иногда надо. Особенно, если он управляемый и особенно до L3. А ещё, я получал случайное кольцо и хаб клал сегмент мгновенно, а свитч держался несколько секунд (за счёт кеша таблиц адресов).
UFO just landed and posted this here
Точно также и Patriot'ы должны были регулярно перезагружаться…
UFO just landed and posted this here
То есть, это не баг, а фича.
Теоретически можно представить себе ситуациюБизнес вряд-ли будет такой держать включенным. А вот регулярные рейсы — там самолёт эксплуатируют по-полной: он прилетает в один аэропорт, через 1-2 часа вылетает в другой. И так без остановки гоняют самолёты. Зачем самолёту просто так стоять отдыхать, если есть народ, который хочет лететь?
Если бы самолёты стояли после перелётов по несколько дней в аэропортах, то аэропорты были бы ими забиты. К тому же парковка самолётов в аэропортах — довольно дорогое удовольствие, которое просто кушает деньги, но не приносит прибыли. Лучше самолёт отправить лететь, возить пассажиров и приносить деньги.
Как и обычно — сток глючит, приходится кастом накатывать.
Старый глюк лучше новых двух
Добрый день! У нас самолёт не взлетает. Перезагружать пробовали?
UFO just landed and posted this here
Sign up to leave a comment.
Из-за бага прошивки Airbus A350 самолёт нужно перезагружать каждые 149 часов