Atlas is being built by Ferranti, and we hope that it will be working in the new building at the National Institute in the summer of 1964. The machine will be available to the Universities, the NIRNS, the Atomic Energy Authority, and various Government research laboratories, including DSIR, the Meteorological Office and the Medical Research Council.
The essential parameters of our machine are:-
Core store 48K words (each 48 bits)
Drums 96K words
Magnetic tape 16 Ampex TM.2
2 IBM 729 Mark IV
Input 2 card readers (600 cpm) + data channels
2 paper tape readers (300 ch/sec) + data channels
Output 1 card punch
2 paper tape punches (110 ch/sec)
2 line printers (900 lines/m)
(Off-line IBM 1401
Benson-Lehner graph plotter)
A general statement of the speed of the machine is that it will work at around 500,000 instructions per second, which corresponds to about 100 times the speed of Mercury. With this speed, the very large store and the time sharing features, we are likely to have one of the most powerful computing installations in the world.
There is much large scale experimental equipment on this site, and there will be a good deal more which produces large amounts of raw data needing processing; in some cases the calculations have to be done at high speed and with the least possible delay for monitoring of experiments.
There seem to be three main categories:
Categories (i) and (ii) raise problems of computer hardware, data transmission and internal organisation. Category (iii) raises the problem of compatibility of the recording gear with Atlas.
The demands are known to be large; we want to decide how best to meet them, and in particular what extra equipment is needed. At present we do not have enough facts on which to base a decision, and we hope to get today:
We cannot expect to settle anything today, but we shall be in better shape to do so after we have collected all this information.
We need to find out how far Atlas can be used to deal with that data processing which forms an integral part of experimental the time-sharing feature of Atlas makes it possible to deal efficiently with information arriving slowly or irregularly and so puts quite a new complexion on the use of a big central computer for this kind of work. The alternative is to associate data handling equipment (some of it specially designed) with individual experiments. To what extent one does this depends on economics. Special electronic equipment can be expensive. Atlas has been bought, but will be expensive to run, and we do not know what is the cost of, for example, high priority interruption - not only in the running cost of the time used but in the effect of any possible disturbance of computation in progress. Also, the processing can be carried on only when Atlas is working, and any extension of the working day needed to handle these problems could be expensive.
The connecting of experiments to the central machine will require a two-way flow of information, probably along high quality cables; this too can be expensive, because the whole site covers a large area. There can be quite serious problems in providing cable runs so as not to interfere with existing or future services on the site.
All the activities of Atlas are controlled by a built-in program called the Supervisor, which is stored mainly in a special read-only store called the fixed store but partly also in the main store. Its operation is made possible by certain features of the hardware, in particular the indirect method of addressing words in the main store via the Page Address Registers and the system of lock-out protection between parts of the main store.
The word length is 48 bits. This can represent either two 24-bit fixed-point integers, a floating point number with a 40-bit mantissa and an 8-bit octal exponent, or eight 6-bit characters, or a single instruction. When representing an instruction this is made up of:
F Ba Bm N
where
F 10 bits - function digits
Ba, Bm 7 bits each - B register addresses
N 24 bits - either an address in the store of an operand or
itself an operand, depending on the function code.
24-bit words are used for addressing the stores of Atlas. Of these the top bit is used to distinguish main store from the other stores (see below). The next 20 bits are used to address 48-bit words within these stores (allowing a maximum of 220 main store addresses). The next bit is used to permit 24-bit half-word addressing, and this and the last two bits to permit 6-bit character addressing.
The first three digits of an address identify the particular store as follows
23 22 21 0 x x Main store (core store and drums) 1 0 0 Fixed Store 1 0 1 (Not allocated) 1 1 0 V-store Private Store 1 1 1 Subsidiary Store, Private Store
There is a theoretically maximum size of 218 48-bit words for this store (the National Institute machine will have 213 = 8192 words).
It is constructed in the form of a woven wire mesh into which can be inserted ferrite and copper rods represent 1's and 0's. It is a "read only" store, with a read time of about 0.4 µs, and writing to it by program has no effect. It contains
This is available only to the extracode and supervisor routines, and any attempt to address it directly by ordinary program causes an automatic interrupt. It is made up of:
Maximum size = 220 48-bit words. Can be either ferrite cores (2 (µsec cycle time) or cores supplemented by drums. A drum holds 24,576 words, has an average access time of 8 milliseconds and a transfer rate of 4 µsec per word. (NIRNS 49,152 words of cores plus 4 drums). The supervisor allows the main store to be treated as a single uniform store irrespective of any separation into cores and drums - this is the "One-Level-Store" concept.
The main store is addressed indirectly by programs. It is regarded as divided into blocks of 512 words. Bits 22-12 of a main store address define a block number and bits 11-3 the word position within a block.
The core store is divided into sections of 512 words known as pages. Associated with each page of the core store is a register of 12-bits (numbered 23 to 12) in the V-store known as the Page Address Register (PAR). When a block of information is in use by a program (as instructions or operands), it is placed in a page of the core store by the Supervisor. The Supervisor also sets bits 22 to 12 of the corresponding PAR to the block number of the block of information and bit 23 to 0. Whenever a reference is made to any information in the store (to extract the next instruction or to extract or store an operand), hardware automatically separates off digits 23 to 12 of the address concerned and compares these at high speed with the contents of all the PARs and, having discovered the page with the correct block number, causes the remaining address digits to be decoded and the required core-store reference made.
However the required block of information may not be in the core store. It may have been placed in the drum store by a mechanism to be described later. In such a situation the comparison just described will fail to discover a PAR containing the correct block number. In this circumstance an automatic interrupt (known as the "Non-Equivalence" Interrupt) occurs and the Supervisor program is quickly entered. The supervisor program scans a directory known as the Block Directory which is kept in the subsidiary store and which has one entry for each page of cores and each 512-word sector of the drum, discovers where on the drums the required block is stored and initiates a drum transfer of this information to the core store. When the transfer has been completed, the supervisor sets up the required block number in the appropriate PAR and causes a return to the main program beginning with the instruction which caused the Non-Equivalence Interrupt. This time the page with the correct block number will be discovered and the program will proceed. Thus the program is written as if the information is all in the core-store, the supervisor automatically arranging transfers from drums to cores as required.
The above process is used in only a slightly modified form to permit the defining of new blocks. Since all store references initiate a comparison in the Page Address Registers, an attempt to write information to, or read it from, a block not previously referred to will cause a Non-Equivalence Interrupt in the usual way. In this case however the supervisor will not discover a corresponding entry in the Block Directory and must instead create a new entry and can set up the required block number immediately in the PAR of an empty page without having to initiate a drum transfer.
This technique is used for the definition of blocks for instructions as well as operands. Thus when the compiling of a program is initiated, the supervisor only has to ensure that there is sufficient space in the one-level store and to allocate a corresponding number of entries in the block directory, the block numbers themselves not being decided nor the entries in the block directory completed until the blocks are actually referred to, either by the compiler or the program.
The process so far described explains how blocks on the drum or new blocks are automatically made available in the core store as required. However it is obvious that there must also be some mechanism for arranging that information is continually being transferred from the cores to the drums to ensure that there is an empty page always available. This is the function of the Drum Learning Program which is a routine of the Supervisor. It is called in whenever the last empty page in the core store is claimed for a program. It attempts to select the block of information in the core store which is in least use and arranges for it to be transferred to the next available empty sector on the drums, amending the corresponding entry in the Block Directory, deleting the corresponding Page Address Register setting, and marking the page as Free in a Page Directory in the Subsidiary Store. It is assisted in its selection by a set of digits in the V-store known as the Use Digits. There is one Use Digit for each page of the core store. A Use digit is set automatically by hardware to 1 (by "or-ing") whenever any reference is made to the corresponding page. Thus by examining these at frequent intervals, storing the set of them for several successive intervals, each time re-setting them to zero, the pattern of use of the core store pages can be determined. The actual rules followed by the Drum Learning Program to select the page to be written to the drums on each occasion are somewhat complex. They are fully described in the paper "One-Level Storage System" by Professor T. Kilburn and others.
The One-Level store system just described not only permits information to be spread between the cores and the drums. It also permits the use of any addresses in the range 0 to 220-1 provided that only the total number of blocks required at any instant by a program does not exceed that available to it in the whole main store (cores plus drums).
A further facility of the system permits the simultaneous use of the main store by more than one program and, when necessary, by the supervisor also. The twelfth bit, digit 23, of each PAR is called the lock-out digit. As stated above it is normally set to 0. If however the supervisor sets it to 1 in any PAR, then the comparison of any main store address with the contents of this PAR will fail, so that access to the corresponding page of information is barred. The look-out bit is set to 1 for all core store pages belonging to programs other than the one being executed at any instant, for all core store pages being used by the supervisor, for all pages involved in drum or tape transfers, and for all free pages. If a program change is required then the lock-out digits of the programs concerned are changed. In addition it is arranged that after a Non-Equivalence Interrupt only the area of the Block Directory associated with the current program is scanned to see if the required block is on the drums. Thus there is complete protection between information belonging to programs sharing the store both in cores and on the drums.
The lock-out system just described not only makes it possible for object programs to share the main store but also permits the supervisor to take over sections of the main store if or when necessary. The supervisor uses the main store for some of its less frequently activated routines, so that these can normally reside on the drums, and can if necessary be relegated to magnetic tape, without interfering too drastically with the efficiency of the system; it also uses parts of the main store as buffering for input and output.
In some cases it is necessary for the operation of the supervisor to ensure that certain blocks of information in the core store are not transferred to the drums under the operation of the one-level store system by the Drum Learning Program. In this situation a device known as "lock-down" is used. This uses a set of digits in the Page Directory. If this digit for any page is set to 1 then the Drum Learning Program will ignore this page from its considerations and so the information in this page will be kept in the core store. This device is used most frequently for the one page primary input and output wells which are kept in cores all the time that any peripherals are engaged. It would also be used for any interrupt routine which, for any reason, were not in the fixed store; it could thus be used, for example, for interrupt routines associated with special-purpose on-line peripherals. The lock-down digits can be set by the supervisor as required.
That then is the main store system. It permits the most flexible and efficient use of the core and drum stores of the computer. It permits programs to expand and contract, to take over large portions of the core store when active or to retire to the drums when dormant. It permits the supervisor to expand into the main store as and when necessary, to provide efficient bufferage for input and output and to prepare programs for execution in the store.
One further aspect of the system should be pointed out. It is that the Supervisor automatically arranges that, should a program be dormant for long periods and should other programs which could be active require most of the main store (cores and drums), then the dormant program is automatically temporarily dumped on to one of the system magnetic tapes until it can "be re-activated. Thus it should not be assumed that a program which is going to be dormant for considerable periods, for example one which is on-line to an experiment which transmits data to be processed at infrequent intervals, is going to occupy space in the main store all the time.
All input and output through the normal slow peripherals - paper tape readers and punches, card readers and punches, line printers, etc. - is handled by what is known as the peripheral coordinator. This coordinates the transmission of information and of control signals between the peripherals and the computer. All signals between the computer and the peripherals are handled by means of addressable registers in the V-store.
The digits in the V-store associated with slow peripherals are of three types: information digits, control digits and look-at-me's. The information digits and the control digits are normally combined in a single register of up to 24 bits. The look-at-me's for various peripherals are grouped together in other registers. Whenever a peripheral requires attention either to transmit or receive information, an interrupt occurs and the associated look-at-me is set. The common interrupt routine identifies the look-at-me which is set and branches to the appropriate peripheral interrupt routine to take the required action. It takes a maximum of 6 instructions in the common interrupt routine before the peripheral routine is entered and the peripheral routine may take between 10 and 50 instructions to take the required action. Thus there is a theoretical maximum rate at which information could be handled in this way of about 30,000 words per second, allowing 2µs per instruction, but, to achieve this rate for any one peripheral, all other activities would have to be inhibited, including transfers with other peripherals. Thus the maximum normally allowed for any peripheral is considerably less than this. The actual maximum permitted to any particular peripheral depends on the position in the "priority tree" of its associated look-at-me, since this determines the maximum time that the peripheral concerned may be kept waiting for attention whilst higher priority look-at-me's are dealt with. It should be noted that once the position and thus the rate have been determined, the peripheral concerned must in some way ensure that this rate is not exceeded; otherwise other peripherals may not be able to be dealt with within their "crisis-times", in some cases with serious consequences.
The normal input peripheral interrupt routines all transfer information initially from the V-store to a single locked down page of the core store, this page being divided into sections for each peripheral. When any section is full, the information accumulated in it is transferred to a block devoted solely to the one peripheral. This block is not locked down and thus will normally find its way quickly back to drum where it will remain until the section has been refilled, when it will be called back to the core store. Blocks of input are accumulated in this way and then transferred to the System Input magnetic tape where they remain until they are required. In this way input is handled using only one core-store page permanently and a minimum of one block of one-level store for each active peripheral. A similar system in reverse is adopted for output through the normal output peripherals.
Peripherals which are on-line to specific programs are handled in a different way. (This applies to the IBM channel if used for data rather than as a satellite tape and also to any on-line special purpose peripherals). For each of them a separate buffer is set aside (which will only be locked down whilst the peripheral is engaged), its size being specified by the programmer according to the manner in which the information passed through it is to be handled. The programs will transfer information to or from this buffer, and the supervisor and interrupt routines will handle the transfers between the V-store and this buffer. In the case of an on-line input peripheral, the program will be halted if an attempt is made to read from the buffer when it is empty; in the case of an on-line output peripheral, the program will be halted if the buffer becomes full. This halting procedure is exactly the same as when a program is waiting, for example, for a drum or tape transfer and requires no special supervisor handling.
If any program is halted for a long period and there are other programs making claims on the main store space, then the supervisor can automatically dump them on the System Dump tape until the reason for halt is removed. Thus a program associated with an online device which only becomes active at infrequent intervals need not occupy main store space for the whole of its duration.
The system so far described, using a single 24-bit V-store buffer with an interruption every time this needs attention, is satisfactory for transfer rates of up to about 5,000 words (of up to 24 bits) per second. Above this rate it is inefficient and inconvenient. For IBM tape a 2 × 48 bit V-store buffer is used so that more information is transferred at each interruption. Even this takes a considerable proportion of central computer time during IBM tape transfers. For other fast peripherals three methods are theoretically possible.
In conclusion it should be stated that the on-line operation of peripherals in conjunction with object programs, whether with feedback (process control) or simply for data analysis, presents no essentially new problems for Atlas and demands no essentially new techniques. Because of the nature of Atlas as a fast time-sharing computer, care must be taken to ensure that, as far as possible, on-line operation is performed efficiently, making good use of core-store and central computer time. But even if an on-line peripheral is engaged for long periods and only active infrequently, or if it produces information at a very high peak rate although with a much lower mean rate, then by a suitable combination of hardware and software, the Atlas system will cope, with the minimum possible interference with the operation of other programs.
I will describe a proposal we have made to the National Institute for a data handling system involving the on-line use of Orion.
Experiments involving large numbers of detectors are being considered for many accelerators at this time, especially those of the Nimrod type. These experiments, for example, involve the detection of multiple secondary particles or perhaps they use a large number of detectors in order to utilise fully the whole of the solid angle available in the laboratory, and so increase counting rates. These experiments are characterised by the fact that for a single event of interest a number of parameters have to be recorded. These parameters may be simple labels describing the detectors involved in the event, or pieces of analogue information, or binary numbers giving positions related to the event.
We have proposed a system which will handle up to 100 pieces of information pertaining to one event. Each piece of information is a word of 13 binary bits - that is, 1300 binary bits per event. Further we require that the equipment should be capable of accepting a second event 20 ms. after the first event.
We are of the opinion that in such an experiment, if we arranged for these 100 numbers to be printed out, our puny brains would be incapable of digesting this information and of making decisions from this large bulk of data. For this reason, we propose that this information should be passed to Orion for two operations.
Firstly, to record the raw information on magnetic tape for posterity and future analysis - Orion is acting here as a derandomising store and an output facility, and secondly that Orion should perform some partial analysis and calculate parameters of the event which would be more easily assimilated by the experimenters and could be used as guide in directing the experiment.
The design of the memory has been largely dictated by the special way the data we have presents itself. Very briefly, the detector we will use is a sonic spark chamber - a gas filled parallel plate condenser in which a spark breakdown is caused at the place a charged particle has passed through the gas. We are developing a method whereby the location of the spark is not determined by photography but by timing the arrival of the acoustic disturbance in travelling from the spark to a small number of transducers situated round the edge.
The spark is initiated by pulsing the plates with some 10-20 kv, and this gives the time zero - the START pulse. With a spark chamber 1m. square, sound signals arrive at the transducers up to 4 ms. later depending on the position of the spark. The arrival of the sound wave produces the STOP signal.
The time of flight of the sound is to be determined by gating a free running oscillator with the START pulse opening the gate and the STOP pulse closing the gate.
The frequency of the clock is determined by the performance of the sonic chamber and is to be 2Mc/s.
Thus the system is:
We now make use of the fact that the scaler is in fact stopped between successive clock pulses and it is in this interval of time that the binary number contained in the scaler is transferred nondestructively to the memory matrix. This implies that the information has to be transferred
in 350 ns. This is short. There is a twin ferrite core by Plessey with a write time of 250 ns. which we are investigating, and also we are looking into a system recently developed by G. V. Planer Ltd. using thin cylindrical magnetic films with a write time of 10-15 ns. This is of course much faster than we require, but relaxing the write time to 50-100 ns. would mean that transistor drives could be used.
Costs: Plessey about £180 Planer less than V600
So then the system will be
Staticicers are used in the stop lines to synchronise the stop pulse with the clock pulse; i.e., a stop pulse may be delayed by up to about ¼µs. This is quite acceptable.
The word drive amplifiers are only triggered on arrival of a stop pulse. Thus, even if more than one stop pulse arrives simultaneously, the same number is transferred to more than one location. In this way, 4 ms. after the event the store contains 100 13 bit words describing that event.
It is fortunate for us that Orion has the facility for accepting on-line information, and in this mode Orion will accept 48 bit words.
The Hough Powell Device for scanning Bubble Chamber photographs will use, essentially permanently, 19 of these wires. This could then leave 29 wires for other on-line users.
In the absence of an on-line experiment (OLX), the HPD will be presenting information to Orion continuously in a macroscopic sense, but at the present time it is possible to provide for an arrangement whereby an OLX could interrupt the flow of HPD information for the time required to feed a few thousand bits of information to Orion.
In terms of hardware the provision would be a control box fed by 19 wires from HPD and up to 29 from an OLX. This control box then feeds either 19 HPDs OR 29 OLXs, but never both. A further provision in terms of brainpower is that Orion would be required to be programmed to recognise these two types of data and to deal with them accordingly.
The times of importance in reading into Orion are:
32 µs. / 48 word i.e. 19 HPD or up to 29 OLX bits. The 100 × 13 bit words could be presented to Orion either as 100 × 13 bit words → 3.2 ms. or 50 × 26 bit words → 1.6 ms.
It is intended that the raw data presented to Orion should be recorded on magnetic tape regardless of the fact that some of the events may have been analysed for monitoring purposes. The tape transfer time is of the order 80 µs./48 bit word with a start/stop time of about 4 ms., i.e. for our requirement about 10 ms. per event, including start/stop time. Although this time is longer than the 3 ms. taken to read the information into Orion, this is no bottleneck as Nimrod, the producer of the events has a duty cycle which looks like
and in the 1.5s. Orion could transfer to tape about 200 events which is vastly more than we are anticipating observing in a beam pulse.
Further, it should be noted that 1 reel of magnetic tape ; could hold up to 105 events with 1300 bits/event, so that there would not be an enormous consumption of tape. These tapes could be analysed on Atlas if desired.
At first sight it would seem desirable to use the fact that the data is being partially analysed on-line to produce considerable monitoring information for the guidance of the experimenters. We have supposed that 3 printed lines of monitoring information could be digested. An electric typewriter of 10 characters per second would take 20-30 seconds to produce this. This could be a serious bottleneck under certain circumstances, for example during the setting up of an experiment; but we are making a more detailed study of this problem. When the experiment is going smoothly, it would probably be sufficient to print out occasionally the analysis of 10 or 20 events on the Orion line printer, and for the experimenter to collect them periodically.
It is necessary that the on-line use of a computer should not impair the flexibility of the experiment, i.e. magnet currents and detector positions can be changed at will. This can be achieved by-having the analysis programme in two parts.
A change of parameter can then be notified to Orion by replacing the parameter programme by one suitably modified. It would be most efficient to use punched cards for the parameter programme, i.e. one parameter per card, which can then be readily changed. It is highly likely that with this system one will be able to change the parameter programme must more quickly than one can move a detector.
The possibility of Orion breaking down during a run must be envisaged, and two systems have been considered to allow for this contingency.
In the first system? a TM 2 1" 16 track tape system could be used, and ideally one would like to write the information on to this tape in exactly the same format as used by Orion. The tape could then physically be taken to Orion for analysis. This method involves considerable electronic logic and is expensive.
The second system uses the FR 400 tape deck and the information is stored in the pure binary form that the data has in the memory matrix. Subsequent entry into Orion is gained by playing back the tape through the memory matrix and into Orion through the direct data connection. This system is considerably cheaper.
Although the form of this data handling system has been largely determined by the necessity for use with sonic spark chambers, the system does lend itself to use for purely counter experiments.
In such experiments the need is usually to record analogue information, that is pulse heights referring to the rate of energy loss, total energy and short (10s. of nano seconds) time of flight of particles.
Existing equipment allows one to change amplitude information to time information, which can readily be entered into the memory matrix.
It is doubtful whether 100 pieces of information would be required for each event in such an experiment, in which case more than one event can be stored in the memory before transfer to Orion.
We are constructing at the present time, with the aid of the. Electronics Division, a 15 word store, each word 10 bits, which should be finished in February. This will not be fed on-line to a computer. A 1 Mc/s clock will be used with Mullard Px 1899 cores with 0.5µs write time. We will use this system in an experiment to find the snags and the set up will then be used as a test bed for the faster cores to achieve the 2 Mc/s clock rate.
In this system we are also building a number of facilities so that the operation of the device can be quickly checked and facilities for directly observing selected words stored will also be built in. In this way we hope to be able to decide what peripheral systems will be desirable in the 100 word system.
Time of flight measurements with the linear accelerator give as output a long series of binary numbers, each signalling the existence of a pulse in a particular energy range, identified by the value of the number. The first thing to be done is to form these into a histogram, that is to count the number of pulses in each energy interval. This is done at present by recording on magnetic tape, usually over a fairly long time, around 24 hours to get statistical accuracy, and then reading the tape into an instrument called a multi-channel magnetic tape analyser which does the counting. The output from the analyser is a set of words giving,for example, the number of pulses in each interval. The latest plans are to have a 16,000 channel analyser whose output will therefore be a set of 16,000 words. It will take about 16 minutes to read the raw data tape into the analyser. One analyser will serve a number of experiments on the accelerator, and recording is likely to go on for several days on end. The total production of raw data is likely to be about 107 words per experiment per day, and there are likely to be about 10 experiments running simultaneously. The analyser reduces the amount of information by a factor of about a thousand, so the amount of processed information is about 105 words per day.
With smaller scale analysers (1,000 to 4,000 channels), it has proved satisfactory to punch the output on cards or paper tape and to do the rest of the processing on Mercury or the 7090. This is not likely to satisfactory with 16,000 channel instruments, and magnetic tape read-out of Atlas seems desirable. Ideally, one would want to read 16,000 words into the computer about every 30 minutes; this read-in could be spread over a half to one minute, and the information put on to the system input tape and queued : with the other traffic through the machine. In making a choice between direct input of the sorted data (16,000 words), and input via a subsidiary magnetic tape, the factors of continuous availability of the computer and the need for holding a record of the primary data must be considered. Since the computer is most unlikely to be available continuously, particularly during the first year or two of operation, an auxiliary read-out system is essential to avoid congestion of the tape analyser. It seems likely that the magnetic tape output will form the necessary permanent record, and will be the normal method of transferring information, together with appropriate programmes, to the computer, at least during the first year or two of Atlas' life.
An alternative is to dispense with the analyser and read the raw data into Atlas, using the computer to do the analysis; this. would make it possible to monitor long runs on the accelerator at convenient intervals. It would be necessary for Atlas to be running continuously, and for there to be stand-by tapes to store the information if the computer broke down. It would, however, appear that the cost of this system would be prohibitive in view of the very large number (108 words per day) to be handled.
CERN uses the Hough-Powell device (HPD), a flying spot scanner which produces digital values for the co-ordinates of points where the scanning lines meet tracks on the photograph. These numbers are fed into the 709 via a "direct data connection" (DDC), and go into the core store via a 128 word buffer of 18 bits per word, which is part of the HPD. There are two 2,000 word buffers in the computer core store, and input can be switched from one to the other.
A picture of an event consists of three views to allow reconstruction in three dimensions. The times involved in the digitising process are as follows:
| Machine | Line Scan | Total Time Per View |
Minimum Time between digitising | |
|---|---|---|---|---|
| raw | buffered | |||
| 709 | 7.50ms | 15 sec | 7.0µs | 200µs |
| 7090 | 2.08ms | 5 sec | 2.5µs (can be reduced to 1µs) |
70µs |
The number of digitisings per view is about 40,000 for bubble chamber picture, 6,000 for spark chamber; in each case the number of digitisings per scan line can go up to 100, but is likely to be around 30. The computer programme rejects those points which do not correspond with tracks specified by preliminary rough digitisings fed in on cards.
A much faster CRT device is being produced by Wiskott & Anders called Luciole. It is intended for spark chamber pictures. It could give a scan time of 750 µs per line with a minimum time between digitisings of 0.1µs; the time to scan a complete view could be 200 ms. So far there is no operational experience of this.
All peripheral transfers are organised by the peripheral co-ordinator; the general flow of information is peripheral-B Store-main store. The peripherals have addresses assigned to them in the V-Store of the form 6004XXX (octal).
The peripherals are not controlled directly by the operators or by the programme, but by the Supervisor in response to signals in the V Store. All have the following V Store digits associated with them:
The Engage/Disengage signals for all peripherals are examined by a Supervisor programme every one second. The peripheral co-ordinator is wired to take certain maximum numbers of each device as shown in the following table. This gives also the "crisis times" for each device which is the time within which an incoming unit of information must be dealt with.
| N.I. Machine | Maximum | Crisis Times | |
|---|---|---|---|
| Card reader | 2 | 4 | 660µs |
| TR 7 (1,000 ch/sec. tape reader) | 0 | 4 | 1,000µs |
| Graphical Output | 0 | 2 | not applicable |
| TR 5 (300 ch/sec. tape reader) | 2 | 4 | 3,000µs |
| Creed 3000 (300 ch/sec. tape punch) | 0 | 8 | not applicable |
| Teletype (110 ch/sec. tape punch) | 2 | 8 | not applicable |
| Card punch | 1 | 2 | not applicable |
| Anelex printer | 2 | 4 | not applicable |
| Teleprinter | 2 | 4 | not applicable |
This uses a 16 character buffer (6 bits per character), giving a crisis time of 256µs; the input programme for 16 characters takes 80µs., and the effect is to limit the simultaneous input when this tape is in us to the-IBM tape plus two card readers plus 6 TR 5 paper tape readers.
The IBM runs at 62,500 characters per second, and a typical rate at which information can be transferred as single characters is only 10,000 characters per second, so that grouping by the 16 character buffer is vital.
The circuitry for the IBM channel could be used to deal with input from other devices at a similar rate.
This could be a useful and reasonably inexpensive recording device. It uses half-inch magnetic tape, 5/7 tracks, and normally runs at 2,000 characters per second. The tapes are 1800 feet long, with 200 characters per inch. ICI are using these decks in connection with an Argus computer which writes on the tapes at 10,000 characters per second, and these are later read into Mercury.
On closer examination, it seems that very elaborate high speed input such as a buffer controlled by the drum co-ordinator is not strictly necessary; the computer could be used to edit the raw data and reduce the rate to about 5 digitisings per scan line of 2 ms., which is easily handled through the V Store. If a 128 word buffer were provided, 64 words could be transferred at a time, taking 256µs; therefore the crisis time would be the same as for the IBM tape.
The ability of Atlas to take in slow input efficiently reduces the need for off-line equipment, but there may still be a need for satellite computers away from the main installation; such machines could be used, for example, for checking programmes, to piek out punching errors and statements which do not obey the formal functions, and assembling jobs in batches. The normal system of input or output tape has a mixture of programmes and data in no particular order; the Supervisor assembles this in the right order when either a programme is about to be obeyed or information is about to be sent to an output device. A satellite would use tapes with programmes or output already correctly assembled with complete documents head to tail.
The scale of operations of this kind is shown by the fact that it takes about a complete day for a card reader to fill one magnetic tape, and this might be worked through by Atlas in a short time.
The I.B.M. channel on the NIRNS Atlas will enable 1401's to be used in this way but the efficiency with which Atlas can handle I.B.M. tapes is much lower than that for "Atlas Compatible" tapes.
Ferranti are making a satellite based on the Argus 100 process control computer. This will have a core store of either 4K, 8K or 12K of 24 bit words (identified by Argus 104, or 108, or 112), and the times for fixed point operations are as follows:-
Add 80µs Multiply 2µs Divide 2.16ms
As peripherals the machine can have card reader and punch, TR 5 teletype paper tape punch, 2 Ampex TM 2 magnetic tape decks, Anelex 300 line per minute printer. On-line inputs can also be accepted.
There will be a simple Autocode, actually the Pegasus/Sirius Autocode, and checking programmes for Fortran and Algol, and cost would be from £27,000 to £100,000 according to the amount of peripheral equipment.
Basically there are 3 types of system for dealing with information from experiments which it is desired to input to Atlas.
The methods of gathering and digitising analogue signals is essentially the same for all three cases.
The maximum continuous data rate which the Argus 100 system can handle when used in the Atlas satellite role is approximately 120,000 bits/second.
Conversion is performed by the successive approximations method.
Speed 4 µs per digit, i.e. 40 µs for 10 bit conversion Sensitivity Standard converter input is 0 - 15mA D.C. Accuracy 0.2% FSD
i) One of the most difficult analogue inputs to handle is the thermocouple giving signals, say, in the range of 0 - 10mV.
The standard module for transistor thermocouple switches can handle 16 thermocouples and uses double pole switching. The switch is of the form shown below.
The two transistors are made on the same slice of silicon and are mounted in the same can. The Vce of the two transistors is matched to about 40 µV. With double pole switching the switches in the two input lines can be matched to suit the accuracy required from the system. The Vce stability of each switch is extremely good due to the fact that the two transistors are constructed on the same slice of silicon.
Leakage through the switches produces errors whose magnitude is determined by the number of switches in parallel and by the temperature. Thus the number of switches per amplifier is limited by the required accuracy. As an example, an accuracy of 0.5% is possible with a 0 - 30mV input and 128 thermocouples driving a single amplifier.
ii) At levels greater than 200mV the double transistor is not economic and single matched transistors are used. With higher level of inputs which are capable of driving lower input impedance amplifiers, the closed resistance of the switch becomes important.
The main outputs channel of the satellite computer would be magnetic tape for input to Atlas. Other outputs could be provided, e.g, cards, paper tape.
The Rutherford High Energy Laboratory's main interest in Atlas was to analyse bubble chamber tracks. The hope that the scanning device (HPD) could be directly attached to Atlas. Orion had proved to be to too small for the processing load anticipated. The report was prepared initially by RHEL and commented on by Ferranti.
This report gives in outline a proposed method for the analysis of Bubble Chamber photographs using an Atlas computer. These proposals must be treated as preliminary ideas on the subject, but they attempt to solve some of the problems of store utilisation, and the organisation of programmes within the structure of the Supervisor, and it is hopes that the times shown in the final sheet are sufficiently accurate to assess the work load.
The Bubble Chamber photographs will be scanned by a Hough-Powell device which will be connected on-line to Atlas. The attachment will be via the V-store in the same way as a conventional slow peripheral device.
Each event in the Bubble Chamber is recorded on three separate photographs (or views) so that a three dimensional geometrical reconstruction of the event can be obtained. Only one film can be scanned by the HPD at a time, and collation of the separate views must therefore be achieved in the computer.
The HPD can be operated at a slow speed with a scan time of approximately 7.5 ms. or at high speed with a scan time of approximately 2ms. Both speeds would be acceptable to Atlas. The slow HPD will allow part of the filtering programme to reside normally on the drums, whereas the fast HPD will probably require part of the filtering programme to be kept permanently in the core store. This fact must be borne in mind when comparing storage requirements.
Against this, the total storage requirement would be approximately 6,000 words in each case and must be occupied throughout the time the HPD is attached to Atlas. This period is approximately three times as long when the slow HPD is used.
The period for which magnetic tape units must be reserved is similarly increased.
It has also been suggested that it would be possible to produce a rough filtering by means of a gate which uses an Atlas half word as a mask. This would mean that two thirds of the data was discarded even before it reached the HPD buffer.
The operations which have to be carried out on data produced from the HPD are:-
The HPD scans the photographs producing an average of 30 digitizings per line of scan. These digitizings are fed into a 128 word buffer, which is part of the HPD itself. Where external gating is used, only those digitizings which pass through the gate will be stored in the buffer. The buffer can be considered as divided into two 64 word blocks. When one block is full, output from the HPD is fed into the other block, and the full block is emptied into Atlas.
Input from the buffer store to Atlas is achieved using an interrupt routine which will form part of the Supervisor system. The suggested mechanism is as follows:-
The final gating and filtering programme will be treated as a normal object programme. When it requires further digitizings it calls for a new block by entering the Supervisor by means of a special extracode function. The main gating/filtering programme is then halted until a block of input is made available to it. (This process is very much like calling for a magnetic tape transfer.) The interrupt routine which deals with the HPD will simply fill a block of the core store with digitizings direct from the HPD buffer. The speed of the buffer store must be sufficient to cope simultaneously with the rate at which the scanner generates digitizings and with the interrupt routine.
Number of 24-bit words per view on input to Atlas (without rough gating) = 75,000
Number of 24-bit words per view (with rough gating) = say, 25,000
One view will take about 20 seconds to scan and wind on, at the slow scanning rate (7.5 ms. per scan line) or about 7 seconds at the fast scanning rate (2 ms. per scan line).
Let us now consider the amount of machine time used for this operation in each of the various cases:-
It is estimated that one scan line would require an interrupt routine lasting about 250 µs.
The utilisation of the arithmetic unit in this case = 3%
Utilisation of arithmetic unit = 1.0%
Utilisation of arithmetic unit = 8.6%
Utilisation of arithmetic unit = 2.9%
There will probably be too much rough road data for it to be stored on the drum throughout the time the HPD is operating. It will therefore be necessary to put the data on a magnetic tape, which will require a tape unit throughout the time the HPD is in operation.
This programme will be handled in the computer as a normal object programme, which may be held up for data in which case it will be time-shared with other object programmes.
The degree to which this programme will be held up for lack of data depends on the speed of the HPD scanner and whether or not rough gating is done.
It is reasonable to suppose that the Gating and Filtering programme will occupy about 6,000 words of store and that it will take about 0.8 seconds computing per view. (The storage will be used throughout the scanning time and one or two tape units will also be required.) Since it is estimated that the gating and filtering programme will run for 0.8 seconds per view, and there are about 75 blocks of data per view, (without rough gating) one can assume that the processing of one block will take about 11 ms. Since even at the fast rate the HPD cannot provide a block of data in so short a time, this means the gating and fi1tering programme will be HPD limited.
It will thus be appreciated that in all cases the main gating and fi1tering programme will be held up for lack of data. It will not therefore, be necessary to reserve a large area of store to receive data waiting to be filtered.
The utilisation of the central computer in the various cases will be as follows:-
A Fortran programme has been written for this job on the IBM 7090 and it occupies about 20K words of store, including 4K words of data. This programme will require two magnetic tape decks, one for input of the filtered data and the other for output data. It is estimated that approximately 30 hours of Atlas time will be required by this programme per year, for 100,000 events.
It is estimated that approximately 32K words of store will be required by this programme and the data; and 140 hours of Atlas time will be used per year for 100,000 events. Two tape decks will be utilised, one for input of data, and the other to keep a permanent record of the output. Output will also be provided on a line printer, printing being carried out by the Supervisor from information stored on the permanent record tape.
| Mean Weekly Duration (Hours) |
% Utilisation |
Mill Time |
Blocks | Block Hours |
Tape Units |
Tape Unit Hours |
|
|---|---|---|---|---|---|---|---|
| Slow HPD - no rough gating | |||||||
| Input | 33.0 | 3.0 | 1.0 | 2 | 66 | ||
| Gating and Filtering | 33.0 | 4.0 | 1.3 | 12 | 396 | 2 | 66.0 |
| Spatial Reconstruction | 0.6 | 100.0 | 0.6 | 40 | 24 | 2 | 1.2 |
| Kinematics | 2.8 | 100.0 | 2.8 | 64 | 180 | 2 | 5.6 |
| Total | 5.7 | 666 | 73.0 | ||||
| Fast HPD - no rough gating | |||||||
| Input | 11.0 | 8.6 | 1.0 | 2 | 22 | ||
| Gating and Filtering | 11.0 | 11.5 | 1.3 | 12 | 132 | 2 | 22.0 |
| Spatial Reconstruction | 0.6 | 100.0 | 0.6 | 40 | 24 | 2 | 1.2 |
| Kinematics | 2.8 | 100.0 | 2.8 | 64 | 180 | 2 | 5.6 |
| Total | 5.7 | 358 | 29.0 | ||||
| Slow HPD - with gating | |||||||
| Input | 33.0 | 1.0 | 0.3 | ||||
| Gating and Filtering | 33.0 | 1.4 | 0.5 | ||||
| Spatial Reconstruction | 0.6 | ||||||
| Kinematics | 2.8 | ||||||
| Total | 4.2 | 666 | 73.0 | ||||
| Fast HPD - with gating | |||||||
| Input | 11.0 | 2.9 | 0.3 | ||||
| Gating and Filtering | 11.0 | 3.8 | 0.3 | ||||
| Spatial Reconstruction | 0.6 | ||||||
| Kinematics | 2.8 | ||||||
| Total | 4.2 | 358 | 29.0 | ||||