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

Этот же фреймворк задаёт порядок, в котором мы будем разбираться с вопросом.
И виртуализация сети, которой посвящён этот выпуск, не особо укладывается в тематику АДСМ, где мы разбираем автоматику.

Но давайте взглянем на неё под другим углом.

Уже давно одной сетью пользуются многие сервисы. В случае оператора связи это 2G, 3G, LTE, ШПД и B2B, например. В случае ДЦ: связность для разных клиентов, Интернет, блочное хранилище, объектное хранилище.

И все сервисы требуют изоляции друг от друга. Так появились оверлейные сети.

И все сервисы не хотят ждать, когда человек настроит их вручную. Так появились оркестраторы и SDN.

Первый подход к систематической автоматизации сети, точнее её части, давно предпринят и много где внедрён в жизнь: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Вот с ним сегодня и поразбираемся.

Вам нужна аналитика.

Я совершенно уверен в этом, потому что сегодня всем нужна аналитика. Не только продуктовой команде, не только маркетингу или финансам, но и продажам, доставке, сегодня каждому в стартапе нужна аналитика. Аналитика помогает принимать все решения, от стратегических до тактических, как управляющим, так и рядовым сотрудникам.

Это пост о том, как создать аналитику в вашей организации. Речь пойдёт не о том, какие метрики отслеживать (об этом уже написано много хороших постов), а о том, как сделать так, чтобы ваш бизнес их генерировал. На практике выясняется, что на вопрос реализации —  как мне построить бизнес, который добывает данные для принятия решений? —  ответить гораздо труднее.

Меня зовут Сергей, я из компании ITSumma, и я хочу вам рассказать, как мы подходим к резервированию в Kubernetes. В последнее время я много занимаюсь консультативной работой по внедрению разнообразных devops-решений для различных команд, и, в частности, плотно работаю по проектам с использованием K8s. На конференции Uptime day 4, которая была посвящена резервированию в сложных архитектурах, я выступал с докладом о резервировании «кубика», и вот его вольный пересказ. Только заранее предупрежу, что он является не непосредственным руководством к действию, а скорее, обобщением размышлений на указанную тему.



В принципе мониторинг и резервирование — это два основных инструмента повышения отказоустойчивости любого проекта. Но ведь в кубере всё балансируется само, скажете вы, всё масштабируется само, и если что-то произойдёт — поднимется само… То есть, при первом поверхностном исследовании темы, на вопрос, кто как подходит к резервированию K8s, интернет ответил мне «а зачем?» Многие думают, что кубер представляет собой такую магическую штуку, которая избавляет от всех инфраструктурных проблем и делает так, что проект никогда не упадет. Но… мир не то, чем кажется.

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

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

В службу технической поддержки RUVDS регулярно обращаются по поводу GUI и удаленного доступа к нему на виртуальных серверах с Linux, несмотря на то что в интернете достаточно много материалов освещающих эту проблему. Поэтому, для наших пользователей мы решили собрать всё по этой теме в одну статью.

В последнее время Kubernetes пользуется большой популярностью, и разработчики ищут дополнительные способы и методы для развёртывания приложений в кластере этой системы. Даже командная строка kubectl стала восприниматься как инструмент низкого уровня, при этом пользователи продолжают искать ещё более простые способы взаимодействия с кластером. Draft, Gitkube, Helm, Ksonnet, Metaparticle и Skaffold — вот лишь некоторые инструменты, помогающие разработчикам создавать и разворачивать приложения в Kubernetes.

Draft, Gitkube и Skaffold упрощают разработку приложений, позволяя разработчикам как можно быстрее запускать их в кластере Kubernetes. Helm и Ksonnet помогают в процессе развёртывания, т.к. могут определять готовность приложения к отправке, а также управлять выпуском новых версий, обработки различных кластеров и т. д. Metaparticle — необычный инструмент, который позволяет вам в рамках собственного кода работать с любыми форматами (YAML, dockerfile).

Итак, что же использовать в конкретной ситуации?

Давайте посмотрим.

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

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

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

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

Если вам это знакомо, то данная статья как раз для вас, так что продолжайте читать.

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

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

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

Знаете, когда я почти нечаянно обнаружил, читая прекрасную книгу Дмитрия Кетова «Внутреннее устройство Linux» (и это не реклама), что каждый скачанный нами файл из Интернета с легкой руки браузера оставляет в расширенных атрибутах файла (в inode файла, не в самом файле) как минимум полную ссылку на то откуда он был скачан, я пришел в легкое возбуждение и хотел тут же броситься спасать мир. Позже, немного изучив этот вопрос, почитав «коммиты» и «комменты», говорившие, что этой возможности, встроенной в ядро GNU/Linux, как минимум уже около 10 лет, что ею пользуется не только браузеры, но и, к примеру, популярная утилита wget (curl нет), и что эта вещь считается чуть ли не нормой в Linux (и, как выяснилось позже, в MacOS), то я немного подуспокоился. Одно не давало мне покоя: поиск ключевого слова getfattr в google по сайту «Хабра»: site:https://habr.com getfattr, равно как и по ЛОРУ: site:https://linux.org.ru getfattr ничего толком не дал. «Значит» — подумал я — «эта тема еще особенно не обсуждалась». — Что же, тогда пришло время ее обсудить, но для начала пришлось немного по-исследовать. И вот что я обнаружил:

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


Рисунок 1. Сравнение различных квазислучайных последовательностей с низким расхождением. Заметьте, что предлагаемая мной $$-последовательность создаёт более равномерно распределённые точки, чем все остальные методы. Более того, все остальные методы требуют тщательного подбора базовых параметров, а в случае неправильного подбора приводят к вырожденности (например справа вверху)

Рассматриваемые в статье темы

• Последовательности с низким расхождением в одном измерении
• Методы с низким расхождением в двух измерениях
• Расстояние упаковки
• Множества с многоклассовым низким расхождением
• Квазислучайные последовательности на поверхности сферы
• Квазипериодический тайлинг плоскости
• Маски дизеринга в компьютерной графике

Какое-то время назад этот пост был выложен на главной странице Hacker News. Можете прочитать там его обсуждение.

Буду краток, причина оказалась в непостоянстве частоты GPU (больше), и CPU(меньше). Используя MSI Afterburner, HWiNFO64, и RivaTuner экспериментальным путем я выяснил что пропуски кадров происходят из-за достижения powerlimit в gpu и pl4 limit в cpu. Лимиты есть и всегда будут. Даже если убрать лимиты для мощности и тока, упремся в температурный лимит, который ещё более наглый чем предыдущие, тк изменяет частоту более резкими скачками. Но есть решение. Прошу под кат.

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

О Bitcoin я узнал относительно недавно, но он меня сразу подкупил своей идеей p2p. Чем глубже я зарывался в их Wiki, тем больше проникался этой идеей. Ее реализация красива и элегантна с технической точки зрения.

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

У моих игр довольно много загрузок на Google Play (больше 20 млн.), наверное поэтому, меня часто спрашивают про продвижение. Если кто-то из разработчиков пишет мне в личку или почту, готов поспорить, все сведется к вопросу: «Как ты продвигаешь свои игры, чувак?». Все думают, что у меня есть какой-то секрет (нет). Ладно, давайте я попробую сформулировать то, что знаю и будем надеяться, что это будет кому-то полезно. По крайней мере, я смогу давать ссылку на этот пост.

При развитии free-to-play мобильной игры вместе с новыми фичами регулярно добавляется и новая графика. Часть ее включается в дистрибутив, часть скачивается в ходе игры. Для возможности запуска приложения на устройствах с небольшим размером оперативной памяти разработчики применяют аппаратно сжатые текстуры.



Формат ETC1 обязателен к поддержке на всех Android-устройствах с OpenGL ES 2.0 и является хорошей отправной точкой оптимизации потребляемой оперативной памяти. По сравнению с форматами PNG, JPEG, WebP загрузка текстур ETC1 осуществляется без интенсивных расчетов обычным копированием памяти. Также улучшается производительность игры по причине меньших размеров данных текстур пересылаемых из медленной памяти в быструю.

Finite State Entropy (FSE) – алгоритм энтропийного кодирования, чем-то похожий и на алгоритм Хаффмана, и на арифметическое кодирование. При этом он взял лучшее от них обоих: работает так же быстро, как хаффмановский, и со степенью сжатия как у арифметического кодирования.

FSE принадлежит семейству кодеков ANS (Asymmetric Numeral Systems),  изобретённых Яреком Ду́дой. На основе его исследований Ян Колле разработал оптимизированный вариант алгоритма, впоследствии названный FSE.

В заметках Яна Колле непросто разобраться, поэтому я изложу объяснение в несколько ином порядке, более удобном для понимания, на мой взгляд.

Художники нарисовали яркую графику, программисты встроили ее в игру, аниматоры добавили движения — казалось бы, все, готово. Но нет, менеджерам не нравится:

«Надо убрать серые пятна и белые линии. Тут пульсирующая кнопка дергается, там прогресс-бар лесенкой идет».

Смотришь игровые ресурсы — нет в них ничего такого, все спрайты обрезаны. Читаешь код — формулы правильные, точности шейдера хватает. Но результат все равно получился неважный. Где ошибка?



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

1. Нужна мощная видеокарта и свежие драйверы;
2. Стоит сделать скачиваемые наборы графики для всех возможных разрешений экрана;
3. У квадратных текстур с размерами степени двойки нет таких проблем;
4. Это все из-за сжатия графики (PVRTC/DXT5/ETC1/...);
5. В графическом редакторе придется слегка размазать края;
6. Так и должно было получиться, ведь мы не подготовили графические данные;
7. Поможет только антиалиасинг;
8. Нужны текстуры и таргеты в режиме premultiplied alpha.

Какой вариант ответа правильный, почему именно он и как побороть артефакты графики читайте под катом.