Данная статья является логичным продолжением предыдущей и её прочтение рекомендуется после ознакомления с предшествующим материалом. Текущая заметка необходима для понимания последующего материала, дополнительного понимания подсистемы gpio в целом и способствует разработке собственных gpio драйверов. Положения данной статьи уже применимы не только к нашему виртуальному драйверу gpio, но и к любому mmio gpio драйверу в целом. Речь пойдет об упомянутой в предыдущей части "оптимизации".

Немного предыстории

Преамбула

Некоторе время назад перед нами стала задача спроектировать и развернуть систему для потокового видео. Суть была в массовом запуске/остановке инстанций, на которых происходит обратная сборка потокового видео и стриминг на множество media cdn провайдеров (youtube, livestream, ustream итд ) а также на собственные rtmp и ts точки назначения. Каждая инстанция требовала настройки перед запуском т.к. содержала специфическую для каждого клиента информацию. Также было понятно, что система должна работать в большом количестве регионов (как минимум во всех точках, где присутствует Амазон, а как максимум — в любом месте где можно арендовать сервер). Также основное требование — запуск инстанции в течении 1-2 секунд максимум, чтобы это было прозрачно для пользователя.

Каждый должен делать свою работу качественно и в срок. Допустим, вам нужно сделать веб-сервис классификации картинок на базе обученной нейронной сети с помощью библиотеки caffe. В наши дни качество — это асинхронные неблокирующие вызовы, возможность параллельного исполнения нескольких заданий при наличии свободных процессорных ядер, мониторинг очередей заданий… Библиотека RQ позволяет реализовать все это в сжатые сроки без изучения тонны документации.

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

Несколько лет назад я уже выкладывал статью о том как из роутера сделать сетевую звуковую карту. Тот вариант требовал наличия активного источника звука и колонок. Переносной вариант выглядел бы слишком громоздким, потому было решено приобрести готовый продукт. По причине доступности и как самое дешевое из возможных вариантов (50 евро) я выбрал renkforce IR 1.

Из ключевых характеристик мне были важны следующие:

• DLNA (возможность прямого воспроизведения через pulseaudio)
• WiFi (802.11bg)
• AUX
• Пульт
• Хороший звук
• Экран
• Возможность создавать свой плейлист
• USB

Отчёт о новых функциях свободного графического редактора

• обновленный интерфейс;
• серьёзные улучшения в управлении цветом;
• готовый к использованию инструмент MyPaint Brush;
• симметричное рисование;
• сплит-превью для фильтров на GEGL.

Раз Swift компилируется в нативный код, то почему бы не попробовать на нём написать модуль ядра? Всех заинтересовавшихся просьба под кат!

cron -f

• неудобство просмотра логов (команда docker logs не работает)
• cron использует свой собственный Environment (переменные окружения, переданные при запуске контейнера, не видимы для cron заданий)
• невозможно нормально (gracefully) остановить контейнер командой docker stop (в конце концов в контейнер прилетает SIGKILL)
• контейнер останавливается с ненулевым кодом ошибки

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

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

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

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

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

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

Что мы будем делать

CREATE TABLE Messages (
    message_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    created_ts DATETIME,
    message_text BLOB
)

Предлагаю вашему вниманию перевод статьи What are Docker none:none images? из блога Project Atomic.

Последние несколько дней я потратил на упражнения с образами Docker <none>:<none>. Чтобы объяснить, что они собой представляют, и что могут натворить, я пишу этот пост, в котором ставлю вопросы:

1. Что собой представляют образы Docker <none>:<none> ?
2. Что собой представляют обособленные (dangling) образы ?
3. Почему я вижу кучу образов <none>:<none>, когда делаю docker images -a ?
4. В чем разница между docker images и docker images -a ?

Прежде чем я начну отвечать на вопросы, запомните, что есть два вида образов <none>:<none>: хорошие и плохие.

Вступление