Jump to content

    

nice_vladi

Свой
  • Content Count

    176
  • Joined

  • Last visited

Community Reputation

0 Обычный

About nice_vladi

  • Rank
    Частый гость

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

1507 profile views
  1. Интересная схема. Меня чуть смущает, что в таком случае усложняется арбитр доступа к памяти. Получается, порты должны ещё обновлять содержимое памяти (внутренний заголовок с флагами). Сейчас сделал немного по-другому: модифицировал свой второй вариант. Только теперь он работает не по таймауту, а дожидается наполнения <кол-во портов> буферов с указателями на широковещательный пакет. Получается: принял широковещательный пакет -> выставил ему бит "широковещательный" -> засунул во все выходные фифошки -> после передачи все пакеты с флагом "широковещательный" проходят через модуль, в котором <кол-во портов> фифо -> когда ВСЕ фифо в этом модуле не пустые оттуда вычитывается указатель и передаётся в список свободных. Здесь подразумевается, что указатели ВСЕГДА выходят из передающих портов в "правильном" порядке - fifo. Теоретически, если что-то сломается в выходном порте указатель может потеряться. На этот случай сделал проверку равенства считанных указателей. Но, скорее всего, переделаю по вашей подсказке. Это мне видится более правильным решением, которое "не ломается". Но нужно еще подумать. В любом случае, спасибо, взял на вооружение.
  2. Немного продолжу тему. Появился очередной вопрос на тему архитектуры коммутатора. Вопрос опять довольно "низкоуровневый", в сети и букварях не нашёл описания. Всё ниже относится к концепции коммутатора с общим буфером. Как то, что было описано выше. С передачей указателя всё понятно. Указатель передаётся в очередь каждого из портов, кроме порта-источника. А вот как *правильно* возвращать этот указатель в список свободных? Что я пробовал: 1. Передача пакетов блокируется, пока не будет передан широковещательный пакет. Работает, но однозначно плохой вариант, не обсуждаю. 2. К указателям на пакет добавляется флаг broadcast. С этим флагом передающие порты не возвращают указатель в общий пул. Вместо этого есть отдельный буфер для указателей, относящихся к широковещательным пакетам. Это буфер копит указатели и возвращает их по таймауту в общий пул. Основной недостаток: необходимо выбрать таймаут *гарантирующий*, что пакет будет разослан во все порты до того, как указатель вернётся в общий пул и, возможно, будет использован каким-либо приёмным портом. При большом количестве широковещательных пакетов память очень быстро заканчивается. Собственно, вопрос: как правильно обрабатывать указатель на пакет, предназначенный для широковещательной рассылки? Есть ли общепринятые правила?
  3. Нет, все в одной зоне радиовидимости. Спасибо, почитаю. В моих мечтах это должна быть сеть даже БЕЗ координатора. Ну, например, кадр разбивается на 100 слотов. И каждый вновь включившийся абонент проверяет наличие свободного слота и встаёт в него. Ну это так, рассуждения. Я ж наивный и дословно ввёл) Тут тоже, судя по описанию, всё сводится в узел (шлюз) - "звезда"
  4. Такой запрос отсылает в сторону биткоинов и веб-торрентов). Я немного не о том спрашивал) Все сети, которые нашёл, подразумевают наличие шлюза/маршрутизатора - устройства, которое и организовывает сеть, либо служит точкой доступа, базовой станцией. Мне же интересна сеть, состоящая только из "абонентов"-"пиров".
  5. Всем привет. Хочу найти готовое решение для беспроводной связи. Хотелки: Низкое потребление Многоточка без базовых станций Opensource-free to use или что-то типа. В общем, что-то вроде современных ZigBee, LoRA и т.д. Что меня в них не устраивает - необходимость некой базовой станции. Шлюз, маршрутизатор и т.д. Я же хочу систему, где будет Н абонентов, организующихся в сеть без необходимости регистрироваться на БС. В идеале должны быть 2-4-8-N независимых приемопередатчиков, которые настраиваются на требуемую частоту, выходят в эфир и имеют доступ "каждый-с-каждым". Может быть есть какие-то готовые решения? Либо сами по себе существующие, либо на базе вышеупомянутых lora-zigbee? Спасибо
  6. ИМХО, спрашивать разъяснения ТЗ на форуме, у людей не "в теме" вашей работы с заказчиком - так себе идея. Ну насоветуют и разъяснят вам тут. А где гарантия, что это именно то, что подразумевал заказчик? Всё-таки, первоисточник первостепенен. Даже "испорченный телефон" до него >> неизвестные люди с форума =))
  7. Наткнулся в сети на довольно интересные материалы по теме, да ещё и на русском. Судя по всему, будет и продолжение этих статей. Ссылки: https://nag.ru/articles/reviews/106515/intellekt-seti-kak-peredat-paket.html https://nag.ru/articles/reviews/106886/pamyat-seti-kak-sohranit-paket.html Так же нашёл очень интересную книжку которая затрагивает в том числе и организацию и структуру свитчей: Network Routing. Algorithms, Protocols, and Architectures. Deepankar Medhi, Karthikeyan Ramasamy
  8. @Rst7 для 8 портов тогда будет 8*8*2 = 128 бит, как вы писали выше. Для 16 - уже 256. Это ок? На мой взгляд, 16 портов на 125 МГц даже для современных ПЛИС не так уже легко... Повторюсь, я не знаю, как правильно, просто рассуждаю. Бесконечно увеличивать разрядность мы же не сможем. Про разбиение буфера на какие-то атомарные куски - круто, спасибо.
  9. Спасибо большое, очень хорошее и доступное описание. Хочу уточнить пару нюансов: Если чуть усложнить - можно передавать указатели на начало/конец пакета, что бы не было пустых слов в блоке. Но в приведенном вами простейшем случае мы бьём общий пулл на много блоков, фиксированной длины (максимальный размер пакета), я правильно понял? Здесь получается преобразование разрядности? А как обрабатываются пакеты длины не кратной 2*N*8? Какой-то дополнительный маркер вводится? Это означает, что нужно либо увеличить частоту работы с общим полем в 2 раза относительно шины данных, либо потерять половину пропускной способности? Ну, или предположить, что общее поле двухпортовое.
  10. Всем здравствуйте. Довелось заниматься разработкой Ethernet 100 коммутатора L2 на ПЛИС. Здесь, для примера возьмём 4х портовый. Моя проблема - я не до конца понимаю, как должен буферизироваться трафик. То, как я сделал: В каждом порте стоит 2 FIFO - TX/RX. Пакет пришёл, обработался, передался из буфера порта 1 в буфер порта 2. Вроде, всё ок, всё работает. Но возникают проблемы: 1. Блокировка. Текущий пакет не будет передан, пока занят выходной буфер. Это тормозит все последующие пакеты в очереди. 2. Нерациональное использование памяти. В каждом из портов используются буфера 1520*количество портов байт, для того, что бы успевать обработать все, без потери пакеты. 3. Большая утилизация памяти ПЛИС. Логики используется не так уж много, но вот затраты памяти растут катастрофически. И, главное, мне непонятно, как можно использовать внешнюю память? Если 1-2 как-то терпимо, то 3й пункт очень мешает. Я знаю про round-robin и тому подобные вещи, но не могу понять, как это применить без огромного перетактирования. Например, у меня внутренние шины работают на 125 МГц*8 бит. "В лоб" это означает, что мне нужно (125*количество портов) МГц частоты памяти, что бы сложить туда все порты параллельно. Так же вся внешняя память, как правило, 1-2 портового исполнения. Как туда затолкнуть чтение-запись из 4, 8 портов параллельно? В интернетах нашел много общих слов на эту тему: виртуальные входные очереди, динамически распределяемая память. Но конкретного примера, в котором описан алгоритм работы с единым буфером для множественных каналов БЕЗ большого перетактирования не встретил. Да и вообще, что у буржуев, что у нас вразумительных и четких примеров не получилось найти. Собственно, основной вопрос к знающим людям: как, вообще, это делается? Как работать с памятью в коммутаторе? Спасибо.
  11. COBS требует буфера размера не менее 256 байт. Но, в случае ТС, можно COBS подрезать и сделать его на 10 байт. Соответственно, буфер понадобится тоже на 10 байт. Избыточность - не более 1 байта. ИМХО, проще взять готовую реализацию, там будет буфер на 256 байт. Зато никакого ограничения на размер пересылаемых данных. ЗЫ. В интернетах куча примеров и реализаций - от pure C до python и delphi.