Парсер Хабра: 2020-10-11

суббота, 17 октября 2020 г.

[Из песочницы] Быстрый старт в видеоаналитику: Опыт использования OpenVINO Toolkit в хакатонах

Всем привет! Мы активные студенты НГТУ им. Р.Е. Алексеева, и мы хотим рассказать о своем опыте участия в хакатонах и создании IT-решений с использованием набора инструментов Intel – OpenVINO (Open Visual Inference & Neural Network Optimization) – отличной палочки-выручалочки при разработке систем видеоаналитики.

Для начала расскажем немного о себе. Мы студенты 3 курса ИРИТ, кафедра «Информатика и систем управления» – Татьяна Бородина, Тимофей Карклин, Александр Зенкин и Владимир Салтыков. С 1 курса мы активно участвуем в различных конкурсах IT-сферы, создав команду MirITeam^{[Прим. модератора: ссылка убрана, чтобы не нарушать правила. Google it.]} – команду молодых и целеустремленных ребят. Мы разрабатываем стартапы в области компьютерного зрения и видеоаналитики, выступаем на научных конференциях и очень любим Хакатоны, их атмосферу и дух соревнования, где быстро нужно разработать хорошее, качественное решение, привнести в него «изюминку», и успешно (из опыта – это очень и очень важно) защитить свой проект перед жюри. Это ценный опыт реализации инновационных идей, получения новых знаний и качеств и, конечно же, командного сотрудничества.

Поделимся впечатлениями о последнем хакатоне, где мы участвовали –региональном этапе Всероссийского конкурса «Цифровой прорыв», где в рамках кейса ПАО «Ростелеком» мы занялись разработкой системы мониторинга за поведением студента во время экзамена год назад и предположить не могли, что это будет актуально и даже прикольно – сами выступаем в рамках испытуемых.

Итак, наш кейс и его защита выглядит так.

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

Наша система использует инструментарий Intel в виде моделей OpenVINO для видеоаналитики (о них мы расскажем чуть более подробно ниже), работу с процессами компьютера, контроль кликов и скроллингов, а также ближайшие соединения по протоколу Bluetooth. Использование последних методов исключает не только возможность использования таких сторонних ресурсов, как открытые вкладки браузера с подсказками, любые текстовые инструменты, но и использование дополнительных систем связи (Discord, Skype, Zoom и т.п.). Обнаружение всех этих «аномалий» поведения максимально исключает использование уловок и значительно повышает честность сдачи дистанционного экзамена.

После того, как мы поставили перед собой задачу, требующую решения, началось обсуждение способов анализа параметров студента – и сразу всем в голову пришло одно и тоже – это классный случай использования библиотеки OpenVINO и репозитория предварительно обученных моделей Open Model Zoo это наш помощник и даже преданный «сообщник» в кейсе по анализу параметров студента.
Мы использовали каскад из глубоких моделей (facial-landmarks-35-adas, head-pose-estimation-adas, open-closed-eye, gaze-estimation-adas), что в режиме реального времени позволило находить ключевые точки лица и анализировать такие параметры студента, как положение головы и направление движения его глаз. Кроме того, для аутентификации студента и исключения появления посторонних людей в кадре мы использовали Single Shot MultiBox Detector, а именно его Caffe реализацию для быстрого переобучения под конкретного человека и сравнения с полученным с камеры через метод опорных векторов (SVM алгоритм).

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

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

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

По итогу наш проект вошел в шорт-лист и прошел во Всероссийский финал конкурса «Цифровой прорыв», где мы еще поборемся за звание победителей. Сам проект на данный момент дорабатывается: дополняется интерфейс и его функциональность. Но система уже и сейчас является жизнеспособной. Надеемся в ближайшее время опробовать нашу систему на кафедре «Информатика и системы управления», а позже, возможно, ранжировать на наш институт радиоэлектроники и информационных технологий и весь университет, город и даже страну.

По итогу разработчикам мы очень советуем заглядывать в репозиторий c готовыми демо-приложениями и моделями OpenVINO не только в рамках конкурсов с использованием компьютерного зрения и видеоаналитики, но и при построении серьезных приложений, ну а студентам напомним слова Бенджамина Франклина: «Незнание не стыдно, стыдно не стремиться к знаниям».

Let's block ads! (Why?)

[Перевод] Лидары для автомобилей стоили $75.000, а теперь лидары будут в каждом iPhone

Как Apple удалось создать доступные лидары без движущихся частей для iPhone

На презентации iPhone 12 во вторник Apple представила возможности нового лидара. По словам Apple, лидар позволит усовершенствовать камеру iPhone за счёт ускорения фокусировки, особенно в условиях низкой освещённости. Возможно, таким образом появится новое поколение сложных AR-приложений.

Во вторник на презентации было рассказано о том, как работает лидар в iPhone, хотя это не первое устройство с лидаром от Apple. Впервые компания представила устройство, использующее эту технологию, в марте – это был обновленный iPad. И хотя пока еще никто не успел разобрать iPhone 12, мы можем многое узнать из недавних разборок последнего iPad.

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

Июньский анализ, проведенный компанией «System Plus Consulting», показал, что лидар в iPad посылает свет, используя матрицу вертикально-излучающих лазеров (VCSEL), изготовленную компанией «Lumentum». Затем он фиксирует обратную вспышку, используя массив однофотонных лавинных диодов (SPAD), поставляемых компанией Sony. Я объясню что это такое в следующем разделе.
Я нашел презентацию Apple особенно интересной, потому что я работал над текстом о компаниях, которые используют эти технологии (VCSEL и SPAD) для создания гораздо более мощного лидара для автомобильного рынка. Вертикально-излучающие лазеры и однофотонные лавинные диоды интересны тем, что они могут массово изготавливаться с использованием обычных технологий производства полупроводниковых приборов. Таким образом, выгода возникает за счет огромной экономии на производстве в больших объемах. По мере того, как растет распространенность датчиков на основе лазеров с вертикальным излучением, будет расти их качество (а цена будет снижаться).

Две компании, работающие над топовыми лидаром на основе лазеров с вертикальным излучением (Ouster и Ibeo) уже сейчас получают больше поддержки, чем большинство игроков на тесном рынке лидаров. Решение Apple о принятии этой технологии (и возможность того, что другие производители смартфонов последуют примеру Apple), обеспечит им попутный ветер в ближайшие годы.

Лазеры с вертикальным излучением позволили Apple создать очень простые лидары

Компания Velodyne стала пионером на рынке лидаров, выпустив 64-лазерный датчик

Первый трехмерный лидар был представлен компанией Velodyne более десяти лет назад. Вращающееся устройство стоило около 75 000 долларов и по габаритам было значительно больше смартфона. Apple должна была удешевить и уменьшить лидары, чтобы их можно было вставлять в iPhone, и лазеры с вертикальным излучением позволили компании этого добиться.

Что такое лазер с вертикальным излучением? Если вы создаете лазер, используя традиционные методы производства полупроводниковых устройств, у вас есть две основные технологии. Вы можете сделать лазер, излучающий свет со стороны подложки (такие называют лазерами с торцевым излучением) или сверху (лазеры поверхностного излучения с вертикальным резонатором – VCSEL).

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

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

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

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

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

В свою очередь, Apple, Ouster и Ibeo производят лидары без движущихся частей. Лидары на основе чипов с сотнями/тысячами лазеров с вертикальным излучением могут использовать отдельные лазеры для каждой точки в поле зрения датчика. А поскольку все эти лазеры предварительно упаковываются на одном чипе, сборка этих устройств намного проще по сравнению с лидарами от Velodyne.

В последних моделях iPhone использовался еще один трехмерный датчик под названием TrueDepth Camera – он обеспечивал работу функции FaceID. Также сообщается, что в этом модуле использовался массив лазеров с вертикальным излучением от Lumentum. Принцип работы TrueDepth заключается в проецировании 30 000 точек на лицо пользователя для формирования трехмерной модели и сравнения сохраненной модели с полученной (с учетом ее деформаций).

Лидар в iPad проецирует намного меньше точек, чем камера TrueDepth. Видео от iFixIt, снятое ИК-камерой показало, что лидар проецирует сетку размерностью в несколько сотен пикселей. При этом если датчик TrueDepth распознавал глубину на основе формы света, падающего на лицо человека, то лидар в iPad измеряет расстояние напрямую, засекая время на полет света до объекта и обратно. Такой подход, вероятно, обеспечивает более высокую точность измерения глубины, а также увеличивает дальность работы датчика.

В более мощных лидарах также используются лазеры с вертикальным излучением (VCSEL) и однофотонные лавинные диоды (SPAD)

Лидары OS-1 и OS-2 от Ouster

Производительность лидаров от Apple намного ниже, чем у топовых датчиков, производимых компаниями, специализирующимися на лидарах. Velodyne, компания выпустившая первый трехмерный лидар, утверждает, что их датчик может работать с дальностью в 200 метров, в то время как датчик от Apple работает с дальностью 5 метров.

Многие лидары, использующие лазеры с вертикальным излучением, более мощны чем датчики, которые используются в устройствах от Apple. Например, самый мощный лидар от Ouster на основе VCSEL-лазеров может похвастаться дальностью около 100 метров при 10-процентной отражательной способности.

Все нынешние датчики от Ouster похожи на вращающиеся устройства от Velodyne. В них используются чипы, в которых установлены от 16 до 128 лазеров с вертикальным излучением – эти чипы устанавливаются столбцами на вращающейся основе. Простота этой цельной конструкции позволила Ouster снизить цену своих устройств и стать одним из крупнейших конкурентов Velodyne. Впрочем, эти датчики все еще стоят тысячи долларов – слишком дорого для использования в автомобилях, не говоря уже о смартфонах.

На прошлой неделе Ouster объявила о планах выпустить новый твердотельный лидар без движущихся частей. Вместо того, чтобы выставлять в ряд от 16 до 128 лазеров, в новом устройстве от Ouster будут использоваться 20 000 лазеров с вертикальным излучением, расположенных в двумерной сетке.

Ibeo придерживается аналогичной стратегии и может превзойти Ouster. Компания Ibeo разработала самый первый лидар, когда-либо поставляется на рынок автомобилей массового потребления — датчик для Audi A8. Это было абсолютно примитивное устройство с разрешением всего в 4 линии по вертикали. Сейчас компания занимается разработкой нового устройства под названием IbeoNext. Данная модель будет иметь лазерную сетку размером 128 на 80 пикселей – чуть меньше чем в проектируемом датчике от Ouster, но значительно больше, чем в последних устройствах от Ibeo. Компания утверждает, что ее новый датчик будет иметь дальность работы 150 метров и 10-процентную отражательную способность.

Последний игрок, о котором стоит упомянуть – Sense Photonics, компания, о которой мы рассказывали еще в январе. Как и другие компании, о которых мы говорили, Sense в своих лидарах использует лазеры с вертикальным излучением и однофотонные лавинные диоды. При этом, при работе с лазерами Sense используют технологию, которая называется микротрансферной печатью. С ее помощью лазеры могут потребять больше энергии, не перегреваться и оставаться безопасными для человеческих глаз. Пока что устройства от Sense не отличались большой дальностью работы, но генеральный директор компании Шона Макинтайр сказала Ars, что компания стремится разработать датчик, работающий с дальностью 200 метров – об этом устройстве Sense объявит в начале 2021 года.

Лидары скоро ворвутся на автомобильный рынок

Лидар от Ibeo

Ibeo, Sense и Ouster выпускают новые недорогие модели, поскольку ожидают резкого роста спроса со стороны автомобильной промышленности. Лидары могут значительно улучшить ADAS-системы.

Например, многие считают, что у Tesla одни из передовых ADAS-систем в индустрии. При этом у компании есть постоянная проблема – ее автомобили врезаются в неподвижные объекты, иногда со смертельным исходом. Лидары справляются с обнаружением неподвижных объектов лучшем, чем камеры и радары, а значит внедрение лидаров может предотвратить множество аварий, за счет чего системы ADAS будут более полезными для водителей.

До нынешних времен считалось, что лидары слишком дороги для автомобильного рынка, но ситуация меняется. Некоторые компании обещают, что в следующие несколько лет выпустят лидары, стоящие менее 1000 долларов.

Ouster планирует подготовить свой датчик ES2 к массовому производству для автомобильной индустрии в 2024 году. Компания заявляет, что изначально устройство будет стоить 600 долларов, а в будущем цена снизится до 100.

Ibeo не объявила цену на IbeoNext, но компания заявляет, что уже заключила сделку с Great Wall Motors (крупным автопроизводителем в Китае) о начале серийного производства в 2022 году.

Компании, не использующие лазеры с вертикальным излучением, также устремились на этот рынок. Одной из наиболее известных компаний в этом пуле является компания Luminar – она объявила о сотрудничестве с Volvo в мае. Volvo планирует выпустить автомобили с лидаром от Luminar в 2022 году.

Все эти конструкции имеют свои сильные и слабые стороны (причем разные). Пока что Luminar может похвастаться значительной дальностью – целых 250 метров. Возможно дело в том, что Luminar использует лазеры с длиной волны 1550 нм, которая находится далеко за пределами диапазона видимого света. Жидкость в человеческом глазу непроницаема для такого света, а значит Luminar может использовать мощные лазеры, которые не будут опасны для человеческих глаз. Также у лидаров от Luminar более широкое поле зрения, чем у устройств от Ouster.

Самый большой вопрос к Luminar – смогут ли они уложиться в заявленную цену, равную 1000 долларов. Когда я два года назад брал интервью у генерального директора Luminar Остина Рассела, он сказал, что Luminar нужно будет «снизить цену до нескольких тысяч», чтобы выйти на массовый рынок. Тогда я предположил, что лидар от Luminar стоит больше, чем «несколько тысяч». Теперь же компания утверждает, что цена на их лидары упадет ниже 1000 долларов.

Ouster и Ibeo же не имеют проблем с тем, чтобы сделать свои устройства дешевыми. Вероятно, у компаний возникнет проблема с достижением дальности работы в 200 метров – считается, что она необходима для работы на скоростях езды по магистрали.

«Лазеры с вертикальным излучением уступают по яркости тем лазерам, что используются в привычных лидарах», – так мне сказал генеральный директор Ouster Ангус Пакала. «Если вы создадите физическую модель, подключите однофотонный лавинный диод и лазер с вертикальным излучением, то в результате получите невысокую производительность». Впрочем, Пакала сказал, что Ouster разработала ряд «фундаментальных решений на разных уровнях», которые могут заставить это сочетание работать. Пакала сказал, что в перечень этих решений входят «исключительное» подавление света, выбивающегося из диапазона, и «размещение устройств обработки сигнала рядом с диодами», что помогает отличить возвращающиеся лазерный свет от шумов.

Таким образом, в ближайшие годы Ouster, Ibeo и Sense столкнутся с большой проблемой: развить производительность сочетания лазеров с вертикальным излучением и однофотонных лавинных диодов до такой степени, чтобы их устройства могли работать с дальностью в 200 метров. Если им удастся решить эту задачу, то низкая стоимость и простота чипов дадут этим компаниям решающее преимущество. Если же им не удастся, то они могут опуститься на более низкий уровень этого рынка.

Вакансии

НПП ИТЭЛМА всегда рада молодым специалистам, выпускникам автомобильных, технических вузов, а также физико-математических факультетов любых других высших учебных заведений.

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

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

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

О компании ИТЭЛМА

Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

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

Список полезных публикаций на Хабре

Let's block ads! (Why?)

[Из песочницы] Модель адаптивного усвоения углеводов искусственной поджелудочной железы AIAPS

Друзья, команда проекта AIAPS разрабатывает систему искусственной поджелудочной железы или ИПЖ.

Искусственная поджелудочная железа — это система автоматизированной доставки инсулина в организм человека, страдающего инсулинозависимым диабетом, включающая мониторинг глюкозы, инсулиновую помпу и центр принятия решений (такой, как приложение AIAPS).

AIAPS это приложение — центр управления ИПЖ, цель которого: регулирование глюкозы крови и удержание ее в целевом диапазоне. Для достижения целей система строит прогноз глюкозы крови, используя линейную логику и нейронные сети.

При разработке приложения, команда проекта делает особый акцент на безопасность использования системы.
Функцией AIAPS, которой посвящена данная статья является адаптивная (ее еще называют динамическая) модель усвоения углеводов.

Исходная точка

Начнем с того, что девять месяцев назад в AIAPS была внедрена модель действия углеводов, зависящая от времени разложения углеводов разных типов, а именно:

1 тип — углеводы с длительностью 60 минут и пиком 25 минут
К таким можно отнести Кока-колу, леденцы, сахар и т.п.
2 тип — углеводы с длительностью 120 минут и пиком 40 минут
Например, это может быть конфета или белый хлеб.
3 тип — углеводы с длительностью 180 минут и пиком 60 минут
Это комплексное питание, например гречка с мясом.
4 тип — углеводы с длительностью 240 минут и пиком 70 минут
Жирная и белковая пища в большом объеме.

Мы тестировали эту модель в течение 6 месяцев, постоянно отмечая длительность, но вскоре столкнулись со следующими сложностями (помимо того, что введение длительности усложняет запись углеводов).

Во-первых, например, мой комплексный обед с гречкой и мясом включает больше 100 углеводов (любое большое количество для вас), мы заметили, что в этом случае неверным будет указать длительность углеводов 180 минут. А по прошествии этих 180 минут повышение глюкозы продолжится и явно — триггером этого повышения являются углеводы.

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

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

В-третьих, мы посчитали, что несмотря на сложность углеводов, с момента начала приема углеводов, их пик придется примерно на 25-30 минут. Этот пункт не вяжется, вверху написано сложности, а это просто наше допущение.

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

Все это навело на мысль о доработке ранее заложенной модели, которая тем не менее давала хорошие результаты.

Новое решение

Мы решили провести исследование и увидеть реальную модель разложения углеводов.
Для этого, мы реализовали модель адаптивного усвоения углеводов или модель адаптивных углеводов (МАУ).

Ниже вы можете видеть пример первой визуализации отражения адаптивной подели.

Картинка 1: Скрин экрана программы, показывающей разложение углеводов

Обратите внимание на отличия между стандартной моделью (фиолетовый, считывание 1 раз в минуту) и усвоенными углеводами (зеленый, считывание 1 раз в 5 минут). Модель отличается и это прекрасный пример того, как в действительности действуют углеводы.

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

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

Как происходят вычисления

Первы этап — прогноз глюкозы на основе текущих коэффициентов, инсулина и углеводов на борту,
Второй этап — получение значений глюкозы.

Далее, мы вычисляем разницу между прогнозом и реальными значениями и получаем дельту МАУ.

После получения дельты МАУ, мы причисляем ее:

К углеводам
К их отсутствию
К активности.

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

Регулировка согласно полученным данным будет осуществлена в следующих вариантах.

Действие углеводов началось, разрешена подача инсулина, присвоенного на разложение углеводов.
Действие углеводов не началось вовремя, в этом случае их действие может быть продлено на 1,5 часа.
Действие началось, но не в ожидаемом объеме, в этом случае остаточный инсулин будет подан согласно потопающему количеству углеводов по факту.

На что направлена разработка

Модель адаптивных углеводов это попытка освободить пользователя от таких утомительных задач, как:

точный подсчёт углеводов
подсчет белков
подсчёт перекусов

А также способ более безопасно вводить инсулин.

Технические детали

Установка и использование искусcтвенной поджелудочной железы AIAPS cегодня возможно на устройствах с ОС Андроид (версии выше 6.0) и вскоре станет возможно на IOS платформе. Виpуализация разложения углеводов находится в стадии тестирования и устанавливается отдельной программой на Windows. Система протестирована пользователями на устройствах Samsung, Xiaomi, но мы не видим препятствий для работы на иных устройствах.

Вскоре мы получим первые результаты исследований в рамках модели адаптивного усвоения углеводов и дополним AIAPS новыми возможностями.

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

t.me/aiaps
instagram.com/diabet_type_1

Let's block ads! (Why?)

[Перевод] Сборка недорогой домашней NAS-системы на Linux

Я, как и многие другие пользователи MacBook Pro, столкнулся с проблемой недостачи внутренней памяти. Если говорить точнее, то используемый мной ежедневно rMBP был оснащен SSD объемом всего 256GB, чего, естественно, надолго не хватало.
А когда я плюс ко всему стал записывать видео во время своих полетов, ситуация только усугубилась. Объем заснятых материалов после таких полетов составлял 50+ GB, и мой несчастный SSD на 256GB очень скоро заполнился, вынудив меня приобрести внешний диск на 1TB. Тем не менее, спустя один год, и он перестал справляться с генерируемыми мной объемами данных, не говоря уже о том, что недостаток избыточности и резервного копирования делали его неподходящим для размещения важной информации.
Итак, в один момент я решил собрать NAS большого объема в надежде, что эта система продержится хотя бы пару лет, не требуя очередного апгрейда.
Эту статью я написал в первую очередь как памятку о том, что именно и как я делал на случай, если мне потребуется сделать это снова. Надеюсь, что и для вас она окажется полезна, если вы соберетесь делать то же самое.

Быть может проще купить?

Итак, нам известно, что мы хотим получить, остается вопрос как?
Сначала я ознакомился с коммерческими решениями и рассмотрел, в частности, компанию Synology, которая, как предполагалось, предоставляет лучшие NAS-системы потребительского уровня на рынке. Однако стоимость этого сервиса оказалась достаточно высока. Самая дешевая система с 4-мя отсеками стоит $300+, и при этом жесткие диски в комплект не входят. Кроме того, сама внутренняя начинка такого комплекта не особо впечатлительна, что ставит под вопрос ее реальную производительность.
Тогда я и подумал: а почему бы не собрать NAS-сервер самому?

Поиск подходящего сервера

Если собираешься комплектовать такой сервер, то в первую очередь необходимо найти правильное железо. Для данной сборки должен вполне подойти подержанный сервер, так как для задач хранилища нам не потребуется особой производительности. Из необходимого же нужно отметить большой объем RAM, несколько SATA коннекторов и хорошие сетевые карты. Поскольку мой сервер будет работать в месте моего постоянного проживания, то и уровень шума тоже имеет значение.
Свои поиски я начал с eBay. Несмотря на то, что там я нашел много подержанных Dell PowerEdge R410/R210 стоимостью менее $100, имея опыт работы в серверном помещении, я знал, что эти блоки 1U издают слишком много шума и для домашнего использования не подойдут. Как правило, сервера формата tower чаще менее шумны, но, к сожалению, на eBay их было выставлено немного, и все они были либо дорогие, либо маломощные.
Следующим местом для поиска стал сайт Craiglist, где я нашел человека, продававшего подержанный HP ProLiant N40L всего за $75! Я был знаком с этими серверами, которые даже в подержанном виде обычно стоят в районе $300, так что я отправил продавцу письмо в надежде, что объявление еще актуально. Узнав, что так оно и есть, я, недолго думая, направился в Сан Матео, чтобы забрать этот сервер, который уже с первого взгляда меня однозначно порадовал. У него был минимальный износ и, за исключением небольшого налета пыли, все остальное было отлично.

Фото сервера, сразу после покупки

А вот спецификация приобретенного мной комплекта:

CPU: AMD Turion(tm) II Neo N40L Dual-Core Processor (64-bit)
RAM: 8 GB non-ECC RAM (установлен предыдущим владельцем)
Flash: 4 GB USB Drive
SATA Connectors: 4 + 1
NIC: 1 Gbps on-board NIC

Стоит ли говорить, что несмотря на возраст в несколько лет, спецификация этого сервера по-прежнему превосходит большинство вариантов систем NAS, предлагаемых на рынке, особенно по оперативной памяти. Несколько позже я даже сделал апгрейд до 16 GB ECC с увеличенным объемом буфера и повышенной защитой данных.

Выбор жестких дисков

Теперь у нас есть отличная работоспособная система и осталось подобрать для нее жесткие диски. Очевидно, что за те $75 я получил только сам сервер без HDD, что меня и не удивило.
Проведя небольшое исследование, я выяснил, что для работы с NAS-системами в круглосуточном режиме 24/7 лучше всего подходят HDD WD Red. Для их покупки я обратился на Amazon, где приобрел 4 экземпляра объемом по 3 TB. По сути, вы можете подключить любой предпочтительный HDD, но обратите внимание, чтобы они были одинакового объема и скорости. Это поможет вам избежать возможных проблем с производительности RAID в перспективе.

Настройка системы

Думаю, что многие будут использовать для своих NAS-сборок систему FreeNAS, и в этом нет ничего плохого. Однако, несмотря на возможность установки этой системы на своем сервере, я предпочел использовать CentOS, поскольку система ZFS on Linux изначально подготовлена к продакшен-среде, и вообще управление Linux-сервером мне более знакомо. Кроме того, меня не интересовал модный интерфейс и функции, предоставляемые FreeNAS – мне было достаточно массива RAIDZ и совместного использования AFP.
Установить CentOS на USB достаточно просто – достаточно указать USB в качестве источника загрузки, и при запуске мастер установки проведет вас по всем ее этапам.

Сборка RAID

После успешной установки CentOS я также установил ZFS on Linux, следуя перечисленным здесь шагам.
По завершении этого процесса я загрузил модуль ZFS Kernel:

$ sudo modprobe zfs

И создал массив RAIDZ1 при помощи команды zpool:

$ sudo zpool create data raidz1 ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T0609145 ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T0609146 ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T0609147 ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T0609148
$ sudo zpool add data log ata-SanDisk_Ultra_II_240GB_174204A06001-part5
$ sudo zpool add data cache ata-SanDisk_Ultra_II_240GB_174204A06001-part6

Обратите внимание, что здесь я использую ID жестких дисков вместо их отображенных имен (sdx), чтобы уменьшить шанс сбоя их монтирования после загрузки из-за смены буквенного обозначения.
Я также добавил ZIL и кэш L2ARC, выполняющиеся на отдельном SSD, разбив этот SSD на два раздела: 5GB под ZIL и остаток под L2ARC.
Что касается RAIDZ1, то он может выдержать отказ 1 диска. Многие утверждают, что данный вариант пула не следует использовать из-за вероятности выхода из строя второго диска в процессе пересборки RAID, что чревато потерей данных. Я же пренебрег этой рекомендацией, поскольку регулярно делал резервные копии важных данных на удаленном устройстве, и выход из строя даже всего массива может повлиять лишь на доступность данных, но не их сохранность. Если у вас нет возможности делать резервные копии, то лучше будет использовать решения, наподобие RAIDZ2 или RAID10.
Убедится в успешности создания пула можно, выполнив:

$ sudo zpool status

$ sudo zfs list
NAME                               USED  AVAIL  REFER  MOUNTPOINT
data                               510G  7.16T   140K  /mnt/data

По умолчанию ZFS монтирует только что созданный пул прямо в /, что, как правило, нежелательно. Изменить это можно, выполнив:

zfs set mountpoint=/mnt/data data

Отсюда вы можете выбрать создать один или несколько датасетов для хранения данных. Я создал два, один для бэкапа Time Machine и второй для общего хранилища файлов. Объем датасета Time Machine я ограничил квотой в 512 GB, чтобы предупредить его бесконечный рост.

Оптимизация

zfs set compression=on data

Эта команда включает поддержку сжатия ZFS. Сжатие задействует минимум мощности CPU, но может существенно улучшить пропускную способность I/O, поэтому всегда рекомендуется к использованию.

zfs set relatime=on data

С помощью этой команды мы уменьшаем количество обновлений до atime, чтобы уменьшить генерацию IOPS при обращении к файлам.
По умолчанию ZFS on Linux использует для ARC 50% физической памяти. В моем случае, когда общее число файлов невелико, этот объем можно безопасно увеличить до 90%, так как другие приложения на сервере выполняться не будут.

$ cat /etc/modprobe.d/zfs.conf 
options zfs zfs_arc_max=14378074112

Затем при помощи arc_summary.py можно убедиться, что изменения вступили в силу:

$ python arc_summary.py
...
ARC Size:                               100.05% 11.55   GiB
        Target Size: (Adaptive)         100.00% 11.54   GiB
        Min Size (Hard Limit):          0.27%   32.00   MiB
        Max Size (High Water):          369:1   11.54   GiB
...

Настройка повторяющихся задач

Я использовал systemd-zpool-scrub для настройки systemd-таймеров на выполнение очистки раз в неделю и zfs-auto-snapshot для автоматического создания снимков состояния каждые 15 минут, 1 час и 1 день.

Установка Netatalk

Netatalk – это открытая реализация AFP (Apple Filing Protocol). Следуя официальной инструкции по установке для CentOS, я буквально за пару минут получил собранный и установленный пакет RPM.

Настройка конфигурации

$ cat /etc/netatalk/afp.conf
[datong@Titan ~]$ cat /etc/netatalk/afp.conf 
;
; Netatalk 3.x configuration file
;

[Global]
; Global server settings
mimic model = TimeCapsule6,106

; [Homes]
; basedir regex = /home

; [My AFP Volume]
; path = /path/to/volume

; [My Time Machine Volume]
; path = /path/to/backup
; time machine = yes

[Datong's Files]
path = /mnt/data/datong
valid users = datong

[Datong's Time Machine Backups]
path = /mnt/data/datong_time_machine_backups
time machine = yes
valid users = datong

Обратите внимание, что vol dbnest является в моем случае серьезным улучшением, так как по умолчанию Netatalk пишет базу данных CNID в корень файловой системы, что было совсем нежелательно, поскольку моя основная файловая система выполняется на USB, в связи с чем работает относительно медленно. Включение же vol dbnest приводит к сохранению базы данных в корне Volume, который в этом случае относится к пулу ZFS и уже на порядок производительнее.

Включение портов в Firewall

$ sudo firewall-cmd --permanent --zone=public --add-service=mdns
$ sudo firewall-cmd --permanent --zone=public --add-port=afpovertcp/tcp

sudo firewall-cmd --permanent --zone=public --add-port=afpovertcp/tcp
Если все было настроено верно, то ваша машина должна отображаться в Finder, и Time Machine тоже должна работать.

Дополнительные установки
S.M.A.R.T мониторинг

Рекомендуется отслеживать статус ваших дисков с целью предупреждения их отказа.

$ sudo yum install smartmontools
$ sudo systemctl start smartd

Демон для ИБП

Мониторит заряд ИБП APC и выключает систему, когда заряд становится критически мал.

$ sudo yum install epel-release
$ sudo yum install apcupsd
$ sudo systemctl enable apcupsd

Аппаратный апгрейд

Спустя неделю после настройки системы, я начал все больше беспокоиться о том, что в сервере установлена память без ECC. К тому же в случае с ZFS дополнительная память для буферизации будет весьма кстати. Поэтому я снова обратился к Amazon, где приобрел 2x Kingston DDR3 8GB ECC RAM за $80 каждый и заменил десктопный RAM, установленный предыдущим владельцем. Система с первого раза загрузилась без каких-либо проблем, и я убедился в том, что поддержка ECC была активирована:

$ dmesg | grep ECC
[   10.492367] EDAC amd64: DRAM ECC enabled.

Результат

Результат меня очень порадовал. Теперь я могу постоянно загружать 1Gbps LAN соединение сервера копированием файлов, и Time Machine работает безупречно. Так что, в общем и целом, настройкой я доволен.
Итоговая стоимость

1 * HP ProLiant N40L = $75
2 * 8 GB ECC RAM = $174
4 * WD Red 3 TB HDD = $440

Итого = $689
Вот теперь я могу сказать, что цена того стоила.

А вы делаете самостоятельно сервера NAS?

Let's block ads! (Why?)

[Из песочницы] Приоритизация фичей

Мы как продукт менеджеры, генерируем неисчисляемое количество идей. Каким-то образом у себя в голове их приоритизируем. Голова лопается, мы не знаем, что делать с этими идеями. В вашем “листе идей” какой-то ад творится… Особенно это знакомо людям которые только начинают свой путь в бизнесе, или же только начинают свой путь продуктами.

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

Для начала рассмотрим переменную таблицу методов приоритизаций:

Исходя из данной таблицы, можно сделать вывод.

По горизонтали есть внутренние методы приоритизации, которые решаются в рамках компании — команды.

Если же принимают участие пользователи, то соответственно это внешние.

По вертикали, то сколько данных есть для принятия решений.

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

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

Внутренние методы применяются:

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

Уточнение результатов полученных из внешних методов;

Мы рассмотрели основные различия внутренних и внешних методов.

Далее мы рассмотрим такие методы приоритизации как быстрая (на пальцах) и медленная.

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

Быстрые методы

Метод Reach/Frequency

Reach — охват аудитории. Сколько людей готовы воспользоваться фичей.

Frequency — частота использования фичи.

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

Метод Poker planning

Идея взята из Agile методологий. (Оценка производится внутри команды.)

Оценка пользы фичи

Команде ставится условие: 1 палец — фича не очень, 2 пальца — фича норм, 3 пальца — фича просто бомба.

Вы произносите фичу и на счет “раз, два, три”, члены команды поднимают пальцы. Считаете средний балл. (Можете приглашать внешних людей из других проектов).

Оценка затрат

Собираем разработчиков, говорим про функционал и так же ставим условие: 1 палец — быстро сделают. 2 пальца — разработка будет не сложной. 3 пальца — разработка будет очень сложной и долгой.

Далее мы делим пользу на затраты и получаем приблизительную оценку функциональности.

Фича 4 имеет самый высокий процент, значит точно будет вверху таблицы приоритизаций. Фича 2 имеет самый низкий процент — мы точно выкидываем из нашего бэклога.

Медленные методы

RICE

Разработан компанией intercom.

Это такой метод приоритезации идей и фич продукта, который включает 4 фактора, которые менеджер продукта использует для оценки и приоритизации фич:

Reach — охват аудитории. Не забываем, что охват именно тех людей, которые увидят эту фичу.

Impact — влияние фичи на пользователя. Его радость, бусты, эмоции от данной фичи. (0.25 — очень плохо, 0.5 — плохо, 1 — средне, 2 — хорошо, 3 — отлично)

*** Некоторые считают что impact — это именно влияние фичи на компанию. То есть какое количество метрик мы подымем при помощи этой фичи.

Confidence — Уверенность в гипотезе. Довольно важный параметр, показывающий на сколько вы считаете хороша ли гипотеза, т.к мы не всегда придумываем супер-топ идеи. ( Высокая = 100%, средняя = 80%, слабая = 50% и ниже)

Effort — Сложность разработки. Обычно указывается в месяцах. (пол месяца 0.5)

Приоритизация по ROI

Изначально Вам нужно сделать иерархию метрик. Если Ваш продукт не Amazon и не google, более чем достаточно будет сделать древовидную систему. Что из чего происходит. Например Life time Value напрямую зависит от Retention. Отлично! Этого будет достаточно для интернет магазина. Далее по аналогии в зависимости от масштабов продукта, можно использовать аналитические данные и делать формулы.

Очень удобно когда есть идея, знать на какую метрику она повлияет. И понимать на каком уровне дерева находится. И чем будет придуманная фича ближе к главной метрике, тем профитнее она. Чем дальше, соответственно шансов почти нет, что она повлияет на главную метрику.

Пример приоритизаций из иерархии метрик

С командой мы расставляем “вес” фичи, на сколько кто в нее верит. + ставится на те которые выбирает большинство. На них можно делать основной акцент на ближайшие пол года.

Пример приоритизации по ROI

У нас есть количество пользователей за год. Мы делаем прогноз, что воспользуются продуктом 70%, а приобретут продукт 50% от пользователей.

Я прикидываю, что внедрение фичи принесет компании 4% от прибыли.

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

Далее мы идем к разработчикам и понимаем сколько будет длиться разработку. Переводим все в челвоека часы и получаем стоимость разработки.

Имея эти данные мы можем посчитать ROI ((доходы — расходы) / расходы * 100%) фичи.
Таким образом, мы можем посчитать все фичи из бэклога и приоритизировать его.

*** Так же можно сделать более детальную проработку таблицы с Реальными % конверсии, пессимистичными и оптимистичными.

Плюсы:

Ты получаешь оценку в деньгах. Люди любят деньги.

Люди верят числам.

Минусы:

Не учитываются абсолютные значения
Многое зависит от личных скилов продакт менеджера.
Мелкие фичи не понятно как считать.

Нюансы:

Считать прибыль, а не выручку.

Типичные ошибки Product manager’ов

1. Оценивать в одиночку.

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

2. Не учитывают влияние одной части на другие части продукта.

Очень важно думать как вся экосистема работает, чтобы не проседали другие части продукта;

3. Повестись на хейтеров.

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

4. Количественная оценка не всегда лучше, чем качественная.

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

5. Закопаться в мелочах. Смотрите на продукт сверху!

Итог

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

Спасибо за уделенное время.

Let's block ads! (Why?)

RAID-массивы на NVMe

В данной статье мы расскажем про разные способы организации RAID-массивов, а также покажем один из первых аппаратных RAID-контроллеров с поддержкой NVMe.

Все разнообразие применений технологии RAID встречается в серверном сегменте. В клиентском сегменте чаще всего используется исключительно программный RAID0 или RAID1 на два диска.

В этой статье будет краткий обзор технологии RAID, небольшая инструкция по созданию RAID-массивов с помощью трех разных инструментов и сравнение производительности виртуальных дисков при использовании каждого из способов.

Что такое RAID?

Википедия дает исчерпывающее определение технологии RAID:

RAID (англ. Redundant Array of Independent Disks — избыточный массив независимых (самостоятельных) дисков) — технология виртуализации данных для объединения нескольких физических дисковых устройств в логический модуль для повышения отказоустойчивости и производительности.

Конфигурация дисковых массивов и используемые при этом технологии зависят от выбранного уровня RAID (RAID level). Уровни RAID стандартизированы в спецификации Common RAID Disk Data Format. Она описывает множество уровней RAID, однако самыми распространенными принято считать RAID0, RAID1, RAID5 и RAID6.

RAID0, или Stripes, — это уровень RAID, который объединяет два или более физических диска в один логический. Объем логического диска при этом равен сумме объемов физических дисков, входящих в массив. На этом уровне RAID отсутствует избыточность, а выход из строя одного диска может привести к потере всех данных в виртуальном диске.

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

Уровень RAID5 решает проблему дороговизны. Для создания массива с уровнем RAID5 необходимо как минимум 3 диска, при этом массив устойчив к выходу из строя одного диска. Данные в RAID5 хранятся блоками с контрольными суммами. Нет строгого деления на диски с данными и диски с контрольными суммами. Контрольные суммы в RAID5 — это результат операции XOR, примененной к N-1 блокам, каждый из которых взят со своего диска.

Хотя RAID-массивы повышают избыточность и предоставляют резервирование, они не подходят для хранения резервных копий.

После краткого экскурса по видам RAID-массивов можно переходить к устройствам и программам, которые позволяют собирать и использовать дисковые массивы.

Виды RAID-контроллеров

Существует два способа создать и использовать RAID-массивы: аппаратный и программный. Мы рассмотрим следующие решения:

Linux Software RAID.
Intel® Virtual RAID On CPU.
LSI MegaRAID 9460-8i.

Отметим, что решение Intel® работает на чипсете, из-за чего возникает вопрос, аппаратное это решение или программное. Так, например, гипервизор VMWare ESXi считает VROC программным и не поддерживает официально.

Linux Software RAID

Программные RAID-массивы в семействе ОС Linux — достаточно распространенное решение как в клиентском сегменте, так и в серверном. Все, что нужно для создания массива, — утилита mdadm и несколько блочных устройств. Единственное требование, которое предъявляет Linux Software RAID к используемым накопителям, — быть блочным устройством, доступным системе.

Отсутствие затрат на оборудование и программное обеспечение — очевидное преимущество данного способа. Linux Software RAID организует дисковые массивы ценой процессорного времени. Список поддерживаемых уровней RAID и состояние текущих дисковых массивов можно посмотреть в файле mdstat, который находится в корне procfs:

root@grindelwald:~# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid10] 
unused devices: <none>

Поддержка уровней RAID добавляется подключением соответствующего модуля ядра, например:

root@grindelwald:~# modprobe raid456
root@grindelwald:~# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
unused devices: <none>

Все операции с дисковыми массивами производятся через утилиту командной строки mdadm. Сборка дискового массива производится в одну команду:

mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/nvme1n1 /dev/nvme2n1

После выполнения этой команды в системе появится блочное устройство /dev/md0, которое представляет из тебя виртуальный диск.

Intel® Virtual RAID On CPU

^{Intel® VROC Standard Hardware Key}
Intel® Virtual RAID On CPU (VROC) — это программно-аппаратная технология для создания RAID-массивов на базе чипсетов Intel®. Данная технология доступна в основном для материнских плат с поддержкой процессоров Intel® Xeon® Scalable. По умолчанию VROC недоступен. Для его активации необходимо установить аппаратный лицензионный ключ VROC.

Стандартная лицензия VROC позволяет создавать дисковые массивы с 0, 1 и 10 уровнями RAID. Премиальная версия расширяет этот список поддержкой RAID5.

Технология Intel® VROC в современных материнских платах работает совместно с Intel® Volume Management Device (VMD), которая обеспечивает возможность горячей замены для накопителей с интерфейсов NVMe.

^{Intel® VROC со стандартной лицензией} Настройка массивов производится через Setup Utility при загрузке сервера. На вкладке Advanced появляется пункт Intel® Virtual RAID on CPU, в котором можно настроить дисковые массивы.

^{Создание массива RAID1 на двух накопителях}
Технология Intel® VROC имеет свои «козыри в рукаве». Дисковые массивы, собранные с помощью VROC, совместимы с Linux Software RAID. Это означает, что состояние массивов можно отслеживать в /proc/mdstat, а администрировать — через mdadm. Эта «особенность» официально поддерживается Intel. После сборки RAID1 в Setup Utility можно наблюдать синхронизацию накопителей в ОС:

root@grindelwald:~# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md126 : active raid1 nvme2n1[1] nvme1n1[0]
      1855832064 blocks super external:/md127/0 [2/2] [UU]
      [>....................]  resync =  1.3% (24207232/1855832064) finish=148.2min speed=205933K/sec
      
md127 : inactive nvme1n1[1](S) nvme2n1[0](S)
      10402 blocks super external:imsm
       
unused devices: <none>

Отметим, что через mdadm нельзя собирать массивы на VROC (собранные массивы будут Linux SW RAID), но можно менять в них диски и разбирать массивы.

LSI MegaRAID 9460-8i

^{Внешний вид контроллера LSI MegaRAID 9460-8i}
RAID-контроллер является самостоятельным аппаратным решением. Контроллер работает только с накопителями, подключенными непосредственно к нему. Данный RAID-контроллер поддерживает до 24 накопителей с интерфейсом NVMe. Именно поддержка NVMe выделяет этот контроллер из множества других.

^{Главное меню аппаратного контроллера}
При использовании режима UEFI настройки контроллера интегрируются в Setup Utility. В сравнении с VROC меню аппаратного контроллера выглядит значительно сложнее.

^{Создание RAID1 на двух дисках}
Объяснение настройки дисковых массивов на аппаратном контроллере является достаточно тонкой темой и может стать поводом для полноценной статьи. Здесь же мы просто ограничимся созданием RAID0 и RAID1 с настройками по умолчанию.

Диски, подключенные в аппаратный контроллер, не видны операционной системе. Вместо этого контроллер «маскирует» все RAID-массивы под SAS-накопители. Накопители, подключенные в контроллер, но не входящие в состав дискового массива, не будут доступны ОС.

root@grindelwald:~# smartctl -i /dev/sda
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-48-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               AVAGO
Product:              MR9460-8i
Revision:             5.14
Compliance:           SPC-3
User Capacity:        1,999,844,147,200 bytes [1.99 TB]
Logical block size:   512 bytes
Rotation Rate:        Solid State Device
Logical Unit id:      0x000000000000000000000000000000
Serial number:        00000000000000000000000000000000
Device type:          disk
Local Time is:        Sun Oct 11 16:27:59 2020 MSK
SMART support is:     Unavailable - device lacks SMART capability.

Несмотря на маскировку под SAS-накопители, массивы с NVMe будут работать на скорости PCIe. Однако такая особенность позволяет загружаться с NVMe в Legacy.

Тестовый стенд

Каждый из способов организации дисковых массивов имеет свои физические плюсы и минусы. Но есть ли разница в производительности при работе с дисковыми массивами?

Для достижения максимальной справедливости все тесты будут проведены на одном и том же. Его конфигурация:

2x Intel® Xeon® 6240;
12x DDR4-2666 16 GB;
LSI MegaRAID 9460-8i;
Intel® VROC Standard Hardware Key;
4x Intel® SSD DC P4510 U.2 2TB;
1x Samsung 970 EVO Plus M.2 500GB.

Тестируемыми выступают P4510, из которых одна половина подключена к материнской плате, а вторая — к RAID-контроллеру. На M.2 установлена операционная система Ubuntu 20.04, а тесты будут выполняться при помощи fio версии 3.16.

Тестирование

В первую очередь проверим задержки при работе с диском. Тест выполняется в один поток, размер блока 4 КБ. Каждый тест длится 5 минут. Перед началом для соответствующего блочного устройства выставляется none в качестве планировщика I/O. Команда fio выглядит следующим образом:

fio --name=test --blocksize=4k --direct=1 --buffered=0 --ioengine=libaio  --iodepth=1 --loops=1000 --runtime=300  --rw=<mode> --filename=<blkdev>

Из результатов fio мы берем clat 99.00%. Результаты приведены в таблице ниже.
Помимо задержек при обращении к данным, хочется увидеть производительность виртуальных накопителей и сравнить с производительностью физического диска. Команда для запуска fio:

fio --name=test --blocksize=4k --direct=1 --buffered=0 --ioengine=libaio  --loops=1000 --runtime=300  --iodepth=<threads> --rw=<mode> --filename=<blkdev>

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

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

Заключение

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

Let's block ads! (Why?)

Как организовать IT-конференцию и не сойти с ума

Восьмого октября прошёл прямой эфир с Натальей Крапкиной (больше известная как Кейт или
ladynoname), одной из организаторов конференции Chaos Constructions.

Наташа создает курирует IT-сообщества в Петербурге: ITGM 14, митапы DevOps40, MonHouse, и работает как идейный вдохновитель программистских коммьюнити.

Делимся с вами расшифровкой и записью интервью

[embedded content]

Меня зовут Наталья Крапкина. Я несколько лет занималась проведением IT-конференций, IT-фестиваля Chaos Constructions: изначально это была демо-пати, потом она превратилась в большую конференцию IT-сообществ. Давайте поговорим о том, почему Петербург – столица митапов и IT-конференций.

Сложилось так, что у нас всегда существовала линуксовка — SPB LUG (Linux User Group). Сложилась она 20 лет назад. Мы встречаемся каждый месяц вот уже 20 лет, хотя сейчас из-за эпидемии пришлось все затормозить.

Затем стали постепенно подтягиваться другие ребята, со своими сообществами. У нас огромное количество митапов проходит в городе, самых разных: это OpenData, и PythonGroup собираются с четверговым пивом, и сообщество SRE, которые бизнес-завтракают по пятницам. У нас все нереально здорово, огромное количество информации, огромное контента генерируется и заливается на YouTube, все знакомятся, дружат. У нас в городе достаточно спокойный и размеренный ритм жизни, отличавшийся от Москвы. Людей проживает достаточно много, и все прекрасно себя чувствуют в компании друзей, собираются, митапятся. В Москве все собираются только в рамках крупных конференций – например, у Олега Бунина и у Алексея Федорова, который тоже пришел в Москву. В Петербурге у нас изначально все супер-круто. Когда постишь анонс, ребята из других городов обычно в большом восторге, и жалуются: почему у нас в городе такого нет, почему мы так круто не собираемся. Поэтому у нас столица IT-митапов – в больших объемах, в разных форматах.

Российские IT-конференции выросли из IT-сообществ. Все между собой дружили классно, потихоньку стали собираться, и все это вышло на более профессиональный уровень. Московские IT-конференции Олега Бунина тоже очень крутые, и их огромное количество, и там есть огромный фестиваль «Российские интернет-технологии». И у Алексея Федорова на jug.ru проходит экспансия в столицу, происходят столичные события. Олег Бунин сейчас еще отлично расширяется в регионы, жители других городов теперь тоже могут посещать качественные профессиональные мероприятия, в том числе IT-митапы сообществ. Ребята это делают с большим удовольствием. Все это развивается благодаря сообществу, благодаря программистам, благодаря IT-специалистам, сисадминам, сетевикам, спасибо вам всем, ребята, что вы общаетесь, делитесь друг с другом всем самым важным.

Chaos Constructions – что это, откуда взялось, для чего делается? Это супер-крутое событие, не такое официальное, как конференция, не такое пафосное, совершенно простое. Туда приходят все желающие, возможно – даже те, кому компания не купила билет; вход бывает то бесплатным, то с символической платой. Хотелось бы всегда оставаться более открытыми, более бесплатными, более фестивальными. Когда на фестиваль приходят совершенно любые люди, которые говорят: классно, мы тоже делаем крутые штуки, у нас электромеханика, или мы взламываем замочки – это очень круто. Всегда здорово. Для участия не надо платить; просто все пришли, вместе здорово провели два дня, показали свои умения, свои способности, познакомились все. Вечером обязательно афтепати-программа. Мы на Chaos Constructions разговариваем на совершенно разные темы; то постоянно кто-то кого-то взламывает, то кто-то выискивает точки связи, доступа в закрытых городах. Такая информация, которой сложно просто взять и поделиться на какой-то профессиональной конференции по чему-либо, потому что делишься конкретными кейсами, которые могут быть чувствительными. Ну, на грани.

Порог входа к нам на фестиваль достаточно свободен. У нас нет программного комитета, который бы отбирал доклады. У нас есть сообщество, мы голосуем – хотим мы доклад или не хотим. Еще голосовали – хотим мы спонсора или не хотим. Недавно не пустили какого-то спонсора. Полная свобода и полный хаос.

Изначально это была демо-пати. Это тоже сообщество ребят, которые на всяких старых и новых платформах генерируют визуально-звуковой ряд, то есть пишут демки. Раньше это можно было увидеть в играх – были такие интро, когда все возможности видеокарт показывались. Потом это переросло в отдельную ветвь андеграундной IT-культуры. И поэтому наш андеграундный фестиваль объединил всех тех, кто не готов под запись что-то рассказывать, делать доклады, но готов просто прийти, потусоваться, отдохнуть. Фестиваль всегда проходит по выходным. В этом году его нет: в онлайне скучно, неинтересно. Рынок онлайн-эвентов сейчас перенасыщен, каждую неделю и день что-то случается, происходит.

Еще, кроме Chaos Constructions, я проводила фестиваль ITGM 14. Проводила его в компании с Виталием Левченко, за что ему огромное спасибо, и это тоже было здорово и классно. Мы собрались IT-сообществами, мы прочли доклад; было очень удобно и комфортно – для каждого сообщества было время в комфортных залах, не приходилось друг друга перебивать, как бывает обычно на ITGM. ITGM – это IT Global Meetup, там очень много сообществ – 20, 30. Обычно они собирались в одном зале, и это было очень странно: одновременно проходил доклад моего сообщества по программированию PGA, и тут же, совсем рядом – рассказ каких-то тренеров по софт скиллам про выгорание.

Почему появление тренеров по софт скиллам в хардкорной тусовке негативно влияет? Когда программа формируется, и в зале 1-2 тысячи человек, и хардкорные доклады в основном, то доклады по софт скиллам – как белые вороны. Конечно, бывает что-то интересное, что можно послушать – если сообщество само пригласит. А бывает, что на конференциях существуют платные доклады: приходит такой тренер и оплачивает себе время на сцене, является спонсором. На наших самоорганизованных сообществом слетах такого не бывает: сообщество само выбирает, кого мы хотим или не хотим слушать. А тут нам периодически поставляют бизнес-тренеров господа, которые этим профессионально занимаются.

Это плохо, потому что внимание рассеивается от общей темы. Кроме того, когда ты за 40 минут послушал тренера и вдохновился, вдохновение быстро проходит – вместе с этими 40 минутами. А системно возникающими проблемами надо системно бороться. Нельзя за 40 минут наглотаться каких-то тезисов из презентации и стать лучше, здоровее, веселее и бодрее. Надо отдельно выбирать время, обращаться к специалистам. Подбирать их лучше не на конференции, а по рекомендации или по рекламе в Google, как кому удобнее. Перемешивать все сразу – и эффективность, и выгорание, и все остальное – это так не работает. Надо конкретно плотно заниматься собой, определять, есть ли проблемы, обращаться к специалисту. Можно хоть сразу к психотерапевту, он сразу определит и скажет, что делать.

Также у нас тема выступления: «Как организовать IT-конференцию и не сойти с ума». Я честно скажу, что в 2019 году, когда, за 5 дней до фестиваля, генеральный спонсор отказался от участия – от нас это, конечно, не зависело – я действительно обращалась к психотерапевту. Прямо в этой классной гостиной с рыбками. Приезжала женщина, работала со мной, успокаивала – все уже случилось, чего теперь бояться.

Каждый раз, когда происходит конференция на пару тысяч человек, это бывает страшно – вдруг кто-то сломает ногу, вдруг еще что-то произойдет. Приходится брать и делать; тут уже нет времени сходить с ума. Есть четко поставленные задачи, которые решают все – организаторы, соорганизаторы, каждый – свою. Дело добровольное.
Я уже рассказывала, почему доклады о софт скиллах на этих конференциях превращаются в бесполезно потраченное время. Если мы идем техническую конференцию, делаем технический митап – значит, все техническое. Если мы хотим экспертное мнение тренеров, мы их позовем на другую конференцию.

Q: Как создать сообщество по интересам? Почему площадка – последний по важности вопрос?

Потому что площадок огромное количество. Например, в нашем сообществе DevOps 40 используется основная площадка meetups.com. Там ничего нет, совершенно. Там можно только сделать эвент, написать комментарии и загрузить немного фотографий (потому что загрузка неудобная). И мы ею пользуемся достаточно активно. Мы всегда туда выкладываем все наши ивенты. Там такие же люди, которым действительно интересны митапы, они ждут их в виде оповещения — и приходят. Бывало, что сохраняется на митапе какое-то ядро: например, на митап приходит 200 человек, и из них ядро – только 10, остальные все новенькие. Не все время; кто-то прибивается, вливается в тусовку. Это здорово. Такие люди сами становятся классным ядром, лидерами мнений, активными пользователями, которые готовы делать доклады, делать презентации, записывать видео для сообщества. Это супер здорово. Спасибо вам, ребята, если вы активны, если вас интересно слушать – это всегда вызывает восхищение.

Как создать сообщество по интересам? Собственно, все очень просто. Это когда активный человек находит для себя интересную тему – например, самое классное сообщество, в котором я сейчас тусуюсь, это охотники за северным сиянием (мне это очень интересно, это разгружает, отвлекает от серых будней – когда ты среди ночи выезжаешь в лес, смотришь на Млечный путь, думаешь о вечном, звезды светят, здорово). Я могу рассказать на примере этого сообщества. Вот у меня такой интерес – и у меня, конечно, должны быть единомышленники, и я начинаю их искать. Я начинаю делиться своими публикациями звездного неба; какие-то друзья в соцсетях откликаются – о, здорово, я тоже хочу с тобой поехать в лес. Я говорю – классно, запрыгивай в мою уютную тачку, погнали мерзнуть в -20. И это здорово. И только так: если вам интересна конкретная тема, из которой вы хотите создавать сообщество, и вам это важно, то вы берете и открываете клёвый чат – у меня это «Церковь метрик». И появляется офигенное сообщество. Люди из разных городов приходят, начинают болтать, обсуждать свои проблемы, находить решения, смотреть вместе доклады, обмениваться статьями. Они вместе учатся и вместе развиваются. Это удобно.

В общем, если у вас есть такое желание, то вы идете и знакомитесь в людьми, потом с большим количеством людей. Может быть, про вас даже покажут репортаж по Рен-ТВ, как про «охотников на аврору». Общаясь, вы найдете активных людей. У вас появится ядро. Если вы создадите удобную платформу для общения, куда все могут подключаться – например, чат или канал, если нужно что-то срочно обсуждать. Это может быть и простая платформа meetups.com, где можно получать эвенты в ленту и регистрироваться. Площадка – абсолютно второй вопрос. Даже на meetups можно сделать сообщество: планируешь удобную дату, и все едут в лес смотреть за сиянием.

Q: Как сделать сообщество интересным?

Как и когда появляется ядро, я уже рассказала. Естественно, нужны активные люди для генерации контента. В сообществе охотников я генерировала большое количество фотографий, рассылала их везде; их периодически показывают по утренним новостям, иногда – на локальных питерских каналах, иногда – даже на федеральных. Люди смотрят, читают разные издания, интернет-издания репостят – и подключаются ко мне, подписываются на инстаграм, а потом – подключаются к нашей беседе, к нашему каналу, где мы постим красивости. И потихоньку находятся такие люди, которые начинают наиболее активно с тобой ездить в лес. Вот появился парень, Саша Спиридонов; ему говоришь – поехали в лес сегодня, а он – да, без проблем. Он готов там часами мерзнуть, он активный. Он приглашает всех своих друзей в сообщество. Вот так получается вырастить сообщество с нуля – когда мы делаем вклад в него, когда мы знакомимся и приглашаем к себе. И таким образом появляется ядро – активные участники, которые активно приходят, активно что-то делают, драйвят остальных. Недавно было круто: мы приехали ночью на маленький пляж под Приозерском – представьте, что на таком пляже гуляет десять человек, и все здороваются с тобой! Вообще нереально круто, согласитесь. И так же здорово в случае с фестивалем. Две тысячи человек за два дня посещают лекции, смотрят все, слушают музыку. И точно так же появляются молодые программисты, которые готовы писать демки. Это очень круто.

Q: почему сообщества и конференции – это не про деньги, но про власть и влияние?

Давайте вернемся к психотерапевту и спонсору. Так вышло, что в 2019 году я успокоилась, перестала наконец реветь о том, что нет денег. Я взяла кредит в «Тинькоффе». Всего не очень большая сумма, 350 тысяч, но со всеми процентные выплаты вышло около полумиллиона. На самом деле, мне очень стыдно было просить поддержки и помощи, но я месяц назад запустила кампанию по поддержке; сообщество поддержало меня, всем им нереальное спасибо, надеюсь, потихоньку все вместе погасим этот долг.

Денег, если у тебя некоммерческое мероприятие, ты не поднимешь. Не получится зарабатывать деньги на своих друзьях, которых ты пригласил. Нельзя просто взять и замонетизировать чат в телеграме, от платной рекламы все разбегутся — логично. Это очень сложно. Если нет какой-то цели полезной, а есть цель поднять бабок – лучше не делать так, ничего не выйдет. Дружба, хорошие человеческие отношения, обмен опытом – в первую очередь, а не попытки как-то заработать.

Про власть и влияние – ну, их нет, конечно. Большую часть времени на фестивале после организации приходится бегать и следить за тем, чтобы урны вовремя убирали, чтобы никто ничего не пролил на дорогой ковролин. Это не власть, тут просто следить надо всегда. За чистотой, порядком, чтобы никто не сломал ногу, за безопасность, пожарной безопасностью – все очень серьезно. Никакой власти и влияния тут нельзя получить. Несмотря на то, что я как бы владелец нескольких чатиков, меня все посылают.

Q: откуда брать деньги на конференцию и зачем ее делать?

Ну, зачем – это мы уже разобрали. Если у нас конференция IT-сообществ, то мы собираемся, чтобы делиться, узнавать новое, знакомиться. Нетворкинг. Свободная атмосфера, свободная обстановка, никаких галстуков и пиджаков. Можно спокойно валяться в толстовке или без нее и общаться. Или можно за пределами party place отойти на полянку, подышать свежим воздухом, что-то покрепче выпить – такое тоже бывает.

Деньги лучше всего брать с тех, кому интересна аудитория, если она не против. В 2019 году мы выгнали спонсора, проголосовав – уж очень они нас в 2018 достали. Собирали телефоны всех участников, звонили, все было очень навязчиво – ну, мы открыли голосование и не пустили их.
Не всякий спонсор хорош. Обычно хорошие спонсоры – это компании, в которых работают ваши активисты. В 2015-16 году я работала в компании «Метротек», за что спасибо Антону Фельдману; как раз эта компания была генеральным спонсором Chaos Constructions – до этого и после этого. Наш соорганизатор Саша Калмыков работает в «Газпромнефти», и один год нас спонсировала «Газпромнефть». А наш коллега Александр Чистяков тоже работал в какой-то компании, и эта компания тоже стала спонсором. Активисты драйвят свои компании и приводят их за ручку, такое бывает. Никаких серых схем, конечно, все предельно ясно, просто. Суммы подбираются соответствующие – 100-150 тысяч; в 2019 году генеральный спонсор дал 300.

Злополучный год, да. Но было круто же. Ковролин, удобные кресла, хорошая прекрасная площадка, большие залы, вентиляция, интернет. «Яндекс» тоже принял участие, целый музей привез из Москвы. Спонсоры – это не про деньги, это про любовь! Все в тему обязательно.

Ну, и привлекаемые спонсоры тоже. Для спонсора на тусовке должна быть целевая аудитория. Например, для Яндекса было важно видеть программистов, заинтересованных в старых «Смектрумах», «Амигах», древних телевизионных приставках – они были целевой аудиторией Яндекс-музея. Кстати, он есть и в Питере, там очень интересно. Можно ознакомиться с историей, прикоснуться к прекрасному. Открыт 7 дней в неделю, заходите.

Q: чем конференция отличается от unconference?

Конференция – это когда есть программный комитет, все на серьезных щах обсуждают: а что это у нас тут студент какой-то задумал что-то рассказывать, давайте его сейчас откоучим! Будет 25 интервью, он пришел с такой темой – а мы ее так перевернем или вообще вывернем. Это – конференция: программы, жестокий отбор. Нет проблемы отсутствия докладчика: если он не пришел, ребята просто оплатят профессионала, который придет и доложит тему.

А у нас – unconference. Мы, простые люди из зала, приходим и собираемся. Мы сами решаем, какие хотим слушать темы. Мы не собираемся под какую-то интересную программу, мы ее сами полностью делаем. Бывало, что 20-40 докладов (и мастер-классов и других форматов) идет за 2 дня, и это потрясающе. И мы можем это все пробовать, миксовать, чтобы было классно, и у нас постоянно идет обсуждение с сообществом в плотном контакте.

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

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

Можно снимать что угодно, коворкинги даже бывают бесплатные – например, хакспейсы. У нас есть такой, Backspace, туда помещается человек 20. Мы там проводим мастер-классы по программированию, паяем, обсуждаем хардовые темы, которые не интересны широкому кругу зрителей – не DevOps, в общем. То есть, такая тема вполне жизнеспособна. И мастер-класс можно делать, и что угодно.

Из таких площадок есть еще много корпоративного. Мы сотрудничали с Dell – у них есть своя собственная большая конференц-комната. Можно сотрудничать с Газпромнефтью – у них тоже огромные площади. Вполне можно связаться с большой компанией и организовываться у них бесплатно, и они даже сделают бонус для вас – организуют трансляцию, вопросы-ответы, все что угодно. Я считаю – это нормально. Мы кооперируемся, чтобы снять с себя головную боль: мы же на свои бабки не организуем все митапы в городе; а тут уже готовая инфраструктура, и ею можно пользоваться.

Могу рассказать, как мы организовывали стримы на DevOps. Мы запускались на Twitch, и там есть одна классная программа – OBS (Open Broadcaster Software). Через нее можно сразу брать и делать всякие заставки, менять видео с камер туда-сюда. Очень удобно, совершенно бесплатно, в Twitch можно сразу выйти, к YouTube подключиться тоже.

Q: реально ли сделать онлайн-телеконференцию на несколько сотен человек?

Реально, почему нет. Давайте подумаем. У нас есть Zoom, например, который, если корпоративный, позволяет огромное количество людей собирать. Кроме того, необязательно, чтобы все люди подключались по видео к тебе – столько твой экран не вместит. Надо заранее собирать докладчиков и по очереди подключать. Было бы желание.

Q: Онлайн – это фуфуфу, или съедобно?

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

Q: планируете развивать географию Chaos Constructions, или Питер навсегда?

Я в этом году после февраля нахожусь в некоем подвешенном состоянии. Сил как-то не хватает. Надо успевать работать, сидеть на карантине, гладить котов. Я не смогла даже в Питере сделать, даже в онлайне. А так – в любом другом городе сложно делать. Все организаторы живут в Питере. Всеволод Рангуев, Саша Калмыков, Володя-оператор. Есть ли смысл делать, если уже есть демо-пати в Казани – «Кафе»; правда, там докладов нет и IT-сообществ нет, но по картинкам и видео очень много работ присылают. В Нижнем Новгороде тоже событие происходит; небольшое, локальное, но там вообще нереально круто. Ребята снимают коттедж с баней и тусуются 2 дня. Туда тоже можно поехать. Называется DiHalt Demo Party. И в других городах есть всякое. Яндекс-музей, опять же, делает конкурсы по программированию, но без современных технических докладов; попользоваться ими как площадкой тоже не вышло, хотя была идея – попросить предоставить площади и попросить саппорт для IT-сообществ. Они сказали, что не предоставляют свои площади.

Q: есть ли планы по завозу именитых заграничных IT-шников?

Это платная тема, конечно. Я звать пытаюсь всегда – и импортных IT-шников, и импортных музыкантов. Если сообщество действительно хочет – оно готово оплачивать перелет и все такое, почему нет. Просто наши докладчики Chaos Constructions-ские сами приезжают, за свой счет. И бывает такое, что кто-то говорит, например, Bobuk – о, вы же берете 1000 за вход, у вас коммерческое мероприятие. А ты взял эту тысячу, донес туда еще 200 тысяч и говоришь – ну как оно коммерческое, если некоммерческое? Но приходится же оплачивать выступления Bobukа, и поэтому нужны билеты. Обычно мы не хотим таких спикеров. Bobukа можно слушать часами, но зачем это делать за такие деньги? Можно просто на Youtube посмотреть его. Ну, а с зарубежными выступающими такая же ситуация. Мало людей, которые готовы ехать за свой счет на какую-то конференцию с докладом.

Q: в чем преимущества проведения митапов в онлайн или оффлайн? Если можно публиковать материалы в виде статей, заметок или видео на сайте сообщества с возможностью обсуждать в комментариях.

Смотрите: для того, чтобы разобраться со своей проблемой, или поделиться своей проблемой и решением с сообществом, надо контактировать с сообществом. Через видео это удобно. Или лично – мы приходим обсуждать какую-то тему, какой-то DevSecOps. Или приходим обсуждать вопросы по мониторингу – когда надо хранить огромное количество данных, и для этого есть решения. Когда возникает необходимость увидеться – собраться, встретиться, обсудить – тогда и возникают успешные митапы и сообщества. Собираемся, обсуждаем, а потом можно делать расшифровки докладов, и выложить видео. А вот когда ты стоишь, докладываешь перед публикой, когда тебе страшно, ты учишься этому, тренируешь свое мастерство болтальное; кстати, некоторые отлично натренировались так: Александра Кистякова можно с удовольствием слушать. Здорово, прикольно. Так что разговаривать надо. Надо учиться, практиковаться. Статьи тоже надо писать, и заметки, и видео на сайте сообщества.

Что было ранее

Let's block ads! (Why?)

В Linux выявили уязвимость стека Bluetooth, которая позволяет выполнить код на уровне ядра

Специалист Google обнаружил почти во всех версиях Linux уязвимость нулевого клика в программном стеке Bluetooth BlueZ. Уязвимости подвержены сотни миллионов устройств по всему миру.

Особенную опасность уязвимость представляет для компьютеров и устройств на дистрибутивах Linux и Chrome OS, так как у Android есть собственный Bluetooth-стек.

Стек BlueZ разработала Qualcomm, а курирует группа компаний во главе с Intel. Он работает с ядром Linux версии 2.4.6 и выше.

В Intel заявили, что новые уязвимости BleedingTooth «всего лишь» ведут к открытию информации и к изменению уровня привилегий на атакуемом устройстве, а последняя версия Linux 5.9 не подвержена этой уязвимости. «Некорректная проверка ввода в BlueZ позволяет не прошедшему аутентификацию пользователю повысить права», — так сформулировали проблему в компании. Уязвимость оценили в 8,3 из 10 баллов.

Однако разработчик ядра Linux Мэтью Гаррет предположил, что Intel преуменьшает опасность уязвимости, когда утверждает, что в версии Linux 5.9 она не работает. Он выразил возмущение тем, что разработчиков дистрибутивов Linux не предупредили о проблеме до публикации официального отчета Intel об уязвимости.

Между тем реализация новой уязвимости относительно проста. Злоумышленник должен находиться в зоне действия Bluetooth-передатчика атакуемого устройства, и оно должно быть активированным. Однако предварительного сопряжения с атакуемым устройством не требуется, как и активных действий жертвы. Для атаки достаточно знать MAC-адрес целевого устройства, который определяется, если «прослушивать эфир» программами для анализа трафика. В итоге хакер может отправить жертве Bluetooth-пакеты, которые позволят ему выполнить на устройстве программный код на уровне ядра Linux. Однако для осуществления атаки необходимы определенные знания, поэтому, как отмечают эксперты, уязвимость не будет представлять интереса для злоумышленников.

Исследователи безопасности продемонстрировали эксплойт уязвимости. Он работает с версии Linux 4.8. Это касается дистрибутивов Debian, RHEL (начиная с 7.4), SUSE, Ubuntu и Fedora.

[embedded content]

Патчи от Intel вошли в ветку linux-next, однако в ветке Linux 5.9 их пока нет.

См. также:

Let's block ads! (Why?)

Сложение двух чисел с плавающей запятой без потери точности

Здравствуйте, друзья, как вы думаете, если мы напишем такой код:

s = a+b;
z = s-a;
t = b-z;

то не кажется ли вам, что в результате его выполнения получится, что t=0? С точки зрения привычной математики действительных чисел это и правда так, а вот с точки зрения арифметики с плавающей запятой в переменной t будет кое-что другое. Там будет то, что спасает нас от потери точности при сложении чисел

$inline$ и

$inline$ . Кого интересует данная тема, прошу под кат.

По моей традиции текстовая статья дублируется на видео. По содержанию текст и видео идентичны.

[embedded content]

Читателю статьи для её восприятия нужно понимать способ представления чисел с плавающей запятой в формате IEEE-754 и понимать, почему, например, 0,1+0,2≠0,3, но если такого навыка у вас по каким-то причинам нет, но вы хотели бы его приобрести, то прошу обратить внимание на список источников конце статьи, на пункты [1] и [3-5].

Итак, у нас следующая проблема. Сумма двух чисел с плавающей запятой c=a+b может вычисляться с некоторой ошибкой. Знаменитый на весь интернет пример 0,3 ≠ 0,2+0,1 хорошо это показывает. Наша задача в том, чтобы всё-таки складывать числа без этой ошибки. То есть сделать так, чтобы мы могли как-то сложить 0,2+0,1 и хоть в каком-то виде знать точный результат. В каком смысле точный, если даже исходные числа 0,1 и 0,2 не имеют точного представления в формате IEEE-754? Вот сейчас и поясню.

Начнём с того, что чисел 0,1 и 0,2 в двоичной арифметике с плавающей запятой быть не может, а наиболее близкие к ним значения для типа данных double (число удвоенной точности binary64, так его называют в Стандарте IEEE-754) следующие:

$0{,}1 → 0{,}1000000000000000055511151231257827021181583404541015625 ={}\\ {}=\frac{3602879701896397}{36028797018963968}$

$0{,}2 → 0{,}200000000000000011102230246251565404236316680908203125 ={}\\ {}=\frac{3602879701896397}{18014398509481984}$

Десятичный результат получен с помощью правильного онлайн-конвертера, а дробь посчитана с помощью библиотеки MPIR и функции mpq_set_d, которая умеет переводить double к рациональной дроби.

К сожалению, это данность, от неё никуда не уйти, если хранить числа в типе данных double (или любом другом типе фиксированного размера из Стандарта IEEE-754). Но проблема, которую мы решаем, другая. Нам нужно эти два числа, наиболее близких к 0,1 и 0,2, сложить так, чтобы получить результат без погрешности. То есть чтобы в результате сложения иметь число

0,1000000000000000055511151231257827021181583404541015625 +
0,2000000000000000111022302462515654042363166809082031250 =
0,3000000000000000166533453693773481063544750213623046875.

К сожалению, если просто написать код s=0.1+0.2, то мы получим кое-что другое, а именно

s == 0.3000000000000000444089209850062616169452667236328125

что отличается от правильного ответа ровно на

$t = 2{,}77555756156289135105907917022705078125 \cdot 10^{-17}$

«Подумаешь, — скажете вы, — десять в минус семнадцатой! Мне чтобы пиксель на экран вывести такая погрешность не помеха!». И будете правы. Задача точного вычисления каких-либо выражений относится к очень узкой области Computer Science, связанной с разработкой математических библиотек для языков программирования. Когда вы вызываете какую-нибудь функцию из такой библиотеки, то можете и не подозревать, что в основе её работы лежит труд десятков и сотен человек, выполняемый на протяжении десятилетий, а работает такая функция правильно благодаря совершенно неочевидным алгоритмам… Вот я и хотел бы приоткрыть для вас этот удивительный мир, для чего и пишу такие научно-популярные статьи.

Зачем может понадобиться точное сложение двух чисел? Приложений много, но вот одно из них, которое будет понятно всем. Если вы хотите сложить все числа из массива X[N] и сделаете это вот так:

S = 0.0;
for (i=0; i<N; ++i)
  S = S + X[i];

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

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

У нас есть два числа $inline$ и $inline$ типа double. Нам не важно, что эти числа $inline$ и $inline$ уже содержат в себе какую-то погрешность, полученную, например, в результате конвертирования десятичной строки в формат IEEE-754. Важно, что они сейчас перед нами, а их предыстория нас не интересует. Нужно сложить эти два числа c=a+b так, чтобы в результате сложения не возникло погрешности.

Но ведь это невозможно!

Да, это невозможно, спасибо что дочитали, до новых встреч :)

Шучу, конечно. Это невозможно только если мы храним результат сложения в одной переменной того же типа данных. Но вспомните пример выше. У нас была переменная s, и переменная t. Причём s была округлённым результатом сложения a+b, а t была равна разности этого округлённого результата и точного значения суммы. При этом выполняется равенство s+t=a+b.

И вот хорошая новость состоит в том, друзья, что такое представление суммы a+b в виде суммы s+t можно выполнить всегда (если a+b≠∞)! Если s=a+b оказывается точно-представимым значением в типе double, то очевидно, что t=0. Если это не так, то t будет равно некоторому очень маленькому (по сравнению с s) числу, которое является точно-представимым. Итак, вот оно, фундаментальное свойство суммы чисел с плавающей запятой: ошибка округления в результате суммирования чисел типа double всегда будет точно-представимым числом типа double! А это означает, что пара чисел (s, t) всегда даёт нам возможность сохранить сумму чисел a+b «как бы» без погрешности. Да, мы вынуждены хранить две переменные вместо одной, но прелесть в том, что их всего две, а не больше.

Теперь опишем это свойство на математическом языке. Введём обозначение RN(x) – это результат приведения произвольного вещественного числа x к типу данных double по правилу округления round-nearest-ties-to-even, то есть это округление к ближайшему, но в случае равного удаления от двух ближайших к тому, у которого последний бит мантиссы равен нулю (чётный). Именно этот режим работает почти везде по умолчанию, то есть если вы не знаете, о чём я сейчас говорю, то в вашем процессоре на 100% работает именно этот режим, так что не беспокойтесь.

Пусть a и b – числа типа double. Пусть |a|≥|b| и RN(a+b) ≠ ∞. Тогда следующий алгоритм

s = RN (a+b);
z = RN (s-a);
t = RN (b-z);
return (s, t);

вычисляет пару (s, t) таких чисел, для которых:

s+t = a+b (в точности)
s – число типа double, наиболее близкое к a+b.

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

Прямоугольник олицетворяет переменную с плавающей запятой фиксированного размера, поэтому прямоугольники, помеченные символами «а» и «b» имеют одинаковый размер, но

$inline$ смещён относительно

$inline$ вправо, потому что у нас есть условие: |a|≥|b|. Третий прямоугольник «Точное а+b» — это некоторое промежуточное значение, которое может иметь больший размер, чем размер переменных

$inline$ и

$inline$ , поэтому оно будет округлено, и «хвостик», вылезающий за границы нашего типа данных, будет отброшен. Таким образом, мы переходим к четвёртому прямоугольнику «Округлённое a+b», это и есть наше значение s, полученное в первой строке алгоритма. Если теперь из s снова вычесть

$inline$ , то останется только «b без хвостика». Это делается во второй строке алгоритма. Теперь мы хотим получить «хвостик» от

$inline$ , и это делается в третьей строке алгоритма, когда из исходной переменной

$inline$ мы вычитаем «b без хвостика». Остаётся «хвостик», это и есть переменная t, которая показывает ту самую погрешность, которая возникла в ходе округления. При этом из данных рассуждений видно, что такой «хвостик» всегда будет умещаться в одну переменную, потому что он не может превышать размера переменной

$inline$ . В крайнем случае, когда смещение

$inline$ относительно

$inline$ будет настолько большим, что s=RN(a+b)=a, то в этом случае, очевидно, z=0 и t=b. Скучный рисунок на эту тему я вам предлагаю изобразить самостоятельно.

Если вы не находите картинки убедительными для себя, то в книге [1, раздел 4.3.1, теорема 4.3] есть строгое математическое доказательство, но оно не умещается в формат научно-популярной статьи. Его краткая суть в том, что в нём показано почему в строках 2 и 3 алгоритма не будет выполняться округления, то есть эти выражения вычисляются точно, а если так, значит t=b-z=b-(s-a) = (a+b)-s в точности, что нам как раз и нужно: t является разностью между реальной суммой a+b и её округлённым значением s.

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

Пример 1.

$\begin{array}{rcl} a &{}={}& 9007199254740991 = 2^{53}-1, \\ b &{}={}& 2, \\ s &{}={}& 9007199254740992, \\ t &{}={}& 1. \end{array}$

Пояснение. Реальное значение a+b=2⁵³+1, однако в типе данных double младший бит, равный единице, не влезет в 52 бита дробной части мантиссы, по какой причине будет выброшен при округлении, но переменная t «подхватит» его и сохранит в качестве погрешности, а переменная s сумеет сохранить только 2⁵³ ровно. Легко видеть, что s+t будет равно 2⁵³+1.

Пример 2.

$\begin{array}{rcl} a &{}={}& 1152921504606846976 = 2^{60}, \\ b &{}={}& 1073741823 = 2^{30}-1, \\ s &{}={}& 1152921505680588800, \\ t &{}={}& -1. \end{array}$

Пояснение выполнено в двоичном коде.

  a = 1000000000000000000000000000000000000000000000000000000000000
  b =                                111111111111111111111111111111
a+b = 1000000000000000000000000000000111111111111111111111111111111
      -------------------------------------бит округления--^ 
  s = 1000000000000000000000000000001000000000000000000000000000000

Если выравнивание кода не поехало, то вы видите, где у суммы a+b будет бит округления, и что само округление будет выполнено вверх. Чтобы снова получить паровоз из 30 единиц, нужно вычесть единицу из s=2⁶⁰+2³⁰. Поэтому t=-1. Как видим, t может быть отрицательным, когда округление выполняется вверх.

Я не говорил этого явно, но алгоритм работает даже когда b<0, то есть фактически происходит вычитание.

Пример 3.

$\begin{array}{rcl} a &{}={}& 9007199254740991 = 2^{53}-1, \\ b &{}={}& -2251799813685247{,}75 = -\frac{2^{53}-1}{4}, \\ s &{}={}& 6755399441055743, \\ t &{}={}& 0{,}25. \end{array}$

В этом примере число

$inline$ является сдвигом вправо на 2 бита числа

$inline$ , поэтому если

$inline$ влезает в double «впритык», ясно, что вычитание здесь точным получиться не может. Останется небольшой хвостик размером в два бита после запятой.

Из доказательства, приведённого в [1], следует один положительный момент данного алгоритма: в ходе его выполнения не может возникнуть переполнения во второй и третьей строках, если оно не возникло при вычислении s=RN(a+b).

Недостатком является то обстоятельство, что алгоритм работает только для |a|≥|b| (однако если вы посмотрели доказательство, то знаете, что в действительности достаточно более слабого условия, чтобы экспонента $inline$ была не меньше экспоненты $inline$ , но проверить это условие намного сложнее). То есть нам нужно либо делать лишнюю проверку, либо как-то иначе гарантировать правильный порядок чисел на входе алгоритма. Ветвление не всегда обрабатывается достаточно быстро, это зависит от процессора и от того, как на это ветвление посмотрел компилятор (иногда он может его убрать, иногда — нет, а иногда он его убрал, но оказалось так плохо, что лучше бы не трогал). Возникает вопрос: а можно сложить числа без ошибок округления, если их порядок друг относительно друга заранее неизвестен?

Можно. Для этого есть второй алгоритм, но в нём вместо 3-х операций их уже 6.

  s = RN (a+b);
  b' = RN (s-a);
  a' = RN (s-b');
  d_b = RN (b-b');
  d_a = RN (a-a');
  t = RN (d_a+d_b);
  return (s, t)

Как это работает? В случае когда |a|≥|b|, алгоритм работает по сути так же как предыдущий, и строгое доказательство для этого случая, которое вы можете отыскать в [2, раздел 2.3, теорема 7], сводится к тому, чтобы показать, что «лишние» три операции не портят этого результата. А вот основная сложность доказательства в том, чтобы рассмотреть случай |a|

Первые два прямоугольника показывают соотношение между

$inline$ и

$inline$ , на этот раз

$inline$ смещено относительно

$inline$ вправо. Следующие три прямоугольника показывают процедуру сложения и отбрасывания «хвостика». Дальше начинается основная сложность. Вычисляем b’=s-a, то есть мы вычитаем из округлённого значения s число

$inline$ и выброшенный «xвостик», а это значит, что b’ будет чуть меньше, чем

$inline$ , и этот недостаток отмечен красным прямоугольничком. Другое дело, когда мы вычисляем a’=s-b’, то есть вычитаем из суммы величину «b с недостатком», а значит получим «а без хвостика с избытком», и этот избыток обозначается зелёным прямоугольничком. Если мы теперь вычтем из

$inline$ величину b’ (которая с недостатком), то получим избыток d_b. Далее вычитаем из

$inline$ величину a’ (которая с избытком), и получаем хвостик с недостатком d_a. Если теперь сложить хвостик с недостатком и избыток, мы получим «чистый хвостик».

У читателя может возникнуть вопрос: а в каких случаях можно с уверенностью сказать, что t=0? Иными словами, про какие пары чисел (a, b) точно известно, что их сумма будет точно-представимым (без округления) числом в том же типе данных?

Мне известны только три теоремы на этот счёт, которые также приводятся в [1] и [2].

Теорема 1 [книга 1, раздел 4.2.1, теорема 4.2]. Если сумма RN(a+b) оказалась денормализованным числом, то сумма a+b является точно-представимой.

Теорема 2 [статья 2, раздел 2.2, лемма 4] Если |a+b|≤|a| и |a+b|≤|b|, то число a+b является точно-представимым (аналогичное верно и для разности).

Теорема 3 [книга 1, раздел 4.2.1, лемма 4.1] Пусть a≥0 и a/2 ≤ b ≤ 2a, тогда разность a-b будет точно представимой.

Бдительный читатель сразу вспомнит про так называемую ошибку критического сокращения старших значащих битов, называемую в литературе “Catastrophic Cancellation” и спросит: «Как же так, ведь давно известно, что когда мы вычитаем очень близкие друг к другу числа, там возникает такая погрешность, что ой-ой-ой! Как ты говоришь, что в этом случае разность будет точно-представимой».

Дело в том, что Catastrophic Cancellation – это не ошибка вычисления, а неизбежное свойство чисел с плавающей запятой; это свойство не порождает никакую новую погрешность, а как бы «высвечивает» ту, что уже изначально была заложена в уменьшаемом и вычитаемом. Если не смотря на уже имеющееся в интернете описание вы хотите подробного обсуждения данной особенности чисел с плавающей запятой именно в моём исполнении, то пишите об этом в комментариях, пойду навстречу.

На основе рассмотренных в этой статье алгоритмов в следующей мы будем более правильно складывать числа из массива.

Благодарю за внимание!

Список источников

[1] Jean-Michel Muller, “Handbook of floating-point arithmetic”, 2018.
[2] Jonathan Richard Shewchuk, “Adaptive Precision Floating-Point Arithmetic and Fast Robust Geometric Predicates”, Discrete & Computational Geometry 18(3), 1997, pp. 305–363.
[3] На Хабре: «Что нужно знать про арифметику с плавающей запятой».
[4] На Хабре: «Наглядное объяснение чисел с плавающей запятой».
[5] Учебный видео-курс для «самых маленьких», предельно наглядное разъяснение чисел с плавающей запятой в 8-ми уроках. Первый урок на на YouTube.

Let's block ads! (Why?)

...

суббота, 17 октября 2020 г.

Лазеры с вертикальным излучением позволили Apple создать очень простые лидары

В более мощных лидарах также используются лазеры с вертикальным излучением (VCSEL) и однофотонные лавинные диоды (SPAD)

Лидары скоро ворвутся на автомобильный рынок

Исходная точка

Новое решение

Как происходят вычисления

На что направлена разработка

Технические детали

Быть может проще купить?

Поиск подходящего сервера

Выбор жестких дисков

Настройка системы

Сборка RAID

Оптимизация

Настройка повторяющихся задач

Установка Netatalk

Настройка конфигурации

Включение портов в Firewall

Дополнительные установки S.M.A.R.T мониторинг

Демон для ИБП

Аппаратный апгрейд

Результат

Быстрые методы

Метод Reach/Frequency

Метод Poker planning

Медленные методы

RICE

Приоритизация по ROI

Пример приоритизаций из иерархии метрик

Пример приоритизации по ROI

Типичные ошибки Product manager’ов

Итог

Что такое RAID?

Виды RAID-контроллеров

Linux Software RAID

Intel® Virtual RAID On CPU

LSI MegaRAID 9460-8i

Тестовый стенд

Тестирование

Заключение

Q: Как создать сообщество по интересам? Почему площадка – последний по важности вопрос?

Q: Как сделать сообщество интересным?

Q: почему сообщества и конференции – это не про деньги, но про власть и влияние?

Q: откуда брать деньги на конференцию и зачем ее делать?

Q: чем конференция отличается от unconference?

Q: реально ли сделать онлайн-телеконференцию на несколько сотен человек?

Q: Онлайн – это фуфуфу, или съедобно?

Q: планируете развивать географию Chaos Constructions, или Питер навсегда?

Q: есть ли планы по завозу именитых заграничных IT-шников?

Что было ранее

Список источников

суббота, 17 октября 2020 г.

Дополнительные установки
S.M.A.R.T мониторинг