The period 1983 - 1986: Control Data CYBER 170-835

Benchmark "en Français": pupitreur and pi

In October 1981, Control Data
announced a new line of systems, the CYBER 170-800 series at the Control Data
VIM/ECODU "world conference" in Minneapolis. The first two models were the 825
and the 855. The Physisch Laboratorium was looking for a model that had the performance
(and costs) that was somewhere between those two systems. The reason was a very
high load on the CYBER 74: A CPU-load of 100% during
office hours and an average of 75-85% in the evenings and the weekends.

The requirements for the replacement system of the CYBER 74 were 256 MB
SecDed (single error correction and double error detection) memory at a minimum
and more and faster I/O-channels in order to take advantage of new and faster
disk units with higher I/O transfer speeds. When the new level source code arrived
we found in some comment lines in the PP-code for
"bootstrapping" the system, that Control Data worked on a new system with the
code name S2. As that was a number between the S3 (CYBER 855) and the S1 (CYBER
825), we had reasons enough to ask details under non-disclosure conditions.

In May 1982, it was agreed that we could run benchmark tests on one of the
first beta-test systems of the CYBER 170-835 ("Early
Bird program"), that was installed at Aerospatiale in Toulouse, in France. We
went there with two sets of four magnetic tapes with all the sample jobs and
required data on it. One set of the tapes was in our luggage, that took a touristic
route for a day when we had to change planes in Paris. The other set of tapes
was in our carry-on luggage, but the French security police at the Charles de
Gaulle airport insisted in X-raying the tapes in a non-magnetic safe system.
On arrival in Toulouse and finding that our back-up tape set was missing, our
priority one was to verify whether the tapes could be read at all. Fortunately
that was the case.

On Saturday and Sunday, we were allowed to make use of the CYBER 170-835 system
which was installed in the for us impressive computer center of Aerospatiale.
Apart from the French CDC engineer that supported us, nobody else was around
in that center. Four large mainframes, many rows of disk units and a large number
of printers and card readers were installed in a room that was part of an airplane
construction building. The NOS/BE system was heavily
modified by the French. We all did, but they had gone much further. All (error)
messsages on the console, compiler output and so on were replaced by their French
equivalent. Fortunately, our French colleagues were less good in understanding
how the complex code worked that parsed the command input at the console, thus
the input was (fortunately) still in English. This allowed us to operate the
system in a normal fashion.

The French engineer hardly spoke English. Moreover, it lasted only a couple
of sentences after asking to speak a little slower before he picked up speed
again and flushed us with a stream of French words. They had new computer systems
(835, 855), disk units (844, 885)
and printers (e.g., 580). In French, the (for
us) complex way of counting required a lot of decryption processing. Especially
when numbers are close (cinq cent quatre-vingt cinq) and all had eigths and
five in them. Did he talk about a disk unit or was it a mainframe that worked
quit well? Even worse, he mentioned many times the word "pupitreur", a term
which we could not find in our French-Dutch dictionary. It took us two days
before we finally figured out that he had talked about operators. "Pupitre"
turned out to be a word for "desk".....

Our benchmark consisted of twelve sample jobs that represented the heavy I/O- and
CPU-work at our Laboratory and for our Defense customers.
Apart from that, we had a set of artificial system test programs that belong to the
NLR. These jobs measured the system throughput of a representative
batch of jobs. This set was tuned to be a reflection of our specific operational environment
on the CYBER 74.

During the benchmark at the CYBER 170-835 in Toulouse,
we found an error in the systems' microcode. A Pascal program generated an "error
mode 4". Debugging the code, while other CPU intensive benchmark jobs ran
at the system, we figured out that the constant pi (¶) was calculated by
calculating arctan(0)/4. The way "old" CYBER's rounded the result of a divide
by zero (RXi Xj/Xk) differed from
the way microcode at the new CYBER 170-835 worked. Just to get any results for
the jobs, we did not require 100% accuracy of the job results, we changed the
program and set pi equal to 3.14.

The results of the benchmarks, which comprised different I/O and PP-configurations,
and included some simulated predictions, was an advice to install a CYBER 170-835. On April 7, 1983, the rental agreement for a CYBER 170-835 was signed.

CYBER 170-835 hardware

The CYBER 170-835 CPU had a 56 nanoseconds major clock
cycle and a cache memory of 2KByte. The memory consisted of 16 K DRAM memory chips,
had SecDed. It was organised with 64 bits words (actually 72 bits when SECDED
is taken into account). The system had water cooling, used 65 KWatts per
hour and required (only) 2.5 uur preventive hardware-maintenance per month.

The architecture was particular. The hardware supported an extensive 64-bits
instruction set that worked with virtual memory. It supported the emulation
of up to 16 different microcodes in one single system. One of these emulations
was the support for the old CYBER 60-bits instruction
set and fixed memory addressing in the lowest memory part. The old operating
systems NOS and NOS/BE used this absolute memory.

The 20 peripheral processors worked in four rings of 5
PP's, each ring having a clock speed of 250 nsec (major cycle). The "native"
PP's used 16 Kwords by 16 bits of memory.

Installation and configuration

Op September 1, 1983, the
CYBER 74 was dismantled. A number of the cables of the so-called Christmas tree,
the interconnections between the four system bays,
were cut using a cable cutter. Within half an hour, word spread in the Laboratory
that the system would be dismantled and scrapped. Soon, a helping hand was given
by technicians who could use many meters of the special twisted wires that connected
all parts of the CPU. Other had screwdrivers and collected modules as these were
a "technicians delight" regarding to packaging. For the Labs' history, some memory
blocks and logic hardware were saved.

After modifications to and isolation of the pipes of the water cooling system,
the CYBER 170-835 bays were moved in. Installation
and acceptatance testing were carefully planned. The whole operation went very
smoothly, that the CYBER went into operation one day ahead of schedule.

The disk configuration was extended to four 844-41 disk
units and four 885 disk units
with two HDA's each. A HDA contained 692 Mbyte. (885 units are visible at the
left of the picture). To distribute the load
and to increase availability, the twelve disk packs were controlled by three
disk controllers; each disk packs was accessed by two different controllers.
The PP's were fast enough to change from 2-fold
interlaced (consecutive information blocks are written onto alternate disk blocks,
which gave the disk controller/PP processing time enough to handle the information
during the skipping of 'alternate' block and minimised the risk that a full
disk revolution of 18.3 ms had to be waited for; this allowed for the highest
throughput possible at that time) to full tracking (just consecutive disk blocks)
which gave an impressive increase in disk performance.

Two new magnetic tape drives were installed.
These could only read the 'old' 800 bits per inch (bpi) tapes, but could read
and write 1600 bpi and (new) 6250 bpi tapes. The latter gave a large capacity
increase, especially for backup dump tapes. The speed of the tape unit was 200
inch per second (ips), which was an improvement over the old '150 ips'. The
only drawback was that the units had so many safety features that no manual
tricks were feasable as the air loop pressure would drop (the air loops handled
start/stop differences between the capstan and the reels). As our customers
were sometimes very 'inventive' with magnetic tapes, certain measurements recorded
on tape required all the tricks available to the operator, especially with recordings
made by submarines of the Royal Netherlands Navy. Unaware of knowledge of computers,
the conscripts did a fast forward of a couple of meters, added a 'blinker' (aluminium
sticker on the tape that was spotted by a light as a reflective marker and that
either indicated the beginning or the end of tape). Then he would start a new
series of measurements. That saved 'magnetic tape'.

It should be remarked that our friends of the
Royal Netherlands Navy
were quit inventive with respect of handling computer materials.
In 1990, we received a papertape that was winded in the form of an eight, as if it
was the anchor chain!

The memory of the CYBER 170-835 was split into two: NOS/BE could use
256 MB directly and 256 MB was set aside as UEM (extended) memory.

Batch jobs now could use 200000B words maximum and during the non-offioe hours
and weekends 377000B words (492 KB resp. 980 KB).
We changed the system in such a way that jobs did not abort when the memory limit was
decreased in the morning. For interactive work, the memory limit was set to 100000B woorden
(246 KB). During office hours, an interactive user was only allowed
15 seconds CPU-time per interactive step; batch users were allowed 8 minutes of CPU-time
at maximum.

ACCU and ENR in trouble by a TNO-worm

As some of our users had urgent projects, computer services were arranged for them
at the computer sites of two of our colleagues during the removal of the CDC 74 and the
installation of the CYBER 170-835. During installation of the new CYBER, we got
an urgent telephone call from our colleagues at the university of Utrecht.
(ACCU)
We (of course) were the first one in the world having the latest and newest level of the operating system
in production in order to support the new 6250 bpi tape units as mentioned earlier.
During a backup (Dumpf) a (PFC) file description block
(in Unix-terms: inode-table) was stored on the magnetic tape. This PFC contained a bit
signalling the tape density. This allowed for automatic archival retrieval of the
data on the right tape unit. The new software had put the "6250 bpi" bit
in the byte and bit which in previous levels was reserved for signalling the system
that this was a non-removable, non-archivable system file. To speed up use of the
system at ACCU, our user had received a DUMPF tape of his whole user environment.
After a LOADPF (load permanent files run), the files could not be moved, deleted and so on.
As our colleagues did not yet looked at the documentation of the new level,
they did not understand why the 'normal user' files could not be removed.
After a short brainstorm, the TNO system programmers developed a simple and effective
solution to remove the files. The solution was tricky and required some 'patching'
of the memory bits in memory.
As another of our users would make use of the computer facilities of the Energiecentrum
Nederland (ENR), we contacted him. Fortunately, his files were not loaded yet.
As we knew the cause of the problem, we could suggest a way of circumventing the
same 'sticky' problem there.

Accounting

In 1984, as the CYBER facilities of the Laboratory increasingly attracked external paying users,
we had to change the 'pro forma' account card content. Another reason was the management
requirement to get more insight in the use of the CYBER for projects.

Based on the project and institute number, a simple secret number in the ACCOUNT card
replaced the institute number for the Physics Laboratory users.
The algorithm for calculating this number was: ((X2+42) modulo 89 + 10).
The offset of ten caused a number range between ten and 99, a two digit number. This simplified the
assembler code of the ACCOUNT card program a lot.
The magic number "42" was invented by the lazy Systems Programming people. As they figured out
that they did not want to change the ACCOUNT cards in all their card jobs,
they used 42 in order to cause the verification number of their project number to become
equal to the former Physisch Laboratorium institute number "51". Designers have that advantage,
isn't it? (by the way, the number 51 was dragged along already for over ten years as that
was the institutes number invented by IWIS-TNO)

Based on the earlier described "fast I/O"-module, each active project number was indicated by
a bit in a project database. The ACCOUNT-program read this database file and verified
the status of the project by looking at the bit value indicating whether the project was active
or not.

Computer graphics: Preview and Plotlib

The basic Calcomp
plot library that was used at the Laboratory was in use since the days of the
Control Data 3200 system. Much effort was required to keep the library
working with Fortran 5 and the loader presets of unused memory. As we moved
away from the data conversion station and went to use a
Calcomp 1051 plotter controlled
by a Calcomp 906-controller, the basic plot library had to be updated.
The basic Calcomp library comprised some simple
routines for pen selection, pen up/down and the drawing of a line and an
axis. This library drove the plotter. On top of this library, another Calcomp-library
with "top-level" routines was available, for drawing for instance logarithmic axis.

A project team was formed to supply the users with much more user friendly plot facilities.
New routines were designed to allow the assigment of colors and different line thicknesses
to certain pens (in the back, these were mapped to pre-arranged physical pens and color schemes),
one could choose between ballpoint or ink, normal paper or 'velum'. Scaling and "clipping"
were other new functions that were offered.

The main design problem was to keep long-time ago developed programs running.
The changes had to be minimal for the user. At the same time, the new plot library
had to be used by the 1966 and 1977
versions of the Fortran languge.

Some statistics

In 1884, performance measurements in the CYBER 170-835 showed:

34 interactive commands per minute.

40 I/O-calls per second.

107 disk accesses per second.

162 interactive swaps per minute (the number of times the
"Enter" is hit/minute).

150 PP-programs loaded per second; only 5 per second
were loaded from disk.

compared to the CYBER 74, the number of program
swaps to disk decreased with a factor 100.