хм. Ну, возможно, я не совсем четко представляю себе механизм работы коммутации пакетов в современных коммутаторах (поправите меня, если я в чем-то неправ): в любом случае после выкусывания src/dst mac на входе (чем вполне могут заниматься asic'и) нам необходимо произвести lookup в таблице мак-адресов для того, чтобы определить выходной интерфейс для dst mac (ну или flood в случае, если dst mac в таблице нет).
вполне вероятно, что это не задача самой «матрицы коммутации» как таковой, но некоего аналога routing engine (из маршрутизатора).
но как бы то ни было, вычисления произвести надо и память будет нужна.
когда это будет «хитрая матрица» — тогда не будет «store and forward». Будет cut-through.
более того, тогда не будет механизма коммутации, это будет обычный повторитель а-ля хаб, потому что для того, чтобы распарсить mac-адрес, его необходимо прочитать.
сетевой стек системы не вытащит (ну, т.е. его программно-аппаратная часть). Насколько мне известно, максимальная производительность сетевой карты, которую выжимали в freebsd (в линуксе даже этого нет, увы) — порядка 5,5 гигабит/сек.
такие вещи обычно реализуются при помощи infiniband.
я увидел у вас волшебное слово «TDMA». А каким образом реализована синхронизация, сколько точек в топологии ptmp можно навесить при относительно нормальных условиях?
радиомодули у вас собственного производства или заказываете где-то?
во-вторых, L3 там куцое донельзя, об этом говорит хотя бы размер RIB: в 128к префиксов даже 1FV не влезет. Чисто OSPF гонять, не более того.
в-третьих, даже L2-функционал у него не самый большой для ядра: не умеет балансировку по L4 в lacp, а IGMP Snooping групп всего 256! Это вообще бред — на сети провайдера их порядка нескольких сотен (в лучшем случае) — на каждого клиента задействуется пара src ip-мультикаст группа. Конечно, есть способы сократить их количество (заменяя src ip на коммутаторе доступа), но это сильно поднимает трафик (особенно если делать это на агрегации).
как добивающий агрумент: в спецификации не указан даже размер таблицы мак-адресов! Зато перечисление отдельными пунктами ipv4 telnet и ipv6 telnet есть обязательно.
вердикт: мне кажется, что основное применение этой железяки — агрегация в ДЦ без особых изысков, просто коммутировать виланы. И ни в коем случае не ставить ее в качестве L3.
З.З.Ы. юзаем серверы Etegro, так вот многие компоненты от них совершенно идентичны тем, что на фотках :) Блоки питания и радиаторы для процессоров точно.
кластер из 2020, виновник — сервер ЦАИР в москве, к которому отправлялся запрос на классификацию урла. Проектом занимался не я, так что информацию могу дать только самую приблизительную.
был разговор хотя бы об увеличении размера локального кеша или о возможности хранить часть (наиболее часто используемую) БД url на местном кеше, но что-то заглохло.
ну и на новых что-то там есть, связанное именно с коммитами, тарщ freefd рассказывал, кажыся.
впрочем, возможно на чем-то дц-специфичном типа Nexus все не так, и балом там правит как раз cut-through или вовсе какой-нибудь fragment-free.
вполне вероятно, что это не задача самой «матрицы коммутации» как таковой, но некоего аналога routing engine (из маршрутизатора).
но как бы то ни было, вычисления произвести надо и память будет нужна.
можно контрпример?
если все заранее определено и у нас коммутация каналов — тогда да, все проще.
но как-то оно с ethernet слегка не согласуется, не находите?
более того, тогда не будет механизма коммутации, это будет обычный повторитель а-ля хаб, потому что для того, чтобы распарсить mac-адрес, его необходимо прочитать.
для L2 так вообще песня.
там, конечно, своих тараканов полно, но L3 там вполне рабочий.
такие вещи обычно реализуются при помощи infiniband.
радиомодули у вас собственного производства или заказываете где-то?
во-вторых, L3 там куцое донельзя, об этом говорит хотя бы размер RIB: в 128к префиксов даже 1FV не влезет. Чисто OSPF гонять, не более того.
в-третьих, даже L2-функционал у него не самый большой для ядра: не умеет балансировку по L4 в lacp, а IGMP Snooping групп всего 256! Это вообще бред — на сети провайдера их порядка нескольких сотен (в лучшем случае) — на каждого клиента задействуется пара src ip-мультикаст группа. Конечно, есть способы сократить их количество (заменяя src ip на коммутаторе доступа), но это сильно поднимает трафик (особенно если делать это на агрегации).
как добивающий агрумент: в спецификации не указан даже размер таблицы мак-адресов! Зато перечисление отдельными пунктами ipv4 telnet и ipv6 telnet есть обязательно.
вердикт: мне кажется, что основное применение этой железяки — агрегация в ДЦ без особых изысков, просто коммутировать виланы. И ни в коем случае не ставить ее в качестве L3.
З.З.Ы. юзаем серверы Etegro, так вот многие компоненты от них совершенно идентичны тем, что на фотках :) Блоки питания и радиаторы для процессоров точно.
был разговор хотя бы об увеличении размера локального кеша или о возможности хранить часть (наиболее часто используемую) БД url на местном кеше, но что-то заглохло.