Комментарии 27
В самом же деле, что делать, как обороняться, если пришельцы выберут тактику нападения с разных направлений из соседних звёздных систем? Тогда каждый кластер обороны будет знать о нападении лишь части армии, а нападающие уже заранее согласовали план о направлении главного удара? Может быть, нам надо сделать передовую линию обороны на дальних подступах, в а.е. 300 примерно? Давайте подумаем о перестройке всей стратегии обороны ресурсов.
Но что, если они уже тут, а мы в зоопарке в обезьяньей клетке, в которой нам дадут развиваться до некоторых пределов, а потом ограничат, потому что ресурсы всем нужны, а сильным — нужнее? Тогда надо побольше урвать ресурсов у окружающих, пока те внешние нас всех не остановят. И ведь не просто так, а ради высокой цели, мобилизовать всех на защиту всей цивилизации и её будущего.
Но что, если они уже тут, а мы в зоопарке в обезьяньей клетке, в которой нам дадут развиваться до некоторых пределов, а потом ограничат, потому что ресурсы всем нужны, а сильным — нужнее? Тогда надо побольше урвать ресурсов у окружающих, пока те внешние нас всех не остановят. И ведь не просто так, а ради высокой цели, мобилизовать всех на защиту всей цивилизации и её будущего.
Я вас умоляю :) Если пришельцы захотят нас уничтожить — им проще будет натравить людей самих на себя, либо сымитировать ядерное нападение. Человечество само себя уничтожит.
Логика расширяющегося сектора подсказывает, что линию обороны надо выносить на точки исходящей агрессии. То есть в столицу пришельцев. Или что там у них.
Вообще-то все давно перешли на подпространнственную синхронизацию доступную из любой точки.
Внешние давно управляют системой, вопрос в том сколько они могут позволить себе затратить ресурсов для удержания контроля. Т.е. захват ресурсов первостепенная задача.
Внешние давно управляют системой, вопрос в том сколько они могут позволить себе затратить ресурсов для удержания контроля. Т.е. захват ресурсов первостепенная задача.
Я давно подозревал, но видно при скачивании Erlang с официального сайта компания высылает всем новичкам дополнительные вещества для изучения?!
А давно у нас есть космичесая военная группировка?
Если программисты строят велосипед, то планируют, что он будет летать в космос и погружаться на дно океана.
В языке учитываются такие моменты: https://habrahabr.ru/post/146109/ (оригинал http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time)?
В языке учитываются такие моменты: https://habrahabr.ru/post/146109/ (оригинал http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time)?
Я полетел дальше.
Мой корабль действует на кардинально иных физических принципах.
Мой корабль действует на кардинально иных физических принципах.
Пока читал все надеялся, что внизу-таки найдется ссылка на гитхаб, а там — корабли, битвы, подпространство!.. Эх.
Вызывает интерес механизм синхронизации и алгоритм поддержания синхронизации кораблей, действующих в пределах одной звездной системы.
Как осуществляется передача сигнала точного времени, по какому физическому каналу? Ведь даже наша маленькая Солнечная система достаточно велика, чтобы задержка распространения информации от края до края измерялась в минутах.
Второй момент: корабли флота в пределах системы, выполняя боевые задачи, задачи патрулирования и разведки, могут двигаться с переменными, непредсказуемыми ускорениями и относительными скоростями. Соответственно будет накапливаться отставание/убегание внутреннего времени кораблей друг относительно друга. Есть ли алгоритм поддержания необходимой синхронизации и как он реализован?
Если необходима синхронизация с точностью до микросекунд, учитывает ли алгоритм влияние массивных объектов?
ПыСы. Да, видимо мы пользуемся с топикстартером услугами одного дилера.
Как осуществляется передача сигнала точного времени, по какому физическому каналу? Ведь даже наша маленькая Солнечная система достаточно велика, чтобы задержка распространения информации от края до края измерялась в минутах.
Второй момент: корабли флота в пределах системы, выполняя боевые задачи, задачи патрулирования и разведки, могут двигаться с переменными, непредсказуемыми ускорениями и относительными скоростями. Соответственно будет накапливаться отставание/убегание внутреннего времени кораблей друг относительно друга. Есть ли алгоритм поддержания необходимой синхронизации и как он реализован?
Если необходима синхронизация с точностью до микросекунд, учитывает ли алгоритм влияние массивных объектов?
ПыСы. Да, видимо мы пользуемся с топикстартером услугами одного дилера.
По вопросу 1: я предполагаю, что как и в наземных системах с GPS учитывается время прохождения сигнала от источника точного времени и происходит соответствующая корректировка.
По вопросу 2: корабли синхронизировать либо на источник точного времени, либо на корабль с более точным временем. На самом деле суть изменений ядра не в том, как синхронизировать время. Время в любом случае будет подводиться вперед или даже назад. Суть изменений в том, что созданы инструменты о том, как с этим жить. Системное время ОС является больше справочной информацией. По факту, каждый корабль живет на своей оси времени. Получая команды, он их все равно не сможет выполнить раньше, чем получил. При использовании системного времени напрямую, например для записи в бортовой журнал, может произойти «запись_1» в 10:00, а потом произойти корректировка системного времени и «запись_2» в 09:59. В случае использования Erlang, задача работает в среде, как в полноценной операционной системе, получая весь необходимый сервис(как например, распределение времени между задачами). Таким же образом Erlang обеспечивает и равномерность хода времени, если использовать не System Time, а Erlang Time. При небольших переводах времени, пользуясь Erlang Time, ход таймера времени будет либо немного замедляться, либо немного ускоряться, пока разница не будет устранена (этот момент сейчас пока что проверяется на стендах, в лабораторию должен подойти корабль для тестов). Но не смотря на переводы времени, Erlang имеет формат времени (который очевидно, содержит не только время, но и данные от счетчика тактов процессора). Этот формат поставит записи борт журнала «запись_1» и «запись_2» в правильном порядке, не смотря на перевод времени. Таким же образом, не испортится возможность ядра отмерять интервалы времени между событиями либо текущим временем. Если что-то нужно сделать через час, то переведя часы на 20 минут вперед, мы не уменьшим интервал времени до события.
По вопросу 3: синхронизация до микросекунд и вообще точность будет зависеть от плотности группировки (разнице прохождения сигнала и точности дальномеров для корректировки). Но это только если работать в одном таймлайне. Еще важный момент, в каком режиме корабли будут выполнять команды флагмана: а) по получению команды сразу; б) полученную команду выполнять по наступлению какого-то времени или события. Тут надо обсуждать с капитанами особенности руководства.
По вопросу 4: влияние массивных объектов пока не учитывается, но у нас уже имеется модель сферического алгоритма массивного объекта в вакууме…
По вопросу 2: корабли синхронизировать либо на источник точного времени, либо на корабль с более точным временем. На самом деле суть изменений ядра не в том, как синхронизировать время. Время в любом случае будет подводиться вперед или даже назад. Суть изменений в том, что созданы инструменты о том, как с этим жить. Системное время ОС является больше справочной информацией. По факту, каждый корабль живет на своей оси времени. Получая команды, он их все равно не сможет выполнить раньше, чем получил. При использовании системного времени напрямую, например для записи в бортовой журнал, может произойти «запись_1» в 10:00, а потом произойти корректировка системного времени и «запись_2» в 09:59. В случае использования Erlang, задача работает в среде, как в полноценной операционной системе, получая весь необходимый сервис(как например, распределение времени между задачами). Таким же образом Erlang обеспечивает и равномерность хода времени, если использовать не System Time, а Erlang Time. При небольших переводах времени, пользуясь Erlang Time, ход таймера времени будет либо немного замедляться, либо немного ускоряться, пока разница не будет устранена (этот момент сейчас пока что проверяется на стендах, в лабораторию должен подойти корабль для тестов). Но не смотря на переводы времени, Erlang имеет формат времени (который очевидно, содержит не только время, но и данные от счетчика тактов процессора). Этот формат поставит записи борт журнала «запись_1» и «запись_2» в правильном порядке, не смотря на перевод времени. Таким же образом, не испортится возможность ядра отмерять интервалы времени между событиями либо текущим временем. Если что-то нужно сделать через час, то переведя часы на 20 минут вперед, мы не уменьшим интервал времени до события.
По вопросу 3: синхронизация до микросекунд и вообще точность будет зависеть от плотности группировки (разнице прохождения сигнала и точности дальномеров для корректировки). Но это только если работать в одном таймлайне. Еще важный момент, в каком режиме корабли будут выполнять команды флагмана: а) по получению команды сразу; б) полученную команду выполнять по наступлению какого-то времени или события. Тут надо обсуждать с капитанами особенности руководства.
По вопросу 4: влияние массивных объектов пока не учитывается, но у нас уже имеется модель сферического алгоритма массивного объекта в вакууме…
Спасибо за развернутый ответ.
Однако, большая часть вопросов осталась нерешенной:
1. Какой физический канал передачи данных в условиях чужой звездной системы? (Вопрос активного противодействия средствами РЭБ противника пока не учитываем). Оптический канал связи или радио-диапазон? Синхронизация точка-точка или передача в эфире «всем кто меня слышит»? Учитывается ли особенность распространения сигнала в среде? Возможность приема переотраженного сигнала, вносящей ошибку синхронизации, timedelay при прохождении газовых облаков?
2. Для боевого маневрирования категорически важно иметь полную синхронность часов всех сил и средств при выполнении боевой задачи, вне зависимости от типа управления -непосредственными командами или по заранее разработанному плану. Например, выход в расчетную точку, расчет тормозного импульса или импульса ускорения, одновременность удара (и фокусировки), донесений от службы дальнего обнаружения противника, средств наведения и корректировки огня. Для последних точность до микросекунд представляется минимально допустимой. При движении флотов с высокими относительными скоростями, ошибка даже в 1 микросекунду ведет к промаху. Так же критически важна синхронизация, например, при залповой ракетной стрельбе, когда часть ракет первой волны служит для преодоления противоракетной обороны противника. Несвоевременность старта ракет, несинхронное маневрирование, несвоевременный подрыв боеголовок могут означать срыв боевой задачи.
Однако, большая часть вопросов осталась нерешенной:
1. Какой физический канал передачи данных в условиях чужой звездной системы? (Вопрос активного противодействия средствами РЭБ противника пока не учитываем). Оптический канал связи или радио-диапазон? Синхронизация точка-точка или передача в эфире «всем кто меня слышит»? Учитывается ли особенность распространения сигнала в среде? Возможность приема переотраженного сигнала, вносящей ошибку синхронизации, timedelay при прохождении газовых облаков?
2. Для боевого маневрирования категорически важно иметь полную синхронность часов всех сил и средств при выполнении боевой задачи, вне зависимости от типа управления -непосредственными командами или по заранее разработанному плану. Например, выход в расчетную точку, расчет тормозного импульса или импульса ускорения, одновременность удара (и фокусировки), донесений от службы дальнего обнаружения противника, средств наведения и корректировки огня. Для последних точность до микросекунд представляется минимально допустимой. При движении флотов с высокими относительными скоростями, ошибка даже в 1 микросекунду ведет к промаху. Так же критически важна синхронизация, например, при залповой ракетной стрельбе, когда часть ракет первой волны служит для преодоления противоракетной обороны противника. Несвоевременность старта ракет, несинхронное маневрирование, несвоевременный подрыв боеголовок могут означать срыв боевой задачи.
Есть варианты. В любительском радио все тежнологии уже отработаны (не говоря о профессиональном).
Если использовать коротковолновые передатчики, то чаще всего из за размеров антенн, передача не имеет очень острой направленности. В этом случае получится «общая шина» и каждая передача по сути броадкаст.
В качестве модуляции, эффективнее всего использовать однополосную (SSB). Цифровые данные удобнее всего передавать, используя цифровые протоколы, например Packet Radio (AX.25 — адаптированная под радиоканал версия X.25). По сути дела это канальный уровень(формирование пакетов, контрольных сумм, подтверждение приема, установка соединений). Поверх AX.25 желательно использовать APRS(я о нем уже писал). Это даст: 1) широковещательную работу; 2) возможность ретрансляции промежуточными станциями; 3) позиционирование в пространстве. Есть решения дороже/быстрее(PACTOR).
Стоит учесть, что с повышением несущей частоты передаваемого радио-сигнала, свойства такой радиоволны все ближе становятся похожи на свойства видимого света: больше поглощение физическими объектами, необходимость прямой видимости. В то же время, антенны становятся меньше и проще создать направленные антенны с узкой диаграммой направленности (многоэлементные yagi, спиральные, параболические).
Для передачи данных с дальних рубежей можно использовать медленные виды связи, когда мощность разменивают на скорость. Например BPSK31, либо WSPR, когда уровень сигнала ниже уровня шумов, есть более простой вариант — медленный телеграф (QRSS). Есть возможность передавать изображения, с помощью SSTV.
Есть весьма интересные разработки, когда сигнал «размазывается» в широкой полосе частот. Его сложнее «глушить», находить, декодировать(см. Л.Е. Варакин — Системы связи с шумоподобными сигналами М:. 1985г).
Проблему приема переотраженного сигнала нужно решать на качественно новом уровне, применяя разнесенные в пространстве антенны и цифровые приемники SDR Radio на основе быстрых АЦП и ПЛИС либо спец ASIC(в том числе и Российские). Есть много работы и для математиков. Есть наработки по секвентному анализу (Функции Уолша). Общество к ним пока еще не готово.
Про возможности совместного маневрирования, есть интересные наработки в Москве. Общая суть которых заключается в том, что очень сложно создать модель даже автомобиля и его адаптивной подвески (учитывающей N человек на сиденьях и в багажнике). Они предлагают для самоадаптации использовать нейронную сеть. Есть тестовая модель спутника, где устройство на нитке, с мотором и грузом, используя нейронную сеть, без физической модели, смогло приспособиьтся к позиционированию (ссылка).
Так что я думаю, все решаемо
Если использовать коротковолновые передатчики, то чаще всего из за размеров антенн, передача не имеет очень острой направленности. В этом случае получится «общая шина» и каждая передача по сути броадкаст.
Диаграммы направленности
В качестве модуляции, эффективнее всего использовать однополосную (SSB). Цифровые данные удобнее всего передавать, используя цифровые протоколы, например Packet Radio (AX.25 — адаптированная под радиоканал версия X.25). По сути дела это канальный уровень(формирование пакетов, контрольных сумм, подтверждение приема, установка соединений). Поверх AX.25 желательно использовать APRS(я о нем уже писал). Это даст: 1) широковещательную работу; 2) возможность ретрансляции промежуточными станциями; 3) позиционирование в пространстве. Есть решения дороже/быстрее(PACTOR).
Стоит учесть, что с повышением несущей частоты передаваемого радио-сигнала, свойства такой радиоволны все ближе становятся похожи на свойства видимого света: больше поглощение физическими объектами, необходимость прямой видимости. В то же время, антенны становятся меньше и проще создать направленные антенны с узкой диаграммой направленности (многоэлементные yagi, спиральные, параболические).
Для передачи данных с дальних рубежей можно использовать медленные виды связи, когда мощность разменивают на скорость. Например BPSK31, либо WSPR, когда уровень сигнала ниже уровня шумов, есть более простой вариант — медленный телеграф (QRSS). Есть возможность передавать изображения, с помощью SSTV.
Есть весьма интересные разработки, когда сигнал «размазывается» в широкой полосе частот. Его сложнее «глушить», находить, декодировать(см. Л.Е. Варакин — Системы связи с шумоподобными сигналами М:. 1985г).
Проблему приема переотраженного сигнала нужно решать на качественно новом уровне, применяя разнесенные в пространстве антенны и цифровые приемники SDR Radio на основе быстрых АЦП и ПЛИС либо спец ASIC(в том числе и Российские). Есть много работы и для математиков. Есть наработки по секвентному анализу (Функции Уолша). Общество к ним пока еще не готово.
Про возможности совместного маневрирования, есть интересные наработки в Москве. Общая суть которых заключается в том, что очень сложно создать модель даже автомобиля и его адаптивной подвески (учитывающей N человек на сиденьях и в багажнике). Они предлагают для самоадаптации использовать нейронную сеть. Есть тестовая модель спутника, где устройство на нитке, с мотором и грузом, используя нейронную сеть, без физической модели, смогло приспособиьтся к позиционированию (ссылка).
Так что я думаю, все решаемо
ОК, по поводу физического канала понял. Но есть нюанс, о котором я пытался спросить -как можно быть уверенным в достоверности синхроимпульса, если мы не можем гарантировать однородность и предсказуемость свойств среды, через которую пролегает трек сигнала?
Примеры: гравитационные искажения времени на корабле-носителе базового времени (НБВ), приход сигнала через газовое облако с замедлением времени прохождения. Переотражение сигнала, увеличивающее длину трека. Ведь даже в пределах Солнечной системы, если, например, корабль НБВ находится у Солнца в районе орбиты Меркурия, а принимающий -на орбите у Земли, то мы не можем ничего сказать, будет ли пришедший радиосигнал носителем достоверного сигнала точного времени, поскольку ничего не знаем о треке, скорости движения источника сигнала и гравитационных условий в месте излучения. Причем «недостоверность» может достигать секунд! Например, если сигнал пришел к нам не прямой, а отраженным от поверхности Луны, да еще и прошедшим через кометный след. Возможно, часть этих проблем можно решить разнесенным приемом, часть протоколом передачи, где будет указываться скорость и местоположение НБВ относительно центрального светила. Но всех проблем эти меры не решат, они несколько повысят достоверность, но оставят высоким уровень погрешности.
Вот о возможных мерах борьбы с недостоверностью и протоколах передачи я и хотел услышать))
Примеры: гравитационные искажения времени на корабле-носителе базового времени (НБВ), приход сигнала через газовое облако с замедлением времени прохождения. Переотражение сигнала, увеличивающее длину трека. Ведь даже в пределах Солнечной системы, если, например, корабль НБВ находится у Солнца в районе орбиты Меркурия, а принимающий -на орбите у Земли, то мы не можем ничего сказать, будет ли пришедший радиосигнал носителем достоверного сигнала точного времени, поскольку ничего не знаем о треке, скорости движения источника сигнала и гравитационных условий в месте излучения. Причем «недостоверность» может достигать секунд! Например, если сигнал пришел к нам не прямой, а отраженным от поверхности Луны, да еще и прошедшим через кометный след. Возможно, часть этих проблем можно решить разнесенным приемом, часть протоколом передачи, где будет указываться скорость и местоположение НБВ относительно центрального светила. Но всех проблем эти меры не решат, они несколько повысят достоверность, но оставят высоким уровень погрешности.
Вот о возможных мерах борьбы с недостоверностью и протоколах передачи я и хотел услышать))
Вот о возможных мерах борьбы с недостоверностью и протоколах передачи я и хотел услышать))
Я же говорю: в AX.25 есть CRC. Тип передачи AFSK. Единица и ноль кодируются разными частотами. Переотражения, временные искажения приведут к ошибкам декодирования отдельных бит, контрольная сумма не сойдется, пакет будет отброшен. Но это для автоматической работы.
В случаях с BPSK31 будут теряться символы, будет мусор. Но это работа с дальними рубежами. Их могут операторы принимать, если техника не справится.
При передаче в SSTV появятся «помехи» в картинке
Мне кажется мы говорим о сильно разном. Проблема не в достоверности сообщения (которую можно восстановить сверточным кодированием, сложными кодами с восстановлением ошибки или разнесением передачи по каналам). Проблема в достоверности времени приема, ведь сигнал точного времени это не только сигнал с содержащейся в нём информацией, но и именно момент времени, та микросекунда его приема, грубо говоря передний или задний фронт импульса, по которому мы считаем, что вот оно, время.
И если все сообщение принято корректно, но время прохождения импульса по тракту -неправильное, или время на разных кораблях вследствие разности скоростей, с которыми они двигались с момента последней синхронизации разошлось, то это убивает весь смысл синхронизации на корню. Это в пределах Земли эта проблема легко решается (все тракты заранее известны, относительные скорости объектов, ведущих к искажению течения ИХ внутреннего времени ничтожны). В масштабах звездных систем это уже не так, почему -я уже писал.
И если все сообщение принято корректно, но время прохождения импульса по тракту -неправильное, или время на разных кораблях вследствие разности скоростей, с которыми они двигались с момента последней синхронизации разошлось, то это убивает весь смысл синхронизации на корню. Это в пределах Земли эта проблема легко решается (все тракты заранее известны, относительные скорости объектов, ведущих к искажению течения ИХ внутреннего времени ничтожны). В масштабах звездных систем это уже не так, почему -я уже писал.
Где код для моего космического корабля?
А lager уже переехал на новое API?
Судя по коду, да.
На сколько я знаю, в Erlang есть правило, что deprecated функционал будет доступен до следующего релиза. То есть erlang:now() был нормой до 17 версии, в 18 объявлен deprecated, и только в 19 его не будет совсем.
Интересно, что Elixir поверх Erlang 18 уже ругается warning'ами на эту функцию.
На сколько я знаю, в Erlang есть правило, что deprecated функционал будет доступен до следующего релиза. То есть erlang:now() был нормой до 17 версии, в 18 объявлен deprecated, и только в 19 его не будет совсем.
Интересно, что Elixir поверх Erlang 18 уже ругается warning'ами на эту функцию.
С каких пор вычислительные кластеры работают без внятной синхронизации времени? =)))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Информация для адмиралов космических флотилий