Все идеи и алгоритмы, описываемые в данной статье, являются результатом моей независимой и полностью самостоятельной интеллектуальной деятельности. Как автор, разрешаю свободно использовать, изменять, дополнять все идеи и алгоритмы любому человеку или организации в любых типах проектов при обязательном указании моего авторства.
© Балыбердин Андрей Леонидович 2019 Rutel@Mail.ru
Синхронная Символьная Иерархия
Принципы управления виртуальными каналами
(создание, удаление, изменение скорости)
Современные телекоммуникации разделены на два основных типа синхронные (SDR и прочее) и асинхронные (IP и другие пакетные сети).
Синхронные сети требуют достаточно большого времени на создание нового соединения, обеспечивают постоянство скорости и задержек передачи. Есть возможность задействовать практически всю полосу физического канала. Отсутствует взаимное влияние виртуальных каналов и нет потерь данных из-за переполнения буферов. Синхронные сети отличает достаточно простая схемотехника.
Асинхронные сети в противоположность не требуют никаких действий по установлении соединения (отправил пакет и все), но такой подход не позволяет использовать больше половины физической пропускной способности сети и присутствует сильное взаимное влияние различных абонентов порой приводящее к существенной потере скорости и данных (после загрузки канала в 75% КПД использования канала падает практически до нуля). Требуют наличия в коммутаторе буферов достаточно большого объема, что становится проблемой при больших скоростях передачи.
ССИ в своей основе является синхронной сетью, при этом она избавлена от основных недостатков присущих синхронным сетям. Основным плюсом является механизм быстрого создания виртуального канала, не требующий предварительного уведомления соседнего коммутатора. Это порождает некоторую асинхронность сети на уровне доступа. В момент прохождения одного из промежуточных коммутаторов может выясниться, что создание виртуального канала невозможно из-за отсутствия пропускной способности. В современных сетях загрузка изменяется быстрее чем распространяется информация о изменениях. В целом ССИ можно охарактеризовать как систему с асинхронной передачей короткого запроса создания виртуального канала и синхронной передачей основных данных.
Для создания нового виртуального канала необходимо получить информацию о возможных маршрутах, последовательности промежуточных коммутаторов и их физических каналов. Данная информация может задаваться как константа, так и получаться от какой либо сетевой службы. Эту информацию необходимо получить заранее.
Этап непосредственного создания виртуального канала не требует дополнительного времени..
Последовательность создания нового виртуального канала.
Физический канал в сетях ССИ разделяется на отдельные виртуальные каналы с помощью алгоритма описываемого в «ССИ_Коммутатор синхронных потоков (3)». Символы разделены на две основных группы служебные (интерпретируются коммутатором) и пользовательские (интерпретируются пользователями и промежуточными модулями виртуальных каналов).
Физический канал разбит на два потока служебный и пользовательский. При создании нового канала, необходимая пропускная способность отбирается от служебного потока. Служебный канал не разбивается на отдельные виртуальные каналы и является единым потоком имеющим синхронную и асинхронную составляющую (не используемую пользователями пропускную способность).
Возможность создания виртуального канала есть только если есть не распределенные тайм-слоты (синхронная составляющая) и есть свободный модуль виртуального канала. Модуль виртуального канала, достаточно простое устройство и микросхемы построенные по современным технологически нормам могут содержать сотни тысяч таких модулей.
Для создания нового виртуального канала необходимо поместить в служебный поток символы с запросом, содержащим требуемую скорость и маршрут.
В момент приема символов с этим запросом, УУ коммутатора выделяет запрошенную часть физического канала (на прием и на передачу) и один из свободных модулей виртуального канала, а также транслирует символы запроса в служебный канал затребованного коммутатора. Если предоставить затребованную производительность невозможно, то запрос отбрасывается. Механизмов удаления таких обрезков может быть много, передать служебное сообщение предыдущему коммутатору является наиболее оптимальным. При обработке запроса, от маршрута «отрезается» использованная часть и в момент исчерпания данных маршрута считается, что цель достигнута, канал построен и запрос удаляется. Относительная маршрутизация не требует слишком сложного УУ коммутатора. Отмечу, что полоса служебного потока (при удачном выделении полосы) всегда больше чем скорость виртуального потока, соответственно запрос «пробежит» маршрут виртуального канала быстрее чем данные для этого канала, значит данные можно передавать сразу за запросом (без паузы). Удаление канала инициируется пользовательским символом закрыть канал, при его отправки передатчиком все использованные ресурсы освобождаются. Для противодействия накапливания «мусора» следует ограничить время «жизни» канала.
Изменение скорости уже созданного виртуального канала.
Пропускная способность виртуального канала определяется числом последовательных комбинаций циклического счетчика символов (ССИ_Синхронный поток_Фрагментация потока (2)). Каждый новый канал создается добавлением в конец выделенной области нового резерва.
В процессе удаления виртуального канала все модули виртуального канала с большим чем у удаляемого значением счетчика, производят вычитание числа тайм-слотов (скорости удаляемого потока) из своего диапазона комбинаций счетчика. Был диапазон N до N+скорость канала, стало N - скорость удаляемого до N+ скорость канала - скорость удаляемого канала. В результате выделенная область становится монолитной (противодействие фрагментации). Алгоритм изменение скорости выглядит примерно также, но без удаления канала. Простое изменение границы начиная с некоторого значения комбинаций счетчиков.
Все эти операции возможно проделать за один такт и они не содержат логических цепочек неконтролируемого размера.
Конкретные алгоритмы создания, удаления, переноса и других действий над виртуальными каналами должны быть проработаны в момент создания стандарта ССИ.
Задачи для НИР:
1. Как влияют процессы удаления и изменения скорости виртуальных каналов на синхронность потоков в соседних каналах (где редактирование не происходит). Иными словами: Как влияет перемещение виртуального канала в диапазоне значений циклического счетчика символов ?
Комментарии
что за глупость написана? Вам показать линки на 1/10/100 гигабит работающие в полку? С чего вдруг они не позволяют использовать полосу, только потому что вам не нравится пакетная передача?
какое влияние могут оказать абоненты на линию связи? Она что, уменьшает полосу пропускания? Что значит "КПД использования"? Где есть описание сего термина?
Буферы передачи вообще не нужны, если вы готовы терять данные при перегрузке канала, и да, на жирных линках всё больше оборудования без store and forward, ибо это просто глупо. А там где соска небольшая можно и забуфферизировать, чтоб абону было мягко. Накаких проблем никакие буферы у производителей коммутаторов не вызывают.
https://ieeexplore.ieee.org/book/5236680 ознакомьтесь с проф.литературой и постарайтесь больше не болтать ерундой.
"что за глупость написана? Вам показать линки на 1/10/100 гигабит работающие в полку? С чего вдруг они не позволяют использовать полосу, только потому что вам не нравится пакетная передача?"
Давайте попробуем включить мозг.
Когда никто не мешает (не пытается одновременно передавать), источник данных и приемник данных находятся рядом, передается большой объем данных в рамках одной сессии, ну и скорость канала не очень большая. Одним словом тепличные или полигонные условия.
Попробуем представить работу коммутатора уровнем несколько выше, чем коммутатор доступа. В данном случае ничто не запрещает в целом случайный прием пакетов по любому из физических портов. Соответственно есть некоторая вероятность что число пакетов требующих коммутации в какой то конкретный физический порт будет больше его пропускной способности. Данную ситуацию сглаживает наличие буфера, но это только уменьшает вероятность возникновения перегрузки. В таких случаях происходит отбрасывание пакета. Что происходит дальше : происходит повторная отправка потерянных данных - это как раз и есть "влияние абонентов на линию связи". При увеличении производительности канала требуется все большие значения буферной памяти.
Например коммутатор видит переполнение буфера, что он сделает: "попросит" предыдущий коммутатор уменьшить поток, но ему нужно суметь поглотить весь трафик который будет принят до момента срабатывания этого механизма. Для высоких скоростей это проблема.
И когда наступает момент, что производительности пакетной сети не хватает даже на повторную передачу потерянных данных : проблема начинается с 41% загрузки каналов и при 75% приводит практически к полному параличу.
Для компенсации данных проблем (скорее для размазывания проблемы равномерно по всем пользователям) в TCP создано много различных алгоритмов, но это только костыли и они сломаются при переходе на скорости в 1Т и более.
Если не верите, то посмотрите какие трудности вызывает передача голосового трафика по IP сетям. При этом не смотря на все усилия звук так и заикается и пропадает, тоже самое можно сказать про видео (там где нельзя допускать буферизации - конференции).
Хочу особенно выделить : ССИ в первую очередь предназначена для сетей связи в рамках суперкомпьютеров, где требуются времена коммутации в единицы наносекунд, скорости передачи 1Т-100Т на порт, точно известная и неизменная задержка, точно известная и конфигурируемая скорость передачи данных, полное отсутствие отбрасывания данных (потери определяется только шумами в тракте передачи). И все это при загрузке физических каналов больше 90% и огромном числе соединений (в большинстве своем требующих быстрой передачи всего нескольких символов данных), машина для которой предназначена сеть должна работать по принципам DataFlow/
Мое мнение по поводу IP сетей: Они уступят лидерство ССИ по той причине -А зачем нужно более дорогое и менее эффективное решение, которое к тому же может быть прозрачно эмулировано сетью следующего поколения.
PS Если IP так хороши, то почему их не применяют в магистральных сетях, зачем нужны всякие OTN SDR и прочее ?
нажимайте пожалуйста кнопку цитирования, так любая тырнет беседа становится немного удобнее
этот пассаж оторван от контекста, непонятно для чего он написан. Нужно представить такую ситуацию? Или обратную?
так, один из портов у нас перегружен...
во первых коммутаторы бывают не только store and forward. Отталкиваемся от того, что при перегрузке (и линии и буфера) у нас пакет сброшен. Хорошо...
он может ничего не просить, тут уж каждый закладавается либо на стандарты контроля перегрузки, либо на пропиетарь либо тупо сбрасываем. Влияние на источник данных мы можем осуществять или нет, много опций...
так, мы подошли наконец к каким-то данным. Вопрос: откуда эти данные у вас? С чего вдруг переполнение линии связи приводит к такой деградации? Откуда берётся паралич? Вы исключительно теоретик или тестировали какие-то протоколы перегрузки на уровне l2/l3? Какие? Какая методика? Мат аппарат? Почему ваши выводы не сходятся с моими практическими знаниями и опытом?
Категорически заявляю, что хоть 1, хоть 10, хоть 100гиговыйй порт линии пакетной передачи данных (ethernet) выходя на полку не становится свободен, он остаётся занят полностью. Количество потеряных пакетов при этом естественно растёт, если коммутатор не съел весь буфер имеем рваный rtt (round trip time)
да, tcp сложно и congestion control алгоритмов в том-же Linux вагон и маленькая тележка, только реализация ip стэка конкретной OS уходит далеко мимо озвученной темы.
от чего-ж не верить, для real-time трафика придуманы разные протоколы резервирования гарантированной полосы и на уровне metro-ethernet с этим проблем нет, а большой тырнет... ну, да, никто не гарантирует передачу без потерь. Но на уровне обычного провайдера нет проблемы откусить часть линка для real-time задач. А иметь перегруженый uplink, для нормального оператора это моветон, если не считать аварийных ситуаций. Когда вы говорите что нельзя допускать буферизации для конференций нужно описывать все условия. Буферы уровня коммутатора на видео-конференцию не влияют вообше никак, ибо поток просто огромен, контроль досылки и/или коррекции потока обычно зашит внутрь протоколов l7. Короче, такие категоричные заявления без конкретики не имеют основания.
моя претензия к вам в том, что описывая синхронные линии связи и ваши придумки поверх них, вы обозначаете архитектурные особенности пакетной сети как минусы. Они такими не являются. Всё именно так и задумано и работает. Потери пакетов это лучше, чем описаные вами невозможность зарезервировать (суб)канал внутри синхронной линии. Для суперкомпьютеров вообще-то уже есть масса протоколов, начиная от inifiband с rdma для вычислений до всяких там fiberchannel для данных.
о дороговизне можно рассуждать когда описаные вами задумки появятся в железе, а я как "пакетчик" уже сейчас могу покупать и эксплуатировать оборудование с задержками порт-порт в районе сотен наносекунд и полосой от 10G до 400G. см. Arista.
что в данном случае магистральнаяя сеть? Межконтенентальная? Межгородская? Межрайонная? Пакетные сети есть любые из вышеперечисленных. А всякие странные синхронные нужны для редких задач. Из последнего что вспоминается это высокочастотный трейдинг, да и то, там все переехали на озвученую выше Arista, т.к. задержки минимум.
P.S. Если-бы не ваши голословные утверждения об деградации канала и уменьшении его ёмкости смысла писать небыло-бы вовсе.
P.P.S.
https://www.maltsystem.ru/images/book/AppE.pdf про задержки и взаимовлияние частично есть здесь.
Да согласен : Баг к которому привыкли называется фича )))
Пакетная сеть обладает некоторыми врожденными минусами (надеюсь Вы не считаете их плюсами ?), которые делают не эффективным ее использование в высокопроизводительных системах.
Только народ очень переживает и пытается изобретать программно управляемые сети и тд.
Для высокопроизводительных систем это слишком медленно - Степень распараллеливания задачи пропорциональна корню квадратному от времени исполнения задачи на одном процессоре к времени затрачиваемому на коммуникации. Иными словами, чем больше задержки передачи тем меньшее число параллельных процессов можно запустить.
Время коммутации в сотни наносекунд - это драматически медленно и не позволяет реализовать технологию дезагрегации оперативной памяти (выделить оперативную память в виде отдельного аппаратного устройства как сделано для дисков). Современные RDMA больше чем на порядок отстают по производительности от установленной DDR.
Cейчас 10G это домашняя сеть.
Про магистральные коммутаторы - воспринимаю как демогогию.
Ладно, на вкус и цвет все фломастеры разные.
Вы вот скажите, заметили ли вы в описаниях сети логические ошибки не позволяющие сети функционировать или существенно ограничивающие ее применимость?
Вы смогли понять принципы на которых она функционирует?
ПС Если нужно транслировать пакетный трафик (через сеть ССИ), то самый простой способ : достаточно в начале пакета добавить запрос на создание виртуального канала , в конце запрос на закрытие. Если пакетов много, то создать (периодически изменяя структуру и скорости) сеть из виртуальных каналов и помещать пакеты в нужные потоки в зависимости от требуемого направления и приоритетов. Получится что то типа распределенного коммутатора.
Нашел интересное высказываение
Ломать уже сложившиеся стереотипы мышления особенно у взрослых людей - это дело чрезвычайной сложности. Потому вражда с текущей научной парадигмой - это отдельная задача, которую должны решать не учёные-физики. Это вопрос скорее психологический.