Разбиваем один из мифов о спутниковой сети StarLink Элона Маска

vsatman888 — 02.07.2020 Глобальную сеть спутниковой связи СтарЛинк, создаваемую Элоном Маском сопровождают несколько мифов.
В последнее время в сети появилось несколько роликов, посвященных StarLink в которых  авторы радостно информируют зрителя, о том что Старлинк сможет обеспечить более быструю передачу данных, чем существующие  ВОЛС, и что за счет этого, Брокеры ,Банкиры и финансисты , торгующие  из США на биржах Лондона (и наоборот) просто озолотят Элона Маска  за право воспользоваться его сверхбыстрым каналом и получить возможность на 1..10 миллисекунд раньше нажимать на кнопуи отвечающие за покупку или продажу акций ценой в миллионы и сотни миллионов длларов .
  .
К сожалению для Спейс Х и авторов рекламных  Роликов на ютуб (иногда носящих достаточно звучные титулы в области телекоммуникаций)  это полная чепуха ...


Вот для примера подобный ролик, об этом где то после 9 й минуты


или еще один


Авторы базируют свою теорию о преимуществе СтарЛинка в скорости передачи на том основании , что скорость света в вакууме на 30% выше, чем в оптическом канале. Обратим там внимание на пару кадров



 А это самый скоростной  кабель, специально проложенных для биржевых брокеров



Время передачи для оптики указано верно. А вот для СтарЛинка - нет!!!  Но запомним речь идет буквально о преимуществе в 20..25 миллисекунд!

Вот 2 типичных варианта, которые я видел в роликах , раскрывающих  возможности сверхбыстрого канала, якобы имеющиеся у СтарЛинк

Первый  с использование Гейтвеев когда Один терминал передает информацию на  через Гейтвей



Здесь самое большое заблуждение,что ИСЗ будет работать не через самый ближний к нему  Гейтвей , то есть тот который находится как можно бдлиже к надиру ИСЗ,   и имеет  самый большой угол места, а система будет выбирать тот Гейтвей до которого можно дотянуться на пределе Зоны покрытия. Увы, при  этом угол места  будет минимальным, а потери в атмосфере  максимальными, и эффективность в отношении скорости на  терминале из за этого минимальными.

Второе, что забыл указать автор сего Ролика и это говорит о его НЕПОНИМАНИИ архитектуры сети СтарЛинк, это то, что  сигнал от ИСЗ 1 приходит на одну Антенну Гейтвея, работающую с ИСЗ 1,   там полностью демодулируется и преобразуется в IP и в самом идеальном случае тут же должен быть снова отмаршрутизирован  на соседнюю Антенну того же Гейтвея, работающий с ИСЗ 2 . При этом между Гейтвей 1 и 2 должен стоять отдельный маршрутизатор , который  будет обрабатывать  трафик (в обычной ситуации такой маршрутизатор должен стоять  в точке обмена трафиком сети СтарЛинк с другими Провайдерами Интернета в США или в центре управления сетью СтарЛинка). То есть по сути вместо одного центра управления сетью для такого маршрута как на картинке будут нужны независимые миниЦУПы в каждом Гейтвее.  Но в любом случае , маршрутизировать мы можем только IP пакеты , а не радиоволны и весь трафик должен быть  из радиосигнала преобразован в IP пакеты

Следующая интересная  картинка говорит о том прекрасном времени, когда ИСЗ СтарЛинк получит  межспутниковые каналы и выглядит так :



Что ж   видеоролик,  как и бумага все стерпит.. Но мне бы хотелось понять немножко технических деталей,  итак IP  пакет  на абонентском терминале был преобразован в радиосигнал, имеющие конкретную модуляцию, поляризацию и частоту, достиг ИСЗ ,  сейчас этот IP пакет пересылается  вниз на гейтвей  ни о чем не задумываясь   без какой либо обработки на борту, кроме изменения частот  и модуляции в радиотехническом комплексе ИСЗ (на борту меняется частота,  и возможно поляризация и модуляция,  что так же стоит нам нескольких миллисекунд)) .

В описанном выше случае, нам надо понять, а куда надо гнать этот пакет, то есть  его надо раскрыть , докопаться до IP определить, что Пакет надо переслать именно в Лондон, дать команду на систему наведения  антенны межспутниковой связи установить соединение между ИСЗ и передать  сигнал на других частотах, модуляциях и поляризациях..

При этом данный маршрутизатор , должен управлять некоей внутренней орбитальной сетью  СтарЛинка , точно знать положение всех ИСЗ и периодически принимать рещение какой маршрут будет оптимальным и что делать антенне лазерного канала, если одновременно пришедшие 2 пакета  требуют передачи их на разные ИСЗ??

И ГЛАВНОЕ  авторы роликов упорно отрицают (или не показывают) существование так называемой "аппаратной задержки", то есть времени которое тратится в каналообразующем оборудовании  (спутниковом модеме МоДем от Модулятор-Демодулятор)) на модуляцию и демодуляцию  Ip пакета в радиоволну и в маршутизаторе на  обработку и маршрутизацию  IP пакета . А это не Ноль, это реальные миллисекунды:

//Спутники на геостационарной орбите отлично работают в сетях радио- и телевизионного вещания, где задержка 270 мс в каждом направлении не сказывается на качественных характеристиках сигналов. Системы персональной радиотелефонной связи (см. рисунок) более чувствительны к столь длительным задержкам, которые реально (в одном направлении связи) могут составить около 320 мс (с учетом времени на обработку сигнала в кодере или декодере — 50 мс).

и если мы , посчитаем, что аппаратная задержка для одного этапа  из IP в радиоволну займет хотя бы 10 раз меньше времени это будет все равно 5 миллисекунд, а из  радиосигнала на волне Х1 с модуляцией Y1 в  радиосигнал на волне Х2 с модуляцией Y2,  хотя бы в 3 миллисекунды, то все прекрасная картинка  из этого рекламного ролика накроется медным тазом.

Есть еще  параметры, которые обозначают задержки при передаче данных:
Задержка сериализации (serialization delay) это время,  которое необходимо интерфейсу чтобы переместить биты информации в канал передачи. Это фиксированное значение, которое является функцией от скорости интерфейса;
Задержка обработки и очереди в рамках маршрутизатора.

Они безусловно малы, но эти задержки накапливаются при прохождении трафика по сети с несколькрими узлами и чем больше будет узлов (то есть спутников СтарЛинк или Гейтвее на пути) тем больше в  итоге будет задержка

И last but not least..  Есть  в телекоммуникациях такая штука, характеризующая сеть (канал) передачи данных,  как Джиттер:
джиттером также называется изменение задержки пакетов. Это относится к разнице во времени задержки в миллисекундах (мс) между пакетами данных по сети. Обычно это нарушение нормальной последовательности отправки пакетов данных. Это также означает, что задержка при передаче пакетов по сети колеблется. Уровень задержки на протяжении всего транзита будет колебаться и может привести к задержке передачи пакетов в 50 миллисекунд.

Указанные 50 миллисекунд является сейчас предельной величиной , когда  Корпоративные Клиенты готовы использовать такой канал в своих сетях. Идеальные каналы, это те,  где минимум транзитных узлов, постоянный маршрут (=длина канала)  и имеют существенно меньший джиттер.

Так вот предлагаемая профессорами в этих рекламных роликах модель канала связи между биржами через СтарЛинк  будет  кошмаром для всех тех, кто будет управлять  клиентскими серверами и ПО на концах  канала через СтарЛинк, ибо за счет постоянного изменения положения ИСЗ между собой время передачи будет постоянно меняться  и настроить работу серверов на конце канала будет архисложно, и я практически гарантирую, что администраторы сетей потребуют от  Провайдера канала , чтобы джиттер был близок к тому, что он есть в канале со стабильной длиной и минимальным количеством узлов обработки трафика, то есть в Волоконно оптическом канале связи..

Таким образом, несмотря на красивые картинки, шансы на то, что канал связи , организованный через сеть СтарЛинк будет быстрее  оптического кабеля между этим точками , равны нулю и  рассказы об этом являются мифом ...



P.S. Уважаемые Читатели , автор сего поста крайне заинтересован понять ценность для Вас этих его «многабукофф». Для чего, если Вас это не затруднит, просит Вас френдить .его ЖЖ и/или нажимать на кнопочку "понравилось" в старой версии ЖЖ она  вверху  Это поможет Автору понять запросы  Аудитории и улучшить свои посты .Конечно, прямая критика, что не так, всячески приветствуется.

Оставить комментарий

Популярные посты:

• Ранее
• Архив