PDP-11 и всё всё всё :)

Почему многопроцессорные PDP-11 не были выпущены в продажу?

Об этом ходят слухи, и все они исходят от источников, не имеющих отношения к DEC и не имеющих непосредственного опыта работы с многопроцессорными системами. Самый распространённый слух связан с появлением VAX 11/780 примерно в то же время. Согласно ему, 11/74 превзошёл бы VAX в (2, 4, 8, 16 — выберите любое случайное число) раз, поэтому DEC сняла с производства PDP-11/74, чтобы начать продавать VAX.

Эмоционально заманчиво, но неверно. 780-я была быстрее 11/70, а 16-битный многопроцессорный компьютер нелогично сравнивать с 32-битным однопроцессорным. Кроме того, это неправдоподобно, учитывая известную любовь Кена Олсена к серии PDP.

Также высказывалось мнение, что плата KB11-CM была слишком дорогой в производстве и продаже с целью получения прибыли. Однако разница между платами KB11-C и KB11-CM была незначительной, и в любом случае платы DEC с накруткой производились на автоматизированных станках Gardner-Denver. Сложность изготовления этой конкретной детали не была проблемой.

Правда о том, что выпуск 11/74 не состоялся, заключается в том, что это было разочаровывающе простое бизнес-решение.

«Технически продукт был весьма успешным. Финансово он, вероятно, был бы успешным. Но в то время создание и настройка 11/74 требовали огромных ресурсов. Существовал комитет по конфигурации 11/74, который должен был рассматривать каждый заказ PDP-11/74, утверждать список устройств, которые в него входили, и так далее. Это было диаметрально противоположно философии линейки PDP-11 и скорее напоминало подход DECsystem-10 и DECsystem-20 к системам — индивидуальные системы, уникальные для каждого заказчика, требующие значительной поддержки DEC.

«Было ясно, что поставка систем потребует больших усилий. Было неясно, заработает ли DEC больше, поставляя 11/74 и используя имеющиеся ресурсы, чем, скажем, продавая 11/44, которые было легко настраивать.

Были также проблемы с выездным обслуживанием. Выездное обслуживание работает по принципу «предоставьте нам всю систему, мы проведем диагностику и исправим её». Это диаметрально противоположно философии многопроцессорной системы.

«Сложность 11/74 была высокой. Сотрудники RSX работали над оборудованием, потому что не доверяли никому, кто прикасался бы к их оборудованию. В системе было около 500 кабелей BC06R разной длины, которые время от времени выходили из строя, и их было трудно найти. Были проблемы с проходными разъёмами, выходящими из строя в местах, где BC06R проходили через переборку, и найти их было просто кошмаром.

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

Источник: Брайан С. Маккарти, группа DEC RSX

- - - Добавлено - - -

Была ли когда-либо построена версия с Qbus?

Да. Люди сообщают, что видели её во время экскурсий по Спит-Брук.

Официально DEC никогда ничем не занималась. Однако они...

"... изучали возможность создания мультипроцессора с Qbus на основе модифицированных процессоров KDJ11-B.

"Конечно, мы бы не стали комментировать, если бы построили прототип. Если бы мы собирались это сделать, то, вероятно, потребовалось бы модифицировать плату процессора и добавить внешнюю плату арбитра, которая заменит встроенный арбитр в KDJ11-B."

- - - Добавлено - - -

«Система на 83MP была завершена и действительно загрузила M+. Двухпроцессорная система была ненамного быстрее однопроцессорной из-за конкуренции за шину Qbus, поэтому мы так и не продвинулись дальше.

«Что касается местонахождения оборудования, нам понадобится Леонард Нимой или Джеральдо Ривера, чтобы разгадать эту загадку. Полагаю, модифицированные процессоры были разыграны в качестве одного из призов на викторине PDP-11, возможно, в Цинциннати?»

- - - Добавлено - - -

Какова была производительность многопроцессорной системы?

Для PDP-11/74, сконфигурированной с четырьмя процессорами, все из которых работали, производительность была примерно в три раза выше, чем у 11/70. (На самом деле, у 11/780 не было серьёзных конкурентов.) Какой показатель использовался, неизвестно.

Источник: The Big Book of RSX Applications, Том II, Приложение B

- - - Добавлено - - -

Как многопроцессорная система справлялась со сбоями ЦП?

Как ни странно, очень плохо. Когда один ЦП падал, все ЦП падали.

«Философия 11/74 заключалась в высокой доступности, а не в высокой надежности. Поэтому, с философской точки зрения, нам нужны были аварийные дампы всех ЦП для выявления проблем с программным обеспечением.

«С прагматической точки зрения, продолжать работу было бы сложно. Вызывающий сбой ЦП находится в ядре и, по всей вероятности, владеет как минимум $EXECL, а также, возможно, некоторыми другими спин-блокировками. Конечно, любая блокировка, которой он владел, была установлена для защиты атомарной транзакции, и падение приводило к проблеме».

«Список Fork может быть поврежден, пул может быть поврежден, состояния устройств могут быть несогласованными, контекст выполняемой задачи на вызвавшем сбой ЦП (это может быть MCR или F11ACP) теряется в том, что могло быть атомарной транзакцией внутри компонента (помните $LOCKL?), и может существовать множество других проблем. [Они] навалятся друг на друга и ... крах».

Источник: Брайан С. Маккарти, группа DEC RSX (июль 2005 г.)

- - - Добавлено - - -

Сколько многопроцессорных систем было построено?

Всего шесть. Далеко не так много, как предполагали люди за пределами Digital.

Разработчики RSX в Спит-Брук (ZKO) в Нашуа, штат Нью-Гэмпшир, имели четырёхпроцессорную систему 11/74 с названиями DECnet CASTOR и POLLUX, в зависимости от конфигурации: один четырёхпроцессорный или два двухпроцессорных.

«Другие системы, о которых я знаю, которые когда-либо существовали, это:

1. Прототип четырёхпроцессорной системы в Тьюксбери. На передней панели было написано 11/70mp, а не 11/74. Прототип был хорош тем, что на задней панели имелась панель ввода ошибок с примерно 20 тумблерами. С их помощью можно было: отключить одну линию на тракте данных MASSBUS; отключить IIST и, мой любимый, самый коварный, вносимый сбой — выключить обход кэша на одном из процессоров. Позже он был заменён четырёхпроцессорной системой в Спит-Брук.

2. У группы аппаратного обеспечения был двухпроцессорный комплекс.

3. У группы DecNet, по-моему, был двухпроцессорный, но, возможно, четырёхпроцессорный комплекс.

4. В лаборатории производительности в Мерримаке был четырёхпроцессорный комплекс.

5. Система, предназначенная для первой поставки клиентам, произведенная для GTE в Лайле, штат Огайо. Насколько я помню, она была двухпроцессорной.

Были и другие системы, но, по-моему, только эти шесть систем хоть когда либо загружались.

Источник: Брайан С. Маккарти, группа DEC RSX (июль 2011 г.)

- - - Добавлено - - -

Я не верю, что такое когда-либо существовало.

Фотографии этих систем существуют, их демонстрировали на симпозиумах DECUS в США, и многие видели систему CASTOR группы разработчиков RSX «вживую» в Спит-Брук (ЗКО).

Брюс Митчелл (почётный редактор журнала Multi-Tasker, группа специалистов по RSX DECUS в США) получил специальное разрешение сфотографировать 11/74 во время встречи SIG в «Вудсе», и ему в качестве сувенира подарили лицевую панель PDP-11/74 и различные другие атрибуты 11/74.

Ещё в 1986 году существовало электронное письмо, свидетельствующее о том, что группа поддержки DECnet в Колорадо-Спрингс проводила общекорпоративный поиск процессоров 11/74 для создания собственной многопроцессорной системы.

Если это был заговор DEC, призванный запутать сообщество пользователей, то он оказался невероятно успешным. Многие видели в галлюцинациях 10-тонный четырёхпроцессорный 11/70 размером 12 на 18 футов в небесно-голубом «корпоративном шкафу» PDP-11 с панелями управления общей памятью MKA11, а рядом с ним — Брайана Маккарти. Теперь и вам это мерещится.

- - - Добавлено - - -

Что случилось с системой группы внедрения RSX?

Компьютер PDP-11/74 группы внедрения RSX находился в ZKO, центре разработки программного обеспечения DEC, расположенном в лесах Спит-Брук в Нашуа, штат Нью-Гэмпшир. В сети DECnet он имел название CASTOR.

После вывода из эксплуатации в ZKO он перешёл в CXO (Колорадо-Спрингс). Группа DECnet вновь ввела его в эксплуатацию под названием PHEANX, что стало единственным неиспользуемым вариантом написания слова «phoenix» в корпоративной сети DECnet.

«CASTOR, после того как мы вывели его из эксплуатации в ZKO, перешёл в CXO к Дэйву Кэрроллу. [...] Я понятия не имею, где сейчас находится ни он, ни Дэйв».

И никто другой тоже не знает. Ни CASTOR, ни другие процессоры 11/70mP, которые были произведены и в конечном итоге возвращены компании в качестве однопроцессорных 11/70.

Источник: Брайан С. Маккарти, группа DEC RSX [март 2002 г.]

- - - Добавлено - - -

Что представлял собой 11/68?

По слухам, ещё менее весомым чем слухи о 11/74, 11/68 проектом многопроцессорной системы, основанной, как сообщается, на архитектуре PDP-11/60. Это был бы не просто 11/60 с другим микрокодом. О нём мало что известно, за исключением тех немногих сотрудников DEC, которые участвовали в проекте или имели с ним контакт.

Если помните, 11/74 — это новый контроллер кэша и изменение инструкций ASRB по сравнению с 11/70. 11/68 (который назывался то ли Bluefish, то ли Dolphin, не помню точно) был процессором, разработанным для MP. Наиболее важной его особенностью была когерентность кэша между процессорами, что исключало необходимость очистки кэша и обхода его в ядре. Он также обладал микрокодом, доступным для записи пользователем, а-ля 11/60 (отсюда и название), но с тем улучшением, что к процессору с плавающей запятой можно было легко обращаться из микрокода.

«Не знаю, существовал ли когда-либо работающий 11/68. Это было бы потрясающе».

Источник: Брайан С. Маккарти, группа DEC RSX (июль 2011 г.)

- - - Добавлено - - -

Как XXDP работал на одном процессоре, не работая на всех процессорах?

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

«Контроллер памяти MKA-11 позволял каждому процессору видеть или не видеть каждый из блоков памяти по заданному адресу.

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

«Также можно было настроить блок памяти в верхней части памяти (в конфигурации mP) как блок 0 для автономного процессора. Это позволяло загрузить XXDP в блок памяти. Затем её можно было запустить с передней панели автономного процессора».

Источник: Брайан С. Маккарти, группа DEC RSX (май 2015 г.)

- - - Добавлено - - -

Как XXDP работал на одном процессоре, не работая на всех процессорах?

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

«Контроллер памяти MKA-11 позволял каждому процессору видеть или не видеть каждый из блоков памяти по заданному адресу.

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

«Также можно было настроить блок памяти в верхней части памяти (в конфигурации mP) как блок 0 для автономного процессора. Это позволяло загрузить XXDP в блок памяти. Затем её можно было запустить с передней панели автономного процессора».

Источник: Брайан С. Маккарти, группа DEC RSX (май 2015 г.)