Докладная записка
Мой Адмирал, ваш флот насчитывает сотни, а может и тысячи кораблей. Все они действуют, как единый организм, действуя в одном информационном поле. В качестве канала связи используется радиоэфир, либо лазерная связь в случае работы в условиях радиоподавления (либо радиомолчания). Вероятнее всего, в качестве базового программного обеспечения, на кораблях используется Erlang, а каждый корабль является Нодой вычислительного кластера вашей космической армады. Благодаря этому, боевые программы, выполняемые на флагманском корабле, могут управлять ресурсами любого корабля армады, как своими собственными, координируя боевое взаимодействие. В условиях ведения космической битвы в окрестностях нашей солнечной системы, такой подход показал высокую эффективность, как на испытаниях, так и в реальном бою. Однако, партия ставит перед нами новую задачу: не допускать проникновения противника в пределы нашей солнечной системы, обнаружение противника и борьбу с ним вести на дальних рубежах.
В условиях субсветовых скоростей и огромных расстояний нас подстерегает новый враг. На этот раз технический. Этого врага зовут «временной разрыв» (Time Warp). Что это такое и как с ним бороться (используя Erlang версии 18 и выше), изложено в данной докладной записке. Записка основана на технической документации — Time and Time Correction in Erlang.
Единый таймлайн
Новые условия ставят перед инженерами новые технические задачи. Слаженная работа космических объектов достигается не только сетевым взаимодействием, но и точной синхронизацией часов со временем на Земле. Для того, чтобы автоматический космический объект мог следовать заданной программе, либо действовать в условиях потери сетевой связи, его внутренние часы должны быть синхронизированы со временем Земли. Для этого, в пределах нашей солнечной системы, правительство(на деньги налогоплательщиков) построило и установило группировку спутников временной синхронизации. Теперь любой автоматический спутник даже в случае повреждения основных аккумуляторов, в условиях работы только напрямую от солнечных батарей, способен принять сигнал ближайшего спутника временной синхронизации и определить точное время.
Почему эта система не поможет в бою?
1) В новых условиях, мы должны сражаться за пределами солнечной системы. В открытом космосе нет спутников временной синхронизации.
2) Боевой флот не может и не должен быть зависим от гражданских систем.
3) Боевой флот не может зависеть от стационарных систем.
Флот обязан быть полностью самостоятельным и самодостаточным.
Для этого, корабли флота должны самостоятельно синхронизировать время друг с другом. Вероятнее всего, все часы нужно синхронизировать с часами флагмана.
Но вы скажете: «На наших крейсерах установлены атомные часы, даже в кораблях истребителях используются часы на рубидиевых опорных генераторах, а управляемая ракета живет не так долго, чтобы ее термокомпенсированный кварцевый генератор ошибся на значимое значение». И будете правы. Да, можно один раз перед боем провести синхронизацию. В процессе боя, отдельные корабли могут терять связь с кластером, но продолжать выполнять боевые задачи в одном масштабе времени.
Действия в условиях разных масштабов времени
Существует ряд причин, по которым в кораблях может установиться разное значение времени:
— флагманский корабль может подойти к месту событий через подпространственный тоннель: в этом случае он мгновенно сменит свои координаты, при этом не теряя синхронизации с временем Земли;
— спутник наблюдения, находящийся в месте событий, мог там находиться длительное время без возможности синхронизации, и из за неточности генератора в часах, его время может как «отстать» от времени Земли, так и «уйти вперед»
— корабли среднего класса могут подойти к месту событий на субсветовых скоростях и на их часы могут повлиять релятивистские эффекты
— автоматические корабли, прошедшие рядом или через сверхмассивную черную дыру
В каждом случае, как только корабль появится в зоне радиовидимости флагмана, он произведет синхронизацию времени, с последующим подключением к кластеру. В процессе синхронизации, часы синхронизируемого корабля будут переведены вперед, или, что еще хуже, назад. Этот эффект называется временным разрывом (Time Warp).
Техническое решение
В OTP 18 (ERTS версии 7.0) были расширены функциональные возможности работы со временем. Эти возможности включены в API для работы со временем и с разрывами времени (time warp), которые изменяют поведение систем при изменении системного времени. Режим работы с разрывами времени, который используется по умолчанию, ведет себя так же, как и старое API, которое пока еще в силе. Таким образом, вы можете ничего не менять, если не хотите этого. Однако, настоятельно рекомендуется использовать новые функции API вместо старых, которые основаны на erlang:now/0. В настоящее время erlang:now/0 помечен, как устаревший (deprecated), так как он является узким местом при масштабируемости. Используя новый API, вы автоматически улучшаете свойства маcштабируемости и производительность. Так же у вас появляется возможность использования режима мульти-разрывов (multi-time warp), что повышает точность измерения времени.
Платформа Erlang, использует не только часы реального времени, но и внутренний счетчик тактов процессора. Благодаря временной коррекции Erlang, приложениям гарантируется, что Erlang monotonic clock не имеют разрывов во времени и являются относительно точными. Для полного понимания работы временных систем, пожалуйста, направьте ваших инженеров к технической документации [1]. В ней даются понятия из нового временного API, такие, как: «монотонное время», «строго монотонное время», UT1, UTC. POSIX Time, Time Precision, Time Resolution, Time Accuracy, Time Warp, OS System Time, OS Monotonic Time, Erlang System Time, Erlang Monotonic Time и др. Описаны возможности получения как Erlang так и системного времени, даны инструкции по корректировке устаревшего программного кода.
Команда Erlang идет в ногу со временем, добро пожаловать в будущее!
Список использованных источников
1. http://erlang.org/doc/apps/erts/time_correction.html — Время и временная коррекция в Erlang
Комментарии (30)
slavait
04.08.2016 21:49+1Вообще-то все давно перешли на подпространнственную синхронизацию доступную из любой точки.
Внешние давно управляют системой, вопрос в том сколько они могут позволить себе затратить ресурсов для удержания контроля. Т.е. захват ресурсов первостепенная задача.
taulatin_one
04.08.2016 22:46+3Я давно подозревал, но видно при скачивании Erlang с официального сайта компания высылает всем новичкам дополнительные вещества для изучения?!
Sonichka
04.08.2016 23:01А давно у нас есть космичесая военная группировка?
UA3MQJ
04.08.2016 23:01+1На счет группировки — нет точных данных. Но Erlang к этому готов. Возможно, они что-то знают…
Stalker_RED
05.08.2016 04:28+2Великий вождь подумал о неравномерном времени заранее, пока военно-космический флот еще строится!
Milfgard
05.08.2016 18:39540 лет
Deosis
05.08.2016 07:47+1Если программисты строят велосипед, то планируют, что он будет летать в космос и погружаться на дно океана.
В языке учитываются такие моменты: https://habrahabr.ru/post/146109/ (оригинал http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time)?
Daniro_San
05.08.2016 08:49Я полетел дальше.
Мой корабль действует на кардинально иных физических принципах.
AstarothAst
05.08.2016 11:10Пока читал все надеялся, что внизу-таки найдется ссылка на гитхаб, а там — корабли, битвы, подпространство!.. Эх.
ArkturTierry
05.08.2016 11:14Вызывает интерес механизм синхронизации и алгоритм поддержания синхронизации кораблей, действующих в пределах одной звездной системы.
Как осуществляется передача сигнала точного времени, по какому физическому каналу? Ведь даже наша маленькая Солнечная система достаточно велика, чтобы задержка распространения информации от края до края измерялась в минутах.
Второй момент: корабли флота в пределах системы, выполняя боевые задачи, задачи патрулирования и разведки, могут двигаться с переменными, непредсказуемыми ускорениями и относительными скоростями. Соответственно будет накапливаться отставание/убегание внутреннего времени кораблей друг относительно друга. Есть ли алгоритм поддержания необходимой синхронизации и как он реализован?
Если необходима синхронизация с точностью до микросекунд, учитывает ли алгоритм влияние массивных объектов?
ПыСы. Да, видимо мы пользуемся с топикстартером услугами одного дилера.UA3MQJ
05.08.2016 11:59По вопросу 1: я предполагаю, что как и в наземных системах с GPS учитывается время прохождения сигнала от источника точного времени и происходит соответствующая корректировка.
По вопросу 2: корабли синхронизировать либо на источник точного времени, либо на корабль с более точным временем. На самом деле суть изменений ядра не в том, как синхронизировать время. Время в любом случае будет подводиться вперед или даже назад. Суть изменений в том, что созданы инструменты о том, как с этим жить. Системное время ОС является больше справочной информацией. По факту, каждый корабль живет на своей оси времени. Получая команды, он их все равно не сможет выполнить раньше, чем получил. При использовании системного времени напрямую, например для записи в бортовой журнал, может произойти «запись_1» в 10:00, а потом произойти корректировка системного времени и «запись_2» в 09:59. В случае использования Erlang, задача работает в среде, как в полноценной операционной системе, получая весь необходимый сервис(как например, распределение времени между задачами). Таким же образом Erlang обеспечивает и равномерность хода времени, если использовать не System Time, а Erlang Time. При небольших переводах времени, пользуясь Erlang Time, ход таймера времени будет либо немного замедляться, либо немного ускоряться, пока разница не будет устранена (этот момент сейчас пока что проверяется на стендах, в лабораторию должен подойти корабль для тестов). Но не смотря на переводы времени, Erlang имеет формат времени (который очевидно, содержит не только время, но и данные от счетчика тактов процессора). Этот формат поставит записи борт журнала «запись_1» и «запись_2» в правильном порядке, не смотря на перевод времени. Таким же образом, не испортится возможность ядра отмерять интервалы времени между событиями либо текущим временем. Если что-то нужно сделать через час, то переведя часы на 20 минут вперед, мы не уменьшим интервал времени до события.
По вопросу 3: синхронизация до микросекунд и вообще точность будет зависеть от плотности группировки (разнице прохождения сигнала и точности дальномеров для корректировки). Но это только если работать в одном таймлайне. Еще важный момент, в каком режиме корабли будут выполнять команды флагмана: а) по получению команды сразу; б) полученную команду выполнять по наступлению какого-то времени или события. Тут надо обсуждать с капитанами особенности руководства.
По вопросу 4: влияние массивных объектов пока не учитывается, но у нас уже имеется модель сферического алгоритма массивного объекта в вакууме…ArkturTierry
05.08.2016 16:02Спасибо за развернутый ответ.
Однако, большая часть вопросов осталась нерешенной:
1. Какой физический канал передачи данных в условиях чужой звездной системы? (Вопрос активного противодействия средствами РЭБ противника пока не учитываем). Оптический канал связи или радио-диапазон? Синхронизация точка-точка или передача в эфире «всем кто меня слышит»? Учитывается ли особенность распространения сигнала в среде? Возможность приема переотраженного сигнала, вносящей ошибку синхронизации, timedelay при прохождении газовых облаков?
2. Для боевого маневрирования категорически важно иметь полную синхронность часов всех сил и средств при выполнении боевой задачи, вне зависимости от типа управления -непосредственными командами или по заранее разработанному плану. Например, выход в расчетную точку, расчет тормозного импульса или импульса ускорения, одновременность удара (и фокусировки), донесений от службы дальнего обнаружения противника, средств наведения и корректировки огня. Для последних точность до микросекунд представляется минимально допустимой. При движении флотов с высокими относительными скоростями, ошибка даже в 1 микросекунду ведет к промаху. Так же критически важна синхронизация, например, при залповой ракетной стрельбе, когда часть ракет первой волны служит для преодоления противоракетной обороны противника. Несвоевременность старта ракет, несинхронное маневрирование, несвоевременный подрыв боеголовок могут означать срыв боевой задачи.UA3MQJ
05.08.2016 16:56Есть варианты. В любительском радио все тежнологии уже отработаны (не говоря о профессиональном).
Если использовать коротковолновые передатчики, то чаще всего из за размеров антенн, передача не имеет очень острой направленности. В этом случае получится «общая шина» и каждая передача по сути броадкаст.
Диаграммы направленности
ArkturTierry
05.08.2016 17:33ОК, по поводу физического канала понял. Но есть нюанс, о котором я пытался спросить -как можно быть уверенным в достоверности синхроимпульса, если мы не можем гарантировать однородность и предсказуемость свойств среды, через которую пролегает трек сигнала?
Примеры: гравитационные искажения времени на корабле-носителе базового времени (НБВ), приход сигнала через газовое облако с замедлением времени прохождения. Переотражение сигнала, увеличивающее длину трека. Ведь даже в пределах Солнечной системы, если, например, корабль НБВ находится у Солнца в районе орбиты Меркурия, а принимающий -на орбите у Земли, то мы не можем ничего сказать, будет ли пришедший радиосигнал носителем достоверного сигнала точного времени, поскольку ничего не знаем о треке, скорости движения источника сигнала и гравитационных условий в месте излучения. Причем «недостоверность» может достигать секунд! Например, если сигнал пришел к нам не прямой, а отраженным от поверхности Луны, да еще и прошедшим через кометный след. Возможно, часть этих проблем можно решить разнесенным приемом, часть протоколом передачи, где будет указываться скорость и местоположение НБВ относительно центрального светила. Но всех проблем эти меры не решат, они несколько повысят достоверность, но оставят высоким уровень погрешности.
Вот о возможных мерах борьбы с недостоверностью и протоколах передачи я и хотел услышать))UA3MQJ
05.08.2016 18:35Вот о возможных мерах борьбы с недостоверностью и протоколах передачи я и хотел услышать))
Я же говорю: в AX.25 есть CRC. Тип передачи AFSK. Единица и ноль кодируются разными частотами. Переотражения, временные искажения приведут к ошибкам декодирования отдельных бит, контрольная сумма не сойдется, пакет будет отброшен. Но это для автоматической работы.
В случаях с BPSK31 будут теряться символы, будет мусор. Но это работа с дальними рубежами. Их могут операторы принимать, если техника не справится.
При передаче в SSTV появятся «помехи» в картинке
ArkturTierry
08.08.2016 14:50Мне кажется мы говорим о сильно разном. Проблема не в достоверности сообщения (которую можно восстановить сверточным кодированием, сложными кодами с восстановлением ошибки или разнесением передачи по каналам). Проблема в достоверности времени приема, ведь сигнал точного времени это не только сигнал с содержащейся в нём информацией, но и именно момент времени, та микросекунда его приема, грубо говоря передний или задний фронт импульса, по которому мы считаем, что вот оно, время.
И если все сообщение принято корректно, но время прохождения импульса по тракту -неправильное, или время на разных кораблях вследствие разности скоростей, с которыми они двигались с момента последней синхронизации разошлось, то это убивает весь смысл синхронизации на корню. Это в пределах Земли эта проблема легко решается (все тракты заранее известны, относительные скорости объектов, ведущих к искажению течения ИХ внутреннего времени ничтожны). В масштабах звездных систем это уже не так, почему -я уже писал.UA3MQJ
08.08.2016 15:47Теперь точно придется писать свою Eve/Elite чтобы это дело симулировать проверить.
HDDimon
05.08.2016 13:16А lager уже переехал на новое API?
UA3MQJ
05.08.2016 13:51Судя по коду, да.
На сколько я знаю, в Erlang есть правило, что deprecated функционал будет доступен до следующего релиза. То есть erlang:now() был нормой до 17 версии, в 18 объявлен deprecated, и только в 19 его не будет совсем.
Интересно, что Elixir поверх Erlang 18 уже ругается warning'ами на эту функцию.
padla2k
05.08.2016 15:30С каких пор вычислительные кластеры работают без внятной синхронизации времени? =)))
spmbt
В самом же деле, что делать, как обороняться, если пришельцы выберут тактику нападения с разных направлений из соседних звёздных систем? Тогда каждый кластер обороны будет знать о нападении лишь части армии, а нападающие уже заранее согласовали план о направлении главного удара? Может быть, нам надо сделать передовую линию обороны на дальних подступах, в а.е. 300 примерно? Давайте подумаем о перестройке всей стратегии обороны ресурсов.
Но что, если они уже тут, а мы в зоопарке в обезьяньей клетке, в которой нам дадут развиваться до некоторых пределов, а потом ограничат, потому что ресурсы всем нужны, а сильным — нужнее? Тогда надо побольше урвать ресурсов у окружающих, пока те внешние нас всех не остановят. И ведь не просто так, а ради высокой цели, мобилизовать всех на защиту всей цивилизации и её будущего.
TimsTims
Я вас умоляю :) Если пришельцы захотят нас уничтожить — им проще будет натравить людей самих на себя, либо сымитировать ядерное нападение. Человечество само себя уничтожит.
Milfgard
Логика расширяющегося сектора подсказывает, что линию обороны надо выносить на точки исходящей агрессии. То есть в столицу пришельцев. Или что там у них.