Рождение советской ПРО. БЭСМ-6. Итоги
Источник: фотоархив ОИЯИ Еще один миф Еще одним мифом является то, что уникальные разработки БЭСМ-6 были погублены переходом на бездушную ЕС. На самом деле, как мы уже выяснили, БЭСМ-6 принципиально не могла занять нишу универсального компьютера для Госплана, НИИ, заводов и т. п. Да, она задумывалась таковой и в теории могла бы ею быть, цель пути была совершенно верной, но дорожка оказалась кривой и вывела совсем не туда.
БЭСМ-6 в принципе не была конкурентом ЕС, как карьерный самосвал не конкурент универсальной грузовой платформе, тем более что и самосвал из нее вышел так себе, старшие ЕС были не сильно слабее, но куда более управляемыми. Проект БЭСМ-6 был вовсе не закрыт с переходом на ЕС, всего было выпущено 367 машин разных версий, делали их с 1968 по 1981 год, в начале 1980-х выпускалась версия БЭСМ-6 на ИС – Эльбрус-1К2, затем была следующая версия – Эльбрус-Б. БЭСМ-6 всех видов эксплуатировались до 1993–1994 гг.
Более того, в 1971 году были инициированы работы по проектированию БЭСМ-10, но они были свернуты по независящим от серии ЕС причинам (смерть Лебедева, интриги в АН СССР, общий развал, начавшийся с конца 1970-х, выбивание денег конкурирующими группами разработчиков под «Эльбрус» и т. п.). ЕС никак не мешала Юдицкому разрабатывать свои миникомпьютеры, Карцеву – строить монструозный М-13 и так далее. «Эльбрусу» она тоже не помешала.
Более того, под маркировкой ЕС тоже было разработано немалое число оригинальных машин, о них мы поговорим позднее. Кроме того, как мы уже упоминали, БЭСМ-6 не справилась с главной задачей – запуском всего софта, который был написан для машин CDC. Именно провал в этом показал, что если вы хотите использовать ворованный софт без проблем – надо полностью копировать архитектуру машин. Эмуляция неэффективна и имеет ограниченную применимость, кросс-трансляция сложна и трудоемка в отладке.
А перед ИТМиВТ и Лебедевым лично в 1959 году и была поставлена такая задача – сделать так, чтобы на советских машинах можно было запускать американский и европейский софт. В идеале вообще без проблем, в реальности – с перекомпиляцией и не слишком трудоёмкой отладкой, потому что писать всё своё было утопией, это стало ясно уже к началу 1960-х. Дело даже не в операционных системах и компиляторах – их кое-как делали свои, дело в прикладных пакетах, коих уже в 60-е годы были многие тысячи, и никакие советские НИИ были не в состоянии обеспечить софт такого качества в таком количестве.
Только копировать, только так можно было обеспечить народное хозяйство современным софтом и не отстать окончательно. Два последних мифа На закуску нам осталось разобрать два последних мифа. Первый из них в общем и целом мифом не является, скорее – это история, которая не была до настоящего времени полностью рассказана в русскоязычных источниках, и автор хочет исправить это упущение. Как известно, к огромному прискорбию всех техноархеологов, любителей и исследователей истории компьютеров, в СССР (про Россию и говорить нечего) не очень берегли старые машины.
Печальная судьба постигла практически все из отечественных ЭВМ, и сейчас мы можем прикоснуться лишь к крохам из всего технического наследия тех времен. МЭСМ была переплавлена на металлолом, от «Сетунь-70» осталась одна консоль, от «Электроника СС БИС» – части процессора, от «Стрелы» – пара запчастей, некоторые платы «Эльбрус-2» можно увидеть в Калифорнии в величайшем компьютерном музее мира Mountain View Computer History Museum. Останки единственного в СССР CDC Cyber 170 находятся в СПИИ РАН в Санкт-Петербурге, единственный же в Союзе Burroughs – сгинул без следа.
Из 300 с лишним БЭСМ-6 не уцелело почти ничего, суммарно платы каждой машины содержали более килограмма драгметаллов, так что их судьба в конце 1980-х – начале 1990-х была предрешена. В Политехническом музее в Москве находится один экземпляр, но его комплектность и работоспособность под вопросом. Тем не менее существует единственное место в мире, где сохранилась полнокомплектная БЭСМ-6 в абсолютно рабочем состоянии и находится оно в Великобритании – знаменитый The Science Museum в Лондоне. Машина была спасена из развалившегося Союза в 1992 году фанатиком старых компьютеров и исследователем Дороном Суэйдом (Doron Swade) в буйное время, когда купить и вывезти можно было даже танк, не то что древнюю ЭВМ.
Техноархеологи будущих времен будут вечно благодарны настырному куратору отдела истории информационных технологий Музея науки за этот подвиг (кстати, он же, вообще, является первооткрывателем советских ЭВМ на Западе, и он же продавил посмертное внесение советских ученых, включая Лебедева, в зал славы IEEE, представив их работы к медали Бэббиджа). В чем же здесь заключается миф? Он в том, что из всей большой статьи про путешествие Суэйда в дикую Сибирь 1990-х за легендарным компьютером, в русскоязычных источниках цитируют и приводят ровно единственное предложение: Российские суперкомпьютеры класса БЭСМ, разработанные более 40 лет назад, опровергают заявления США о технологическом превосходстве в годы холодной войны.
На самом деле эта история куда интереснее, потому мы представим читателям и прочие части из его увлекательного анабасиса «Back in the U.S.S.R. A museum curator suggests Russia's BESM supercomputer may have been superior to ours during the Cold War». 18 ноября 1992 года. Среда. Глубоко в сердце Сибири живет подмигивающий монстр. По слухам, он занимает целый этаж и оснащен тысячами мигающих консольных лампочек.
Когда-то он был частью военных, космических, инженерных, метеорологических и компьютерных программ СССР и является последней рабочей версией легендарного суперкомпьютера БЭСМ-6. Он стоит среди обломков трех своих соотечественников, которые были разбиты и переплавлены ради утилизации их драгметаллов. Я приехал в бывший Советский Союз, чтобы спасти последнюю машину от такой же жестокой судьбы.
Мы прибыли в эти снега и лютые ветра, чтобы получить рабочий суперкомпьютер БЭСМ-6 для Национального музея науки и промышленности в Лондоне. Готовясь к поездке, я прочитал все, что смог найти о российских компьютерах. Поиск литературы был одновременно и озадачивающим, и показательным. Я узнал, что российская компьютерная культура имеет свои собственные иконы: Урал, МЭСМ, Ряд, Наири, Стрела, БЭСМ, Эльбрус – акронимы с такой же богатой историей и личными ассоциациями для советского компьютерного сообщества, как наши аббревиатурные мантры для нас. Однако из-за секретности в годы холодной войны, эти машины практически неизвестны западным историкам вычислительной техники и почти не упоминаются в историческом каноне… Мне интересно увидеть легендарные машины, о которых я читал – Урал, МИР, и особенно Эльбрус, суперкомпьютер на базе Burroughs, который пришел на смену БЭСМ.
Вскоре после нашего прибытия я обращаюсь к одному из наших хозяев, Дмитрию, молодому компьютерщику из института, который будет нашим основным переводчиком, и спрашиваю об этих исторических компьютерах. На мои вопросы он отвечает пустым взглядом и вежливо уклоняется, поэтому я оставляю эту тему. Мы начинаем несколько дней напряженных переговоров о цене и порядке доставки исторического оборудования, которое мы приехали купить – БЭСМ, рабочей станции «Кронос», персонального компьютера АГАТ (русский Apple II) и других машин. Согласие по каждому пункту сопровождается обязательным глотком водки.
На третий день наш непрекращающийся график встреч неожиданно изменяется. Дмитрий ни с того ни с сего объявляет: В 15:30 вы увидите «Эльбрус». Так я постигаю главный принцип ведения бизнеса по-русски: важно не то, что ты делаешь, и не уровень твоей власти; важно то, с кем ты установил личные связи. Три дня переговоров, похоже, установили необходимое доверие. Теперь наши хозяева не могут нам отказать.
21 ноября 1992 года. Суббота. Нам нужен перерыв. Мы охрипли и окосели от многочасовых разговоров и сопутствующей выпивки. Дмитрий и трое его друзей из института берут нас с собой на огромный блошиный рынок, который круглый год работает на замерзших пустырях под Новосибирском. Рынок называется barakholka, что дословно означает «мусорное место». Нам сказали скрыть нашу вылазку от директоров института: они нервничают из-за риска для иностранцев со стороны враждебно настроенных местных жителей.
Дмитрий предупреждает, чтобы мы не имели при себе ни денег, ни фотоаппаратов и ни в коем случае не говорили по-английски. Если мы хотим что-то купить, мы должны подать сигнал и удалиться, чтобы нас не услышали. Наши спутники из института будут вести дела за нас. Температура значительно ниже нуля, идет легкий снег. Рядом со скотом, автомобильными запчастями, мехами, замороженным мясом и бытовыми товарами мы видим прилавки с интегральными схемами, электронными компонентами, периферийными устройствами, радиодеталями, частями шасси и узлами – сибирская Лайл-стрит под открытым небом.
Среди награбленного – переделанные клоны Sinclair ZX-Spectrum с русской документацией и играми, хранящимися на аудиокассетах. Клоны имеют разнообразные формы, цвета и дизайн и мало похожи на свои западные аналоги. Их материнские платы неофициально изготавливались на государственных заводах электроники рабочими, которые затем собирали компьютеры дома и продавали их по одному или по два в частном порядке или на блошиных рынках. В итоге мы покупаем два клона Sinclair; один из них поставляется с гарантией – рукописной запиской с номером телефона подростка, который собрал устройство.
Стоимость: эквивалент 19 долларов США. Мы возвращаемся в институт с нашими сокровищами. Оказавшись внутри, я поражаюсь противоречию: обилие персональных компьютеров в здании противоречит правилам, установленным CoCom в годы холодной войны – правилам, которые ограничивали страны Восточного блока в приобретении передовых технологий на Западе. Я упоминаю об этом Дмитрию.
«Желтые ПК», – смеется он, махнув рукой на цветные экраны секретарш. Он объясняет, что эти компьютеры – не брендированные машины, приобретенные в результате сделок с заводами в Восточной Азии по контракту с западными компаниями. «Значит, – говорю я, – у русских такая же страсть к персональным компьютерам, как и у нас?» В ответ Дмитрий показывает на зарешеченные окна института. «Как вы думаете, каково расстояние между прутьями?» – спрашивает он.
Я недоуменно смотрю в ответ. «Чуть меньше ширины компьютера», – отвечает Дмитрий. Он уверяет меня, что говорит серьезно, и объясняет, что решетки были установлены для того, чтобы компьютеры не воровали, спуская их из окон. Но кое-что меня все же озадачивает. Как, интересно, это сочетается с тем, что я заметил за стенами института? Рядом с кассой в большинстве магазинов и гостиниц страны стоит русский абак – schyotti. Продавцы и служащие производят расчеты на нем, а затем вводят итоговую сумму в кассу, хотя большинство кассовых аппаратов могут производить сложение автоматически.
Когда я спрашиваю Дмитрия об этой странной практике, он объясняет, что население не доверяет новым технологиям, а schyotti – символ традиционной, доверенной процедуры. Парадоксально, но сейчас schyotti угрожает безудержная инфляция: традиционные деревянные рамки и проволочные перемычки не могут вместить достаточно бусин, чтобы справиться с более мелкими купюрами все более обесценивающейся валюты. 23 ноября 1992 года. Понедельник. Пришло время завершить наши переговоры по БЭСМ, возможно, самому влиятельному компьютеру в истории советской вычислительной техники.
Эти гигантские машины – от прототипа, БЭСМ-1 (1953), до последней модели, БЭСМ-6 (1966) – были рабочими лошадками научных и военных вычислений, а система из четырех БЭСМ в институте одно время поддерживала более 300 независимых пользователей. БЭСМ-6 представляет особый интерес: по некоторым данным, это последний отечественный компьютер, который по производительности не уступал западному аналогу – суперкомпьютеру Control Data середины 1960-х годов. Было построено более 350 БЭСМ-6.
Последние из них были сняты с эксплуатации в начале 1990-х годов. Наши переговоры о покупке суперкомпьютера были мучительными, но в конечном итоге увенчались успехом. Система, которую мы доставим домой, включает в себя полный процессор БЭСМ, шкафы питания, множество периферийных устройств, кабели, документацию и запасные части. Имея более детальное представление об этом выдающемся советском суперкомпьютере, мы, возможно, сможем пересмотреть утверждения времен холодной войны о якобы имевшем место технологическом отставании России и развеять или подтвердить некоторые мифы о технологической доблести наших новых условных союзников.
Как видите – цитата Суэйда, мягко говоря, вырвана из контекста, при всей его любви к компьютерам, он нигде и никогда не утверждал, что БЭСМ-6 превосходит все, что было создано на Западе. Он всего лишь предполагал, что исследование этой машины сможет дать ответ на вопрос – врала ли Америка об оном превосходстве в годы холодной войны. К сожалению, какой ответ он получил, привезя домой драгоценную машину и исследовав ее – нам неизвестно, но, думаю, читателям статьи ответ уже и так очевиден.
Профессор Томилин в Музее науки в Лондоне рядом со спасенной из Сибири БЭСМ-6, фото из архива Томилина Самый последний миф мы оставили на закуску. Он настолько популярен, что встречается везде, даже в русскоязычной «Википедии». Вычислительный комплекс, в состав которого входили БЭСМ-6, в 1975 году в ходе космического полёта «Союз – Аполлон» обрабатывал телеметрию за 1 минуту, в то время как американская сторона на такой расчёт тратила 30 минут. Первоисточником его служит единственное интервью престарелого программиста БЭСМ-6, профессора Томилина (один из авторов той самой протооперационной системы Д-68), к прискорбию скончавшегося совсем недавно в 2021 году.
Вспоминая о своей молодости и работе в ЦУПе в интервью indicator.ru он говорил: Я находился непосредственно у терминала комплекса, где отражались результаты анализа качества измерений. Были прекраснейшие измерения! Я от этого терминала с периферийной машины комплекса АС-6 по громкой связи передавал на другой этаж на БЭСМ-6 сведения о качестве измерений. На полученные сведения о качестве измерений оттуда последовало: «Есть, берем!», и операторы комплекса баллистических программ нажимали на клавиши пультовых регистров и тем самым направляли программы баллистических расчетов по оптимальному по времени пути получения требуемых результатов (регистры опрашивались операционной системой 250 раз в секунду, и указания операторов немедленно передавались в программы расчетов).
В результате расчеты были выполнены на 20 минут быстрее, чем у американцев (результаты совпали), на что из Хьюстона последовало: «Как же так?! Что же за машины у вас такие?» Решение было получено быстрее за счет человеко-машинного взаимодействия. Вообще, по рассказу престарелого ветерана сложно понять, что там, в принципе, происходило, поэтому попробуем копнуть ситуацию с другой стороны и заглянем в ЦУП NASA, чтобы узнать, какие компьютеры управления миссией использовали они. Спасибо Советскому Союзу На самом деле, максимально забавно то, что за развитие космонавтики американцы должны сказать спасибо Советскому Союзу.
Именно запуск «Спутника-1» (чего от СССР никто не ожидал) привел к тому, что США на какое-то время впали в шок, увидев явный пробел в своих технологиях. После такого смачного пинка по самолюбию уже через три месяца было создано (в современной форме) знаменитое агентство перспективных оборонных исследований DARPA, а через полгода – летом 1958 и NASA. При этом какое-то время NASA вовсе не обладало колоссальным бюджетом и какими-то экстремальными технологиями, до 1958 года Лаборатория реактивного движения (JPL), отвечавшая за ранние эксперименты с ракетами, вообще обходилась штатом «человеческих компьютеров» – девушек-вычислителей, вооруженных комптометрами, табуляторами и позднее – стареньким IBM 1620.
Использование человеческих машиносчетных станций, в общем, было распространено в США в определенных областях не меньше, чем в СССР, и эта практика прекратилась только после вливания колоссального финансирования на волне полета «Спутника». Давайте откроем книгу Computers in Spaceflight: The NASA Experience и поглядим, с чем соревновался комплекс из нескольких БЭСМ-6: Самым впечатляющим вкладом Америки в Международный геофизический год (1957–1958 гг.) стал спутник Земли Vanguard. В июне 1957 года в рамках проекта Vanguard на Пенсильвания-авеню в Вашингтоне был создан Вычислительный центр реального времени (ВЦРВ), состоящий из компьютера IBM 7044.
Компьютерная программа на 40 000 инструкций, разработанная для Vanguard, занималась определением орбиты в реальном времени. Таким образом, IBM получила раннюю практику по основным навыкам, необходимым для управления полетами. В 1959 году, когда NASA было готово заключить контракт на создание ЦУП проекта Mercury, у IBM был опыт, на который она могла сослаться в своем предложении, а также рабочая компьютерная систем из проекта Vanguard. 30 июля 1956 года NASA заключило с компанией Western Electric контракт на разработку систем слежения и наземных систем, которые будут использоваться в Mercury, а к концу 1959 года IBM получила субподряд на поставку компьютеров и программного обеспечения.
Местом расположения компьютерной системы оставался Вашингтон. В следующем году NASA основало Центр космических полетов имени Годдарда, и поскольку он находился менее чем в получасе езды от центра Вашингтона, размещение там компьютеров давало те же преимущества инфраструктуры. Объединенные команды NASA и IBM использовали старую компьютерную систему в центре города примерно до ноября 1960 года, когда первый из новых компьютеров для Mercury – IBM 7090 был готов к использованию в Годдарде. Джеймс Стоукс (James Stokes) из NASA вспоминает, что когда он и Билл Тиндалл (Bill Tindall) впервые пришли в новый компьютерный центр, им пришлось пересечь грязную парковку, чтобы пройти к «зданию» с фанерными стенами и брезентовым верхом, которое привело в замешательство инженеров IBM, пытавшихся поддерживать работоспособность системы в полевых условиях.
Это здание стало третьим корпусом нового Центра космических полетов. Центральный компьютер IBM 7090 был сердцем сети управления Mercury. В 1959 году Министерство обороны бросило вызов компьютерной индустрии, заказав машину для обработки данных, генерируемых новой системой раннего предупреждения о баллистических ракетах (BMEWS). Ответом IBM стал компьютер 7090.
Являясь, по сути, усовершенствованием 700-й серии (использовалась для разработки Mercury), 7090 использовал новую концепцию каналов ввода/вывода, впервые примененную в 709, и был настолько велик, что ему требовалось до трех небольших компьютеров IBM 1410 только для управления вводом и выводом данных. Потребности Министерства обороны в системе BMEWS совпадали с потребностями Mercury в плане обработки и отслеживания данных.
Чтобы обеспечить надежность, необходимую для пилотируемых полетов, основная конфигурация Mercury включала два 7090, работающие параллельно, каждый из которых получал входные данные, но только один мог передавать выходные. Названные оперативным компьютером миссии (Mission Operational Computer) и динамическим резервным компьютером (Dynamic Standby Computer) они перекочевали в программу Apollo и стали первой резервируемой компьютерной системой NASA. Переключение с основного компьютера на резервный осуществлялось вручную, так что решение принимал человек.
Во время орбитального полета Джона Гленна главный компьютер вышел из строя на 3 минуты, доказав необходимость активного резерва. Позднее сеть Mercury дополнили еще три компьютера. Один из них был 709, предназначенный для непрерывного прогнозирования точек падения ракет, запускаемых с мыса Канаверал. Он предоставлял данные, необходимые офицеру по безопасности на полигоне для принятия решения о прерывании миссии.
Еще один 709-й находился на станции слежения на Бермудах с теми же обязанностями, что и пара машин в Годдарде. В случае отказа связи или двойного отказа центрального компьютера он становился основным компьютером миссии. Наконец, компьютер наведения Burroughs-GE осуществлял радиоуправление ракетой Atlas во время подъема на орбиту. Размещение компьютеров под Вашингтоном и размещение персонала управления полетом на мысе Канаверал привело к возникновению проблемы связи, которая нашла уникальное решение.
В ранних цифровых компьютерах все входные данные поступали в память через центральный процессор. Большие объемы данных, которые необходимо было принять за короткое время, часто накапливались, ожидая, пока процессор справится с потоком. Решением проблемы является прямой доступ к памяти через каналы данных, впервые использованные компанией IBM в модели 709, а затем в модели 7090. Благодаря использованию каналов обработка данных могла продолжаться во время ввода-вывода, что увеличивало общую пропускную способность системы.
Системы Mercury 7090 были четырехканальными. Обычно периферийные устройства, осуществляющие ввод и вывод, подключаются к каналам, расположенным физически близко к машине, но периферийные устройства (плоттеры и принтеры), управляемые компьютерами Mercury, находились на расстоянии около 1 000 миль во Флориде. Решением было заменить канал F компьютера 7090 на специальный канальный сопроцессор IBM 7281.
Четыре подканала разделяли данные, обрабатываемые устройством 7281. Один был входом от Burroughs-GE для данных, используемых при расчете траектории во время полета с двигателем. Второй вводил данные радара для определения траектории и орбиты. Два выходных подканала управляли дисплеями в Центре управления Mercury на мысе Канаверал и локально в Годдарде. Эти пункты соединяла наземная линия связи, позволявшая передавать данные со скоростью 1 кб/с, для своего времени это была феноменальная скорость.
Расстояние и новизна оборудования иногда вызывали проблемы. Время от времени во время обратного отсчета такие данные, как индикатор взлета, состоящий из одного бита, искажались и давали ошибочные сигналы. В большинстве случаев такие сигналы можно было проверить по другим источникам информации, например, по данным радара, противоречащим сообщению о взлете. Также обычным явлением была задержка до 2 секунд на дисплеях в центре управления.
Во время полета с двигателем такие задержки могли быть значительными; таким образом, возникла необходимость в отдельном компьютере прогнозирования и еще одной машине на Бермудах. Кроме оборудования для контроля полетов IBM, значительно продвинула теорию создания операционных систем реального времени, разработав комплекс управляющих программ с названием IBM Mercury Monitor. Для разработки пакета управляющих программ инженерам IBM пришлось работать в тесном сотрудничестве со специалистами NASA, знавшими тонкие детали математического определения орбит, также они привлекли профессора Пола Хергета (Paul Herget), директора обсерватории в Цинциннати.
Когда в 1962 году программа Mercury была завершена, и NASA начало ускоренную подготовку к полетам Gemini и Apollo, агентство решило разместить компьютеры в объединенном центре в Хьюстоне. Для IBM и NASA разработка центра управления Mercury была очень выгодной, IBM Mercury Monitor и Data Communications Channel были первыми в своем роде и заложили основы многих компьютерных технологий. Будущие многозадачные операционные системы и управляющие программы с приоритетным прерыванием обязаны своим появлением Mercury Monitor, мейнфреймы с терминальным доступом, такие как системы бронирования авиабилетов, имеют в своей основе дальнюю связь между Вашингтоном и космодромом во Флориде.
Для обеих организаций опыт, полученный штатными инженерами и менеджерами, напрямую способствовал успеху Gemini и Apollo. Еще до начала первого орбитального полета Mercury инженеры NASA, работавшие над управлением полетами, пытались повлиять на дизайн нового центра в Хьюстоне. Билл Тиндалл, который с самого начала работал в NASA над наземным управлением, понял, что размещение руководства космической оперативной группы в Исследовательском центре Лэнгли, компьютеров и программистов – в Годдарде, а диспетчеров полета – на мысе Канаверал создает серьезные проблемы с коммуникацией и эффективностью. В январе 1962 года он начал информационную кампанию по объединению всех компонентов в одном месте, в новом Центре пилотируемых космических аппаратов.
В апреле Western Development Laboratories компании Philco Corporation начала исследование требований к новому ЦУП, одним из запросов было облегчить работу диспетчеров, установив оборудование для отображения графической информации о траекториях. В итоге Philco разработала новую концепцию управления полетами, описывающую буквально все – от физических компьютеров до информационных потоков, дисплеев, исследования надежности и даже стандартов разработки ПО, указав, что модульность программ является важнейшим условием. Финальная спецификация требовала безотказной поддержки 336 часовой миссии с вероятностью 99,95 %.
Для достижения указанной надежности Philco изучила существующие компьютерные системы от IBM, UNIVAC и Control Data Corporation, а также свои собственные компьютеры Philco 211 и 212, чтобы определить, какой тип машин нужен и сколько их потребуется. В результате расчетов были получены три возможные конфигурации: пять IBM 7094 (непосредственный преемник 7090 с лучшей операционной системой IBSYS); девять UNIVAC 1107, IBM 7090 или Philco 211; четыре Philco 212; четыре CDC 3600. Независимо от того, какое решение будет выбрано, было очевидно, что сложность центра Gemini-Apollo будет намного выше, чем у его предшественника с двумя компьютерами.
Чтобы сделать систему как можно более недорогой и простой, NASA указало потенциальным участникам тендера на необходимость использования готового оборудования. IBM быстро откликнулась на предложение NASA и в сентябре представила папку толщиной 2 дюйма с предложениями по аппаратному и программному обеспечению, включая подробный список сотрудников, которых они собирались привлечь к проекту. Хотя компания знала, что является ведущим кандидатом (одобрение Тиндалла вряд ли могло остаться незамеченным), она тщательно согласовывала спецификации, например, четко заявила, что модульное тестирование будет нормой при разработке программного обеспечения.
Впрочем, была одна область, в которой их документ отличался от расчетов Philco – количество необходимых машин. Возможно, чтобы снизить общую цену, IBM предложила группу из трех компьютеров 7094. Они предположили, что если одна машина будет выполнять программу расчета орбиты, вторая – станет управляющей, а третья – резервной, то они обеспечат надежность 97,12 %, а на критичных участках до искомых 99,95 %. Восемнадцать компаний приняли участие в тендере на RTCC, включая таких мощных конкурентов, как RCA, Lockheed, North American Aviation, Computer Sciences Corporation, Hughes, TRW и ITT.
В итоге NASA склонилось, как несложно догадаться, к предложению IBM, они подписали контракт до 1966 года на 46 миллионов долларов (около полумиллиарда в современных ценах). Требования NASA к программному обеспечению для управления полетом Gemini привели к созданию одной из самых больших и сложных компьютерных программ в истории. В дополнение ко всем потребностям Mercury, предлагаемые Gemini операции рандеву и изменения орбиты вызвали почти экспоненциальное увеличение сложности программного обеспечения для определения орбит.
Размещение компьютера на борту космического корабля привело к необходимости параллельного использования его вычислений в качестве резервного, а также к необходимости разработать способ использования наземной компьютерной системы для обновления данных Gemini. IBM отреагировала на возросшую сложность несколькими способами. Помимо увеличения численности персонала, компания ввела строгие стандарты разработки программного обеспечения.
Эти стандарты оказались настолько успешными, что IBM приняла их в масштабах всей компании в то время, когда велась разработка ключевых коммерческих программных систем мейнфреймов 1970-х. В более сложных областях IBM обращалась к услугам специалистов-консультантов и спонсировала группу из 10 ученых, искавших решения проблем орбитальной механики. Даже с лучшими инструментами и более мощным компьютером потребности вычислительной мощности быстро превысили возможности 7094.
IBM признала, что обычной 32-килобайтной ОЗУ машины будет недостаточно, поэтому она предложила использовать буферизацию с опережением. Коммерческая практика использования лент для ожидающих программ стала невозможной из-за требований к размеру и скорости ПО Gemini, поэтому IBM проапгрейдила 7094 до модели 7094-IIs с 65 Кб основной памяти и еще 524 Кб дополнительной ферритовой ОЗУ, названной Large core storage (LCS). Кроме этого, расчеты Philco оказались пророческими – даже так вычислительной мощности катастрофически не хватало, и IBM увеличила чисто итоговых машин до 5, как и было изначально предсказано в спецификациях Philco.
В итоге программы с лент подкачивались в LCS, а оттуда в ОЗУ, работы по их стыковке заложили основы технологии виртуальной памяти – главного программного достижения четвертого поколения машин серии S/370 начала 1970-х годов. По мере продолжения программы Gemini NASA все больше беспокоилось о способности компьютеров 7094 адекватно поддерживать программу Apollo, учитывая ожидаемую большую сложность навигационных проблем. ОС реального времени явно нуждалась в существенных улучшениях.
Позором обернулась демонстрация проекта президенту Линдону Джонсону, он прибыл в ЦУП, и сотрудники NASA предложили ему запустить одну из полетных программ. Волею случая Джонсон ткнул в программу, которая была уже вытеснена из ОЗУ на ленту, в итоге, как описывали присутствующие, минуты казались им часами, пока президент терпеливо ждал загрузку. NASA решила плюнуть на IBM и купить у Крэя великий CDC 6600, чья чудовищная вычислительная мощность десятикратно перекрывала все, что было уже установлено в ЦУП.
Контракт IBM повис на волоске, и, как обычно, они сделали хитрый маркетинговый ход, пообещав заменить все 7094 на куда более мощные новейшие мейнфреймы S/360. Пикантность ситуации заключалась в том, что до поставок S/360 осталось еще полгода, машина не была готова, но в пресс-релизе об этом не было ни слова. NASA вздохнуло и отозвало заказ на CDC 6600.
Крэй подал в суд на IBM, утверждая, что они смошенничали, заявивив о недоступной на тот момент машине, как о готовой, с целью вытеснить CDC с рынка. Крыть было нечем, и IBM влепили штраф в 100 миллионов долларов за нечестную конкуренцию. В итоге к беспилотным полетам Apollo IBM успела заменить только одну машину, 4 оставшихся 7094 по-прежнему продолжали управление миссией. Только к 1966 году IBM закончила разработку новой ОС реального времени для S/360 – RTOS/360.
В итоге пилотируемый полет Apollo поддерживали две машины S/360, одна – рабочая и одна – резервная. Эта схема продержалась до 1974 года, когда настырная IBM снова выиграла тендер на поставку оборудования для NASA у Computer Sciences Corporation. С 1984 по середину 1980-х управление полетами в т. ч. программой Space Shuttle осуществлялось пятью мейнфреймами System 370/168.
В конце 1980-х они были заменены на мэенфреймы IBM 3083, ставшие четвертым поколением машин Mission Control. В это время важность наземных машин значительно упала, так как компьютеры космических кораблей стали достаточно быстрыми и продвинутыми для осуществления большей части расчетов траектории прямо на борту по ходу полета. Все эти компьютеры также были созданы IBM: ASC-15 для Saturn 1, ASC-15B для Titan Family, GDC для Gemini, LVDC для Saturn 1B/5, System/4 Pi-EP для MOL и System/4 Pi-TC 1 для Apollo Telescope Mount и Skylab.
Битва мейнфреймов Итак, в 1975 году в битве сошлись 2 мейнфрейма IBM System/360 model 95 (спецзаказ NASA, создано всего две машины, модернизированная версия model 91 с ОЗУ на тонких магнитных пленках, более продвинутый и быстрый вариант обычной ферритовой памяти, разработанный Sperry для UNIVAC 1107 в 1962 году) со стороны NASA и АС-6 в советском ЦУПе. IBM System/360 model 95 во всей своей славе в NASA.
Фото https://ru.wikipedia.org Следует отметить, что за телеметрию отвечала только одна машина IBM, и на самом деле model 95 была настоящим шедевром. Она был заявлена как прямой конкурент CDC 6600, первая суперскалярная машина IBM с полноценной поддержкой спекулятивного выполнения, продвинутым кэшем, современной виртуальной памятью, одна из первых машин с многоканальной ОЗУ, центральный процессор состоял из пяти автономных блоков: блока команд, блока вещественной арифметики, блока целочисленной арифметики и двух канальных сопроцессоров: один – для ОЗУ (фактически современная технология DMA), и второй – для I/O каналов. Продвинутый конвейер использовал ноу-хау IBM – алгоритм Томасуло динамического планирования инструкций, разработанный компьютерным ученым Робертом Томасуло (Robert Marco Tomasulo) специально для S/360.
Алгоритм может работать с любой архитектурой конвейера, поэтому программное обеспечение требует небольшого количества модификаций, специфичных для конкретной машины. Все современные процессоры, включая линейку Intel Core, используют те или иные модификации этого метода. Теоретически model 95 разгонялась до 16,6 MIPS (правда на простых инструкциях), но это уже было сногсшибательным достижением по меркам 1968 года и оставалось таким для компьютеров общего назначения много лет. Сравнимую производительность на микропроцессорах можно было выжать только из Intel 80486SX-20 МГц или AMD 80386DX-40 МГц конца1980-х.
Честно говоря, в этой битве несчастную БЭСМ-6 можно только пожалеть, но не все так плохо! Как мы уже говорили, при общей убогости элементной базы и довольно странных с т. з. магистрального развития ЭВМ технических решениях, БЭСМ-6 обладала вполне удачной системной архитектурой, позволяющей в широких пределах комбинировать ее вычислительные элементы, для этого и была разработана аппаратура сопряжения – АС-6. АС-6 был устроен очень хитрым способом.
Для его функционирования имеющиеся в наличии БЭСМ-6 нужно было фактически разобрать на модули, а потом собрать снова уже как часть комплекса через специальные коммутаторы. На первом уровне коммутации соединялись процессоры от БЭСМ-6 и их ОЗУ с помощью специализированного коммутационного процессора АС-6, получая то, что сейчас можно назвать симметричной многопроцессорной архитектурой – до 16 ЦП от БЭСМ-6 с разделяемой ОЗУ. Одновременно в процессе сборки процессорные шкафы передвигались и перекоммутировались для достижения минимальных задержек сигнала.
Собственно АС-6 как она есть, фото www.besm-6.su Второй уровень коммутации включал так недостающие оригинальной БЭСМ-6 канальные сопроцессоры ПМ-6, объединенные в сеть, через которые подключалась разнообразная периферия. Наконец, третий уровень состоял из устройств сопряжения с внешними источниками данных.
Все это собиралось на основе каналов от мейнфрейма ЕС (даже ненавистники Единой Системы не могут не признать, что тут он здорово помог старушке БЭСМ-6). Все дополнительные сопроцессоры АС-6 были собраны на той же DTL, что и БЭСМ-6. Программное обеспечение имело чрезвычайно экзотическую архитектуру – за управление ЦП отвечала своя операционная система (одноименная ОС АС-6), за периферийные процессоры отвечала своя (!) отдельная операционная система (ОС ПМ-6). Если кому-то показалось, что в схеме не хватает безумия, спешим вас утешить – отдельные БЭСМ-6 в составе комплекса работали под управлением своих родных ОС на выбор (ДИСПАК и т.п.).
Оригинальным был сам управляющий процессор АС-6, представляющий собой глубоко модернизированную БЭСМ-6 (да-да, БЭСМ-6, рулившая другими БЭСМ-6). Он был более мощный, чем оригинал, производительностью до 1,5 MIPS с ОЗУ в 256 килослов и, естественно, мог использовать, как свою собственную, ОЗУ всех прочих БЭСМ комплекса через канал из 86 шин с суммарной скоростью передачи в 8 Кб/сек. Естественно, все это канальное хозяйство имело собственное питание – т.
н. блок УКУП (устройство контроля и управления системой электропитания). Периферия была тоже взята от ЕС (откуда еще бы ее брать). В итоге ЦУПовский АС-6 в определенном смысле слова эмулировал архитектуру System/360 model 95, только собранную из отдельных блоков, и с процессорами сильно отличающейся архитектуры. Возможности этого монстра упирались чисто в физические ограничения – на практике АС-6 никогда не использовался с числом управляемых БЭСМ-6 более двух сразу по элементарной причине.
Даже такая конфигурация требовала предельно огромного машзала в 200 квадратных метров (не считая вынесенной отдельно периферии) и питания не менее чем в 150 киловатт. Итоговую скорость этого комплекса оценить не просто сложно, а вообще невозможно, так как прямых тестов производительности на АС-6 в полной сборке, насколько известно автору, никто никогда не запускал. Реальная производительность каждой из БЭСМ-6 в его составе составляла порядка 0,8 MIPS, сам процессор АС-6 добавлял еще 1,5, сравнить это с S/360 было нереально, так как архитектурно маш?
(Всего одно письмо в неделю, чтобы ничего не пропустить)
