Несколько слов об отладке 1Gb Ethernet-проектов на ПЛИС. Часть II.

В продолжение темы собственно об отладке 1Гбит-Ethernet-девайсов. Данный пост будет носить немного философский характер, т.е. много букв, мало картинок и совсем не будет кода или схем. Но в данном посте я поделюсь с читателями теми «граблями», на которые я реально налетал я и мои подчинённые/коллеги при разработке Ethernet-устройств (а этим делом я занимаюсь весьма немалое кол-во времени), дабы дать возможности избежать оных тем, кто идёт за мной.

Итак , начнём с такого интересного момента, как пауза между пакетами.

Дело в том, что если вы хотите выжать из сетки всё на что она только способна, то вас, понятно дело, будет интересовать, а какова же минимально допустимая пауза между пакетами. Вообще говоря, стандарт не запрещает (ну, по-крайней мере мы не нашли никакой инфы) слать пакеты хоть подряд друг за другом с однобайтовой паузой (что бы определить, где последний байт КС расположен, передача-то всё-таки пакетная :)). Т.е., вроде «шмаркнул» TX_EN разок — и начинай следующий пакет. Но реально не один из известных нам СП или сетевых карт в компах не могут принимать стабильно пакеты, если расстояние между ними меньше 5 «холостых» тактов (байтов). Причём, если предстоит стыковка с незнакомым сетевым оборудованием, лучше увеличить её до 7-8, тогда 99,9% пройдёт через почти везде.
У D-Link'овских СП, например, слишком короткая пауза отлично видна по лампочкам: они начинают моргать, модулируя частоту по закону, напоминающему силу порывистового ветра холодным зимним вечером: то как дунет, то затихнет :).

Кстати, для работ с сетью я крайне рекомендую некий индикатор, тестер что ли. В качестве которого рекомендую использовать, как их только не называют любители русского языка, «свитчи», «хабы», «роутеры» (хотя это, конечно, разные классы устройств, но с точки зрения отладки сетевого устройства на плисине, разницы нет). А мы далее по тексту их будем называть так, как предписывает ГОСТ: сетевые переключатели (СП).

Я очень рекомендую использовать СП, даже если конечное назначение разрабатываемого устройства работа в режиме «точка-точка». Причём опять же не важно кто является «концевиком» — ЭВМ или другое аналогичное устройство. Лично мне понравилось работать вот с такой коробочкой (D-Link DSG-1005D, автор никак не связан с компаний D-Link, просто по положительному опыту)



В частности, очень информативными являются лампочки на передней панели СП. Если у вас идёт стабильный поток с постоянной достаточно высокой скоростью и скважностью, то лампочки, соответствующие входной и выходной линиям должны моргать стабильно и абсолютно синхронно друг с другом. Малейшее «перемыргивание» лампочек синхронно или друг относительно друга – признак проблемы. Кстати, при определённом навыке, по морганию лампочек можно определить потерю уже где-то 5-6% пакетов.

Если же моргает только входная лампочка – это 90% ошибка в контрольной сумме (КС) пакета (CRC32). С этой самой темой мы намучались в своё время по полной программе. Напомню вам структуру Ethernet II — пакета по свистнутой с «Википедии» картинке:



С одной стороны, CRC, или, как их обозначали в советской и российской литературе, ЦПК – циклический проверочный код, штука весьма простая. Это – остаток от деления двух двоичных чисел друг на друга поразрядно по модулю 2 (т.е. аналог суммирования – это «исключающее ИЛИ» (XOR), а аналог обычного умножения – «И» (AND)). Или, другими словами, это обычное деление двоичных чисел, но без переноса в старший разряд.

Часто двоичные числа типа представляются полиномами и начинается наукообразное обвешивание всего этого хоз-ва терминами типа «поля Галуа», «неприводимые полиномы» и т.д. и т.п. На самом деле, поля Галуа и связанные с ним несколько теорем – тоже весьма элементарные вещи, но для понимания работы CRC, в принципе, нафиг это всё не нужно. Нужно просто понять, что CRC – это, по-сути, обобщение бита чётности на случай нескольких проверочных бит. Вот и всё!

Так вот понять просто, а реализовать – не очень. Дело в том, что для собственно вычисления КС существует куча способов от классического деления в столбик на сдвиговом регистре (тоже есть несколько вариантов), до «лобовых» способов. Где-то даже видел изящный способ деления вообще в одну строчку на Verilog'е. Мы, например, не заморачивались и просто воспользовались web-инструментом отсюда www.easics.com, который генерит Eth II – вычислитель КС с побайтной подачей.

Но дальше начинаются «пляски с бубном». Разработчикам Ethernet'а явно шило в одном месте мешало: при расчёте КС биты каждого байта должны идти в обратном порядке, после вычисления КС, она должна быть проинвертирована, а байты КС должны идти также в обратном порядке (LSBy first). Кроме того, если вы используете любую итерационную форму деления (сдвиговый регистр или побайтовую подачу), то исходное значение регистра промежуточного результат должно быть = все единицы! Наверное, применив знания в области работы с теми самыми несчастными двоичными полиномами это всё как-то можно упростить. Но мы же не диссер сюда пришли писать, мы — простые инженеры :)

А дальше начинаются уже подводные камни железячной реализации. Если пакеты формируются на лету (real-time) на максимальной скорости (т.е., почти некогда «дух перевести» (см. выше абзац про паузу между пакетами)), то вы можете посмотреть в первой части поста, какие жёсткие требования налагаются на точность синхронизации. И, в большинстве случаев, возникает три проблемы: разъезжается синхра при подачи бит(байт) либо на вычислитель КС, либо с КС, либо банально «съезжает» TX_EN (вот ещё, кстати, почему я в первой части рекомендовал его протаскивать через ALTDDIO).

Причём, самое паршивое, что при включённом внутреннем ФАПЧ PHY (см. первую часть) вы никак физически это сползание увидеть не сможете. Поэтому, «Таймквесты» и временные ограничения («Тайм констрейнты») – вам в помощь.

В 10% бывают и ошибки, не связанные с КС пакета. Обычно (у некоторых моделей СП это задаётся в настройках), если только СП не является «маршрутизатором», то им до лампочки КС IP. Но вот ошибки в установке длины пакета они почему-то простить не могут.

Некоторые реагируют только на нереальные значения длин (обычно превышающие длину Jumbo-пакетов), а некоторые капризные модели обижаются уже, если просто заявленная длина не соответствует истинной длине пакета. В общем, тут всё либо опытным путём, либо внимательным чтением доки к вашему СП. Ну и, конечно, не забудьте, что оконечное устройство должно иметь IP и MAC-адреса, которые установлены вами в проекте.

И хочу предостеречь от весьма распространённой ошибки. Часто, когда проект не работает через СП, разрабатываемое устройство напрямую соединяют с ЭВМ и оказывается, что всё работает. Разработчик радостно объявляет, что «всё работает» и во всём виноват «кривой свитч» и на этом радостно успокаивается.

НЕ НАДО ТАК ДЕЛАТЬ! Как будет описано далее, сетевые карты ЭВМ имеют очень много особенностей. И часто, да, бывает, что после устранения СП данные начинают поступать к потребителю. Но после этого типично случается следующий конфуз. Проект проверен (даже на паре ЭВМ), СП «выбракован», разработчик едет с проектом в «поле» на другой конец страны (земли), куда одни билеты на самолёт только стоят как его месячная зп. Прилетает на место, включается – и … обломись.

А дело в том, что на месте стоит другая ЭВМ (или походный ноут, привезённый с собой, но на котором, есс-но проект проверять не стали). Что бы так не было, запомните: если пакеты не проходят (или теряются) даже на максимальной скорости при прохождении СП, однозначно ищите ошибку в проекте!!! Только после 100% прохождения через СП, можно считать, что проект на 99% исправен :)

Кроме того, если у вас на плате есть две «азернет-соски», или есть другая плата с плисиной и азеренетом можно за пять минут сварганить схему, позволяющую подсматривать пакеты. Если кто не догадался, делается совершенно элементарно: на ноги, соединённые с приёмной частью PHY вешается СигналТап (ЧипСкоуп). На запускающий триггер вешается вход строба (типа RX_DV) и – вуаля: вот он ваш пакет. Конечно, лучше не поленится, потратить несколько дней и сварганить что-либо более удобное.

Ну или хотя бы (как это сделал в своё время автор поста в Матлабе) слепить программку, которая прямо, подсоединившись к СигналТапу из Матлаба рассчитает и сверит КС.

Вообще говоря, перед каждым пакетом должно передаваться вступление («преамбула») из 7 байт 55H и одного D5H. Для чего нужна эта последовательность, данные весьма разнятся: кто-то утверждает, что это – наследие тех времён, когда 10Мб-сеть работала на общий кабель, и нужно было разрешать конфликты доступа к среде, которые ленивые переводчики обозвали «коллизиями». Вторые утверждают, что она нужна для символьной синхронизации.

Похоже на то, что более близки к истине первые, ибо многочисленные эксперименты (в основном из-за ошибок в коде :) показали, что СП и сетевые карты спокойно поедают пакеты, у которых вместо 55H стоит любая ахинея или вообще TX_EN взводится прямо на байте D5H. Главное что бы был байт D5H. Походу, большинство современных сетевых устройств просто считают, что пакет начинается со следующего байта за первым встреченным в потоке байтом D5H.

Кстати сказать, если приёмным устройством в вашей системе является устройство вашего же розлива, то можно вообще забить на все заголовки, включая Eth II, и гнать свой формат. Кстати, такие пакеты можно принять и на ЭВМ, но придётся писать программу, которая напрямую цепляется к драйверу-перехватчику типа pcap, также как это делает популярная подсматривалка Wireshark.

Можно, кстати, забить даже на пакетность передачи данных и перейти в синхронный режим без пауз (PHY это фиолетово). Правда тогда, этот поток уже никакая ЭВМ прочитать не сможет – только промеж вашими девайсами.

Очень часто бывает так, что пакеты видятся тем же Варешарком, но до конечного приложения они не доходят. Например, автор поста чаще всего загоняет пакеты прямо в Матлаб для дальнейшей обработки.

В Матлабе достаточно создать объект udp и дальше, если лень писать код, открыть его свойства, задать приёмный порт, сказать fopen(u) и следить за свойством BytesAvailable. Если это свойство упорно показывает нуль, то пакеты действительно до вас не доходят. В этом случае не надо кидаться рубить антивирусники и курочить настройки безопасности системы. Как показывает практика, даже самые пароноидальные пожарные стенки и антивирусы типа Касперского, никак не реагируют на поток udp-пакетов с местными адресами, даже если ваше устройство генерит их со скоростью «тапку в пол» (хотя на DDOS-атаку очень смахивает и девайс с таким потоком, включённый в офисную сеть запросто её может положить :). Поэтому, запомните главное: если пакеты не доходят до приложений, однозначно ищите ошибку в своём микропрограммном (firmware) коде!



Причём мест, где можно накосячить довольно много. Первое, проверяйте КС. Про КС всего пакета уже всё сказано выше. Что касается КС UDP, то нулевое значение (+0 в обратном коде, см. правленую мной статью на Википедии: ru.wikipedia.org/wiki/UDP, если его ещё не заблокировали :( ) означает, что её не вычисляли. По стандарту, все сетевые уст-ва MUST такое понимать. Но не все китайские разработчики, похоже, стандарты читают :).

Кстати, 100% проверено пакеты с нулевой КС UDP не проходят через Интернет. В местных сетях в 99% случаев такие пакеты свободно гуляют и это очень хорошо, т.к. КС UDP считать «на лету» ну очень не удобно технически (стоит она в заголовке, но считается по всем данным UDP-пакета, кто такой идиотизм придумал?!).

Второе – это КС IP-заголовка. Я здесь буду говорить только про версию 4, ибо версия 6 в местной сети нужна только для гарантированной стрельбы Jumbo-пакетами, но большинство IPv4-устройств уже давно Jumbo-пакеты тоже поддерживают, так что IPv6 в местных сетях, по-сути, нафиг никому не нужен.

В отличие от маразма с КС UDP, КС IP считается только по данным из IP-заголовка. Формально, эту КС тоже можно не считать, но реально даже Wireshark ругается на IPv4-заголовок с нулями в позиции с КС. Тем более что считается она элементарно, хотя есть простой способ её самому не считать, а просто посмотреть правильную КС в том же Wireshark’е и пересобрать с ней проект. А вот пакет с битой КС IP однозначно до верхнего потребителя не доберётся. Ну и не забудьте проверить установку флагов. Проще всего байты с 5ого по 8ой положить нулевыми.

Кстати, по поводу использования КС. У большинства сетевых карт имеются настройки «разгрузки КС». Суть в том, что пользователю предлагается выбрать, кто будет считать КС: само железо сетевой карты или программно ядро ОС. В первом варианте, при неправильной КС, пакет будет безжалостно прибит и не доберётся даже до подсматривалок. А если КС верные, то в первом варианте, некоторые сетевые карты делают то, о чём их никто не просит: зануляют КС. В результате уже подсматривалки начинают ругаться на неверную КС, вы в панике хватаетесь за голову, в то время как всё правильно.



Третье – это тщательная проверка IP-адресов и макушников. У автора поста был постыдный эпизод, когда было спущено два дня известному домашнему животному под хвост, только из-за того, что автор ошибся в одной цифре номера подсети и в упор этого не видел. Не забывайте также, что адреса передатчика и приёмника лучше всего выбирать из одной подсети. Особенно, если ваш девайс не отвечает на ARP-запросы (или вообще работает в режиме монолога и чихать на всех хотел :).

Кстати, по-крайней мере, в Win XP и Win 7 различных версий в большинстве случаев есть ещё одна подстава: если макушник не соответствует макушнику ЭВМ, то опять ни черта вы не получите. Win 8, вроде, поспокойней к этому относится (Win 10 – не знаю и знать не хочу :) ). Иногда это ограничение удаётся объехать на «кривой кобыле» в виде подстановки широковещательного MAC-адреса. Видимо это зависит от каких-то настроек ОС, но автор не специалист в вопросах администрирования ОСей.

Кстати, ещё один вариант «объезда» этой проблемы – использование т.н. «мультикаст» адреса, или, по-русски, «распределённого» адреса. Их плюс в том, что со стороны передатчика ничего делать не надо, кроме прописывания выбранного адреса и макушника (для распределённого адреса IP и MAC строго связаны (http://juniper.ucoz.ru/index/peresylka_multicast/0-73).

Их минус в том, что на приёмной стороне на них нужно «подписываться», что бы начать получать эти пакеты. Процедура не сложная, но, например, из Матлаба это сделать достаточно сложно.

А вообще рекомендую использовать утилитку netstat, обычно имеющуюся в наборе стандартных программ ОС и запускающуюся из консоли. Она вам многое подскажет.

Ну и последнее – это иногда встречающиеся и весьма неприятные прибабахи с КС всего пакета (CRC32). Дело в том, что некоторые производители сетевых карт умудряются разрешать пропускать через себя пакеты с битой CRC32 и, причём, (есс-но!) эта фича оказывается по умолчанию включенной. Причём, самая подстава состоит в том, что ещё и встречаются два варианта поведения таких карт. Первый – это когда карта переключается в прозрачный режим и пропускает в систему весь пакет даже с CRC32-хвостом.

Видимо разработчики того же Wireshark’а с подобной ситуацией сталкивались, т.к. в этом случае, Wireshark понимает, что последние 4 байта – это КС и предупреждает вас о том, что она неверная. Гораздо хуже – вторая ситуация: когда карта молча отбрасывает последние 4 байта. Именно поэтому, в том числе, следует всегда использовать СП, автор никогда не встречался с ситуацией, что бы пакеты с битой CRC32 проходили СП.

Ну а дальше гигабитный поток с близким к 100% заполнения канала ломится на вашу ЭВМ и вы пытаетесь его без пропусков обработать или хотя бы записать на «винч». И тут начинается вторая часть Марлезонского балета, но это уже совсем другая история …

(с) 2015, Kluwert, (по-прежнему) имею право :)
  • +10
  • 02 сентября 2015, 15:23
  • Kluwert
  • 2
Файлы в топике: Matlab_udp.jpg, Upload.jpg

Комментарии (43)

RSS свернуть / развернуть
Вопрос к коду в первой части.Смотрю сюда:
if (SPEED == `FAST)
                        if ((clk_bytes >= 9'h0) && (clk_bytes < 9'd72))
                                TX_EN <= 1'b1; // Transmission is enabled
                        else
                                TX_EN <= 1'b0;
                else
                        if ((clk_bytes >= 9'h0) && (clk_bytes < 9'd72))
                                TX_EN <= 1'b1; // Transmission is enabled
                        else
                                TX_EN <= 1'b0;

И никак не пойму зачем повторение одного и тогоже кода?
0
Пользователь с ником VGA убедил меня открыть-таки комменты.

По коду, да, исправил уже. Там в исходнике у меня как раз закоменченно было от if до else. Когда статью готовил в попыхах не комменты отвалились :) Спасибо, что заметили.
0
Еще вопросик ALTDDIO вроде как нужен для работы с DDR памятью. Но в ПЛИСах обычно есть 1,2(и более) выделенных блока пинов специально для DDR. Собственно вопрос модуль ALTDDIO можно прилепить к пину из вышеуказанных множеств или к любому пину ПЛИС, который поддерживает соответствующий стандарт.
ЗЫ Ну и если уж про Ethernet интересно было бы почитать про HW реализацию МАС уровня. Типа вот есть у меня мегаацп, хочу переслать его данные на комп.
0
По DDR ничего особо сообщить не могу, т.к. обычно их цепляют к прошиваемым процам типа NIOS или MicroBlaze, но я их ярый противник и никогда не использую, а цеплять внешние ДОЗУхи к логике как-то последние 10 надобности не возникало.
А блок altddio можно прилепить к любому выводу, на котором он, соответственно, физически есть. Это лучше всего выяснить либо в описании соотв. камня, или опытным путём.
А про MAC не очень понял: я ж, собственно, и описал его реализацию? Или я вопроса не понял?
0
Ну вы описали, проблемы при работе с мас, плюс не много «выходного блока» на плис. А интересно было бы посмотреть на реализацию всего остального. Хотя бы из чего состоит конвеер от источника данных до крайнего пина плис.
Просто я пока работал с Ethernet только посредством процессора из SoC, на котором Линукс со всеми вытекающими. А вот как выглядит передача по Ethernet чисто на логике, интересно было бы посмотреть.
0
Выглядит как мрак и смерть, если конечно не raw-интерфейс. Покупается или готовая корка, которая и работает с этернетом, или же софткорный проц, на котором можно хоть lwIP поднять. На Виртексе 6 ставил микроблейз и ПДП и гонялись данные на 1 Гбит- залюбуешься.
Потом потратил 3 дня жизни пытаясь понять почему не работают джамбо пакеты… чтобы открыть что в 7 винде по дефолту они выключены. Как я материл майкрософт…
0
чтобы открыть что в 7 винде по дефолту они выключены. Как я материл майкрософт…
Мда Jumbo-кадры тот еще гемор. На моей памяти только за последний год было несколько тикетов по не стандартным MTU (предоставляем аренду), хорошо что проблема в конечном итоге оказалась на стороне абонента. Похоже куча производителей всяких железок до сих пор уверена что 1500 байт хватит всем.
0
1500 это стандартный минимум, и его действительно хватает в 99%. От клиентов, в общем случае, провайдеры принимают пакеты с максимальным размером 1500, а все что больше фрагментируется или дропается, если установлен бит DF.
0
Т.е. около 40 строчек кода на Верилоге — это мрак и смерть? А програмить убогенький «Микроблайз» в не менее убогом «Эклипсе», так что бы он успевал в ПДП-шный поток подпихивать заголовки, а потом ещё геморроится с отладчиком, который постоянно отваливается (уж не знаю как у вас, у меня, что в Виртексе 4 с «Микроблейзом», что в альтеровсикх чипах с «Ниосом» — это стандартная фича) — это не мрак и смерть? Ну-ну…
0
Что именно убогого в обыкновенном риске?
Если у вас что-то отваливается — это ваши проблемы.
Поделитесь пожалуйста «40 строчками на верилоге», которые могут например передавать и принимать поток данных по UDP.
0
В первой части статьи эти строчки. Приём — ещё проще (ибо можно crc32 не проверять).
И очень бы интересно было посмотреть, как вы почти 112Мбайт/сек будете перекидывать на ЦАП, например (реальная задача), используя «Микроблейз» с ПДП?
0
В первой части генератор фиксированного пакета. Без обработки состояния марвелла, без никакой упаковки данных в пакет(хотя бы счётчика примитивного). Это всё равно что генератор цветных полос на VGA назвать видеокартой. А даже простейший сервер на UDP/TCP это уже совсем другой уровень.
Что касается проброса потока данных, то это делается AXI-Stream/ DataMover напрямую из корки в корку, а Микроблейзом просто удобно сконфигурировать этернет, поднять дхцп, прогнать диагностику сети и прочие плюшки.
0
О! Ну вот я вас и поймал на том, на чём и ожидал! Что такое «напрямую из корки в корку»? Правильно, вы опять же, аппаратно, гоните поток. При этом вы ещё сбоку навешиваете Микроблейз, который висит и съедает ресурсы только ради «для конфигурации» пары AXI'шных блоков. Кроме того, вы имеете исходные коды этих блоков? Нет. А теперь учтём, что 90% разработчиков в РФ (да и не только в РФ :)) используют криво-коряво сломанные САПР и, плюс, 90% проектов в РФ делается под военных — извольте выложить все исходные коды и обеспечьте безотказность.

На самом деле, мы с вами спорим на тему «о вкусе и цвете». Я просто хотел выразить не согласие с фразой про «кошмар и мрак». Написание руками UDP/IP-приёмопередатчика — совершенно не смертельная тема.

А по коду, см. мой ответ Signaller'у выше. Я, есс-но, выложил для поста сильно урезанную версию. В нормальной версии есть, например, вычислитель crc32 на лету
CRC32_byte_stream CRC32_inst
(
	.i_clk(i_clk),
	.i_rst(i_rst),	
	
	.i_start_frame(start_calculate_crc),	
	.i_crc_shiftout(start_output_crc),	
	
	.i8_byte(byte),	
	.o8_byte(crc_byte)
);

Это позволяет уже накладывать поверх UDP всё, что вам нужно и, в т.ч. данные из буфера и, конечно, счётчик пакетов. Честно могу сказать, это, конечно, не 40 строчек, а 260, при распечатке помещается на две странички. Один раз отлаженный, использовался уже минимум в 6 проектах. Собс-нно, всё что я имел сказать по этому поводу.
0
Что именно поймали?
Описанная мной система собирается из готовых блоков за час работы, и будет работать из коробки. Если припрёт то можно вместо микроблейза подцепить голую машину состояний для конфигурации.
Написать просто приёмопередатчик и приёмопередатчик согласно технического стандарта это разные вещи. Чтобы работал в любой сети, программно перенастраивался — без перепрошивки, корректно обрабатывал ошибки и состояния. 260 строчек, да? И конечно же RFC-compliant, или хотя бы полностью покрывает конфигурацию марвелловского контроллера? Вы бы хотя бы приложили код для настройки марвелла, что ли… или он работает как MAX232 — что влетело, то и вылетело? Или простейшую проверку состояния линка, чтобы понять, слушает ли нас кто-то, или кабель из гнезда выпал.
Я не спорю что вручную можно написать и GbE, и SATA, и даже небо с Аллахом, но утверждать что собственные «40 строчек» заменяют полноценную корку — очень самонадеянно. Тем более что даже в корках от Хилинха есть стандартный интерфейс куда можно сразу пихать данные. Грубо говоря, хилые дают автобус куда можно посадить детей, а у вас — рама с мотором, и руль приколочен в одном положении. Это позволяет уже накладывать поверх UDPавтобуса всё, что вам нужно, и в т.ч руль, кресла и бензобак.
Что касается бедных разработчиков из РФ и злых вояк — проблемы негров шерифа не копулируют. Это не имеет никакого отношения к разработке быстрых интерфейсов в ПЛИС.
0
Ну так отлично, напишите статью о своём способе, раскройте тему. А я уж, в отместку, в комментах к ней, оттопчусь уже по вашей статье по полной программе :) Так сказать, что бы всё по-честному было :)
0
Справедливо…
0
ни разу. Просто кто то не умеет принимать негативный отзыв как должное и намерен настаивать что его вариант есть свет и мраком быть не может.
ЗЫЖ на альтеровском семинаре поднимал аналогичный вопрос, но по usb интерфейсу. Вынесли вердикт что сделать конечно можно, но разумнее купить ибо разрабатывать дороже.
0
  • avatar
  • xar
  • 06 сентября 2015, 17:56
ломаный софт это вообще незаконно, если что. А денег у вояк всегда хоть жопой дуй. Так что если вы работаете на войну, а начальство жалуется на недостаток финансирования и заставляет работать на ломаном софте — задавайте вопросы начальству. Далее. Купить готовую корку ДЕШЕВЛЕ чем делать ее самим. Если получается что нет — вам мало платят.
0
  • avatar
  • xar
  • 06 сентября 2015, 17:59
Слушайте, уже немного задолбало сравнение мягко и солёного в этой дискуссии. Поэтому не надо проталкивать своё мнение как единственно верное и тем более пытаться тут всех учить. А за мою зп не переживайте: я и когда в оборонке работал, получал — вам не снилось, а сейчас в славных Европах работаю и получаю даже по местным меркам нехило. Так вот вы удивитесь: в оборонке у нас как раз были лицензии на тот же Квартус, а вот тут мы работаем на ломаном софте! Так что, если что сказать по сути постов — говорите, а учить меня кому и какие вопросы задавать не надо!
0
Поэтому не надо проталкивать своё мнение как единственно верное
дак я о том же.
0
  • avatar
  • xar
  • 07 сентября 2015, 00:41
ПК в общем, и с установленной Windows в частности, это не коммутатор, поэтому MTU у него по умолчанию 1500.
99% узлов в сети Интернет работают с IP MTU = 1500.
0
Ох, блин… И в личке такие вопросы задают. Понимаете, тот код-шаблон, что я выложил — это мегасильно урезанная версия универсального достаточно вылизанного модуля (с внешним буфером данных, расчётом crc32 на лету и т.д.), который я использую в нескольких больших проектах. Но за эти проекты я, в своё время, денег получил и выкладывать их не очень корректно. А, с другой стороны, вопросов много. Я подумаю, может сделаю ещё один пост, где выложу более осмысленный проект-выжимку.
+1
Ну я так и понял, что реализация коммерческая тайна, потому и написал про конвеер. Ну, то есть мне бы для изучения и блок схемы бы хватило, если конечно это не будет выдачаей важной информации и у вас будет желание писать.
0
Спасибо за статью.

Не забывайте также, что адреса передатчика и приёмника лучше всего выбирать из одной подсети. Особенно, если ваш девайс не отвечает на ARP-запросы (или вообще работает в режиме монолога и чихать на всех хотел :).
Я бы даже сказал не просто в одной подсети, а адреса должны быть согласованна с прописанными подсетями вышестоящего роутера. Я когда-то вырвал много волос на голове, из-за того что не учел, что есть такая вещь как Proxy ARP, и в роутерах от CISCO эта штука включена по умолчанию.
0
  • avatar
  • e_mc2
  • 02 сентября 2015, 21:42
Спасибо, я о таком тоже не знал.
0
А что вы в первой части наехали на USB? Там есть замечательный изохронный режим. Не сталкивался с 3.0 пока, но в 2.0 отлично работает. Понятно, что в USB 2.0 гигабит не запихнёшь, но если надо в 4 раза меньше, то всё отлично работает.
0
USB — это шина а не порт. В этом ее сильное — и одновременно слабое место. Дело в том, что у USB имеется пауза длиной в 1 микросекунду, и все устройства, подключенные к шине, должны соблюдать микросекунду молчания. Кто не соблюл — расстрел. Иначе говоря, отключается порт с этим устройством НАВСЕГДА. Пока не переткнёшь. А ведь в этот момент может прийти элементарная помеха. На производствах часто так бывает, что подходишь к компу, к кторому месяц не подходили — а мышка не фурычит. Вырубилась в кокой-то момент. А USB-принтеры это вообще сказка. Ethernet лишен этих недостатков, потому что Ethernet — это порт.
+1
USB — это шина а не порт.

Вот здесь я с Вами не согласен.

Хотя в аббревиатуре USB и присутствует «шина» — на физическом уровне USB имеет топологию «звезда» – вы не можете на одни порт USB повесить несколько устройств просто соединив их последовательно (соединив параллельно D+ D-), вы можете это сделать только через хаб. А вот Ethernet поддерживает разную топологию, и «звезду» и «шину» (старый добрый 10BASE-2, когда один глючащий комп может положить всю сеть). И идеология обмена разная – в случае USB есть ведущий и ведомый, в случае Ethernet все равны и коллизии – это нормальное явление. Да и сами стандарты описывают разные уровни протоколов (от физического до …). Это слишком разные стандарты чтобы их так просто сравнивать.
+2
топологию «звезда» используют практически повсеместно, однако протокол задумывался и работает как шина. Повторюсь. Имеется микросекунда тишины. Это ее сильное в том смысле, если кривое устройство подсунули — шина не накрывается (по сути — это рудимент) и одновременно слабое, в том смысле что помеха может выбить работающее устройство, место. По поводу хабов. видал я хаб, который представлял из себя тупо разъемы usb и светодиод. Без чипов. Кстати, даже работал. Мышка и программатор на нем висели. Часто глючил, потому как «звезда» настоящая получалась со всеми переотражениями. Вот.
0
По поводу хабов. видал я хаб, который представлял из себя тупо разъемы usb и светодиод. Без чипов. Кстати, даже работал

Но как?!

USB хаб физически не может быть пассивным устройством. И дело не в переотражениях а в том, что он принимает активное участие в инициализации устройств. Он, как минимум, сообщает хосту о изменении статуса своего порта, потом под управлением хоста индивидуально ресетит устройства, чтобы вычитать дескрипторы и, главное, присвоить устройствам адреса.
0
USB хаб физически не может быть пассивным устройством.
Вполне может быть, но с некоторыми ограничениями — не более 1 порта.
0
Пассивный удлиннитель?xD
0
  • avatar
  • xar
  • 06 сентября 2015, 18:14
Это частный случай пассивного хаба ;)
0
Наехал уже хотя бы потому, что USB, извините, вы можете просто прийти и воткнуть где вам хочется? Нет! Извольте драйверы сначала поставить, причём строго от той чипухи, что вы используете (FTDI, например), строго под ту ось, на которой вы работаете и то с почти обязательными «танцами с бубном» (что я не помню как дрова ставили для популярных FTDI'ных мостов?). А в Матлаб как? Правильно, приходит Вася-программист, пишет в Дельфях, или на Visual C++ какую-то кривую прогу, которая работает только на одном компе, при это надо выполнить кучу шаманских действий, что бы получить бинарник с отсчётами, которые… А с Ethernet'ом пришёл, воткнулся и — работай прямо из Матлаба.
+1
Ну, простите, претензии к драйверам — это претензии к криворукости, не более того. Можно, например, реализовать стандартный класс аудио (как раз для которого и создавался изохронный режим) и любая современная OS отлично увидит всё без драйверов. Для АЦП (пусть и не звукового) это очень разумное решение. И, нет, вы не будете ограничены 44100 или чем-то ещё, там можно вписывать любые свои числа (винда это понимает, по крайней мере, остальных не проверял на нестандартных частотах дискретизации). А можно просто пользоваться libusb, который есть под все OS и реализовать нужный вам драйвер 100% кроссплатформенно в userland (как это делает RTL-SDR). Выбирайте :) Ясно, что всё это надёжно и стабильно будет работать до примерно 240 мегабит (в случае USB2.0), если повезёт то выше, но 480 не получить никак. Если надо быстрее, то да, гигабитный езернет — следующий разумный выбор, я не спорю.

При этом у езернета есть свои минусы — например, многие ноуты до сих пор имеют или 100-мегабитный порт или формальный гигабит, но полное говно (младшие Реалтеки). Во-вторых, у большинства компов езернет один. Гонять поток которому нужна практически синхронность (если мы всё ещё о АЦП) через тот же порт, через который винда апдейты качает (и через свитч) мне не кажется хорошей идеей. И нужен очень приличный свитч, потому что, например, младшие Д-Линки впадают в 3-4 секундный ступор под полной нагрузкой регулярно, я их доводил до такого поведения не то что сплошным потоком пакетов от трафик-генератора, а до предела оптимизированным файловым сервером всего с двумя клиентами. Явно там что-то перегружалось раз в несколько минут внутри (пробовал 2 или 3 модели совсем младших, управляемые таким, к счастью, не страдают, а из неуправляемых лучше всего себя ведёт HP ProCurve).

В общем, езернет это полезно, но USB тоже не надо списывать со счетов.
0
а вообще говоря, usb3.0 в 5 раз скоростнее ethernet 1Гбит, так-то, уж коль здесь мы за скорость ратуем, то usb — вполне себе конкурент.
0
не так давно анонсировали USB 3.1 скорость 10ГБит. Есть куда расти
0
Единственный плюс Ethernet это большое покрытие по расстоянию. Про драйвера это все натяжка. Для работы с девайсом по сети тоде по нужно. И тоже под конкретный девпйс и под конкретную ось.
0
  • avatar
  • xar
  • 06 сентября 2015, 18:17
Дело в том, что если вы хотите выжать из сетки всё на что она только способна, то вас, понятно дело, будет интересовать, а какова же минимально допустимая пауза между пакетами.

Мин. пауза – 96 бит (Interpacket gap)
0
  • avatar
  • e_mc2
  • 03 сентября 2015, 20:00
Ну стандарты-то мы не читаем. Возможно и слава богу, ибо опытным путём выяснили, что 64 бит хватает везде и всегда :)
0
возвращаю вас к вашим же словам:
НЕ НАДО ТАК ДЕЛАТЬ!
0
Поддерживаю.
0
  • avatar
  • xar
  • 06 сентября 2015, 18:15
Большое спасибо за статью, крайне интересно!
Жду продолжения ))))
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.