Перейти к содержанию
Поиск
    

htol

Новичок
 Профиль  Обзор контента

  • Постов

    4

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные htol

  1. Опубликовано · Пожаловаться

    1. В tcp есть понятие окна. Оно означает сколько пакетов можно принять/передать до отправки/получения подтверждения.

    Советую почитать протокол подстверждения приема/передачи и запроса на повтор при tcp соединении. Все очень просто и обычно с картинками, которые сильно облегчают жизнь.

  2. Опубликовано · Пожаловаться

    Ну обычно доступ начинатеся с авторизации. Т.е. какую-нить формочку с логином паролем. Можно нарисовать логотип конторы или устройства на этой форме.

     

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

  3. Опубликовано · Пожаловаться

    Ну, коль уж 1Гбит захотелось, то это что-то в районе 1.4Мппс при 64-байтных пакетах.

    В принципе, любой MAC и PHY соответствующий стандарту вполне способен и принять и отослать все на полной скорости.

    Т.е. с точки зрения самого интерфейса практически любой удовлетворяет требованием и основная сложность в обеспечении нужной пропускной способности именно в обработке/генерации?

    Если ваши условия позволяют вам подготовить все данные для уходящих пакетов в памяти перед началом отсылания, то и проц особо мощный не понадобится. Подготовил данные и дескрипторы и сказал "поехали".
    Думаю да. Вычисления для такого рода передач не сильно много: crc для ip пакета, для ethernet кадра, я так понимаю это будет делать MAC. Хэш по адресу, и поиск в таблице состояний по этому хэшу. Больше пока вычислений не вижу. Все остальное тупая передача дескрипторов.
    Если же вам надо все непрерывным потоком, да еще с меняющимися данными, то без FPGA тут, пожалуй, тяжко будет. Скажем, есть у нас 2ГГц проц. При 1Мппс у нас есть примерно 2000 циклов на прием и передачу одного пакета. Кажется - не так-то и мало. Но. Работать мы будем с большим количеством данных, которое в кэш точно не влазит, значит вероятность того, что процессору придется лезть в память довольно велика. Типичное время доступа к памяти - в районе 50-100нс. Существенная часть вашего бюджета уйдет на простой в ожидании памяти, но, в принципе, что-нибудь не сильно сложное сделать возможно. Если вам производительность при малых пакетах не критична, то в принципе, можно и нетривиальные вещи делать.
    А вот здесь, если можно, поподробнее. Чем мне поможет fpga, если все равно нужно будет обращаться к памяти? Я так понимаю что скорость доступа к DDR ниже? Например ddr 333MHz 32 bit получаем что-то типа 1s/(333MHz*32bit)= 0.7 нс даже если попадется плохой кусок то задержка будет максимум 15 тактов. Т.е. получается на 2 порядка меньше ваших цифр? Хотя я не исключаю что у меня плохо с арифметикой в 4 часа ночи :) . Хотя я изначально думал что без fpga вообще ничего не сделаешь при приеме/передачи + какой-нить обработки пакетов без того чтоб не задушить процессор прерываниями.
    Из вариантов MAC неплохо себя зарекомендовали интеловские 8254* и Broadcom BCM5706/BCM5708.

    Оба позволяют откладывать прерывания, чтоб не дергать проц на каждый пакет. Оба с адекватным scatter/gather DMA и позволяют выполнять кое-какие операции полезные в сетевых стеках, но вам, это, наверное, поможет не сильно.

    Помоему для меня это не реальные варианты :( . Я на это дело так и не смог найти даташитов, когда правил драйвера к сетевухам броадкомовским для фриибсд. Думаю что с интелом будет тоже самое.
    Броадкомовские маки особенно интересны, что у них "на борту" у МАКа есть пара собственных процессоров, которые-то уже и занимаются раскладыванием принятых пакетов в память процессору. Несколько лет назад народ из FreeBSD сделал zero-copy прием пакетов.

    http://people.freebsd.org/~ken/zero_copy/

     

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

    Вот-вот.

  4. Опубликовано · Пожаловаться

    Приветсвую!

     

    Нужен высокопроизвоительный гигабит интерфейс (точнее 2), способный принимать/передавать 1Mpps (1 миллион пакетов в секунду) full duplex и не умират при этом от прерываний, а за одно не убивать процессор :crying: . Физика не имеет значения, но в идеале была бы совмещенной медь/sfp.

     

    Хочется сделать высокопроизводительный анализатор/генератор трафика с возможностью этого самого трафика изменять на лету (например изменять поля с приоритетами, менять MAC, или работать в качестве транслятора адресов,т.е. изменять входящий адрес адрес при прохождении пакета через устройства на другой и обратно NAT). Обычные писюки умирают от прерываний при таком большой количестве пакетов и в итоге большенство теряется. Флюков на каждый узел тоже не напасешься, да и удаленно они не рулятся. Грубо говоря в итоге хочется получить маршрутизатор с сильно заточенными/обрезанными функциями.

     

    Исходя из того что это будет недо маршрутизатор пытаюсь выбрать архитектура для него. Если класическую схему при которой прерываниями контроллера и обработкой принятых пакетов занимается один и тотже процессор, то скорее всего получу такие же проблемы как с PC. Исходя из этого думаю разделить функции приема/передачи, обработки пакетов и управления устройсва разными процессорами. Один из вариантов сделать специализированную плату под эту задачу для высокоскоростной шины например PCI Express, которую воткнуть в PC для управления ею. Плата на борту будет иметь свой гигабитный интерфейс PHY+MAC, процессор для обработки и большая быстрая память. А с помощью PC будет осуществляться инициализация и конфигурирование, снятие статистики для анализа и подготовка правил для изменения или генерации пакетов.

     

    Меня интересуют в первую очередь существующие PHY+MAC которые без проблем переварят поток до 1Mpps full duplex. Микропроцессоры заточенные под такого рода задачи. Возможно есть готовые IP процессоры? Тестовые платы на которых можно собрать нечто подобное без больших затрат на самостоятельную разработку. Методы высокоскоростной обработки большого потока информации. Архитектуры такого рода устройств. Ключевые слова для грамотного поиска по данной теме (искал, но так и ненашел ничего похожего, либо 100Мбит/с интерфейс со всеми вытекающими ограничениями либо все наглухо закрыто без публичной информации :twak: ). А так же ссылки на тематические форумы и сайты. Возможно есть похожий open source проект? С удовольствием бы к нему присоединился.

     

    Вобщем сильно буду рад любого рода информации и мнений по этому вопросу. :beer:

×
×
  • Создать...