BGP 10G Soft Router Своими руками v1.0

[KaYot 3 708]

Хорошая тема была, веселая, с умными мыслями. А потом пришли Человечищи и засрали все никому не интересным и даже не околонаучным бредом(ну или флудом).

[NEP 217]

DDR2 SRAM !!статическая память!!. прочитайте внимательно! у меня ща на девборде припаяна. я прекрасно знаю отличия. у нее латентности (в тактах) нет, DDR2 просто говорит о стробировании сигнала на шине по обоим фронтам импульсов.

 

вовторых Ваши аргументы не обоснованы, т.к. не содержат соответствующей аргументации, только визги "БРЕД" чуствую что говорю не с технарем а с гумманитарием.

 

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

 

Бред.

 

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

[pavlabor 1 939]

NEP, тут бред в другом.

Сетуют за хард, а доказывают про софт.

 

Хард, это коммутационная матрица, и в кошке, емкость определяется характеристикой например на лимон точек(анонсов) коммутации.

Это здоровенная и дорогущая микросхема и это чистый хард.

Прикол в том, что заливаются анонсы на софтовом уровне, а коммутация идет на хардовом.

 

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

то есть это "киборг" в мире харда.

 

Это как бы два варианта, "чистого харда".

 

Но коммутация не только коммутацией по маку или ип заключается,

ест ацл правила, есть дхцп, нат но у потребителя все это волшебная не заканчивающаяся банка сгущенки

и когда проц упирается в потолок, приходят в ужас - сгущенка закончилась!

Не понимая элементарной истины, что кошка это 70% харда и 30% софта,

а тазик это 90% софта и 10% харда.

И до одного места сколько каналов в памяти.

[nsa 0]

Этот велосипед уже давно изобрели, не знаю на каком железе собрано у автора , может за основу была взята эта статья!

http://nag.ru/articles/article/19974/kak-my-10gigabit-na-linux-routere-marshrutizirovali.html

[ntil 57]

DDR2 SRAM !!статическая память!!. прочитайте внимательно! у меня ща на девборде припаяна. я прекрасно знаю отличия. у нее латентности (в тактах) нет, DDR2 просто говорит о стробировании сигнала на шине по обоим фронтам импульсов.

 

вовторых Ваши аргументы не обоснованы, т.к. не содержат соответствующей аргументации, только визги "БРЕД" чуствую что говорю не с технарем а с гумманитарием.

 

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

 

Бред.

 

Зачем цеплять к плис внешнюю SRAM и получить узкое место - гальваническую шину, если ее можно реализовать в самом же ПЛИС.

Ну да ладно... маркировку вашей "DDR2 SRAM" в студию, посмотрим какой вы Сухов.

 

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

 

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

[mr.Scamp 41]

Сделайте кто-тоо подобный стенд, только на FreeBSD, было бы интересно почитать подобную статью.

Эта ОС весьма популярна на бордерах,возможно даже больше, чем Linux.

[NiTr0 584]

NEP, тут бред в другом.

Сетуют за хард, а доказывают про софт.

 

Хард, это коммутационная матрица, и в кошке, емкость определяется характеристикой например на лимон точек(анонсов) коммутации.

Это здоровенная и дорогущая микросхема и это чистый хард.

Прикол в том, что заливаются анонсы на софтовом уровне, а коммутация идет на хардовом.

Что собссно вам и пытались сказать в ответ на ваше

а причем тут бгп. ?

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

 

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

БЖП это протокол, а в софтовом роутере таблицу наполняет квага(например),

а аппаратный поиск, давно так не делается,

там проц тогда нужен, на соточной мыльнице, минимум 3-6 гигагерц, чтобы перелопатить поток с простой раскладкой пакетов по портам на уровне маков.

Наполнение таблицы что софтроутера, что аппаратного ничем не отличается по большому счету - есть сервис роутинга, получающий/раздающий маршруты, и он передает "HAL-прослойке" маршруты, которые нужно внести в таблицу. Все. Где живет таблица, в каком она виде, кто ее обрабатывает - это сервис уже не волнует.

 

Сделайте кто-тоо подобный стенд, только на FreeBSD, было бы интересно почитать подобную статью.

Эта ОС весьма популярна на бордерах,возможно даже больше, чем Linux.

Если память не подводит, в бзде народ пищал то ли на igb, то ли на ixgb драйверы. Да и в общем-то популярность - скорее дело привычки/стереотипов (или я что-то упустил, и бздя имеет какие-то реальные преимущества?).

[www256 1]

Сделайте кто-тоо подобный стенд, только на FreeBSD, было бы интересно почитать подобную статью.

Эта ОС весьма популярна на бордерах,возможно даже больше, чем Linux.

На FreeBSD сервер працює вже 2 роки

[andryas 1 059]

На FreeBSD сервер працює вже 2 роки

 

У меня 2 высоконагруженых сервера (один из низ pptp) с аптаймом более 2-х лет, последняя перезагрузка была связана с отсутсвием электроэнергии на протяжении 3-х дней. До замены на железку непрерывно 5 лет софроутер трудился на бордере, без единого проишествия.

 

Я о том, что статьи по высоконагруженым софроутерам на FreeBSD мне лично даже более интересны, чем на Linux.

[ntil 57]

вот попытался тут пооптимизировать лукап энжин хардварный. получается интересная штука:

поскольку в межоператорском взаимодействии маршруты к сетям c маской длиннее /24 не применяются (т.е. в фулл вью их просто напросто нет) то напрашивается следующая хрень:

изменяем организацию памяти первого уровня с 64К х 16 на 16М х 24 , что дает возможность разместить _все возможные_ префиксы /24. таким образом скорость выборки всего что короче или равно /24 будет равно частоте работы памяти, например для 300 МГц SRAM скорость коммутации будет равна 300 МППС.

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

память SRAM первого уровня (которую я ранее предлагал использовать внутреннюю ПЛИС ) выполняется внешней , т.к. ее объем ограничен.

 

скорость выборки маршрутов сеток с маской длиннее, нежели /24, будет тем ниже, чем длиннее маска, но не более чем в восемь крат (оставшиеся 8 бит адреса) для /32. С этим правда можно (и нужно) бороться, например накладывая ограничение на кол-во таких маршрутов.

[pavlabor 1 939]

вот попытался тут пооптимизировать лукап энжин хардварный. получается интересная штука:

поскольку в межоператорском взаимодействии маршруты к сетям c маской длиннее /24 не применяются (т.е. в фулл вью их просто напросто нет) то напрашивается следующая хрень:

изменяем организацию памяти первого уровня с 64К х 16 на 16М х 24 , что дает возможность разместить _все возможные_ префиксы /24. таким образом скорость выборки всего что короче или равно /24 будет равно частоте работы памяти, например для 300 МГц SRAM скорость коммутации будет равна 300 МППС.

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

память SRAM первого уровня (которую я ранее предлагал использовать внутреннюю ПЛИС ) выполняется внешней , т.к. ее объем ограничен.

 

скорость выборки маршрутов сеток с маской длиннее, нежели /24, будет тем ниже, чем длиннее маска, но не более чем в восемь крат (оставшиеся 8 бит адреса) для /32. С этим правда можно (и нужно) бороться, например накладывая ограничение на кол-во таких маршрутов.

 

Вот!

Это и есть чистый хард.

А теперь сместить маску в некоректную сторону и девайс получит 100% загрузку проца, это пойдет софтовая обработка.

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

Потому что на процедуру может уходить под сотню-тысячу машинных цыклов.

 

Потому для решения нестандартных задачь, есть кошки с немеряными процами,

все по наивности думают, что раз цыска, то это выше Бога,

а на поверку, некоторые задачи линух укладывает цыску на лопатки.

[ntil 57]

А теперь сместить маску в некоректную сторону и девайс получит 100% загрузку проца, это пойдет софтовая обработка.

смещение маски к более короткой последствий не имеет, т.к. /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.

 

а на поверку, некоторые задачи линух укладывает цыску на лопатки.

знаю, я сам очень люблю линукс. просто обажаю.

 

просто есть вещи, которым после каких-то объемов лучше быть аппаратными.

[NEP 217]

вот попытался тут пооптимизировать лукап энжин хардварный. получается интересная штука:

поскольку в межоператорском взаимодействии маршруты к сетям c маской длиннее /24 не применяются (т.е. в фулл вью их просто напросто нет) то напрашивается следующая хрень:

изменяем организацию памяти первого уровня с 64К х 16 на 16М х 24 , что дает возможность разместить _все возможные_ префиксы /24. таким образом скорость выборки всего что короче или равно /24 будет равно частоте работы памяти, например для 300 МГц SRAM скорость коммутации будет равна 300 МППС.

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

память SRAM первого уровня (которую я ранее предлагал использовать внутреннюю ПЛИС ) выполняется внешней , т.к. ее объем ограничен.

 

скорость выборки маршрутов сеток с маской длиннее, нежели /24, будет тем ниже, чем длиннее маска, но не более чем в восемь крат (оставшиеся 8 бит адреса) для /32. С этим правда можно (и нужно) бороться, например накладывая ограничение на кол-во таких маршрутов.

 

Где обещанная маркировка "DDR2 SRAM" ?

[ntil 57]

Где обещанная маркировка "DDR2 SRAM" ?

 

CY7C1416,18,27,20JV18.pdf

 

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

 

а вот на 633 мгц

CY7C1268XV18_CY7C1270XV18_001-70329.pdf

[pavlabor 1 939]

Правильно сказать не объемов а наработок.

Все аппаратное когдато было софтовым, тестилось и при достижении определенных результатов выливалось в аппаратное решение.

Ускорять коммутационную матрицу можно до бесконечности и это всегда происходит при смене технологий.

 

Но если сейчас говорить в разрезе роутера, то тут другие моменты.

1. аппаратные решения, это стандартные задачи, которые не будут менятся, желательно веками, отсюда..

2. аппаратно решаются стандартные задачи, и задачи стараются преобразовать в стандартные.

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

более того есть два распространенных способа коммутации,

- пакет принят, проверен, отправлен,

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

 

Получается что аппаратно, фабрика коммутации работает с частотой 800 миллионов тактов,

при этом, за машинный цыкл, на фабрику коммутации будет выброшено 800 миллионов пакетов,

фабрика, за машинный цыкл их провалит в соответствующие порты, пробросив через матрицу коммутации,

матрица коммутации, за один такт выбросит пакет в соответствующий порт или в ноль.

 

И даже на таком примитивном устройстве, работает коммутационная фабрика на 800 миллионов пакетов в секунду.

Но стоит, поставить другую задачу, вся конструкция рассыпится.

А другая задача, может быть АЦЛ правило,

логически, нужно просто вырезать с пакета преамбулу и сравнить с фильтром.

Так это задача, которую можно решать через коммутационную матрицу.

Но как она решается?

Последовательно!

Пакет прошол через первое поле коммутации, и направляется во второе, дальше в мир.

Получаем падение производительности по шине передачи данных, в два раза.

Решение, разганяем шину в два раза... О!, Все задышало.

 

Теперь нат.

Хех, нат...

Тут не обойтись полем коммутации, пакет нудно маркировать, гдето в твблице хранить запрос, по возврату сравнивать с запросами и или отдавать или дропить.

Отсюда, скажем мыльницы роутеры, при включении торенита падают. Почему?

Да потому, что торент молотит тьму мелких пакетов, 1:100, и при трафике в 10% переполняет таблицу регистрации запросов, перестает натить поток.

Пока по тайм ауту не отвалится часть таблицы, пукнет пару секунд и опять в даун.

Выход расширять таблицы, но это бабулеты.

Чтобы понять прикол, такое сравнение есть модуль кошки, не помню навскидку модель, чтото там семерка, стоит около пятерки зелени.

там коммутационная матрица - миллион.

Теперь берем поток, "300 МППС", поделим его пополам и получаем матрица 150 лимонов записей,

сколько будет стоять такая матрица?

Сто штук зеленых, микросхемка...!

А если таймаут две секунды?

Вот по этой причине, в лер3 невозможно получить статистику по ип,

а в софтовом можно, но он чего то вдруг на колени падает...!

 

Если идти на софтовый роутер, то так все просто как косяк.

Если один проц, может раздеребанить 200метров,

то паралелим поток, на два проца и деребаним 400метров.

Мало!

Ставим тазик на 16 ядер и получаем 3.2 гига.

При этом, до одного места, какая там память, главное что одна ветка справляется со своей задачей.

 

Итого.

Juniper 80 MX, это тазик уровня Синклер, но с аппаратным решение некоторых задач.

 

Имеея хорошую шину на писюке, софтовый тазик можно комплектовать модулями, так же как кошку,

например ставим сетевую две головы, по 10г,

на обработку, ставим видеокарту,

на видеокарте, можем моделировать БЖП,

мало, ставим еще одну видеокарту, на которой строим шейпер,

а нат можно отрабатывать на штатном проце.

То что и у кошки, шасси+модули+дрова.

 

Данная статья интересна тем, что снимает забобоны, что на тазике невозможно разрулить трафик больше гига.

 

 

[ntil 57]

Правильно сказать не объемов а наработок.

Все аппаратное когдато было софтовым, тестилось и при достижении определенных результатов выливалось в аппаратное решение.

Ускорять коммутационную матрицу можно до бесконечности и это всегда происходит при смене технологий.

 

Но если сейчас говорить в разрезе софтового роутера, то тут другие моменты.

1. аппаратные решения, это стандартные задачи, которые не будут менятся, желательно веками, отсюда..

 

ДА

 

 

2. аппаратно решаются стандартные задачи, и задачи стараются преобразовать в стандартные.

 

ДА

 

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

более того есть два распространенных способа коммутации,

- пакет принят, проверен, отправлен,

- пакет принимается и отправляется, паралельно проверяется, если он битый, то в конце дописывается маркер, и на следубщем хопе пакет будет отброшен

.

 

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

 

 

Получается что аппаратно, фабрика коммутации работает с частотой 800 миллионов тактов,

при этом, за машинный цыкл, на фабрику коммутации будет выброшено 800 миллионов пакетов,

 

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

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

 

фабрика, за машинный цыкл их провалит в соответствующие порты, пробросив через матрицу коммутации,

матрица коммутации, за один такт выбросит пакет в соответствующий порт или в ноль.

за много-много, тысячи циклов.

 

 

И даже на таком примитивном устройстве, работает коммутационная фабрика на 800 миллионов пакетов в секунду.

НЕТ, см выше

 

 

Но стоит, поставить другую задачу, вся конструкция рассыпится.

А другая задача, может быть АЦЛ правило,

логически, нужно просто вырезать с пакета преамбулу и сравнить с фильтром.

Так это задача, которую можно решать через коммутационную матрицу.

Но как она решается?

Последовательно!

Пакет прошол через первое поле коммутации, и направляется во второе, дальше в мир.

Получаем падение производительности по шине передачи данных, в два раза.

Решение, разганяем шину в два раза... О!, Все задышало.

 

КОНВЕЕР! не получаем падение в два раза, получаем рост задержки для каждого отдельного пакета, но с неизменной производительностью всего устройства.

одномоментно:

• один пакет принимается,
  
• второй в ацле сравнивается,
  
• третий в САМ энжине парсит заголовок и определяет маршрут
  
• четвертый в матрице коммутируется куда надо
  
• пятый передается на исходящем порту
  

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

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

я там доку на архитектуру 65го выкладывал, там все стрелочками на картинках показано.

 

 

 

Теперь нат.

Хех, нат...

Тут не обойтись полем коммутации, пакет нудно маркировать, гдето в твблице хранить запрос, по возврату сравнивать с запросами и или отдавать или дропить.

Отсюда, скажем мыльницы роутеры, при включении торенита падают. Почему?

Да потому, что торент молотит тьму мелких пакетов, 1:100, и при трафике в 10% переполняет таблицу регистрации запросов, перестает натить поток.

Пока по тайм ауту не отвалится часть таблицы, пукнет пару секунд и опять в даун.

Выход расширять таблицы, но это бабулеты.

Чтобы понять прикол, такое сравнение есть модуль кошки, не помню навскидку модель, чтото там семерка, стоит около пятерки зелени, там коммутационная матрица - миллион, сколько будет стоять такая матрица?

Сто штук зеленых, микросхемка...!

А если таймаут две секунды?

Вот по этой причине, в лер3 невозможно получить статистику по ип,

а в софтовом можно, но он чего то вдруг на колени падает...!

 

все мыльницы на L3 уровне программны, под линуксом.

 

 

Если идти на софтовый роутер, то так все просто как косяк.

Если один проц, может раздеребанить 200метров,

то паралелим поток, на два проца и деребаним 400метров.

Мало!

Ставим тазик на 16 ядер и получаем 3.2 гига.

При этом, до одного места, какая там память, главное что одна ветка справляется со своей задачей.

 

Итого.

Juniper 80 MX, это тазик уровня Синклер, но с аппаратным решение некоторых задач.

 

 

это тазик с акселлератором. для 3Д игрулин даже кореквад тазик, пока видяху не поставишь.

 

 

 

Имеея хорошую шину, тазик можно комплектовать модулями, так же как кошку,

например ставим сетевую две головы, по 10г,

на обработку, ставим видеокарту,

на видеокарте, можем моделировать БЖП,

мало, ставим еще одну видеокарту, на которой строим шейпер,

а нат можно отрабатывать на штатном проце.

То что и у кошки, шасси+модули+дрова.

Данная статья интересна тем, что снимает забобоны, что на тазике невозможно разрулить трафик больше гига.

 

 

а ктото спорит?

просо 100Г уже не выгодно финансово.

[pavlabor 1 939]

>Цитата

>И даже на таком примитивном устройстве, работает коммутационная фабрика на 800 миллионов пакетов в секунду.

>>НЕТ, см выше

 

 

Это не мое мнение, это расписано в даташите.

 

>Цитата

>фабрика, за машинный цыкл их провалит в соответствующие порты, пробросив через матрицу коммутации,

>матрица коммутации, за один такт выбросит пакет в соответствующий порт или в ноль.

>>за много-много, тысячи циклов.

 

Если бы даже за одну тысячу, то мыльница былабы 10 мегабитной,

причем на проце стоял бы радиатор как ведро.

[ntil 57]

производительность восьмипортовой мыльницы 800МППС? етить-колотит! 400ГБИТ (UPD: а не 4Т ,ошибсо!) мелкими пакетами! лихо.

не путайте тактовую частоту и производительность!

кстати дайте ссылку на даташит, может там очепятка?

[ntil 57]

Если бы даже за одну тысячу, то мыльница былабы 10 мегабитной,

причем на проце стоял бы радиатор как ведро.

 

тактовая частота - это частота сдвигов между звеньями конвеера (в идеале).

10мбит? с чего вы взяли? просто зная производительность и частоту можно приблизительно прикинуть количество стадий конвеера. через конвеер завода ведь не проходит одна машина, их там много! и "тактовая частота" конвеера завода - условно одна минута

[pavlabor 1 939]

Это производительность шины данных,

4 порта в фулдуплекса(800), на другие 4 порта фулдуплекса(800),

максимальная пропускная способность мыльницы,

вот и получаем паспортную производительность.

Как там на самом деле, не проверял.

От размера пакетов нечего не зависит, это идеальная задача чистой коммутации.

 

В паспорте написано производительность шини 800мегабит в секунду.

[ntil 57]

зависит!

парсинг пакетов и поиск маршрута куда коммутировать та еще задача, о которой мы тут пол топика спорим.

не путайте собственно коммутационную матрицу и механиз выбора маршрутов.

неблокируемая коммутация это когда производительность лукап энжина заведомо выше пропускной способности матрицы

 

В паспорте написано производительность шини 800мегабит в секунду.

верю, но не пакетов, как раньше написал. у Вас там наверное еще всего несколько К записей, эт ведь не 1М в BGP

и вообще сама матрица - это устройство простое как полено - просто стопка мультиплексоров, а вот их управляющими входами рулит какраз специальный мезанизм, который взаимодействует с лукапэнжином.

[pavlabor 1 939]

Матрица, это и есть механизм.

Пакет зашел, попал в аккумулятор,

Мак по маске упал на матрицу, если фильтр прошел, то пакет с аккумулятора вывалился в соответствующий порт, за один цикл.

Нет так нет, его подавляет следующий пакет.

Технология называется "неблокируемая матрица коммутации".

 

От размера пакета, производительность не меняется, потому как емкость аккумулятора 1516 байта.

И аккумулятору по барабану, какого размера вгружать/выгружать пакет - 800 лимонов в секунду и будь здоров,

в вот объем трафика, это уже другая история.

 

Расчетной части, там в принципе нет - логический автомат.

[Fanat_non_root 88]

2pavlabor

что-то у тебя не то. Вот, к примеру, вырезка из даташита на DGS-1224T, который я сейчас ковыряю:

 

Max. Forwarding Rate

10M: 14,880 pps

100M: 148,809 pps

1G: 1,488,095 pps

 

Как бы совсем не мыльница, но 800 лимонов пакетов я тут не наблюдаю.

[ntil 57]

Мда, помоему мы с Вами рассматриваем разные уровни схемотехнической абстракции

Вы говорите машина состоит из двигателя руля колёс и кузова, а я говорю что машина состоит из двигателя в составе коренных подшипников, коленвала, шатунов, поршней, клапанов, вала ГРМ , и т.д. и.т.п....

Вы говорите я давлю газило и оно едет, я рассказываю детальные принципы.

Вы говорите коммутатор и для Вас он представлен просто в абстрактного корпуса СБИС..

Хотя я представляю, и пытаюсь описать архитектуру на мамного более деталезированном уровне (на уровне регистровых передач а то и на уровне ЛИ )

вот посмотрите,, Lesson3.PDF , правда тут несколько загрубленная картина

[wladd 382]

Парни, очень многое прочитал впервые,

многое не понял. Но

Идея был такая.

- написать про Soft Border что и как для нас, для "обычных людей"

- написать про Soft Brass

Кто за то что бы открыть тему про BRASS, то есть роутер для PPTP/PPOE?

Если да, прошу не писать офтоп в новой теме. Если про Soft BRASS то про него. ок?

может раздел не тот?

писать в разделе - "для людей"?

 

PS: Ну хотим, мы роутить 2-3-4П на тазике, ну и что с того?