История Computer Science: Системы с разделением времени

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

http://hackaday.com/2012/09/17/retrotectacular-time-sharing/

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

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

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

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

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

Теперь Алисе нужно ждать, пока задание будет выполнено (возможно, это займёт пару часов, если на ЭВМ много других заданий). Когда задание будет выполнено, Боб отдаст Алисе распечатку с результатами вычислений. Или же распечатку с программной ошибкой (если что-то пошло не так). Если в программе обнаружилась ошибка, то Алисе нужно будет внести необходимые изменения, создать новое задание, отдать его на выполнение и т.п.

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

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

Правда здорово?

- Артём

X-сервер в Debian GNU/Hurd и особенности системы

В комметарии к скриншоту из этого [1] поста мне задали два вопроса касательно текущего статуса GNU Hurd. Я решил опубликовать ответ здесь, так как он получился достаточно длинным и он может быть интересен ещё кому-нибудь (кого волнуют эти же вопросы).

Итак, вопрос первый:

> А X сервер на нем заводится?

На сайте Debian GNU/Hurd есть инструкция по запуску X-сервера [2] - судя по всему, сервер должен запускаться без особых проблем. У меня пока не получилось его запустить. Надо будет ещё раз попробовать - возможно, я что-нибудь упустил из виду при настройке.

В качестве подтверждения, что X-сервер действительно работает - вот обсуждение [3] Debian GNU/Hurd, где можно найти скриншоты иксов, работающих на Hurd, запущенном в QEMU.

> Ощущаются ли особенности архитектуры?

Во-первых, надо сказать, что система работает достаточно стабильно (по сравнению с тем, что я видел в Arch Hurd в начале года). Например, исправлена досадная ошибка с "замораживанием" консоли при простое системы (патч оказался достаточно тривиальным [4]).

Однако, в плане производительности Hurd всё ещё отстаёт от Linux - по собственным ощущениям, по крайней мере. При работе с разделами ext2 очень активно нагружает процессор ext2fs сервер (транслятор, в терминологии Hurd), который обеспечивает доступ к разделам с этой ФС - скажем, при aptitude upgrade он ест иногда более 40% CPU.

Вот скриншот с рабочей системы, на котором видно, что ext2fs заметно нагружает CPU (htop запущен через SSH-подключение):

Что интересно, по сути ext2fs представляет собой переписанный драйвер ext2 из Linux (насколько я понимаю), который отражает особенности Hurd - например, его i-node хранят так же информацию о трансляторах, которые являются частью Hurd. В системе даже привычный mount является ни чем иным, как скриптом, который запускает соответствующий транслятор для обслуживания запросов к монтируемому разделу.

Так что ты можешь видеть в ps/top/htop, что творится "под капотом" ОС - работу серверов, которые по сути и превращают микроядро Mach в Hurd.

На тему данную тему есть интересный обзор GNU Hurd с оценкой производительности, который был опубликован в прошлом году на Phoronix [5].

Ссылки:

• [1] http://memory-heap.blogspot.com/2012/09/gnu-emacs-debian-gnuhurd.html
• [2] http://www.debian.org/ports/hurd/hurd-install
• [3] http://www.debianuserforums.org/viewtopic.php?f=10&t=1070
• [4] http://lists.gnu.org/archive/html/bug-hurd/2011-10/msg00087.html
• [5] http://www.phoronix.com/scan.php?page=article&item=debian_gnu_hurd&num=1

По поводу концепции микроядерной ОС

Продолжаю наблюдать за развитием GNU Hurd. Напомню, что Debian GNU/Hurd стоит на одном из моих ПК как основная система. Мне интересна концепция микроядерной ОС - разработчики микроядер обещают высокую надёжность и возможность легко расширять и изменять систему под свои нужды.

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

Эта концепция напоминает деловые связи, которые возникают в обществе людей. Вот пример: Боб выращивает помидоры в теплицах. Он получает каждую неделю удобрения для помидор от Мэлори. Так же раз в месяц к нему приходит электрик Дэйв, который обслуживает автоматическую систему полива. Если, например, Мэлори заболеет и не сможет обеспечивать какое-то время Боба удобрениями, то Боб может обратиться к Джону (другому поставщику) и тот доставит ему удобрения. То есть, бизнес Боба почти не пострадает от того, что Мэлори заболел, так как он является внешним "сервисом", который Боб использует. С другой стороны, некоторая часть работы выполняется самим Бобом - например, сбор и упаковка помидор перед продажей. Так же в небольшой фирме Боба работает его супруга, Элис - она отвечает за учёт средств и поддержку web-сайта фирмы Боба.

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

Следущим важным моментом является то, что микроядра гораздо меньше по размеру (да, приставка микро- здесь используется не просто так). Так, например, ядро MINIX3 - одной из широко известных микроядерных ОС - содержит примерно 10000 строк кода [1]. Чем меньше кода, тем проще его поддерживать и вылавливать ошибки. Меньше кода, меньше ошибок, надёжнее ОС.

В современном мире уже почти каждый холодильник и телефон работает под управлением ОС и/или может быть подключён к компьютеру. Поэтому многим подобным устройствам необходим драйвер, который обеспечивает взаимодействие с устройством, с его аппаратным обеспечением. В монолитой ОС драйверы включаются в состав ядра и (очевидно) работают в пространстве ядра. Таким образом, драйверы являются "доверенными лицами" ядра. ОС полагается на них, когда нужно взаимодействовать с вашим USB-вентилятором или записать данные на жёсткий диск. Однако, если драйвер работает неправильно, то это может привести (и вероятнее всего, приведёт) к нестабильной работе ядра и всей ОС.

Здесь стоит заметить, что ядро Linux, хотя и монолитно по своей природе, предоставляет механизм "модулей ядра", благодаря которому функциональность ядра может быть расширена "на лету" путём загрузки модулей. Вам не нужно включать в ядро драйверы для _всех_ устройств - вы можете собрать ядро с драйверами только для тех устройств, которые у вас есть. Большинство драйверов так же позволяют скомпилировать их, как модули, которые могут быть загружены в ядро при загрузке или во время работы ОС (как правило, без перезагрузки) - например, при появлении нового устройства.

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

Одним из замечательных примеров надёжности микроядерных ОС явлется так называемый сервер реинкарнации (reincarnation server), который является частью ОС MINIX3, и который автоматически перезапускает серверы, если они по каким-то причинам сбоят и аварийно завершают свою работу [2].

Тем не менее, микроядерные ОС обладают своими недостатками - например, их намного сложнее разрабатывать, и обычно они обладают более низкой производительностью (хотя, например, микроядро L4 достаточно быстро[3]).

Исследования в области микроядер ведуться десятки лет, но на данный момент можно назвать лишь несколько успешных проектов в этой области. Микроядро MINIX и микроядро Mach (третья версия которого лежит в основе GNU Hurd и Darwin) - пожалуй, самые известные.

Всё вышесказанное не претендует на полноту и безошибочность, так как мои познания в этой области являются достаточно скромными. За дополнительной информацией вы можете обратиться к соответствующим статьям в Википедии (например, [4] хорошо написана) и другим источникам.

Ссылки:

• [1] More about MINIX 3. http://www.minix3.org/other/read-more.html
• [2] Reliability in MINIX 3. http://www.minix3.org/other/reliability.html
• [3] https://en.wikipedia.org/wiki/L4_microkernel_family
• [4] https://en.wikipedia.org/wiki/Microkernel

GNU Emacs на Debian GNU/Hurd

Сегодня наконец-то запустил GNU Emacs на Debian GNU/Hurd. Emacs версии 23 при запуске у меня выдавал следующую ошибку

$ emacs -nw
emacs: Not a tty device: /dev/tty

Различные попытки запустить Emacs 23 не увенчались успехом.

В списке рассылки нашёл патч [1], который должен был устранить эту проблему. Далее мне нужен был исходный код GNU Emacs, чтобы собрать его с данным патчем.

Однако сначала я решил попробовать более простой путь. Ранее я читал, что данная ошибка была устранена версиях Emacs старше 23.4 (у меня на тот момент была установлена версия 23.2). Поэтому я решил первым делом проверить, не появилась ли более новая версия в репозитории - и обнаружил Emacs версии 24, где ошибка была устранена.

Для меня запуск Emacs на GNU/Hurd был важным рубежом - ведь если у вас есть работающий Emacs в системе, то у вас есть практически всё, что может потребоваться - даже текстовый редактор.

Источники:

1. http://lists.debian.org/debian-hurd/2011/01/msg00023.html

Закат

Сфотографировал сегодня, когда возвращался с работы.

Много работаю. Чтож, мне нравится работать.

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

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

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

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

Фотоаппарат с собой не брал, однако теперь каждый более-менее современный телефон - ещё и фотоаппарат, и видеокамера, и плеер. Так что я даже сделал пару снимков. Как вы, возможно, знаете, я люблю индустриальные пейзажи - все эти дымовые трубы, заводские здания дизайна прошлого века и т.п. И я просто не мог не остановится, чтобы сфотографировать это:

Я думаю, автосервис - вещественное доказательство тому, что на той стороне реки тоже есть жизнь (на случай, если вы вдруг сомневались.)

ClusterGen: Кластерный генератор трафика.

Доброго времени суток,

я хочу рассказать о проекте, над которым сейчас работаю в компании Мера. Проект называется ClusterGen. Репозиторий ClusterGen'а находится на SourceForge, исходный код доступен под свободной лицензией GNU GPLv3.

http://sourceforge.net/projects/clustergen/

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

Для начала - что же из себя представляет генератор трафика? Это некий узел в сети, который может генерировать пакеты (например, TCP- или UDP-пакеты) с заданной конфигурацией. Этим узлом может быть специальная (и очень дорогая) железка, или же специальное программное обеспечение, работающее на обычном компьютере. Рассмотрим преимущества и недостатки каждого из вариантов.

Первый (аппаратный) вариант генератора позволяет генерировать пакеты очень быстро (т.е. добиться высокой интенсивности трафика), благодаря реализации большей части функций "в железе". Недостатки такого способа - высокая стоимость оборудования и недостаточная гибкость (что является следствием аппаратной реализации).

Эффективность второго (программного) варианта ниже, чем аппаратной реализации, и сильно зависит от того, где находится процесс, генерирующий трафик - в пространстве пользователя или в пространстве ядра операционной системы. [Turull] Очевидно, что чем ближе к аппаратной части ПК находится генератор, тем меньше требуется накладных расходов на генерацию каждого пакета, и тем выше эффективность генератора. Поэтому генераторы, работающие в пространстве пользователя (проще говоря, как обычные пользовательские процессы) не могут генерировать пакеты с той же скоростью, что генераторы, расположенные в пространстве ядра.

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

Управление pktgen'ом осуществляется через файловую систему procfs, путём операций записи в файлы и чтения из файлов в каталоге /proc/net/pktgen. Для упрощения процесса настройки генератора и получения от него статистики, автор pktgen'а предлагает использовать bash-скрипты. [Olsson]

Таким образом, pktgen превращает обычный компьютер под управлением GNU/Linux в генератор трафика. Но чтобы использовать этот генератор как полноценный инструмент для тестирования узлов компьютерной сети, нужно немного больше, а именно: удобный интерфейс управления, способ сбора и отображения статистики. Эти задачи решает ClusterGen. Он позволяет контролировать pktgen, собирать статистику и отображать её в виде графика.

Основная идея, которая стоит за разработкой ClusterGen'а - скоординировав работу генераторов на нескольких дешёвых ПК под управлением GNU/Linux со 100-мегабитными сетевыми картами, можно добиться в сумме очень высокой интенсивности трафика, сравнимой с той, которую могут выдавать аппаратные генераторы.

Продолжение следует.

Литература

1. [Olsson] Proceedings of the Linux Symposium. Volume Two. Robert Olsson. "pktgen the linux packet generator". Canada. 2005.
2. [Turull] Daniel Turull. Open Source Traffic Analyzer. Stockholm, Sweden. 2010.