Возможна ли реализация высоконадежного Ethernet коммутатора на основе мажоритарного резервирования информации портов.
Я пока себе плохо представляю как синхронизировать процессора. Так как у каждого процессора есть своя PLL - со стабильностью +- 100% (грубо). И если даже пакеты будут поступать одновременно на 3 коммутатора (10-20 портов), то из за разности частот возможна разная коммутация пакетов. Что при мажоритарном сравнении выявит несовпадение.
Если есть литература описывающая данное резервирование в Ethernet сетях. Или это не возможно. Дайте ссылку или в личку. спасибо.

Увы, у Вас в голове полная путаница.
Итак, есть понятие "сбой" и есть "отказ"... После сбоя информация продолжает проходить, после отказа - нет.
Сбои перекрывают избыточной информацией: контрольными суммами, хемингами, перезапросами и т.д.
Отказы - избыточным аппаратным обеспечением, поскольку в аппаратуру контрольную сумму не всунуть... Это и мажоритары и горячий и холодный резерв...
Так вот, передача данных по Ethernet уже имеет защиту по информации. А каждый порт имеет свой адрес. И если информация не приходит по одному порту, то всегда можно переключиться на резервный порт. А саму линию связи может причем переключать может даже реле...
Тогда зачем ставить себе жуткую задачу на синхронизацию битов? Какой в этом смысл? Тем более, что для долговременного использования мажоритар не сильно хорош. Лучше применять холодный резерв...
И если хотите узнать, что Вы получите, применив мажоритар, то прочтите "Записки Инженера", у меня на сайте...
А вообще надо начинать с расчета надежности. Что у Вас линия связи - провода или оптика, надежнее чем микросхемы?

Спасибо я васпонял. И в обычном ширпотребовском случае я с вами согласен. Вы наверно помните рисунок о том как видет задачу проектировщик. И мой вопрос был примерно из этой области. Начальство придумало, то, что я описал выше. Как повысить надежность "супер" коммутатора. Сделать 3 коммутатора (на разной базе) а на выходе поставить плис (и сравнивать результат комутации). Если совпадает то все нормально. Вот мне и кажется что данный метод не выполним для коммутаторов. В ответ слышу , что я не прав ивсе будет ОК.

Вот давайте еще раз о Вашем варианте...
Допустим так:
Есть 3 передатчика + 3 линии. От них получаем сигнал, например на 3 трансивера и на MII пытаемся подцепить мажоритар. Так?
Теперь представим гипотетически, что 3 передатчика начали одновременно и синхронно передавать... Что получим на приеме на MII? Получим сигнал достоверности данных и начнем из принимать...Но это в теории. А на практике , чтобы получить такую красоту, нужно, чтобы и на передаче и на приеме информация совпала с точностью до бита... И чтобы в линии она поставлялась синхронно. Насколько это выполнимо я предсказать не могу. Поскольку все свитчи разные и задержки в них не описываются...
А теперь так, как Вы пишите:
Сделать 3 коммутатора... А что такое "на выходе"? Это где? Если речь идет о линии, то там сигнал аналоговый. Если коммутатор с несколькими PHY и с одним MII, то куда??? И это: "В ответ слышу , что я не прав ивсе будет ОК.". Значит делаем так. Кладем на стол бумагу и ручку и просим конкретно нарисовать блок-схему. На каждую линию связи, там где PHY и MII готовим описание интерфейса. Готовим блок-схемы микросхем. Ну, например на Микреле их достаточно. Далее делаем серьезный вид и просим разъяснить конкретно, с числом-датой и с подписью... Так снимается много вопросов...

Спасибо. Видимо так и придется "снимать вопросы".
Сигнал на выходе - SGMII (мало этого есть еще 10G (какая плис его распознает? пока не знаю). У алтеры lvds вроде бы смогут сравнить 1Gbps.)

Акроникс тут нарисовался, вот он и успеет...
А будут вопросы - пишите. Могу точно сказать, что за те 7 лет, когда занимался техподдержкой Микрела иногда всплывали вот такие же клиенты, которые хотели "нестандартно" включить микросхемы трансиверов и свитчей... Так вот, с ними и были самые большие проблемы и ничем хорошим это у них не кончалось...
А самое простое - это нарисуйте графики вероятности отказа по времени для мажоритара. Дальше все станет понятно. Я об этом в "записках" как раз написал....

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


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


Ну, таких ПЛИС навалом (реализация SGMII /1000BASE-X, XAUI). Другой вопрос, что стоимость каналов не маленькая, и количество доступных портов на одном чипе лимитировано.

Посмотрите у Марвела есть синхронные езернет коммутаторы, например 88Е6351. При приеме из физики и MII портов происходит выравнивание всех данных перед передачей их в GMAC уровень. Вот ставьте три таких коммутатора, тактируйте их от одного генератора (у коммутатора есть вход 125Мгц тактовой) и на MAC уровне, с уже выровненными тетрадами и занимайтесь мажоритарным резервированием. Я правда с ним не работал, но такая штука есть.

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

Потеря синхронизации одним из свитчей возможна - это неисправность внутри чипа и ее можно победить только физическим резервированием чипа.

Так речь и идёт о разновидности резервирования, которая решает задачу непрерывности функционирования.
И синхронизация свитчей в таких системах - это далеко не просто синхронное тактирование. Это ещё и согласование состояний логических цепей, памяти и т.д..
Задача синхронизации, как уже говорили ранее, действительно кажется жутковатой. Но она решаема.

Потеря синхронизации будет при первой потере пакета одним из 3-х свитчей. А дальше, очереди разбежались, таблицы съехали...
Это стандартная ситуация, которую такая система должна отрабатывать, т.е. восстанавливать синхронность работы всей тройки свитчей.
А 100% гарантию того, что один из троицы не потеряет пакет, может дать... Ну, сами знаете кто.

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

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

а ещё на маршрутизаторах бывает случается реордеринг, т.е. перемешивание очереди пакетов. И что, вы получив с трёх устройств разные пакеты, будете их отбрасывать и ждать перезапроса? А в нагруженном канале они могут приходить out-of-order всегда... во будет веселуха.

Хотите надежности и возможности обеспечения мажоритарности в каналах связи - уходите от ethernet совсем, да хоть например в сторону SDH.

Поэлементное резервирование канала эзернет представляется нерациональной затеей.
Мажоритарные схемы применяются для высоконадежной кратковременной работы в условиях, когда сбой недопустим или нет времени на его анализ. Это эпоха резервирования сигналов.
Эзернет уже другая эпоха, это резервирование сообщений. Два одиночных канала с анализатором общей работоспособности и выбором одного из них буду всегда заведомо надежнее трехканального мажоритата при длительном времени эксплуатации. Сбои парируются повторной передачей сообщения.

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

В общем нужна передача канала езернет поверх трех SDH-1 каналов, либо вообще от езернета отказаться, а связать устройства передачи данных синхронными каналами.

Палка о двух концах. Упрощается одно, усложняется другое. В сумме получится сложней и дороже.
Общая тенденция совершенно противоположная. От SDH к ethernet. Причина простая - цена решений для определённого класса задач.
Коммутация в ethernet и коммутация в SDH - это день и ночь. Многие задачи решаются проще и дешевле именно в ethernet.
И класс таких задач расширяется вместе с развитием ethernet.



Всё это верно ровно до того момента, пока не требуется резервирование обработки сообщений. Речь именно об этом.
Коммутация в ethernet - это именно обработка сообщений. И сильное и слабое место ethernet одновременно.

Резервирование обработки сообщений - это совершенно другой уровень резервирования.
Смешивать его с резервированием сообщений и резервированием каналов не вполне продуктивно.
Так что, мажоритарное резервирование для ethernet вполне актуально. Можно сказать, ренессанс идеи, но уже на другом уровне.
Но система в целом должна оцениваться с учётом всех уровней. Это да.

Другой вопрос, что использование микросхем свитчей ethernet для таких задач выглядит крайне сомнительно. О чём я и намекал ранее.

Стоило бы разделить задачи.
Надежность ПО, кодирования и алгоритмов - одно, надежность линий связи и обработки сигналов - другое.
Сам канал эзернет резервировать аппаратно на уровне ключей, трансформаторов и 2И-НЕ особого смысла не имеет. Задачка достаточно сложная и толку от ее решения будет очень мало в смысле надежности. Для длительных времен это будет даже хуже, чем одноканальная аппаратура.
Эффективнее и проще иметь 2-3 стандартных канала и выбирать исправный.

Это не палка о двух концах. Это разные классы устройств. SDH - поставил, настроил, и забыл.
С Ethernet-роутером в "большом интернете" постоянная головная боль: то таблица MAC переполняется, то 3хBGP full view перестает полностью влезать и его приходится фильтровать-обрезать подсети мельче /24, с соответствующим ухудшением связности, то агрегированный канал из 4х (LACP или подобный) разваливается и в гигабитный линк прилетает все 4 гигабита с такой деградацией, что приходится будить всех инженеров компании.
Сэкономили на спичках, получили массу проблем, зато "стильно, модно, молодежно", а главное - как дёшево! Marketing buzz.
Да, для подключения домашних пользователей к интернету - лучше ничего пока не придумано, его упростили ровно настолько, чтобы им пользовалась любая домохожяйка, а производители не парились реализовывая ненужные "простым смертным" функции.
Но пихать Ethernet всюду не глядя на задачу которую вы решаете - это абсолютно не инженерный подход.
Далее, говорите "развитие" Ethernet? Да, конечно, появился новый RFC, вендоры его внедрили, но извольте теперь выбросить все свое старое Ethernet-оборудование и заменить его новым, только ради поддержки этого RFC. И лучше сразу забудьте о совместимости между производителями. Вот реалии сегодня. Дешевле говорите? Заплатите дважды.

Если посмотрите на магистральные роутеры типа Juniper T1600 - то даже там магистральные Ethernet-порты это не чистый ethernet, а так называемый WAN PHY - а если точнее и ближе к инженерной терминологии - Packet-over-SONET. И в ближайшем будущем от этого отказываться никто не будет.

Мы, собственно, о чём? Если я и упоминал резервирование каналов, то как часть общей задачи.
Что именно в части резрвирования каналов и насколько применимо и целесообразно - отдельный вопрос.
Повторяю, я говорил о резервировании обработки сообщений.


А кто сомневался, что это разные классы устройств?
Надо ещё добавить, что есть разные классы задач и конечные требования к системе.
Судя по исходной постановке задачи и некоторым деталям, к "большому интернету" и близко не лежало.

Исходная постановка: "высоконадежный Ethernet комутатор на основе мажоритарного резервирования".
Так что, кто и что куда пихает - очень интересный поворот. Прикручивать SDH к этой задаче - весьма сомнительная затея.
И с чего Вы решили, что "всюду не глядя на задачу"?