1553 не является общей шиной и подразумевает только один хост(контроллер), который и запускает любую пересылку по ней. На его запрос, если адрес соответствует устройству, оно должно ответить или принять данные. Тайминг на задержку ответа строгий(устанавливается при программировании/разработке системы), но без ответа не будут переданы данные от устройства и не появятся не корректные данные об угловой скорости. Т.е. никакого приоритета на уровне шины нет, как не могут быть перепутаны данными с командами на уровне шины. На более высоком уровне могут быть команды включения, опроса в любом порядке с приоритетами и без, но не возможна ситуация: "В связи с этим в бортовой комплекс управления приходили нулевые сигналы с блока акселерометров прибора БИУС-Л"! С ограничение количества команд в единицу времени не сталкивался, думаю тут есть путаница со временем выполнения команды для данного устройства - действительно ряд команд(инициализации, записи во flash,eprom) требуют время для исполнения, но это прописано в протоколе работы с эти устройством и не допускается продолжение работы с устройством без его готовности к исполнению следующей команды. В этой же конкретно ситуации, используется команда прочитать из памяти(float - угловую скорость), которая в принципе не может иметь дополнительное время исполнения, ее время исполнения - время ответа по шине!
Что про второй «Биус-Л», который должен был нивелировать отказ первого, к тексту не относится? Про ВОГи ошибся. Но раз у них нет времени на инициализацию, как вы можете объяснить набор слов про приоритет команд в массиве данных и случайном их порядке?
Причем здесь алгоритм обработки - заявлено что приоритет команд в массиве данных из-за случайного порядка послужил причиной сбоя. Но как? Интерфейс обмена скорей всего RS485+SSP, скорость 115200 бод, контроллер посылает команду GET с адресом для чтения от 1 до 3 float-ов 20 раз в секунду и получает в ответ от 1 до 3 float-ов. Там нет приоритетов, всего несколько команд, при этом на этапе работы (а не программирования адресов устройств) имеет смысл использовать только команду GET.
Установлено, что наиболее вероятной причиной аварии «Луны-25» стало нештатное функционирование бортового комплекса управления, связанное с невключением блока акселерометров в приборе БИУС-Л (блок измерения угловых скоростей) из-за возможного попадания в один массив данных команд с различными приоритетами их исполнения прибором. При этом распределение команд в массивах данных имеет случайный (вероятностный) характер.
Это заявление о сферическом коне в вакууме а не о причине аварии! Не состыковки:
из открытых источников(ВЕСТНИК НПО ИМЕНИ С.А.ЛАВОЧКИНА за 2021), известно о установке ДВУХ БИУС-Л на «Луну-25» "С целью повышения надёжности при выполнении критических операций коррекции траектории на КА".
в состав каждого БИУС-Л входит три волоконно-оптических гироскопа. При включении гироскопов им нужно время на раскрутку а системе необходимо проверить что они раскрутились и готовы к работе.
"Частота обмена данными бортовой цифровой вычислительной машины и БИУС-Л составляет 20 Гц. " При такой частоте обмена даже самый слабый контроллер прошлого века успеет обработать поступающие данные вне зависимости от приоритета и распределения.
1. Вполне может быть что в первом варианте на уровне логического диска фрагментации нет, а во втором варианте ОС думает что у нее много фрагментированных файлов.
Если расстояние между фрагментами меньше (Количество_Дисков — 1)*Размер_Блока, то фактически, фрагментации можно считать что нет, но тут начинает влиять фактор, что для доступа к файлу нужно считать/записать больше блоков данных(т.к. любая фрагментация увеличивает шанс попадания в +1 блок данных). А для RAID 5 это более затратно, т.к. данные(в случае записи) пишутся на два диска и должны прочитаться с третьего(для формирования контрольной суммы по модулю 2).
2. Как на уровне виртуального логического диска, положить информацию в физические секторы рядом и по порядку?
Как я уже говорил, не фрагментированное расположение данных в ОС залог быстрой работы и RAID. Т.е. данные и будут лежать по порядку, с разрывами по блокам данных RAID. Эти разрывы нивелируются алгоритмами работы RAID(распараллеливанием операций с дисками).
3. Если у нас один физ. диск, и место под файл бд выделили сразу непрерывный кусок 1ГБ, а потом приращениями по 1 ГБ, так ли будет сказываться снижения производительности когда фрагментация файла будет не кусками по 64КБ, а по 1 ГБ?
При архивировании/восстановлении, конечно не будет, т.к. задержка позиционирования головки почти не скажется на общем времени операции. Но если взять случайный доступ к базе данных, то там, увеличение времени позиционирования из-за разнесения данных по поверхности, будет сказываться на производительности. Ведь при записи данных в базу, идет реальная запись на диск(правда нивелируемая при при включенном «write back», кэшем контроллера).(Кстати, приращение БД в 1ГБ(в MSSQL), находящейся на одном диске, это многовато, т.к. при расширении, sql должен проинициализировать эту область на диске «0»-ми).
То у вас оптимизация по секторам идет, то RAID контроллер работает с кластерами… RAID контроллер работает с блоками данных, причем одного размера для всего виртуального диска. Структура RAID5 может быть такой:
(БД-блок данных). Схема чередования, задержка чередования(второй вариант) может отличаться в зависимости от контроллера и настроек виртуального диска.
То, что ОС не видит структуры виртуального диск совершенно не означает, что доступ к фрагментированным данным будет такой же быстрый, как к не фрагментированным! Очевидно же(посмотрев на рисунок) в случае фрагментации на RAID5 просто уменьшается расстояние между фрагментами на физических дисках (в данном примере в два раза).
Вывод: дефрагментация RAID5 — ускоряет доступ к данным.
То, что SQL сервер выделяет место кратно своим страницам, вовсе не означает, что в процессе работы файл базы данных не станет фрагментированным (пример — две базы на одном диске расширяющиеся по очереди).
Не понятен пример с RAID-5.
Для ОС, в которой производится дефрагментация, все три диска разворачиваются в один логический, в котором и происходит упорядочивание логических единиц хранения(кластер, блок...), а не секторов.
Какова бы не была схема размещения данных по дискам RAID5, все равно она строится с учетом, что бы получить максимальную скорость чтения/записи последовательных данных. Поэтому оптимизация сильно дефрагментированных логических дисков все же имеет смысл. Особенности строения современных файловых систем нивелируют фрагментацию, но(исходя из моего опыта) не полностью.
Нет p-n переходов на которых не падает напряжение. Поэтому в цифровых осциллографах часто используются реле(вместо «крутилок») и в зависимости от режима работы они могут ритмично потрескивать :)
1553 не является общей шиной и подразумевает только один хост(контроллер), который и запускает любую пересылку по ней. На его запрос, если адрес соответствует устройству, оно должно ответить или принять данные. Тайминг на задержку ответа строгий(устанавливается при программировании/разработке системы), но без ответа не будут переданы данные от устройства и не появятся не корректные данные об угловой скорости. Т.е. никакого приоритета на уровне шины нет, как не могут быть перепутаны данными с командами на уровне шины. На более высоком уровне могут быть команды включения, опроса в любом порядке с приоритетами и без, но не возможна ситуация: "В связи с этим в бортовой комплекс управления приходили нулевые сигналы с блока акселерометров прибора БИУС-Л"! С ограничение количества команд в единицу времени не сталкивался, думаю тут есть путаница со временем выполнения команды для данного устройства - действительно ряд команд(инициализации, записи во flash,eprom) требуют время для исполнения, но это прописано в протоколе работы с эти устройством и не допускается продолжение работы с устройством без его готовности к исполнению следующей команды. В этой же конкретно ситуации, используется команда прочитать из памяти(float - угловую скорость), которая в принципе не может иметь дополнительное время исполнения, ее время исполнения - время ответа по шине!
фотоны, чтоб спин равнялся единице.
А вы не путаете БИУС-14 где действительно на фото видно четыре ВОГа c БИУС-Л где заявлено три и поэтому их должны были поставить два?
Что про второй «Биус-Л», который должен был нивелировать отказ первого, к тексту не относится? Про ВОГи ошибся. Но раз у них нет времени на инициализацию, как вы можете объяснить набор слов про приоритет команд в массиве данных и случайном их порядке?
Причем здесь алгоритм обработки - заявлено что приоритет команд в массиве данных из-за случайного порядка послужил причиной сбоя. Но как? Интерфейс обмена скорей всего RS485+SSP, скорость 115200 бод, контроллер посылает команду GET с адресом для чтения от 1 до 3 float-ов 20 раз в секунду и получает в ответ от 1 до 3 float-ов. Там нет приоритетов, всего несколько команд, при этом на этапе работы (а не программирования адресов устройств) имеет смысл использовать только команду GET.
ошибся, подумал о гироскопе с волоконно-оптическими датчиками угла поворота :)
Это заявление о сферическом коне в вакууме а не о причине аварии! Не состыковки:
из открытых источников(ВЕСТНИК НПО ИМЕНИ С.А.ЛАВОЧКИНА за 2021), известно о установке ДВУХ БИУС-Л на «Луну-25» "С целью повышения надёжности при выполнении критических операций коррекции траектории на КА".
в состав каждого БИУС-Л входит три волоконно-оптических гироскопа. При включении гироскопов им нужно время на раскрутку а системе необходимо проверить что они раскрутились и готовы к работе.
"Частота обмена данными бортовой цифровой вычислительной машины и БИУС-Л составляет 20 Гц. " При такой частоте обмена даже самый слабый контроллер прошлого века успеет обработать поступающие данные вне зависимости от приоритета и распределения.
Как я уже говорил, не фрагментированное расположение данных в ОС залог быстрой работы и RAID. Т.е. данные и будут лежать по порядку, с разрывами по блокам данных RAID. Эти разрывы нивелируются алгоритмами работы RAID(распараллеливанием операций с дисками).
При архивировании/восстановлении, конечно не будет, т.к. задержка позиционирования головки почти не скажется на общем времени операции. Но если взять случайный доступ к базе данных, то там, увеличение времени позиционирования из-за разнесения данных по поверхности, будет сказываться на производительности. Ведь при записи данных в базу, идет реальная запись на диск(правда нивелируемая при при включенном «write back», кэшем контроллера).(Кстати, приращение БД в 1ГБ(в MSSQL), находящейся на одном диске, это многовато, т.к. при расширении, sql должен проинициализировать эту область на диске «0»-ми).
(БД-блок данных). Схема чередования, задержка чередования(второй вариант) может отличаться в зависимости от контроллера и настроек виртуального диска.
То, что ОС не видит структуры виртуального диск совершенно не означает, что доступ к фрагментированным данным будет такой же быстрый, как к не фрагментированным! Очевидно же(посмотрев на рисунок) в случае фрагментации на RAID5 просто уменьшается расстояние между фрагментами на физических дисках (в данном примере в два раза).
Вывод: дефрагментация RAID5 — ускоряет доступ к данным.
То, что SQL сервер выделяет место кратно своим страницам, вовсе не означает, что в процессе работы файл базы данных не станет фрагментированным (пример — две базы на одном диске расширяющиеся по очереди).
Для ОС, в которой производится дефрагментация, все три диска разворачиваются в один логический, в котором и происходит упорядочивание логических единиц хранения(кластер, блок...), а не секторов.
Какова бы не была схема размещения данных по дискам RAID5, все равно она строится с учетом, что бы получить максимальную скорость чтения/записи последовательных данных. Поэтому оптимизация сильно дефрагментированных логических дисков все же имеет смысл. Особенности строения современных файловых систем нивелируют фрагментацию, но(исходя из моего опыта) не полностью.