Добрый день!

Как вы поняли из названия, вас ждет очередная статья про NetFlow, но на этот раз с необычной стороны — со стороны реализации NetFlow сенсора на FPGA.

Дорогие друзья, 14 мая пройдет большая встреча Петербургских IT сообществ, встречи проводятся два-три раза в год, пространство рассчитано на 800 участников. Каждое из IT сообществ представляет свою программу на мероприятие, обычно это разбор кейсов, мастер-классы, небольшие семинары. В этот раз участие примет 16 сообществ разной IT тематики.

Зарегистрироваться нужно по ссылке.

Пожалуйста, обратите внимание на то, что количество мест — ограничено, пожалуйста, регистрируйтесь только в том случае если действительно собираетесь идти.

Недавно мы применили плату Ethond в качестве мини-роутера и запустили на нём OpenVPN.

Но обнаружилось, что процессор часто нагружается на 100%, а скорость не поднимается выше 15-16 Мбит/с. На канале связи 100 мегабит это очень мало, поэтому мы решили ускорить процесс аппаратно.

Ребята из группы FPGA-разработчиков сделали прошивку на базе открытого IP-core для Altera CycloneV с реализацией шифра AES-128, которая умеет шифровать 8 Гбит/сек и дешифровать 700 Мбит/сек. Для сравнения, программа openssl на CPU (ARM Cortex A9) того же CycloneV может обрабатывать лишь около 160 Мбит/сек.

Эта статья посвящена нашему исследованию по применению аппаратного шифрования AES. Мы сжато представим описание криптографической инфраструктуры в Linux и опишем драйвер (исходный код открыт и доступен на github), который осуществляет обмен между FPGA и ядром. Реализация шифрования на FPGA не является темой статьи — мы описываем лишь интерфейс, с которым происходит взаимодействие c акселератором со стороны процессора.

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

Наивным решением будет запоминать в приложении время сразу после получения пакета от ядра (или перед отправкой ядру):

  recv(sock, buffer, length, flags);
  clock_gettime(CLOCK_REALTIME, timespec);

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

Начиная с версии 2.6.30 Линукс поддерживает опцию сокета SO_TIMESTAMPING. Она позволяет пользовательскому сокету получать временные метки для отправляемых и принимаемых пакетов. Временные метки могут быть сняты самим ядром, драйвером или сетевым устройством (см. список поддерживающих устройств и драйверов). О том, что это вообще такое и как этим пользоваться, стоит почитать в Documentation/networking/timestamping.txt

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

Всем привет!



Пока общественность активно обсуждает неоткрывающиеся двери УАЗа, в Москве, на Красной Пресне, в очередной раз проходит выставка «Связь-2016». Когда мне довелось побывать на выставке года два назад, занимала она больше места. Как минимум, на один павильон. Сейчас занимает 4 зала в двух павильонах. Это не очень много, но если учесть, что сейчас не участвуют члены большой тройки (а раньше они занимали значительную часть), то не так уж и мало. Операторов практически не было, стало больше производителей-разработчиков, и это радует.

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

Добро пожаловать!

Всем привет!
В одной из предыдущих статей мой коллега Des333 реализовал фреймбуфер для LCD, работающего на графическом контроллере ILI9341. Однако, его написание потребовало существенного опыта в разработке RTL-кода.

К тому же, не у каждого под рукой есть embedded LCD-дисплей, зато наверняка есть монитор с VGA-входом.Что же делать, если опыта разработки под FPGA мало, но есть SoC, а сделать что-то интересное хочется?

В этой статье мы расскажем, как разработать графический контроллер, имея на руках плату с SoC (Altera Cyclone V), дисплей с VGA и минимальные знания языков HDL (в нашем случае — Verilog).

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

Всем привет!

Давненько мы ничего не писали. А тем временем...

В тридевятом царстве, в тридесятом государстве, в баварской вотчине, в средневековом городе Нюрнберге проходит выставка под названием Embedded World. Цель выставки — собрать в одном месте производителей, разработчиков, студентов и других заинтересованных граждан. Проходит она три дня — с 23 по 25 февраля.




Сайт выставки: http://www.embedded-world.de

Около 900 участников, примерно 25 тысяч посетителей. Двух дней еле-еле хватает, чтобы понять, что к чему. Поэтому выставка длится три дня :)

Судьба забрасывает меня на это мероприятие уже не в первый раз: мы с коллегами по НТЦ Метротек посещали выставку в 2013, 2014 и 2015 годах. Именно здесь мы впервые увидели Cyclone V SoC (System On Chip c ARM и FPGA на борту), который впоследствии лёг в основу новых девайсов производства НТЦ Метротек (это — Беркут-ЕТ, EthOnd, BlueSoM, ETL-N). Именно здесь мы нашли производителей корпусов EMKO и наладили с ними сотрудничество, теперь все стоечные приборы (свитч Metrotek X10-24, Беркут-МХ) выглядят единообразно. Здесь мы узнаём о новинках и трендах.

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

Сегодня я расскажу о неожиданных проблемах, которые возникли при подключении матричной клавиатуры к ARM-борде под управлением Linux в приборе Беркут-ETN (ETN — новая аппаратная ревизия Беркут-ET). А конкретно о том, почему драйвер adp5589 не захотел получать прерывания и как мы смогли заставить его это делать.

Кому интересно — добро пожаловать под кат.

Я не буду соревноваться в мастерстве написания репортажей с dzeban, вместе с которым мне посчастливилось побывать на конференции линукс-разработчиков LinuxCon Europe. Поэтому постараюсь просто осветить то, что мне больше всего запомнилось, и таким образом дополнить картину.



Мои впечатления не привязаны к хронологии конференции. Я в общих чертах расскажу про саму конференцию и самые интересные доклады со ссылками на презентации и соответствующие сайты. Прошу под кат.

Раз в год в Европе проходит событие, которое мечтают посетить все, кто хоть что-то знает про Linux. Событие, которое собирает вокруг себя самое большое сообщество, когда-либо существовавшее на этой планете. Сообщество энтузиастов, хакеров, инженеров, программистов, админов, корпоративных боссов, всех тех, кто имеет работу и хобби благодаря Linux и open source. Мы в НТЦ Метротек привыкли делиться знаниями и получать их, поэтому такое пропустить не могли. Дамы и господа, добро пожаловать в Дублин на тройную конференцию LinuxCon + CloudOpen + Embedded LinuxCon Europe 2015!

Добрый день!

Недавно прочитал очень интересную статью про обработку 50 гигабит/с на сервере и вспомнил, что у меня в черновиках лежит статья про то, как мы год назад разрабатывали систему мониторинга видео-потоков с общим объёмом трафика до 100 Гбит/с. Ещё раз “вычитал” её и решил представить на суд разработчиков. Статья больше посвящена анализу протоколов и поиску архитектурного решения, нежели тюнингу всевозможных подсистем linux’а, потому что мы пошли по пути распределения нагрузки между сервером и сетевыми пробниками, которые подключаются к транспортным потокам 10 Gigabit Ethernet.



Если интересно, как мы смогли измерить характеристики сетевых потоков от 55 тысяч видео-камер, прошу под кат.

Так сложилось, что в Qt4 Embedded, которую мы используем на нашем приборе Беркут-ММТ, нет поддержки таких устройств ввода, как энкодер. Т.е. если прицепить к прибору мышь — координаты при перемещении обрабатываться будут, а вот колесо прокрутки — нет. Потому что драйвер linuxinput не обрабатывает события с типом REL_WHEEL, которое генерит энкодер, а только REL_X и REL_Y, которые отвечают за изменение координат.

Кому интересно как эту проблему решить — добро пожаловать под кат.

Всем привет!

На этих выходных в Санкт-Петербурге прошёл очередной фестиваль Chaos Constructions, на котором собрались фанаты, программисты и разработчики, чтобы посоревноваться в мастерстве создания demo.

О том, что такое demo, можно почитать на сайте организаторов. А если вкратце, то участникам даётся задача сделать что-то впечатляющее на spectrum'е или аналогичном ретро-железе, и при этом ставятся ограничения на размер программ и длительность демки. Например, меня очень впечатлила вот эта на Spectrum'е, которая уместилась всего в 256 байт! Да, демка выводится на большой экран с отличным звуком, поэтому зрелище впечатляет!

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



О том, как проходил конкурс, как и что мы к нему готовили и будет моя статья. Кому интересно, прошу под кат.

С чего все началось

Итак, в нашем замечательном приборе Беркут-ММТ (на базе PXA320 и GNU/Linux) есть не менее замечательный модуль OTDR (на базе STM32 и NutOS), представляющий собой импульсный оптический рефлектометр. Эта связка работает следующим образом: пользователь нажимает на экране на различные элементы UI, в приборе происходит немножечко магии, и желания пользователя трансформируются в команды вида «duration 300», которые уходят в измерительный модуль. Конкретно эта команда выставляет длительность измерений в 300 секунд. Модуль к прибору подключен по USB, для передачи команд поверх USB поднят CDC-ACM.

Кратенько — CDC-ACM позволяет эмулировать последовательный порт через USB. Так что для верхнего уровня наш измерительный модуль в системе доступен как /dev/ttyACM0. CDC-ACM служит для передачи команд в модуль или чтения текущих настроек/состояния модуля. Для передачи самой рефлектограммы служил USB Bulk интерфейс, который все свое время посвящал только одному — передаче данных рефлектограммы из модуля в прибор, как бинарного потока данных. В какой-то момент мы заметили, что рефлектограмма приходит к нам не полностью. Так мы открыли для себя, что USB может терять данные.

В устройствах, которые мы разрабатываем и производим, требуется быстрый запуск после холодного старта. Для приборов без полноценной операционной системы (в них мы используем NutOS, он же EtherNut) такой проблемы нет — они готовы к работе через пару секунд после включения. Зато в более сложных и продвинутых, с linux внутри, и особенно в портативных измерительных системах, вопрос ускорения алгоритмов инициализации более чем актуален.
В пилотной версии своего коммутатора 10G ethernet мы использовали хорошо известную плату Beaglebone и процесс загрузки, если не считать qemu-эмулятор, с удовольствием отлаживали на ней. Кстати, эта пилотная версия 10-гигабитного свича с управляющей beaglebone-платой (на фотографии к статье) стоит у нас в серверной и пару лет успешно работает,
Сразу скажу, что переход на runit дал ускорение запуска системы на 500MHz arm-процессоре с полминуты до шести с копейками секунд.

Disclaimer: эта заметка была написана для внутреннего wiki нашей компании, и, поскольку далеко не все разработчики ПО системные администраторы, я посчитал нужным объяснить некоторые моменты максимально простым и понятным языком.

В нашей компании в процессе разработки принято придерживаться нескольких простых принципов. Возможно, кому-то они покажутся спорными, кому-то наивными, но, так же как и календарь, про который писал в прошлом году наш IT-директор (aka paulig), эти принципы — результат собственного опыта и ошибок. Кроме того, мы верим, что следование им даёт возможность решать задачи быстрее и эффективнее.

Зачем это было написано, если есть множество книжек по методологиям разработки (в том числе extreme programming, scrum, tdd), по программированию в целом и в частности, о том, «как пасти котов» и про «идеальный код»? Книг много, но разработчики, к несчастью, их читать не любят. Ну, ладно, любят, но не все. У них, мол, своя специфика. Квинтэссенция нужна. И проще, ближе, понятнее. Вот поэтому. И в жизни чаще всего приходится вспоминать, вернее, не забывать, именно те, которые перечислены ниже.

Посмотрев на историю страницы в нашем корпоративном twiki, я обратил внимание, что небольшой список с пояснениями, на основе которого сделана эта публикация, начал своё существование в 2006 году и неспешно дополнялся до 2011 года. Потом почему-то заглохло. Может быть, у кого-нибудь из читателей появится желание что-то добавить?

Вступление

По настоятельной просьбе Des333 (почему все пишут, а вы нет?) публикую историю «НТЦ Метротек».


Не так давно в Санкт-Петербурге был такой институт — ЛОНИИС (Ленинградский отраслевой НИИ связи), в котором разрабатывали разные полезные и бесполезные вещи, имеющие отношение к связи. В частности, там был создан полный аналог финской цифровой телефонной станции DX-200, но на отечественных компонентах и назывался этот аналог «АТСЦ-90». Кто ж тогда знал, что нашу электронику ждёт? Кроме того, в девяностые годы НИИ активно занимался сертификацией зарубежного оборудования: от телефонов до офисных АТС, что приносило хороший доход и давало возможность развивать другие направления. Например, измерения и тестирование каналов связи и протоколов сигнализации в телефонии. Был организован доступ как к российским, так и международным стандартам, можно было приобрести любое программное обеспечение и средства разработки. Кроме того, опыт создания цифровой телефонной станции давал возможность делать своё оборудование любой сложности. В общем, было круто. Почти точно так же, как у Стругацких в «Понедельник начинается в субботу».

Последние пару лет я пишу под ядро Linux и часто вижу, как люди страдают от незнания давнишних, общепринятых и (почти) удобных инструментов. Например, как-то раз мы отлаживали сеть на очередной реинкарнации нашего прибора и пытались понять, что за чудеса происходят с обработкой пакетов. Первым нашим позывом было открыть исходники ядра и вставить в нужные места printk, собрать логи, обработать их каким-нибудь питоном и потом долго думать. Но не зря я читал lwn.net. Я вспомнил, что в ядре есть готовые и прекрасно работающие механизмы трассировки и профилирования ядра: те базовые механизмы, с помощью которых вы сможете собирать какие-то показания из ядра, а затем анализировать их.

Недавно, в ходе работы над 100GE анализатором трафика передо мной была поставлена задача по изучению такого типа приборов, как Network Packet Broker (также встречается название Network Monitoring Switch), или, если просто и по-русски, «балансировщик».

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

Для тех, кому стало интересно, что же такого особенного в этом типе приборов, как они используются и почему именно «балансировщик» — прошу под кат.

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

Для чего это надо

Я работаю в российской компании НТЦ-Метротек, которая разрабатывает и выпускает кучу всякой аппаратуры (свичи, тестеры, балансировщики и т.д.) для систем связи, в том числе и тестеры для ethernet-сетей. Например, вот такой. Одним из параметров, измеряемых этим прибором, является задержка прохождения пакета в тестируемой сети. Ха, скажет читатель Хабрахабра — задержку можно и ping'ом померить. Так-то оно и есть, но при разной загруженности сети может быть разная задержка. Наш прибор может измерять задержку с точностью до нескольких наносекунд и при этом создавать нагрузку до 10 Гб/с.