Добрый день!

Я хочу рассказать о проекте игровой консоли Nintendo Entertainment System (NES) в реализации на FPGA. На постсоветском пространстве она известна как Dendy.


Желающих посмотреть видео и поностальгировать прошу под кат.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

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

Речь пойдёт о демке "8088 MPH", победившей в соревновании Revision 2015's Oldskool Demo. Мы, вместе с Trixter, reenigne и Scali сделали это. И я получил возможность не только работать с группой волшебников программирования, но и побить мировые рекорды при изготовлении демок для старого доброго IBM PC, мамы и папы современной платформы x86.

Если у вас под рукой по какой-то причине не оказалось IBM PC XT x86 с CGA-адаптером, вы можете посмотреть демку на ютубе:



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

Если вы помните мой предыдущий пост, там было высказано желание разобраться, что и как можно добавить к понравившейся мне модели, чтобы DIY forever. Большое спасибо пользователям UseTi, Phmphx, lomalkin и в особенности n4k4m1sh1, которые поделились интересными идеями на эту тему в комментариях. Понятно, что для поставленных целей нужны два навыка, один из которых — монтаж печатной платы. А значит сегодня мы будем паять, с нуля.



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

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

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

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


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

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

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

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)
«Галоп пикселя», часть VI — Анимация персонажей. Бег (линк)

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

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

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

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

Насколько дорогие батарейки лучше дешёвых?
Насколько ёмкость литиевых батареек больше обычных?
Насколько ёмкость солевых батареек меньше, чем у щелочных?
Отличаются ли батарейки для цифровых устройств от обычных?
Какие из батареек, стоящих одинаково, лучше покупать?

Чтобы получить ответы на эти вопросы я решил протестировать все батарейки АА и ААА, которые удастся найти в Москве. Я собрал 58 видов батареек АА и 35 видов ААА. Всего было протестировано 255 батареек — 170 АА и 85 ААА.

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

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

Нас окружает огромное количество всевозможных устройств и гаджетов, призванных облегчить и разнообразить нашу жизнь, начиная от детских электронных игрушек и заканчивая многообразными фотоаппаратами, фотовспышками, фонарями, рациями и т.д. Электропитание многих из них обеспечивается от Ni-MH элементов питания типоразмера АА. В продаже имеется великое разнообразие данных источников питания. Мое внимание привлекли аккумуляторы, как наиболее экономные и экологичные источники питания. В данном обзоре собраны результаты тестирования десяти различных комплектов аккумуляторов.

Ни для кого не секрет, что сейчас можно легко скачать эмулятор почти любой игровой консоли 80х-90х и поиграть в классические игры на компьютере, телефоне и многих других платформах. В сети легко можно найти и ROM'ы этих самых игр. Зачастую люди качают их и даже не задумываются, каким же образом кто-то однажды прочитал их из картриджа. В этой статье я и постараюсь рассказать, как же это делалось в случае с NES/Famicom, которая у нас была больше известна как «Денди», и покажу, как можно сделать это самостоятельно.

Однажды в нашем небольшом офисе понадобилось настроить систему учёта трафика под linux. Бегло просмотрев готовые решения, я решил использовать что-то попроще. Погуглив, мне понравился подход использовать самописный скрипт, который бы конвертировал статистику netflow в squid-совместимый лог, который затем можно анализировать чем угодно. Готовый скрипт, гуляющий по гуглу, я использовать не стал, т.к. он использует ipcad, которой отсутствует в debian и ubuntu. Написал свой вариант, использующий любой netflow сенсор и flow-tools в качестве коллектора. Скрипт постепенно усложнялся и, в итоге, вырос в небольшую систему учёта трафика. Архив этого удовольствия весит около 50кб, при этом:

• устанавливается с помощью deb для дистрибутивов, основанных на debian или с помощью собственного инсталлятора для остальных
• умеет считать интернет-трафик на маршрутизаторе по всем ip v4 протоколам и портам
• умеет ограничивать доступ не прописанным пользователям
• вместо голой статистики ip-адресов netflow умеет детализировать отчёты с помощью dig и squid
• умеет выборочно блокировать трафик
• имеет веб-интерфейс для управления пользователями и группами пользователей
• настраивается немногим сложнее lightsquid, который использует в работе
• не использует промежуточный лог access.log, собственный парсер конвертирует статистику netflow напрямую в отчёт lightsquid

Сеть нашей воображаемой компании linkmeup растёт. У неё есть уже магистральные линии в различных городах, клиентская база и отличный штат инженеров, выросших на цикле СДСМ.
Но всё им мало. Услуги ШПД — это хорошо и нужно, но есть ещё огромный потенциальный рынок корпоративных клиентов, которым нужен VPN.
Думали ребята над этим, ломали голову и пришли к выводу, что никак тут не обойтись без MPLS.

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



Сегодня в выпуске:

• Что такое MPLS
• Передача трафика в сети MPLS
• Терминология
• Распространение меток
• — Методы распространение меток
• — — — DU против DoD
• — — — Ordered Control против Independent Control
• — — — Liberal Label Retention Mode против Conservative Label Retention Mode
• — — — PHP
• — Протоколы распространения меток
• — — — LDP
• — — — — Практика
• — — — Применение чистого MPLS в связке с BGP
• — — — RSVP-TE
• — — — — Практика
• — ВиО
• — Полезные ссылки

А начнём мы с вопроса: «Что не так с IP?»

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

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

Когда у меня встала необходимость разобраться, как сделать failover или load balancing, имея два и более каналов в мир, я нашел множество статей и инструкций, в которых описывались рабочие конфигурации. Но почти нигде не нашел разъяснения, как все работает, и описания отличий разных вариантов. Хочу исправить эту несправедливость и собрать простейшие варианты построения failover и load balancing конфигураций в одной статье.

Итак, у нас есть роутер, который соединяет нашу локальную сеть и два канала в интернет (основной ISP1 и резервный ISP2).

Давайте рассмотрим что же мы можем сделать:

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

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

LA30 Decwriter

Теперь я приступил к заключительной части своего квеста — раздобыть хороший терминал, который был бы таким же винтажным, как и основная система. Мне повезло, что у меня в хранении есть LA30, который я собираюсь теперь начать восстанавливать. Наш экземпляр был изготовлен в начале 1973. Хотя, печатающие головки, видимо, были заменены в 1979.

LA30, по-видимому, был одним из первых матричных принтеров, что делает его интересным, сам по себе, даже в отрыве от PDP-11.

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

Стриммер TU60 и контроллер TA11

В 70х DEC создали простую замену для перфолент, которая базировалась на разновидности простых аудио-кассет. TU60 вмещает два блока стриммеров. 50метровая лента могла хранить до 100Кб:

Перевод статьи по восстановлению одной старой интересной машинки. Много тяжелых картинок. Курсивом мои комментарии.

Этот PDP 11/04 изначально принадлежал Ericsson. Мы получили его в конце восьмидесятых от EDKX — компьютерного клуба Ericsson. Компьютер был передан по частям, но всё было на месте за исключением пары винтиков. Вместе с самим PDP-11 шла ленточная станция TU60.

Панель операторской консоли

Двадцать пять лет назад IBM представила генеральный план восстановления контроля над рынком PC. В ноябре 1987 года в магазины отправились первые дискеты с OS/2 версии 1.0. Microsoft разрабатывала ее вместе с IBM и в случае успешной реализации этих планов мир был бы совсем иным. И мир уже начал меняться.

Сейчас о OS/2 обычно вспоминают только в связи с той ролью, которую она сыграла в промышленной войне, окончившейся триумфальной победой Microsoft. На момент выпуска OS/2 в Microsoft работало 1800 человек, меньше, чем сейчас работает в ливерпульском телемагазине QVC. Microsoft даже не была крупнейшим производителем программ для PC. Но всего через несколько лет компания стала не только крупнейшим игроком отрасли, но и одной самых дорогих компаний в мире; один лишь слух о выходе Microsoft в новую нишу вызывал панику у существующих игроков.

Согласно традициям нашего издания я вернул старые программы к жизни и оценил OS/2 с современной точки зрения. Но гораздо интереснее вновь задать иной вопрос: могла ли IBM победить? Если именно OS/2 стала причиной поражения Синего Гиганта, то смогли бы они остановить Microsoft с помощью более хитрых планов? Давайте вернемся в те времена, когда мир еще не знал слов «платформа» и «экосистема» и вспомним, как выглядела отрасль информационных технологий в середине 1980-х.