Возможна ли реализация высоконадежного 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). Другой вопрос, что стоимость каналов не маленькая, и количество доступных портов на одном чипе лимитировано.

Сообщение отредактировал prig - Jul 1 2013, 13:31

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

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

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

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

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

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

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

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

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

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

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

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