Как стать автором
Обновить
622.54
YADRO
Тут про железо и инженерную культуру
Сначала показывать

Петля времени в пайплайне для уменьшения числа галлюцинаций в LLM

Это — грубая схема работа RAG-пайплайна, который использует одна из ML-команд в YADRO.

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

Что сделали инженеры?

Решили дообучить базовую модель при помощи LoRA на специально собранном датасете для ситуаций, когда в контексте нет ответа на вопрос пользователя. На тот момент в качестве базовой модели LLM использовали saiga_mistral_7b, которая нетребовательна к ресурсам и долгое время была в топе на Russian SuperGLUE. Есть модели лучше, но, как правило, они либо огромные, либо имеют проблемы с лицензией в России, в том числе все, что основаны на LLaMa.

Самое главное: в этом RAG-пайплайне ML-инженеры решили сделать опциональную петлю, в которой проверяли бы каждый найденный фрагмент контекста на релевантность вопросу пользователя. Только те куски контекста, которые пройдут проверку, будут попадать в финальный вопрос для LLM.

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

Что это и за маркер? И к каким результатам привела оптимизация работы модели, читайте по ссылке → 

Спойлер: Модель DeepSeek-R1-Distill-Qwen-7B уступила saiga_mistral_7b по качеству, несмотря на то, что первая намного новее и вооружена механизмом reasoning.

Теги:
+1
Комментарии0

Конкурентность в Go: просто запустить — сложнее управлять

Go предлагает удобный механизм конкурентности, позволяющий запускать задачи максимально просто — достаточно добавить go перед вызовом функции, и она начнет выполняться параллельно с основным потоком. Однако для эффективного использования такого кода важно правильно управлять синхронизацией: собирать результаты, обрабатывать ошибки и учитывать возможные сценарии выполнения. На практике этому аспекту часто уделяют недостаточно внимания.

Полезные материалы о конкурентности в Go можно найти в блоге Дейва Чени. Он рассматривает различные решения в Go, объясняя их происхождение и способы использования. В своих статьях он также подробно разбирает тему конкурентности.

Например, в статье Curious Channels Дейв Чени описывает два важных свойства каналов в Go:

  1. Закрытый канал не блокируется. После закрытия в него нельзя отправлять данные, но можно читать. Если данных нет, возвращается нулевое значение. Это удобно при использовании range, который автоматически завершает цикл.

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

В отличие от языков вроде C, где конкурентность управляется через блокировки и разделяемую память, в Go используются более простые и безопасные механизмы. Однако работа с каналами требует понимания нюансов.

Владислав Белогрудов, эксперт по разработке ПО в YADRO, собрал полезные материалы про конкурентность в Go. В статье — блоги, выступления и книги, которые помогут разобраться, как в Go работать с горутинами и каналами без хаоса и дедлоков.

Теги:
+5
Комментарии0

Готовим прошивки для BIOS. Нужно всего лишь...

В YADRO есть команда, которая разрабатывает и отлаживает UEFI для самых разных продуктов компании. Подробнее о ней — в видеоролике → .

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

Системы, для которых разрабатывают прошивки в YADRO, делятся на два типа: с BMC и без него.

Больше о работе команды и, в целом, об истории BIOS/UEFI читайте в статье → 

А если тоже хотите стать «поваром» UEFI, присмотритесь к одной из вакансий:

→ Старший/ ведущий разработчик на C++ (Linux/OpenBMC)

→ Старший разработчик на С (BIOS/UEFI)

→ Тимлид разработки в OpenBMC

Теги:
+4
Комментарии0

SystemVerilog отжил свое? На пятки наступает Scala/Chisel?

DARPA, управление перспективных исследовательских проектов Минобороны США, описывает Chisel как технологию, позволяющую маленьким командам создавать большие цифровые проекты. И я вполне могу с этим согласиться, но есть нюансы.

Chisel — это, по сути, библиотека Scala, а точнее, Domain Specific Language. Языку Scala уже больше 20 лет, он постоянно развивается, сочетает функциональное и императивное программирование. При написании кода на Scala вам доступны все библиотеки Java. 

Scala — это масштабируемый язык, который позволяет добавлять свои языковые конструкции. На основе Scala можно создать язык под свои задачи. Так 12 лет назад и поступили инженеры в Беркли: выкинули из Verilog 90%, оставив только нужное, и обернули все это в Scala. Получился Chisel. 

Chisel используют прежде всего для создания RTL-описаний. Также он позволяет проводить симуляцию несложных модулей. Это удобно для создания юнит-тестов и моделирования работы различных алгоритмов. В плане симуляции не стоит возлагать на Chisel такие же надежды, как на System C или что-то подобное. Симулировать вы сможете лишь очень маленькие схемки, а генерировать — хоть целые кластеры из тысяч процессоров, вообще все, что захотите.

На основе Chisel/Scala можно написать свой HLS-инструмент (High Level Synthesis), где одним росчерком пера вы будете создавать очень большие схемы, что с использованием одного Verilog невозможно.

В блоге YADRO Денис Муратов подробно сравнил Chisel/Scala с SystemVerilog в создании RTL-описаниях, раскрыл основные преимущества и недостатки альтернативы, а также ее дополнительные возможности — функциональное программирование и переиспользование модулей.

Теги:
+3
Комментарии0

Как не надо использовать Assert, если реализуете подход Design by Contract

Использовать Assert вместо if err != nil { return err}

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

Выполнять вычисления при вызове Assert

Еще одна распространенная и трудно выявляемая ошибка — это выполнение вычислений и присваивание значений переменным прямо при вызове Assert, которые могут быть упразднены при оптимизации кода компилятором:

  •  e.g. Assert(i++ > 0, “осторожно, не факт, что в релизе i увеличится”),

  •  Assert(call_to_f1(), “осторожно, не факт, что call_to_f1() будет вызвана в релизе”).

Удалять Assert, несмотря на то, что это часть описания контракта

Непонимание, что Assert — это реализация контракта, может привести к тому, что разработчик, незнакомый с DbC, захочет просто удалить проверку. Однако нужно всегда помнить, что срабатывание Assert говорит о нарушении контракта одной из сторон. То есть, если срабатывает Assert, надо прежде всего найти баг и пофиксить. А уж если контракт действительно должен быть изменен, Assert подскажет, где находятся участки кода, на которые нужно обратить внимание.

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

В реализации пакета Go 1.23 fmt-функция Printf всегда возвращает err = nil. И практически все игнорируют возвращающееся значение ошибки, тогда как могли бы проверять постусловие assertion.Assert (err == nil). Так, рано или поздно в последующих версиях можно научить код реагировать на err, отличный от nil.

Как правильно применять assertions, если реализуете подход Design by Contract для улучшения производительности кода в продакшене? Читайте в статье →

Теги:
+1
Комментарии0

Командное решение без долгих обсуждений: три проверенных метода

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

→ Голосование точками — быстрое выявление приоритетов

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

→ Степень поддержки — оцениваем и ранжируем

Этот метод предполагает, что каждый участник оценивает предложенные варианты по шкале, например, от 1 до 10. Чтобы решение считалось принятым, оно должно набрать средний балл выше установленного порога.

→ Метод NUF — объективный анализ вариантов

Этот метод помогает взвесить все «за» и «против», оценивая варианты сразу по трем ключевым критериям:

  • Новизна (New): насколько инновационно и оригинально это решение?

  • Полезность (Useful): решает ли оно реальную проблему?

  • Осуществимость (Feasible): есть ли ресурсы и возможности для реализации?

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

Как выглядит колода карт с методами принятия решений
Как выглядит колода карт с методами принятия решений

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

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

Теги:
+7
Комментарии0

Восставший из коррозии: реинкарнация одного «роботрона»

Лучший способ спасти печатную машинку — изготовить для нее новую материнскую плату взамен сгнившей. Тем более я нашел схему, инструкцию по эксплуатации, а также несколько сервисных мануалов для ее родственников. Нужно было только оцифровать схему в современной САПР и развести новую плату с некоторыми изменениями.

Вместо двух десятков мелких корпусов RAM и ROM я поставил по одной микросхеме памяти каждого типа, так как теперь это не дефицит. Особый интерес представлял последовательный порт RS-232 — на оригинальной плате он не был распаян, хотя функционал работы с ним в прошивке был! А значит, очень высок шанс, что интерфейс заведется.

Проект замерзает еще на пару лет, пока один из подписчиков, тов. Folk, не взялся за отрисовку платы в KiCAD. Месяц неспешной работы, и к январю 2022 года рождается она — новая плата для «Роботрона». Разрабатывалась плата один в один по габаритам старой, даже основные детали были на тех же самых местах. И тут я допустил три стратегических просчета...

Полная история восстановления и даже апгрейда Robotron S6130в статье Артёма Кашканова.

Теги:
+1
Комментарии0

Как тестируют чипы перед производством: что такое системная верификация 

Системы на кристалле (SoC) состоят из логических и функциональных блоков. Такое деление позволяет независимо разрабатывать разные части системы, а затем модульно отлаживать их в изолированном окружении. Функциональная верификация — это процесс тестирования таких блоков по спецификации. Она проводится перед отправкой чипа на завод и называется pre-silicon стадией. Без этой процедуры велик шанс получить нерабочий чип, причем в объемах всей произведенной партии.

Проводить тесты можно при помощи таких инструментов, как:

  • Функциональные симуляторы (например, QEMU) — работают очень быстро, но в отличие от других инструментов не предоставляют достоверной информации о работе устройства. Зато QEMU может почти молниеносно осуществить подачу требуемых данных и выдать результат в виде «прошел» или «не прошел», а также некоторые логи.

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

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

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

Как тестируют чипы на примере задач хакатона и как стать инженером по верификации, в статье рассказывают победители прошлогоднего SoC Design Challenge.

Теги:
+7
Комментарии0

Как работает современный RAID-массив: разбираем реализацию YADRO

Чтобы обеспечить доступность данных, T-RAID решает определенный набор задач.

Построение пула хранения на несколько петабайт. Эту возможность обеспечивает архитектура T-RAID: схемы расположения данных, реализация страйпов и allocation-групп дисков.

Оптимизация ребилда дисков и нагрузки на них. T-RAID проводит ребилд только реальных данных, а также распределяет нагрузку ребилда на несколько дисков. Здесь задействована обработка ошибок через блоки, а также фоновые процессы recovery и balancer. В распределении нагрузки помогает фоновый воркер rate limiter и адаптивный троттлер фоновых процессов.

Защита от выхода из строя аппаратных компонентов СХД (процессора, материнской платы, блока питания, контроллера, системного диска). Достигается посредством двухконтроллерной работы в режиме active-active. Тома блоков доступны на запись и чтение одновременно с двух контроллеров при балансировке нагрузки к лунам. Реализацию active-active мы раскроем в отдельной части материала.

Обеспечение отказоустойчивой работы с самими данными от получения запроса до записи в диск. Это реализуется с помощью integrity-механизмов.

Отработка отказов оборудования. Здесь возможно несколько сценариев разного масштаба — от потери отдельного диска до потери целого контроллера или интерконнекта.

О том, как в T-RAID реализованы все перечисленные технические средства, в своей статье подробно рассказал Вячеслав Пачков, ведущий инженер по разработке ПО в департаменте СХД YADRO.

Теги:
+3
Комментарии0

Быстрое трудоустройство в YADRO для разработчиков на С++

У нас стартовал SPRINT OFFER в команду разработки телеком-оборудования. Для «плюсовиков» это возможность получить предложение о работе всего за несколько дней. Если хотите пропустить долгие этапы собеседований, отправляйте заявку до 9 марта. 

Как все происходит

  1. Подаете заявку — мы оперативно рассматриваем анкеты.

  2. Проходите HR-скрининг и техническое интервью — без недель ожидания между этапами.

  3. Получаете оффер — если все этапы успешно пройдены, предложение будет у вас в течение 3 дней.

Где предстоит работать 

Дивизион телекома создает решения для мобильных сетей. Инженеры разрабатывают базовые станции GSM/LTE, полный стек телекоммуникационных протоколов, а также системы управления и мониторинга. Большую часть кода разработчики пишут на C++. В зависимости от задачи они используют как современные возможности C++20, так и низкоуровневые оптимизации для повышения производительности.

Кого мы ищем

→ Software Engineer (Telecom Platform)

Требуемый уровень: middle, senior, tech lead.

Чем предстоит заниматься:

  • Разработкой платформы для базовых станций LTE/GSM (middleware, high availability, node management, delivery).

  • Проектированием архитектуры, работа с C++/Linux.

  • Интеграцией с аппаратной и программной частью системы.

  • Оптимизацией кода и решение проблем производительности.

  • Разработкой API, unit-тестирование, документация.

→ Software Engineer C/C++ (LTE/GSM)

Требуемый уровень: middle, senior, tech lead.

Чем предстоит заниматься:

  • Разработкой программного обеспечения для базовых станций LTE.

  • Реализацией стека протоколов 3GPP.

  • Интеграцией с другими системами, оптимизация кода.

  • Решением задач производительности и стабильности системы.

Подробнее о вакансиях и команде читайте на странице SPRINT OFFER. Успейте подать заявку до 9 марта!

Теги:
+7
Комментарии0

Большой путь микросхемы: от расчета экономики до post-silicon verification

Первый шаг начинается с подготовки в САПР площади, «коробки», для размещения логики или подсистемы СнК — это так называемая зона ядра (core area). В ее границах расставляют большие макроблоки (PLL, аналоговые части больших интерфейсов вроде PCIe и т. п.), блоки статической памяти (SRAM), а также необходимые физические структуры, которые могут нести не только логические, но и другие функции — электрические, геометрические.

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

После подготовки core area и сетки питания, когда разместили контактные площадки, бампы, порты памяти и прочее, мы приступаем к автоматизированным этапам. Первый — размещение стандартной логики и ее оптимизация. Мы получаем логику как результат логического синтеза RTL и размещаем на реальной площади.

После размещения логики нужно провести трассировку ее межсоединений. В зависимости от инструментария это можно делать в той же самой САПР или в другом софте. Здесь виртуальные цепи становятся физическими. Чтобы при трассировке сигналов не пострадали их задержки, нужно просчитать их длину, влияние друг на друга, оптимизировать число переходов между слоями, при необходимости переставить некоторые стандартные ячейки ближе друг к другу.

Весь путь разработки ASIC и SoC глазами тополога — специалиста по физическому дизайну — описал в своей статье Илья Пеплов из дивизиона полупроводников YADRO. А если вы уже чувствуете в себе силы попробовать разработку микросхем на практике, приглашаем на хакатон SoC Design Challenge.

Теги:
+5
Комментарии0

Обойдемся и без Terraform: внедряем GitOps-подход для виртуальных машин

Источник

Для работы с OpenStack удобно использовать Terraform. Хотя компания Hashicorp прекратила свою деятельность на территории России, нам все еще доступен open source-форк под говорящим названием OpenTofu. Он позволяет автоматизировать создание виртуальных машин на основе текстовых файлов конфигурации. Схема его работы примерно такая:

  1. В GitOps-репозитории находятся terraform-файлы с описанием параметров виртуальных машин и DNS.

  2. На основе этих файлов формируются конфигурации для новых ВМ.

  3. Все изменения вносятся через pull request, а их корректность проверяется автоматическими запусками тестов в CI.

  4. После слияния изменений CI запускает процесс приведения нового желаемого состояния репозитория к действительному.

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

В своей статье Кирилл Яшин рассказывает, как с нуля реализовать такой подход к виртуальным машинам, используя провайдеры для работы с OpenStack и DNS.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Ни единого разрыва: как ваш смартфон переходит из 4G в 3G или 2G

Сотовые операторы в России обслуживают более 260 миллионов абонентов (активных SIM-карт), а их сети работают с тремя поколениями технологий мобильной связи. Разберемся, как почти незаметно для нас смартфон переходит из LTE (4G) в 3G. А если базовой станции третьего поколения в зоне доступа не оказалось, то устройство подключается к 2G-сети.

Большинство операторов для взаимодействия между технологиями мобильной связи в части сервисов передачи данных используют архитектуру с Gn/Gp SGSN:

Мобильный трафик идет от абонента до базовой станции по радиоинтерфейсу и далее по транспортной сети оператора связи до шлюзов SGW и PGW — только потом выходит в интернет. Трафик на радиоинтерфейсе между устройством и базовой станцией, как правило, зашифрован, например, широко распространенным протоколом AES.

Трафик между базовой станцией и шлюзом SGW может быть зашифрован с помощью IPsec. Оператор анализирует трафик с помощью системы глубокого инспектирования трафика DPI. Эту систему реализуют на шлюзе PGW или на отдельном сетевом элементе — это так называемый standalone DPI.

Обычно для передачи мобильного трафика служит несущая по умолчанию (default bearer), которая позволяет подключиться к пакетным услугам. Несущая по умолчанию всегда является non-GBR, то есть не гарантирует скорость передачи данных. Поэтому при увеличении количества пользователей, которые подключены к одной базовой станции, скорость мобильного интернета снижается для каждого устройства. 

Для голосовых вызовов по сети LTE (VoLTE) используются две несущие. Первая — несущая по умолчанию с QCI5 для сигнальных сообщений. Вторая — выделенная несущая с гарантированной полосой пропускания (QCI1) для голосового трафика.

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

Если 4G-покрытие от обслуживающей базовой станции ухудшается и рядом нет соседней 4G-станции, то устройство с помощью процедуры handover переводится на 3G-станцию либо перенаправляется на 2G-станцию.

В посте мы рассказали о взаимодействии различных технологий в части сервисов передачи данных. Михаил Бухтеев, который в YADRO отвечает за планирование функционала базовой станции LTE, подробно объясняет в статье, как передаются голосовые вызовы и как устроены мобильные сети.

Теги:
Всего голосов 6: ↑6 и ↓0+10
Комментарии0

Дашборд — лицо системы: как сделать его удобным для команд из более 100 инженеров

Дашборд в версии 2.0
Дашборд в версии 2.0

Переосмысление дашборда стало одной из важных задач в процессе обновления интерфейса TMS TestY.

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

В Testy 2.0 можно выбрать, на каком языке будет работать система. Раньше интерфейс TMS был полностью англоязычным, теперь пользователям доступен русский язык — как часть плана поддержки локализации.

Добавили поиск по проектам и табличное представление, в котором доступно то же самое, что и на карточках: переходы, добавление в избранное, переключатели Only Favorites и Show Archive

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

Какие еще обновления появились в TMS с открытым исходным кодом, читайте в статье.

Теги:
Всего голосов 3: ↑3 и ↓0+4
Комментарии1

А ты такой холодный: представим технологии Rust-дебаггеров в виде айсберга

На верхушке айсберга видим технологии DWARF, PTRACE и ELF, а внизу — набор более редких технологий. 

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

PTRACE — системный вызов, который позволяет одному процессу (tracer) управлять и исследовать другой процесс (tracee).  

ELF (Executable and Linkable Format) — формат исполняемых двоичных файлов. 

DWARF (Debugging With Arbitrary Record Formats) — стандарт, описывающий формат .debug_xxx секций в ELF.

Что касается «подводных» технологий, упомянутых на картинке: применяя закон Парето, можно смело сказать что 80% знаний необходимы, чтобы реализовать только 20% функционала (и не самого важного). Но если хотите узнать о них больше, напишите в комментариях.

Подробнее о PTRACE, ELF и DWARF, а также о функциях, которые они реализуют в отладчиках на Rust, читайте в статье.

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

Учимся в сетевые интерфейсы на Linux: руководство по netlink

В интернете я нашел всего одну статью, где описывали мониторинг сетевых портов. Это был хороший старт, но для решения моей задачи информации оказалось недостаточно. Уже во время написания этой статьи я нашел еще пару материалов, которые, как я рассчитываю, хорошо дополнят мой. Помимо статей, нашел несколько man-страниц, в которых описаны пакеты, параметры, структуры и даже есть примеры кода. Оттуда я взял готовый код, способный получать информацию о появлении нового интерфейса и добавлении его в vlan. Но задача требовала отслеживать намного больше параметров системы.

Следующая остановка — пакет iproute2. Iproute распространяется под GNU GPL 2, так что я скачал исходники, собрал их и начал разбираться в коде на C. Чтобы проще понимать логику, я удалял некоторые участки кода, в которые при вызове моей функции программа не входила. Затем пересобирал программу и продолжал изучение и трассировку. Так я понял общий принцип обработки пакетов и сделал обработку пары дополнительных параметров. Но оставалось еще много других условий.

В какой-то момент я вспомнил про утилиту strace: с ней стало проще изучать код и ориентироваться в нем. Strace позволяла увидеть финальный этап работы функции и все ее параметры. Решая свои задачи, я копировал и адаптировал код из iproute. Я не особо вникал во внутреннее устройство протокола, но с каждым этапом разработки это становилось все сложнее и сложнее.

Наконец, я сделал обработку всех параметров кроме одного. В функции его обработки в iproute вызывалась обработка какого-то системного файла, и это было очень странно, так как я видел этот параметр в сообщении netlink через strace. Я зашел в тупик. Код выглядел очень страшно и совсем не нравился мне. Покопавшись в этом еще один день, я понял, что так продолжаться не может. Я решил переписать все заново без использования кода из iproute. Хотел сделать код красивым и максимально понятным для тех, кто будет читать его после меня.

О том, как с помощью netlink узнать, что именно делает система при настройке сетевых интерфейсов и как обрабатывать ее команды, читайте в статье Тимура Аммаева.

Теги:
Всего голосов 2: ↑2 и ↓0+3
Комментарии1

«Плюсовое» чтиво: ежемесячная рассылка о разработке на С++

Инженеры YADRO пишут не только статьи, но и письма о «плюсах». Подписчики рассылки раз в месяц получают короткую заметку о том, что важно или интересно разработчикам на С++. Какие письма уже выходили:

— Подборка лучших выступлений с Zero Cost Conf с комментариями Константина Владимирова.
— Презентация новой книги Кирилла Колодяжного о машинном обучении на С++.
— Совет, как избежать проблемы с лямбда-корутинами от ведущего инженера Елены Степановой.

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

Подписаться на рассылку →

Теги:
Всего голосов 2: ↑2 и ↓0+3
Комментарии2

Как и зачем дублировать Intel NTB Gen3 в QEMU

Системным программистам в YADRO нужно было «обмануть» драйвер в Linux: он не должен «знать», что работает в эмуляции. 

Для этого ведущий инженер Никита приступил к созданию виртуального двойника Intel NTB Gen3 в QEMU, документации к которому в открытом доступе нет. Реализованная модель позволяет производить разработку и тестирование протоколов более высокого уровня, а также выполнять их качественное сравнение.

PCIe NTB не позволяет увидеть адресное пространство, которое принадлежит к подключенному по NTB соседнему устройству. Вкратце он работает так:

  • перенаправляет трафик PCIe между шинами как мост,

  • CPU рассматривает мост как конечное устройство,

  • CPU не «видит» все устройства на «другой» стороне, как правило, другая сторона — это другой компьютер.

Упрощенное представление PCIe NTB
Упрощенное представление PCIe NTB

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

В работе с PCI BAR необходимо обеспечить прозрачное использование Linux-драйвера Intel NTB для оптимального взаимодействия с оборудованием, которое мы эмулируем. Еще одна задача — разработать новые транспорты, которые работают поверх эмуляции: RPMSG, Virtio/Vhost, NTRDMA и другие. Также одна модель помогла найти ошибки в инициализации драйвера.

Никита подробно описывает тернистый путь создания виртуального двойника Intel NTB Gen3 в статье →

Теги:
Всего голосов 5: ↑5 и ↓0+7
Комментарии0

Тренажер для инженеров: зачем опытным специалистам участвовать в робототехнических хакатонах

Представьте: у вас есть всего сутки, ограниченный набор компонентов и команда из четырёх человек. Ваша задача — создать подводного робота, который должен пройти лабиринт, преодолеть все препятствия и сделать это быстрее остальных. Именно в таком формате проходил робототехнический хакатон Robotics Tournament во Владивостоке.

Команда «Траектория паяльника» завоевала второе место, и во многом этому способствовала грамотная подготовка. Они заранее собрали комплект компонентов — аккумуляторы, контроллеры, датчики и даже клей. Это позволило не тратить время на поиск решений на месте, а сосредоточиться на проектировании и программировании.

«Мы старались предугадать, что может понадобиться, основываясь на открытом регламенте хакатона», — рассказывает младший инженер-программист YADRO Илья Чешко. В условиях жёстких временных ограничений такой подход оказался ключевым фактором успеха.

Как распределить роли в команде, справиться с неожиданными сложностями и создать работающего робота всего за сутки? В новом материале история инженеров, которые превратили хаос хакатона в слаженную работу команды и добились результата, читайте по ссылке →

Теги:
Рейтинг0
Комментарии0

Для точности ваших математических библиотек принимайте «Ульп». «Ульп» — и тесты не страшны!

Числа с плавающей точкой расположены неравномерно. У нас есть результат вычисления математической функции, число с плавающей точкой, и есть «эталон» — это ожидаемый результат в квазибесконечной точности. Но как понять, насколько велика погрешность вычисления, расстояние между ними?

Для этого достаточно договориться о единице измерения. Расстояние между соседними числами обозначается как 1 ульп (ulp — unit in the last place). Относительно него и будем оценивать погрешность вычисления математической функции. Поделим расстояние от результата до эталона на то, что является одним ульпом — то есть на расстояние от эталона до соседнего числа той же точности. Стандарт libm требует, чтобы ошибка не превышала 0,5 ульпа с учетом округления. 

Мы договорились о единицах измерения. Но остался еще один вопрос: с чем же мы сравниваем результаты? Откуда брать эталон в квазибесконечной точности? Здесь помогут системы компьютерной алгебры — прикладные программы для символьных вычислений и числовых операций произвольной точности.

Из таких систем ученые особенно любят Maple или Scilab, инженеры — Mathcad или Matlab, а разработчики — Sollya, поскольку эта библиотека имеет удобный C-интерфейс и ее можно вызывать прямо из тестов libm.

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

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

Читать статью →

Теги:
Всего голосов 2: ↑2 и ↓0+3
Комментарии0

Информация

Сайт
yadro.com
Дата регистрации
Дата основания
Численность
5 001–10 000 человек
Местоположение
Россия
Представитель
Ульяна Соловьева