ССИ_Ethernet поверх синхронной сети (9)

Аватар пользователя Rutel

Все идеи и алгоритмы, описываемые в данной статье, являются результатом моей независимой и полностью самостоятельной интеллектуальной деятельности. Как автор, разрешаю свободно использовать, изменять, дополнять все идеи и алгоритмы любому человеку или организации в любых типах проектов при обязательном указании моего авторства.

© Балыбердин Андрей Леонидович 2019 Rutel@Mail.ru

 

Синхронная Символьная Иерархия Ethernet поверх синхронной сети

 

Предположим, что ССИ превосходит все существующие на данный момент сети передачи данных.

Как внедрять новую сеть?

Если попытаться «силовым» методом внедрять новую сеть на практике, то ничего не выйдет. Пользователи и производители скажут: «Да, новая сеть хороша, но и уже существующие худо-бедно выполняют свои функции и менять ничего не будем». Прецеденты такого поведения есть даже при внедрении минимальных изменений. Сеть IP V6 очень похожа на IP V4, но за 26 лет от момента своего создания доля ее трафика только только превысила 30% (в среднем по миру согласно исследованиям компании GOOGLE).

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

Что делать?

Считаю, что необходимо внедрять новые технологии посредством метода «Троянского коня». Новое устройство проектировать так, что бы в окружении «старого» оборудования оно полностью соответствовало старым протоколам. В случае если два и более новых устройства напрямую соединены кабелем, они превращаются в часть сети ССИ. При этом соединения со старыми протоколами остаются неизменными.

В чем плюсы такого подхода для пользователя: Нет необходимости сразу заменять работающее оборудование на новое и при этом постепенно растет качество предоставляемых услуг (скорость, вероятность потери данных, задержки передачи и тд). Конечный пользователь не почувствует никаких отрицательных последствий перехода с одной технологии связи на другую, просто однажды «проснется» и обнаружит что старой сети нет.

В чем плюсы такого подхода для производителя оборудования:

  • Нет необходимости в резком переходе на новые сети передачи данных.

  • Нет необходимости одновременно поддерживать старую и новую линейку оборудования, замена модельного ряда происходит постепенно.

  • Нет риска потерять покупателя из-за ошибок в проектировании нового устройства (всегда есть возможность продать старое устройство).

  • Поскольку старые протоколы реализуются посредством виртуализации (эмуляции средствами ССИ и DataFlow), то это не вызывает значимого удорожания проектируемого устройства.

  • За счет большей эффективности сети ССИ возможно произойдет существенное удешевление ЭКБ используемой при проектировании, это «почистит» рынок от излишне «тяжелых» решений и ускорит переход на новую технологию связи.

  • Самое главное у производителей, которые ранее не могли создавать свои микроэлектронные решения (отставание в технологиях, патентные препоны и тд) появится возможность догнать лидеров рынка.

  • С большой вероятностью ССИ станет основой нового интерфейса процессоров, уйдет разнородный медный и заменится на оптический сетевой. В настоящее время многие вопросы будущего интерфейса уже освещены (описано в статье: ССИ_Дезагрегация оперативной памяти (6)).

Примерная реализации данного оборудования.

Преобразование асинхронного трафика в синхронный.

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

Алгоритм обработки (преобразования) заголовков пакетов.

В отличии от синхронного канала, привязанного к конкретным приемнику и передатчику, асинхронный пакетный канал нуждается в маршрутизации каждого пакета индивидуально. Другими словами, необходимо анализировать заголовок каждого канала и направлять его в «свой» виртуальный канал. Физический уровень канала является общим для старой и новой сети, до момента интерфейса потока символов. Новая аппаратура должна реализовывать, в дополнению к стандартной для ССИ обработке потока, протокол обслуживания старой сети с интерфейсом к коммутатору ССИ.

В момент выделения (приема) заголовка, необходимо активизировать механизм его обработки. Для простоты будем предполагать что он реализован в виде логической схемы. Базовый для ССИ алгоритм очень простой и практически не увеличивает стоимость микросхемы при работе только в старой сети. Поскольку заголовок пакета принимается относительно редко и при условии быстрой обработки (за один такт или конвейер), такое устройство может быть в единственном экземпляре для всех каналов IP V4. Результатом обработки будут изменения в заголовке пакета (если необходимо) и перенаправление его в нужный виртуальный канал, связывающий данный порт с адресатом.

Эффект от применения сети ССИ

Пока сеть ССИ не вышла за пределы кристалла особого внешнего эффекта нет и ее можно рассматривать как некоторую внутреннюю структуру или набор правил проектирования. Если появилось два или более устройств напрямую связанных между собой физическим каналом, то начинают появляться плюсы использования новой сети. В сети ССИ нет прямого взаимного влияния пользовательских потоков друг на друга, нельзя резким возрастанием скорости «задавить» трафик другого пользователя (переполнить буфера коммутатора). Время доставки и скорость становятся стабильными, а значит такие приложений как голосовое общение, видео будут работать стабильнее. По мере нарастания процента нового оборудования, эти эффекты будут проявлять во все большей степени, причем наибольшее влияние будет оказывать именно операторская его часть.

Регулирование пропускной способности всей совокупности виртуальных каналов

В условиях одного или нескольких рядом расположенных кристаллов, еще есть возможность мгновенного арбитража (перераспределения ресурсов), то в для больших систем это принципиально невозможно. В них время сбора данных о загруженности отдельных физических линий, выработки решений и рассылки команд сильно отстает от развития текущей ситуации. К моменту реакции на перегрузку, она может закончиться по причине исчерпания быстрого и краткосрочного трафика. Перераспределение пропускной способности в большой сети происходит с неизбежной задержкой, обусловленной временем передачи информации по физическим линиям связи. В обычных асинхронных (Ethernet) коммутаторах пульсации трафика могут привести к переполнению буферов, потерям пакетов и существенному увеличению времени передачи пакетов. В ССИ сети резкие пульсации приводят только к краткосрочному проседанию КПД использования имеющихся ресурсов (нет мгновенного нарастания скорости передачи данных). Для пользователя такая реакция сети выгоднее, лучше иметь пусть и не самую большую, но гарантированную мгновенную эффективную скорость передачи данных (есть исследования на эту тему). Проекты глобального управления трафиком в IP сети тоже есть (SDN), но использование выделенных серверов для построения маршрутов не самое лучшее решение. Наиболее оптимальным будет принятие решений на уровне каждого коммутатора отдельно, без необходимости отдельной передачи запросов между ними. Необходимо разделить всю систему управления трафиком на два уровня. На нижнем будет перераспределение пропускной способности между уже существующими виртуальными каналами, на верхнем принятие решения о создании дополнительных виртуальных каналов. Нижний уровень должен функционировать без отдельного протокола взаимодействия коммутаторов между собой, только опосредованно.

Примерный алгоритм регулирования скорости

В каждый канал ССИ (помимо полезной информации) добавлять служебные символы в теле которых кодировать «пожелания» приемника и передатчика о параметрах и типе данного конкретного виртуального канала (Пример: Хочу больше скорости, Хочу: Постоянную скорость на длительный срок и тд). Каждый промежуточный коммутатор самостоятельно воспринимает поток таких символов и вносит предварительные изменения, резервирует на некоторое время ресурс. При этом совсем не обязательно именно столько сколько запросили (возможно даже уменьшит). Далее ожидает от источника трафика сигнала на фиксацию изменений, если такого сигнала не поступило резерв снимается.

Пример:

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

Итог :

Пока устройство работает в окружении сетей использующих старые протоколы, оно ничем не отличается от своих «собратьев». Если появляется прямое соединение с устройством поддерживающим сеть ССИ, происходит их объединение в кластер сети ССИ. По мере роста размера такого кластера (объединения в другими) происходит улучшение качества обслуживания и в момент появления прямого соединения через сеть ССИ пользователь получает весь объем сервиса новой сети. Для аппаратуры это приводит к отключению модулей поддерживающих старые протоколы (до полного отключения питания). Если реализация старых протоколов производилась программным способом, то высвобождается еще и ресурс вычислителя.

Авторство: 
Авторская работа / переводика
Комментарий автора: 

Все идеи и алгоритмы, описываемые в данной статье, являются результатом моей независимой и полностью самостоятельной интеллектуальной деятельности. Как автор, разрешаю свободно использовать, изменять, дополнять все идеи и алгоритмы любому человеку или организации в любых типах проектов при обязательном указании моего авторства.

© Балыбердин Андрей Леонидович 2019 Rutel@Mail.ru

Комментарии

Аватар пользователя Александр Мичуринский

Если реализация старых протоколов производилась программным способом, то высвобождается еще и ресурс вычислителя.

В предложенном Вами алгоритме синхронной коммутации, как я понял, для каждого виртуального канала заводится свой инкрементируемый счетчик.  И на каждом такте для передачи очередного символа производится поиск минимума. Чтобы определить, откуда взять очередные данные в выходной поток.

Вы толком так и не ответили, как именно это будет происходить. По какой шине и с какой скоростью должны будут гоняться данные, чтобы вычислить этот минимум. Не будет ли Ваш алгоритм коммутации в результате более вычислительноёмким, чем  обычная коммутация пакетов?

И не является ли Ваш алгоритм синхронной коммутации по сути той же коммутацией пакетов? Только размер пакета - один символ, и предельно обрезаны заголовки. Как при этом будут работать процедуры восстановления после сбоев?

Аватар пользователя Rutel
Rutel(8 лет 7 месяцев)

для каждого виртуального канала заводится свой инкрементируемый счетчик

Там есть лучший алгоритм (описан вторым), в нем есть один счетчик для каждого физического канала, по кругу (с периодом от 0.001 - 1 сек) считает поступающие символы.

Есть исходный физический поток, передает символы и два счетчика на приемнике и передатчике считают символы.

Счетчик на передатчике и на приемнике синхронизированы (один и тот же символ на передающей и на приемной стороне имеют одинаковый номер).

Счетчик символов используется для разделения физического канала на части (виртуальные каналы с произвольной скоростью).

При приеме каждому символу  соспоставляется текущее значение счетчика, прикрепляется как адрес (в физический канал счетчик не передается - нет смысла счетчики синхронны).

Далее пара передается в коммутатор (набор небольших FIFO), каждое FIFO имеет свой диапазон адресов и при приеме каждого символа сравнивает свой диапазон адресов с перевернутым (младшие биты поменямы со старшими) значением счетчика.

При совпадении данный символ записывается в FIFO.

Тоже саме происходит и при передаче, только там берется значение счетчика и по нему происходит выборка из FIFO.

 

Для регулирования скорости в диапазоне значений счетчика (не перевернутом) выделяется непрерывный участок значений.

Скорость будет равняться периоду счетчика умноженному на число значений в выделенном диапазоне.

КПД такой системы более 95% (95 % бит это полезные пользовательские данные)

 

Если что можно поговорить в скайпе ?

 

Аватар пользователя Александр Мичуринский

нет смысла счетчики синхронны).

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

Если что можно поговорить в скайпе ?

Пока у меня  ощущение, что Ваши алгоритмы могут работать только "на бумаге" и в программных моделях. А не в реальных системах. Так что до разговора в скайпе ещё очень далеко.

Если Вы считаете, что два счетчика на разных концах могут быть синхронны - мне просто не о чём дальше с Вами разговаривать. Любые два счетчика через некоторое время неизбежно разойдутся. Вопрос в том, что с этим делать дальше.

Аватар пользователя Rutel
Rutel(8 лет 7 месяцев)

Давайте так 

Берете листок бумаги (желательно в клетку) и карандаш.

Пишите в первой колонке двоичные числа от 0 до 15 (0-F)

Во второй их зеркальное отображение (младшие биты со старшими)

В третьей колонке выделяете любой непрерывный участок строк (выделено значит есть крестик )

Рядом рисуете строку из клеточек (от 16 и больше)

 

Далее по попрядку перебираете строки от первой до шестнадцатой

Читаете число из второго столбца и ищите строку содержащую в первом столбце такое же число 

Копируете содержимое из третьего столбца найденной строки в клетку с номером (который вы перебираете)

 

После того как сделаете это 16 раз посмотрите как распределятся клетки помеченные крестиками

Если терпения хватит - попробуйте сделать для 32 (0-1F)