Multics Site History: RADC

Location

US Air Force Rome Air Development Center, Griffiss Air Force Base, Rome, NY, USA.

First Installed

08/68 (645) (Multics not installed until 08/70)
1975 (6180)

Configuration:

(Need 645 and 6180 configs)

[Richard Shetron] The dual CPU 6180 system at RADC used the 4 4MB 500ns core boxes that came with the original 635/645 system.

STARAN.

Honeywell Marketing

...

Field Engineering

Don Smith, lead hardware engineer, May 69 - 1974
Terry Pitcher
Wayne Peck
Dave Kurth
David Sharp
Richard Dumar
Graham Bowers, field service mgr
Russ Watson
Peter Bertonis

System Administrators

Don Elefante
Rich Jackson

Operators

Al Burton
Nick Montalbano
Bob Hanouer

Site Managers

Bob Doane
Dennis Maynard

Users

Victor Frost, Rocco Iuorno, Mitzi Kobos, Frank LaMonica, P. Leong, Robert McCauley, M. Mortara, Frederick A. Normand, Bill Rzepka, W. Fred Seigneur, W. Wade, Bob Walker, Douglas White, Paul Karger, Roger Schell, Bill Jones, John Kalyncz.

Application areas

Research done at this site.

[Don Smith] BTW.. I had coined MULTICS (Man's Ultimate Link To Information Computing Service) guess that was proven wrong.

[Don Smith]The original GE-645 mainframe was comprised of 635 modified CPU with the Multics Associative Memory, GIOC (Generalized Input Output Controller), (1) UNIVAC drum, (2) printers, 16 GE mag tapes (designed without the long vacuum columns that even todays technology requires)--oh GE 'the engineering Company' had a better mousetrap, they used a packed tape bin 12" x 12" and measured the light passing thru to determine the syncro motor speeds.. and they failed in spectacular ways; good thing they had GE plastic widows or were they scatter shields... (2) Data Products disc units . These disks were 32 platters , expanded models of the commercial 16 platter units used on the GE-605/625/635 mainframes. What a monster unit; approx 7 feet high with the absolute micron filter top hat, 6 feet long and 40 inches wide. Disk crashes were common until I arrived in May 1989 and installed the filters.

[Don Smith] There wasn't any formal GE 645 training course. The engineers on site when I arrived; Terry Pitcher, Dave Kurth, & Wayne Peck had been supporting the beast for less than one year with only the 635 training and were flying by the seat of their pants. As the new site engineering leader, I came from The GE Corporate Data center in Schenectady (TIPO), the first priority was to get the machine (mean time between failure and mean time to repair)MTBF & MTTR number fixed. The RADC customer was livid since they only had this one machine (a 635 was replaced with the 645) and they had real work to get done. Major Abby, Data center manager had put the GE leaders on notice to get it fixed or get it out. This machine ran three OS's Multics, TSS-605; authored at GE CR&D (that's another story) and GCOS, runtimes split between days and hours of the day. (lots of loss time just rebooting) During May and June I had arranged for the 645 design engineers from Phoenix GE to spend weeks in Rome teaching us. Scheduled downtime Midnight to 6AM, for over a month we had John Ammons (CPU) later shot himself in the Arizona Desert, John (can't recall) (GIOC and device channels) another guy on disc and drum . One year later RADC leaders awarded the GE team the 'excellence in vendor service' citation.

[David Sharp] I was a Field Engineer at RADC from 1970-1979. Richard Dumar was also there during this period. I remember one rain storm we had while the equipment was locate in building 240. There was a brown out and equipment was popping left and right. Rain was leaking down the modem racks and the compressors in the basement for the DS10s were smoking and sparking like crazy. It took some time to recover from that mess. I'm not sure when bldg 3 was built and the equipment moved.

[Paul Karger] The 645 had only 128K words of memory, and that made it rather slow. That memory size also affected the password breaking algorithm mentioned below.

[Paul Karger] Add Roger Schell and me to the list of users, although we only used it by dial-up (and later by ARPAnet) from Hanscom. I later used it by ARPAnet from the Air Force Academy. I think the dial-up use was over the DoD's Autovon network, but I'm not certain. It could also have been using WATS lines.

[Richard Shetron] I started in 7th grade in HS around 1967 and had access to the RADC GE-645 in 1969(?) via President Johnson's (?) edict to allow educational institutes access to some of the surplus non-secret systems. At that point, the 645 was pretty new and ran TSS-645 while waiting for Multics to be delivered. The language choices were BASIC and FORTRAN IV. I think the BASIC may have ben based on Dartmouth, but I'm not sure. Later academic accounts were moved to GECOS-TSS on a GE-635 when Multics was delivered.

[Richard Shetron] I remember one very cold day in winter when the system was available for 15 to 20 minutes at a time and the A/C chillers had frozen so they could only run that long before overheating and having to shutdown until the room cooled. My High school was about an hour's drive away and had a dedicated phone line for the 110 baud modem and teletype.

[Ed Ranzenbach] RADC, I started out in system administration in October 1977 while still in the USAF. I worked with Don Elefante and a gentleman by the name of Bill Jones, who died of MS about a year after I came on board. These two guys taught me a lot. I then left the USAF on a Friday in March of 1979 and reported to work as a Multics Site SA for Honeywell on the following Monday.

[Ed Ranzenbach] I remember the trouble with the chillers documented by Rich Shetron. Considering the time it took to boot and shutdown, we could only bring the system on-line for twenty minutes at a time.

[Ed Ranzenbach] We were using core memory. It took up so much room that it was housed in several "large" boxes. We had several rows of these and I remember calling them "memory lane". We had the starting and ending addresses of the memory controlled by each box listed on sign posts at the intersections so you could open the right box depending on the crash address. At that time we crashed a couple of times a day for core errors.

[Ed Ranzenbach] While most of our terminals were Terminet 300's running at 300 baud (using qedx and ted as the editors), there were two RADC engineers in the building that were using glass TTYs at 1200 baud and we were all jealous. I remember that the comm processor had to be specially configured for the 1200 baud lines and we could only support two of them.

[Ed Ranzenbach] We had a line printer that used "piano string" style wires that controlled timing to the printing drum. The humidity and temperature variances in the room caused the site engineers to have to "tune" the printer regularly by shortening or lengthening the each wire for all 136 columns. I remember that a brass flywheel came flying off the printer once, just missing us. I still use this brass flywheel as a paper weight on my desk at home.

[Ed Ranzenbach] I remember a hardware engineer calling me into his office one day to see this new contraption he was developing to mover a cursor around the screen. It had a couple of wheels rather large (by today's standards) circuit board and a serial cable. He called it a "mouse".

[Ed Ranzenbach] Much of the early communications work on TCP/IP was done at RADC. I remember John Ata being at the center of this. He was also developing something he called "ftp". Much of this work of course became the ARPANET, and later the internet. It is interesting tough, I don't remember anyone by the name of Gore involved in the project.

OLPARS

RADC did lots of research on pattern recognition with a company called Pattern Analysis and Recognition Corp of Rome NY. They built a system called OLPARS. A version of OLPARS was implemented as a Multics application system called MOOS, using Tektronix storage tube graphics.
See MULTICS OLPARS Operating System. Volume I, Pattern Analysis and Recognition Corp Rome N Y, 219 pages, PAR-74-25-A, F30602-75-C-0226, F30602-73-C-0352, RADC TR-76-271-Vol-1, NTIS ADA034393
and MULTICS OLPARS Operating System. Volume II, Pattern Analysis and Recognition Corp Rome N Y, 667 pages, RADC TR-76-271-Vol-1, NTIS ADA033437,
and Programs for On-Line Pattern Analysis and Recognition System (OLPARS), Pattern Analysis and Recognition Corp Rome N Y, 193 pages, NTIS AD0742280.

Several other papers were written on this system. OLPARS ws used for many pattern recognition tasks such as seismic classification to detect trucks, tanks, and aircraft (RADC Seismic Classifier Design, Rome Air Development Center Griffiss Afb N Y, 1973); and analysis of aerial photos to detect what crops were cultivated (Separability Study of Wheat and Small Grains, Lockheed Electronics JSC-14604, Nov 1978).

Breaking Passwords

[Paul Karger] We [at USAF Hanscom Field] were trying to break the Multics (sorry, Tom!!) password encryption algorithm, and I had figured out a break that would work on passwords that had at least two trailing blanks. I could NOT break longer passwords.

[Paul Karger] We used RADC-Multics as the test site for debugging our Multics penetrations, so like all other things, we tried out the password encryption break there first. The question was how many passwords could my weak break actually retrieve.

[Paul Karger] Before I ran it, we had an office lottery on what percent of the passwords would be cracked. My guess was hopelessly wrong, as were the guesses of almost everyone else. Lt. Col. Whitson (then Roger Schell's boss) actually came the closest, although even he did not get very close. The actual figure was around 90% broken. This was because RADC set your initial password to your initials, and most of the users in 1973 never bothered to change it! Given that RADC-Multics was not being used very much yet (because it had so little memory and ran so slowly), it is likely that many of the users had only logged in once or twice at most, so the fact that they hadn't changed their passwords was not really so bad as it might sound today. This wasn't where they did most of their computer work, yet.

[Paul Karger] Even though we got a very high percentage of passwords at RADC and a much lower percentage at MIT, my algorithm was clearly insufficient. Several weeks later, Peter Downey came up with a better algorithm that could break all passwords, and Roger Schell and Steve Lipner implemented that one. It did a time-space tradeoff and used what we considered at the time HUGE tables to make it go fast. The tables were 512K bytes long - the size of the entire core memory of RADC-Multics. Building those tables took a LONG time, and we didn't even consider trying on RADC-Multics. The work was done on MIT-Multics that had three times as much memory (1 1/2 megabytes). Of course by today's standards those are very small memory requirements, but this was 1973.

[Paul Karger] This story is explained in detail (with all the math) in:

MULTICS Security Evaluation: Password and File Encryption Techniques, US Air Force, Electronic Systems Div, Hanscom AFB Mass,, Jun 1977, NTIS AD-A045 279/7
MULTICS Security Evaluation: Password and File Encryption Techniques, volume II, US Air Force, Electronic Systems Div, Hanscom AFB Mass,, Jun 1977
MULTICS Security Evaluation: Password and File Encryption Techniques, ESD-TR-74-193, volume III, US Air Force, Electronic Systems Div, Hanscom AFB Mass,, Jun 1977

Aaron Wright kindly tracked these down at NTIS.