Intel Foveros 3D

Поскольку закон Мура больше не действует, разработчикам микросхем приходится искать иные способы повышения производительности. Одна из подходящих для этого технологий называется 3D-штабелирование (3D chip stacking). Это объёмная этажерочная архитектура чипов, в разработке которой лидирует Intel. Два месяца назад Intel представила архитектуру Foveros 3D: трёхмерную структуру, которая включает в себя CPU по техпроцессу 10 нм, чип ввода-вывода и сквозные вертикальные электрические соединения TSV (Through Silicon Via) в центре микросхемы, а сверху всей микросхемы — чип памяти.

На конференции по высокопроизводительным вычислениям Rice Oil and Gas HPC компания AMD заверила, что работает над собственным вариантом 3D-архитектуры чипов.

Британский стартап UltraSoC представил on-chip-технологию для отслеживания характеристик микросхем без ущерба для производительности. Рассказываем, как устроено решение.

СДСМ-15. Про QoS. Теперь с возможностью Pull Request'ов.

И вот мы дошли до темы QoS.

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

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

QoS настолько опутан аурой шаманизма и недоступности, что все молодые (и не только) инженеры стараются тщательно игнорировать его существование, считая, что достаточно закидать проблемы деньгами, и бесконечно расширяя линки. Правда пока они не осознают, что при таком подходе их неизбежно ждёт провал. Или бизнес начнёт задавать неудобные вопросы, или возникнет масса проблем, почти не связанных с шириной канала, зато прямо зависящих от эффективности его использования. Ага, VoIP активно машет ручкой из-за кулис, а мультикастовый трафик ехидно поглаживает вас по спинке.

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

«КПД» стандартного WAN – всего около 10%

Если заглянуть в практически любой канал связи между филиалом компании и дата-центром, то можно увидеть достаточно неоптимальную картину:

• Во-первых, передается очень много (до 60–70% канала) избыточной информации, которая так или иначе уже запрашивалась.
• Во-вторых, канал загружен «болтливыми» приложениями, рассчитанными на работу в локальной сети, — они обмениваются короткими сообщениями, что негативно сказывается на их производительности в канале связи.
• В-третьих, сам протокол TCP изначально создавался для локальных сетей и отлично подходит для малых задержек RTT и при отсутствии потерь пакетов в сети. В реальных каналах при потерях пакетов скорость сильно деградирует и медленно восстанавливается за счет больших RTT.

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

Когда речь заходит об ограничении пропускной способности на сетевом оборудовании, в первую очередь в голову приходят две технологи: policer и shaper. Policer ограничивает скорость за счёт отбрасывания «лишних» пакетов, которые приводят к превышению заданной скорости. Shaper пытается сгладить скорость до нужного значения путём буферизации пакетов. Данную статью я решил написать после прочтения заметки в блоге Ивана Пепельняка (Ivan Pepelnjak). В ней в очередной раз поднимался вопрос: что лучше – policer или shaper. И как часто бывает с такими вопросами, ответ на него: всё зависит от ситуации, так как у каждой из технологий есть свои плюсы и минусы. Я решил разобраться с этим чуточку подробнее, путём проведения нехитрых экспериментов. Полученные результаты подкатом.

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

В моём случае это была лень объяснять в тысячный раз клиенту, почему он арендовал канал точка-точка и в договоре чёрным по белому написано Ethernet 1Гбит/с, а он как ни измеряет, но чуть-чуть да меньше получается.

Где остальное? Почему недобор? Куда девался интернет из провода? А может его и вовсе страшно обманули?

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

Важно

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

Компания Google опубликовала ряд рекомендаций, как уменьшить задержку (latency) для TCP-соединений между веб-сервером и браузером. В этих рекомендациях обобщаются исследования, которые компания вела в течение нескольких лет.

1. Увеличьте первоначальный размер congestion window до 10 (IW10). Сейчас в начале TCP-соединения отправляется три пакета данных в три раунда (RTT) для передачи небольшой информации (15 КБ). Наши эксперименты показывают, что IW10 уменьшает сетевую задержку для веб-соединений более чем на 10%.

2. Уменьшите первоначальный таймаут с 3 секунд до 1 секунды. RTT в 3 секунды был приемлем пару десятилетий назад, но в современном интернете нужен гораздо меньший таймаут. Наше обоснование для этого хорошо задокументировано здесь.

TCP (Transmission Control Protocol) — основной протокол интернета. Одна из его главных задач — бороться с перегрузками в сети (network congestion), когда возникают заторы из пакетов. Регулирование осуществляется путём взаимной подстройки скорости отправки запросов, причём для этого существует множество хитрых методов. Например, в Linux используется алгоритм под названием TCP Cubic, а под Windows — Compound TCP. Кроме них, существуют ещё TCP Tahoe, Reno, NewReno, Vegas, FAST, BIC и др.

Специалисты из Массачусетского технологического института разработали программу Remy, которая методом проб и ошибок пыталась улучшить существующие алгоритмы подавления заторов TCP. Результат превзошёл все ожидания. Эффективность алгоритмов RemyCC превзошла и TCP Cubic, и Compound TCP, и остальных «конкурентов» в различных сетевых условиях. Проблема только в том, что учёные не совсем понимают, за счёт чего именно Remy удалось показать такой феноменальный результат.

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

Всем привет!

В этот раз подошло время рассмотреть стандартный тест RFC2544: для чего используется, как проводится, его достоинства и недостатки.

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

Покупая продукт или услугу мы часто оперируем таким понятием как качество. Что же такое качество? Если мы обратимся к словарю Ожегова, то там увидим следующее: «совокупность существенных признаков, свойств, особенностей, отличающих предмет или явление от других и придающих ему определенность». Перенося определение на область сетей связи, приходим к выводу, что нам требуется определить «существенные признаки, свойства и особенности», позволяющие однозначно определить отличие одной линии или сети связи от другой. Перечисление всех признаков и свойств обобщаются понятием «метрика». Когда кто-то говорит о метриках сетей связи, он имеет в виду те характеристики и свойства, которые позволят точно судить о системе связи в целом. Потребность в оценке качества лежит большей частью в экономической области, хотя и техническая её часть не менее интересна. Я же попробую балансировать между ними, чтобы раскрыть все самые интересные аспекты этой области знаний.

Всех заинтересовавшихся прошу под кат.

В первой части мы разобрали «тройное рукопожатие» TCP и некоторые технологии — TCP Fast Open, контроль потока и перегрузкой и масштабирование окна. Во второй части узнаем, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.

Надежная передача данных в Интернете осуществляется на базе протокола TCP (Transmission Control Protocol), спецификация к которому была опубликована почти 30 лет назад. Алгоритм TCP (RFC793), позволяет подключенному устройству адаптироваться для работы в сети на скоростях в пределах десятков мегабит в секунду и задержки до 100 секунд. С бурным развитием новых технологий передачи данных, уже через 10 лет после внедрения стало ясно что производительность протокола не будет хватать для более широких каналов.

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

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

Определим первую часть как вводную. Здесь мы поговорим о хардварном инкапсуляторе ethernet-трафика, созданном на FPGA, обсудим его основные функции, архитектурные особенности и преимущества по сравнению с программными решениями.

Вторая часть, назовем ее «сетевой», будет более интересна для разработчиков железа, желающих ознакомиться с сетевыми технологиями поближе. Она будет посвящена тому, какую роль «Etherblade.net» может занять в сетях операторов связи. Так же разговор пойдет о концепции SDN (software defined networking) и о том, как открытое сетевое железо может дополнять решения больших вендоров, таких как «Cisco» и «Juniper», и даже конкурировать с ними.

И третья часть — «хардварная», которая скорее заинтересует сетевых инженеров, желающих приобщиться к аппаратному дизайну и начать разрабатывать сетевые устройства самостоятельно. В ней мы подробно рассмотрим FPGA-workflow, «союз софта и железа», FPGA-платы, среды разработки и другие моменты, рассказывающие о том, как подключиться к участию в проекте «EtherBlade.net».
Итак, поехали!

Всем привет!

Бывало ли у вас такое, что ставите файл на закачку, и скорость медленно, но верно возрастает, затем, в какой-то момент, резко снижается, затем опять возрастает? Закачка файла в один поток не обеспечивает полную скорость канала? Запускаете торрент-клиент, и пинг в игре сильно прыгает? Используете 3G-модем (или другую линию с относительно большой потерей пакетов) и не можете это терпеть?
Наверняка вы винили во всем ваш роутер, либо обвиняли своего провайдера в кривой настройке шейпера? Это влияет, но виноваты не они.
Итак, встречайте:

TCP Congestion Control, или TCP Congestion Avoidance Algorithm.

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

Недавно я испытал потребность выяснить, что на самом деле передаётся в разрабатываемом мной устройстве по шине I2C. Это был тот счастливый момент, когда можно было себе позволить «пилить пилой».

Привет, как вы уже поняли, это продолжение моей истории реверс-инжиниринга и портирования «Нейроманта».

Реверсим «Нейроманта». Часть 1: Спрайты
Реверсим «Нейроманта». Часть 2: Рендерим шрифт
Реверсим «Нейроманта». Часть 3: Добили рендеринг, делаем игру

Сегодня начнём с двух хороших новостей:

• во-первых, я больше не один — к проекту присоединился и уже успел внести ощутимый вклад пользователь viiri;
• во-вторых, теперь у нас есть открытый репозиторий на github.

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

Вступление

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

Да-да, об этом уже была статья на Хабре, но без практической реализации. Здесь же мы сфокусируемся как на теоретической части, так и на программерской. Итак, все под кат!

Как-то я прочитал на Хабре статью про настройку BGP на роутере. Инструкции оттуда можно использовать для настройки домашнего роутера так, чтобы трафик на определённые IP-адреса шёл через другой канал. Однако здесь есть проблема: список IP-адресов может быть очень большим.

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

“CVAX — когда вы забатите довольно воровать настоящий лучший”.
Надпись, оставленная американскими инженерами для советских коллег в топологии микропроцессора.

Реверс-инжиниринг микросхем — головная боль производителей с самых первых лет существования микроэлектроники. Вся советская электроника в какой-то момент была построена на нем, а сейчас с гораздо большим размахом тем же самым занимаются в Поднебесной, да и не только в ней. На самом деле, реверс-инжиниринг абсолютно легален в США, Евросоюзе и многих других местах, с целью (цитирую американский закон) “teaching, analyzing, or evaluating the concepts or techniques embodied in the mask work or circuitry”.

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

Другое не менее (а то и более) важное направление защиты микросхем от реверс-инжиниринга — обеспечение безопасности информации, хранимой в памяти. Такой информацией может быть как прошивка ПЛИС (то есть опять-таки интеллектуальная собственность разработчика), так и, например, пин-код от банковской карты или ключ шифрования защищенной флэшки. Чем больше ценной информации мы доверяем окружающему миру, тем важнее защищать эту информацию на всех уровнях работы обрабатывающих ее систем, и хардварный уровень — не исключение.