ntil

CY7C1416,18,27,20JV18.pdf учтите, что там упоминается латентность в 1 цикл , но память в это время не простаивает, просто данные на выходе появятся с задержкой, при этом может быть подана команда на считывание следующей ячкйки (пока не получена еще предыдущая) - конвеер. а вот на 633 мгц CY7C1268XV18_CY7C1270XV18_001-70329.pdf

смещение маски к более короткой последствий не имеет, т.к. /23 может быть представлен как две /24 если сместить маску в сторону более длинной в этом дизайне приведет к снижению скорости выборки, но софтовой обработкой тут не пахнет, просто там многоступенчатая выборка. просто дополнительно ступеней: 1 для /25 2 для /26 3 для /27 4 для /28 5 для /29 6 для /29 7 для /30 8 для /31-32 вот и все. но с этим можно боротсья, например используя очень быструю накристальную (на плис) память и введя ограничение на количество коротких записей, например 64К на записи каждого типа (скажите, ну нахрена Вам 64К роутов на /32 на бордере ? а? ) схожими средствами организовываются и аппаратные ACL (сравнения) и их редко более 8-16К, ивы-не-поверите - hardware assisted NAT (но вот в его целесообразности я уже не уверен) можно и линукс несколькими десятками тысяч правил на лопатки удожить, если не прибегнуть к иерархическим конструкциям в iptables. знаю, я сам очень люблю линукс. просто обажаю. просто есть вещи, которым после каких-то объемов лучше быть аппаратными.

вот попытался тут пооптимизировать лукап энжин хардварный. получается интересная штука: поскольку в межоператорском взаимодействии маршруты к сетям c маской длиннее /24 не применяются (т.е. в фулл вью их просто напросто нет) то напрашивается следующая хрень: изменяем организацию памяти первого уровня с 64К х 16 на 16М х 24 , что дает возможность разместить _все возможные_ префиксы /24. таким образом скорость выборки всего что короче или равно /24 будет равно частоте работы памяти, например для 300 МГц SRAM скорость коммутации будет равна 300 МППС. опять же таки банков памяти может быть несколько, что кратно повышает производительность. память SRAM первого уровня (которую я ранее предлагал использовать внутреннюю ПЛИС ) выполняется внешней , т.к. ее объем ограничен. скорость выборки маршрутов сеток с маской длиннее, нежели /24, будет тем ниже, чем длиннее маска, но не более чем в восемь крат (оставшиеся 8 бит адреса) для /32. С этим правда можно (и нужно) бороться, например накладывая ограничение на кол-во таких маршрутов.

а какая?

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

где-то так. блин, как лень писать ... вот лучше гляньте Архитектура Cisco Catalyst 6500.pdf

.... а тем временем в нашем гондурасе ДТЕЛ взял двухсоточку... кстати у них вроде тоже экстрим, зто значит что после 256 гиг следует ждать сюрпрайзов?

БЖП это протокол, а в софтовом роутере таблицу наполняет квага(например), а аппаратный поиск, давно так не делается, там проц тогда нужен, на соточной мыльнице, минимум 3-6 гигагерц, чтобы перелопатить поток с простой раскладкой пакетов по портам на уровне маков. Сегодня уже и софтовые роутеры так не работают. Аппаратные роутеры используют коммутационные матрицы, то же и софтовые, только в софтовый идет емуляция поля коммутации. По крайней мере, это уже с нетфлова идет, глупо делать по другому. Потому и говорят - таблицу наполняет. Пожалуйста, прочитайте мои предыдущие посты. я какраз и сетую за хадверный роутер на ПЛИС, описывал и отстаивал методику расчета производительности движка выборки маршрута из уже для него, ХАРДВАРНОГО, специально оптимизированной для аппаратного разбора таблицы.. БГП там может хоть на АРМ крутится, не о нем реч.

а причем тут бгп. ? бгп он чисто софтварный , как правило. его дело наполнять таблицу маршрутов (внешнюю по отношению к нему) в циске так, в линукск так. откройте исходники квагги и посмотрите. здесь описан метод аппаратного поиска в большой таблице маршрутов, которую может заполнять БГП, ОСПФ, или рабыня филипинка, а то и все сразу.

Аргументируйте, почему именно 50, 100 а не 1221 например?

DDR2 SRAM !!статическая память!!. прочитайте внимательно! у меня ща на девборде припаяна. я прекрасно знаю отличия. у нее латентности (в тактах) нет, DDR2 просто говорит о стробировании сигнала на шине по обоим фронтам импульсов. вовторых Ваши аргументы не обоснованы, т.к. не содержат соответствующей аргументации, только визги "БРЕД" чуствую что говорю не с технарем а с гумманитарием. в третьих подтверждением корректности методики расчетов производительности служит собраный лично мною тестбенч на паре десятибаксовых первых циклонах на 20К вентилей, и SRAM памяти выпаяной хрен знает откуда.

ну давайте проведем численную оценку IP LookUp Engine (я тут специально не буду употреблять САМ для того, чтобы не придирались к терминологии ) Вводная Протокол - IPv4 количество маршрутов - 1М Маршруты скомпилированы (оптимизированы) в однозначную заранее сортированую таблицу-структуру, которая затем загружается софтом (демоном BGP например) в лукап энжин. Фактически во внешнем ОЗУ ПЛИС таблица представлена в однозначном виде , подсетями не короче /16 , упорядочеными по возростанию. (тут есть еще ньюансы с масками и more specific subnets, но я это опущу, т.к. долго буду рассказывать, считае что у нас такого нет - т.е. все однозначно). Во внутреннем ОЗУ ПЛИС находится табличка индексов, чтобы избежать бинарного поиска по первым 16 битам. как это работает: по первым двум байтам (16 бит) - фактически они адрес во внутреннем быстром ОЗУ ПЛИС - считывается указатель на точку начала поиска и начальное значение счетчика бинарного поиска. далее аппаратно осуществляется бинарный поиск необходимого значения по оставшимся 16 битам. В этом сценарии узким местом является внешнее ОЗУ ПЛИС. так для поиска по оставшимся 16 битам необходимо произвести в наихудшем случае (максимально) 16 чтений из внешнего ОЗУ. т.е. при использрвании SRAM 200MHz мы получим 200\16=12,5 МППС но! мы можем например использовать 600 МГц DDR2 SRAM, что даст нам 1200 М чтений в сек. соответственно 1200\16= 75 МППС подобное решение относительно легко масштабируется банальным увеличением паралельно работающих банков внешней и внутренней памяти , конвееризацией и паралелизацией всей логики вплоть до исчерпания ресурсов ПЛИС. Сами ПЛИС с собраными в них эгжинами тоже могут работать паралельно, обрабатывая например каждая запросы от всоей группы портов. восемь банков памяти на 1й плис дают 600 МППС, что уже значительно. это 600МППС х 8бит х 64Байт ~ 307 Гбит 64байтными пакетами (с учетоп заголовков эзернет). и тут еще много можно оптимизировать, например с соотношением количества бит в таблице индексов и оставшихся бит для поиска, самим алгоритмом поиска, представлением данных. Кстати интересно будет еще посчитать для SDRAM внешней, хотя имхо тухлый номер

спорим? готов продать рабочее решение на Verilog комм матрица + САМ держи вот, просветись. http://www.actel.com...ents/CAM_AN.pdf

СПЕЦИАЛИЗИРОВАННЫЕ блоки TCAM и есть энжины.

Это как бы одно и тоже ну ТСАМ может быть и без асика причем именно что в виде микросхемы контентно адресуемой памяти , а не энжина на ПЛИС\ASIC для бинарного поиска или там древовидного с красно-черными деревьями, в массиве данных в классическом ОЗУ, как нынче принято. просто у энжина время выборки бОльше, чем у памяти, зато он лихо конвееризируется, в противовес у КА памяти время еденичного запроса сильно меньше, но она дороже.

там 32 ядра, половина, или скока нужно, из которых делает вид что TCAM (в смысле лукапы обрабатывает). И весьма вероятно что все 12 ethernet МАС прям на кристале. В общем я на MUM какраз и иду для того, чтобы выяснить что оно такое внутри, да позадавать каверзных вопросов

на ебее

это уже если дистрибьютед форвардинг. а мне пока хватает карты на классической шине на 16 гбиков.

Мне кажется вы про порты 10 Gb для вашей конфигурации Cisco забыли. ну если они мне нужны (у меня например стопка гиговых), а так это 4к дополнительно за 4ре 10Г порта. куплю как понадобится, зачем замораживать средства, закон мура работает на меня, железо только дешевеет. Кстати если у кого бизнес при 5к хомяков не прибыльный (проблемма найти 3к это уже к подобным мыслям распологает) - то здесьуже какой-то фундаментальный изъян - например попильщик балабосов затаился

абонов много меньше чем 5к , зарплаты плачу. РЭСу плачу, аплинку плачу, транспорт плачу, налоги тоже плачу. Купил и не парюсь уже три года назад (правда немного другой конфиг, но это не важно).

А ты не в РЭС иди а в облэнерго

5000* 50грн=250000грн это 31К у.е. в месяц. я думаю что можно позволить себе купить б\у каталюгу 6500 @ sup720-3bxl за 3, ну пускай даже 4 к у.е. и забыть как про страшный сон пока трафик до 250Г не вырастет даже более мелкие сети могут себе позволить откладывать по 300 баксов в течении года. приобретение нормального железа в ядро и есть развитие сети.

вот кстати чуствую будет ходовая железка http://routerboard.com/CCR1036-12G-4S http://cloudcorerouter.com/ 12 1Г портов, грозятся 24 МППС (на просто роутинге, я так понимаю, без ната\шейпинга), что кстати пр 64 байтных пакетах дает те же 12Гбит цена 1к президдентов обязательно прикуплю себе на попробовать.

Блин софтроутинг и hardware switching это все равно что в игрушках софтрендеринг и аппаратный 3d ускоритель. Поиграть вторую - третюю кваку на софтрендере можно, а вот кризис хрен уж. и с этим почему-то никто не спорит. да, ктото скажет что совтроутинг это очень функционально - не спорю, но это как программный рендеринг в 3dMax - очень функционально(качественно, гибко) но жууутко медленно.

sup720-3bxl = 3000 у.е. если Вам впёрлось 10Г, то значит для Вас 3К не такие уж и деньги. софтроутер на 10+Г с соотв. сетевухами выйдет того же порядка. 100Г я уже сомневаюсь, что возможен за вообще адекватную стоимость. вся заковырка софтроутера в отсутствии CAM, который при 1м маршрутов может выдавать 100М лукапов \ сек. такой СAM реализуется сейчас на плисине за 200$, и например , наличие платки с такой плисиной в серваке весьма уж разрузило бы роутер. НО! зачем вендорам городить огород с платой\плисиной, если проще на эту же плисину прикрутить интерфейсы, соорудить внутри коммутационную фабрику приклеить к ней проц за 20у.е. , чтоб управлял всем хозяйством и держал BGP сессию, то нахрен вообще этот сервак нужен!